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