[db-wg] Database Modifications for X.509 Support

The proposal is good and sane.

Just a comment on the references you quote re: PGP keys IDs.
Both these issues were known at the time and considered by the people 
that contributed to the RFC that defines the key-cert object for us 
with PGP.

It was deemed that for the uses made of PGP keys in the RIPE DB the 
chances of a collision were low enough to be acceptable (how many keys 
are there in the DB today?)

The chance of spoofing was a problem with PGP2.6.2 and earlier and this 
is why everything in the documents mentions PGP 5.x or later should be 
used, probably not an issue these days.

Last, since the key-cert object is defined in an RFC, I would like the 
proposal to be put into an RFC as an update to the current one.

Joao

On 12 Jan, 2004, at 13:05, Shane Kerr wrote:

> 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 at 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 at ripe.net
> mnt-by:       RIPE-DBM-MNT
> changed:      ripe-dbm at 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