RFC 2726 (rfc2726) - Page 2 of 11

PGP Authentication for RIPE Database Updates

RFC 2726      PGP Authentication for RIPE Database Updates December 1999


2. Changes to the RIPE database

   In order to make the database as much self consistent as possible,
   the key certificates are stored in the RIPE database. For efficiency
   reasons a local keyring of public keys will also be maintained,
   however, the local keyring will only contain a copy of the key
   certificates present in the database. The synchronization of the
   database with the local keyring will be made as often as possible.
   The database objects will be created only via the current e-mail
   mechanism (), in particular no public key
   certificate will be retrieved from a key server by the database
   software.

   The presence of the key certificates in the database will allow the
   users of the database to check the "identity" of the maintainer, in
   the sense that they can query the database for the certificate of the
   key the database software uses for authenticating the maintainer.
   This key certificate can then be checked for existing signatures and
   can possibly be compared with the key certificate obtained by other
   means for the same user (e.g. from the owner himself of from a public
   key server). Although the key certificates can be stored in the RIPE
   database with any number of signatures, since the RIPE database is
   not communicating directly with the public key servers, it is a good
   practice to add the key certificate with the minimum number of
   signatures possible (preferably with just one signature: the one of
   itself).  See also section 4. for more details.

2.1. The key-cert object

   A new object type is defined below for the purpose of storing the key
   certificates of the maintainers:

   key-cert:  [mandatory]  [single]     [primary/look-up key]
   method:    [generated]  [single]     [ ]
   owner:     [generated]  [multiple]   [ ]
   fingerpr:  [generated]  [single]     [ ]
   certif:    [mandatory]  [single]     [ ]
   remarks:   [optional]   [multiple]   [ ]
   notify:    [optional]   [multiple]   [inverse key]
   mnt-by:    [mandatory]  [multiple]   [inverse key]
   changed:   [mandatory]  [multiple]   [ ]
   source:    [mandatory]  [single]     [ ]

   The syntax and the semantics of the different attributes are
   described below.






Zsako                       Standards Track