Dear Wilfried, "CERT-COORD", Please find some comments resulted from NCC DB Group discussion below. Have a nice meeting in Barcelona! Regards, Andrei Robachevsky DB Group Manager RIPE NCC "Wilfried Woeber, UniVie/ACOnet" wrote:

[snipped...]

* irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [look-up key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [ ] auth: [mandatory] [multiple] [ ] * mnt-cert: [mandatory] [multiple] [ ] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] * signature: [mandatory] [multiple] [] * encryption: [mandatory] [single] [] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]

- The irt: attribute assigns a unique name to an IRT object.

Q: [to the NCC DB group] in your example, the IRT: attribute's value looks like a handle, and it is used like a handle in references. Wouldn't it be "cleaner" to allow person: and role: like identifications and assign a handle, which is then used to as a reference?

The value of the "irt:" attribute is a handle, much like a mntner one.

Q: Another issue: assuming that a similar facility becomes available in other registry databases, should we try to "reserve" a handle-suffix for those handles? The use of "RIPE-CERT" got me wondering...

We can reserve ..-IRT if we don't want to maintain them as "globally unique". In such case possible solution could be to reserve prefix containing both "source" and "IRT". Something like MG1-RIPE-IRT.

- The mnt-cert: attribute points to a key-cert: object; it is checked when this irt object is added to e.g. an inetnum:.

For all objects that support a pointer to an irt: object, a new attribute is defined as a reference pointing to an irt: object. This attribute might be named irt-c: or incident-c:

Q: from an end-user point of view, wouldn't it be more "obvious" to use abuse-c: ?

irt-c: seems to be a broader term than abuse-c:. In the role object, we have an attribute "trouble" which can point to URL's, e-mail addresses, etc. In fact, free text is permitted. Perhaps, we could have an attribute in the irt object (or even in inetnum and route objects) called "abuse". This is for those cases that do not require strong authentication. This would also separate the usual complaints about spam from serious reports about security holes, etc.

Q: We said that as a value for the auth: attribute, only PGPKEY-<key-id> would be allowed. Do we really need both, the (restricted) auth: _and_ the mnt-cert: ?

In the initial proposal "auth" was the "all purpose" attribute. It referenced key-cert object which was used to authorize additions of "irt-c", for signing messages from the IRT as well as for encrypting them when being sent to the IRT. If we feel that one key-cert is not enough, then I would propose that it has the same meaning as "auth" attribute in the mntner object. In this case we don't need "mnt-cert" attribute. And we don't need to restrict it to PGP-KEY authorization only, just relying on IRT's wisdom. We also have a more radical proposal aiming at reducing the number of security related attributes in the irt object (mnt-by, mnt-cert, auth, signature, encryption). The idea is to get rid of "auth" and "mnt-cert" attributes and instead add the maintainer that protects the irt object to the list of inetnum's mnt-by list. This will probably make the object and roles of the attributes more clear.

- The signature: attribute points to a key-cert: object which defines one or more keys that are user by the CERT's team members to sign and/or encrypt messages sent by the team.

- The encryption: attribute points to a key-cert: object which defines the key that should be used to sign and/or encrypt messages sent to the team.

Having multiple key-cert references makes it harder to figure out which key-cert is for signature is which is for encryption in the output of default object lookup (if we decide to include referenced key-certs in the output, as it was in the initial proposal).

Q: should we try to find a more "obvious" name for those tags? I could think of sig-from: and encrypt-to: (similar to SMTP mail from and rcpt to :-) or even from-irt: and to-irt:

Wilfried.