PGP Authentication for RIPE Database Updates
Extracted elements (24)
Although key ID collisions are highly unlikely, if a key-cert with the same ID as an existing maintainer's key already exists in the database, the maintainer should contact RIPE NCC and may need to generate a new key. This edge case is acknowledged but considered non-critical.
Key certificates are stored in the RIPE database rather than retrieved from public key servers, so the database remains self-consistent. A local keyring of public keys is maintained as a synchronized copy of those certificates.
Key certificates should be submitted with the minimum number of signatures (preferably only the self-signature) because the RIPE database does not communicate with public key servers. Users who need to verify trust should retrieve the certificate independently from a key server and compare fingerprint, key type, and length.
The design signs whole update messages rather than individual objects, which simplifies parsing. Signing individual objects would allow mixed-maintainer messages and on-disk signature storage but is deferred to a later phase.
The existing MAIL-FROM authentication is easily forged and CRYPT-PW exposes the password unencrypted in the update email, necessitating a stronger digital signature mechanism. PGP was chosen as the first method because it is widely deployed both inside and outside the US.
Mailer programs must not transform the signed message text (e.g., line-wrapping, tab-to-space conversion) as such transformations will invalidate the PGP signature. Only ASCII characters should be used in the update message.
PGP key certificates of both version 2.x and version 5.0 are accepted, although keys generated with version 5.0 are recommended. There is no restriction on which PGP software version was used to create the key.
A message may contain only one PGP signature. If an object's mntner requires PGPKEY authentication, the database software checks that a signature is present and that its key ID matches one of the auth attribute values.
At creation or modification of a key-cert object, the database software verifies that the certificate in the certif attribute belongs to the PGP key ID specified in the key-cert attribute; the operation is refused if these two IDs do not match.
If a mntner has multiple auth attributes with PGPKEY-<id> values, the update is accepted if the message carries a valid signature from any one of those keys.
Key-cert objects must be created exclusively via the email mechanism ([email protected]); the database software will not retrieve public key certificates from external key servers.
Key certificates submitted for creating a key-cert object must contain a self-signature of the key. Additional signatures are allowed but it is recommended to submit certificates with as few signatures as possible.
The entire update message must be PGP-signed; the database software first checks whether the message is a PGP signed message before associating the signature with submitted objects.
The method attribute must be consistent with both the prefix of the id in the key-cert attribute and the certificate in the certif attribute; if prefix and certificate are inconsistent, creation of the key-cert object is refused.
The mnt-by attribute is mandatory for the key-cert object; therefore a mntner object must exist before a key-cert object can be created. The referenced mntner must not have its auth attribute set to NONE.
When a key-cert object is deleted, the corresponding public key is also deleted from the local keyring. When modified, the old key is removed and the new certificate's key is added, but only after the update is authorized.
A new key-cert object type is defined to store maintainer key certificates. Mandatory attributes are key-cert, certif, mnt-by, changed, and source; generated attributes (set by the database software) are method, owner, and fingerpr.
The certif attribute holds the lines of the ASCII-armored key certificate in order, including PGP delimiters (BEGIN/END PGP PUBLIC KEY BLOCK). Lines are returned at query time in the same order as submitted.
The fingerpr attribute contains the hex-encoded key fingerprint, space-separated for readability, and is generated by the database software from the certificate. It enables a querier to verify the certificate without importing it into a local keyring.
The key-cert attribute has the form PGPKEY-hhhhhhhh, where hhhhhhhh is the hex representation of the four-byte PGP key ID. The PGPKEY- prefix reserves namespace for future non-PGP certificate types and distinguishes key-cert queries from person queries.
The method attribute is generated automatically by the database software and contains the name of the digital signing method (e.g., the string 'PGP'). Any method attribute submitted at creation time is silently ignored.
The mntner object is extended with a new auth attribute value of the form PGPKEY-<id>, where <id> is the hex ID of the PGP public key used for authentication. Multiple PGPKEY-<id> auth values are permitted; any one valid signature satisfies authentication.
The owner attribute is generated automatically from the PGP user IDs present in the key certificate; one owner line is created per user ID. Any owner attribute submitted at creation is ignored.
RFC 2726 addresses authentication—via strong cryptographic means (PGP digital signatures)—of transactions that add, delete, or update routing policy information in the RIPE database. Authorization of these transactions is addressed separately in RFC 2725.