All, Attached please find a description of the database modifications necessary to implement X.509 authentication in the RIPE Database. This is the outcome of previous discussions on the mailing list, presentations and discussions at RIPE meetings, and a review of the implementation details. The only new feature added is making "fingerpr:" an inverse key, which helps dbupdate lookup the appropriate X.509 key. -- Shane Kerr Software Engineering Group Manager RIPE NCC Database Modifications for X.509 Support 1. Proposal ------------- To add X.509 authentication to the RIPE Database. 2. Changes to the key-cert class -------------------------------- The key-cert class will be altered to allow both PGP and X.509 certificates to be represented. PGP certificates will remain the same. X.509 certificates will have the following attributes: - "key-cert:" will be of the form X509-nnn, where nnn is a unique number assigned by the database. (See "Primary key for X.509 KEY-CERT objects" below.) - "method:" will be X509. - "owner:" will be the Distinguished Name (DN) of the certificate. Sometimes this is called the certificate subject. - "fingerpr:" will be the MD5 fingerprint of the certificate. - "certif:" will contain the ASCII representation of the X.509 certificate. The "fingerpr:" attribute will become an inverse key. The format and meaning of all other attributes remain unchanged. Example of an X.509 KEY-CERT object: key-cert: X509-42 method: X509 owner: /C=NL/O=RIPE NCC/OU=Members/CN=eu.ripe-ncc.shane/Email=shane@ripe.net fingerpr: D5:92:29:08:F8:AB:75:5F:42:F5:A8:5F:A3:8D:08:2E certif: -----BEGIN CERTIFICATE----- certif: MIID/DCCA2WgAwIBAgICAIQwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCRVUx certif: EDAOBgNVBAgTB0hvbGxhbmQxEDAOBgNVBAoTB25jY0RFTU8xHTAbBgNVBAMTFFNv . . . certif: hZNmF5c/d0gauqvL+egb+3V+Zg+sJTzHMVKQLF1ybWgJjU75Pi+mO7BG0zsQ13pT certif: YxuZCR2W15nwt7zLiHtmfw== certif: -----END CERTIFICATE----- remarks: Sample Key Certificate notify: ripe-dbm@ripe.net mnt-by: RIPE-DBM-MNT changed: ripe-dbm@ripe.net 20040101 source: RIPE 3. Primary key for X.509 KEY-CERT objects ----------------------------------------- The "key-cert:" attribute is the primary key of KEY-CERT objects. This will be given a generated value that is the object ID. X.509 object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. For new KEY-CERT objects, the user must use AUTO-<digit> during creation of the object, it will then it will be assigned an appropriate ID. The key-cert ID cannot be reused. If a key-cert ID was used in the past by a KEY-CERT object and then deleted, this ID cannot be used in new KEY-CERT objects. Using a unique identifier is different from the PGP object IDs. In PGP, the key ID is used as part of the object ID (specified in RFC 2726). This is a 32-bit value, expressed in hexadecimal. There are several problems with this. Collisions occur (*), and keys can be spoofed (**). This is less of a problem with X.509 because it uses much longer fingerprints; however, in any system where the source of the fingerprint is passed to other users the possibility exists of a third party adding the certificate to the database. 4. Change to the "auth:" attribute ---------------------------------- The "auth:" attribute is present in MNTNER and IRT objects, and specifies the authentication scheme of the maintainer. The following additional value will be added: X509-<id> Strong scheme of authentication. This string is the same one that is used in the corresponding KEY-CERT object's "key-cert:" attribute. 5. Change to authentication --------------------------- When a maintainer specifies an X.509 KEY-CERT object the signature, using the private key associated with the certificate contained in the KEY-CERT object, will authenticate that maintainer. 6. Changes to e-mail processing ---------------------------- S/MIME messages will be accepted. S/MIME messages must not be encrypted; an encrypted message will be rejected as invalid input. Either the whole message may be an S/MIME signed message or one MIME part may contain an S/MIME signed message. S/MIME may be used fully, partially, or not at all with other authentication mechanisms. Therefore, it is acceptable to receive a message that is an S/MIME signed message which has been further signed by PGP, or an S/MIME message may be forwarded with the addition of a password at the outer level. 7. Changes to synchronous updates --------------------------------- The server will accept SSL connections with any client side certificate, this certificate will be used to authenticate any updates. (*) http://www.imc.org/ietf-openpgp/mail-archive/msg00484.html (**) http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0147.html