Re: CERT Object summary (for review in Paris)

[Andrei Robachevsky andrei@localhost]

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.