RFC 2726 (rfc2726) - Page 2 of 11
PGP Authentication for RIPE Database Updates
Alternative Format: Original Text Document
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