[ncc-services-wg] Re: [db-wg] X.509 authentication in the RIPE Database, take II

Joao,

Joao Luis Silva Damas wrote:
> 
> adding a new strong authentication method to the Database, is in my own 
> personal opinion, a good thing(tm), particularly if the same credential 
> can be used for other interactions with the RIPE NCC, make user's life 
> easier.
> 
> I wonder however about a few questions:
> 
> - will this auth method be available only to RIPE NCC members? Is it not 
> seen as a valuable general addition for non-member users of the IRR part 
> of the RIPE DB?

Initially it will only be available for RIPE NCC members.  There are 
three ways we could extend the service to non-LIRs:

1. Accept certificates from certain "well-known" CAs, for example 
Thawte, Verisign, etc.

2. Issue certificates from a RIPE NCC CA established for this purpose, 
and accept them.

3. Accept all certificates, including self-signed certificates.

#1 is relatively easy - the main overhead would be maintaining the 
Certificate Revokation Lists from the CAs.  Deciding which CAs to 
support may also be tricky.  #2 is also relatively easy, since we 
already have the technology.  #3 is more difficult, and would require 
a slight change of the design, and administration issues (see below).

> - Why the choice of not publishing the pulic part of the certificated in 
> the DB? The choice to have a key-cert for the PGP method was not to do 
> with issues of web of trust but rather for purposes of helping the users 
> with their data maintenance. As a matter of fact the recommendation 
> regarding the use of PGP in the RIPE DB, as described in the RFC and the 
> minutes of the DBSEC TF, was to use a PGP key for this purpose that was 
> not used elsewhere.

When you receive a PGP-signed message, you need the public key of the 
signer to verify the signature.  The program that updates the Database 
needs this information, and it is stored in the key-cert objects(*).

With S/MIME, the certificate is sent with the message, and this 
certificate is signed by the CA.  Since the database is configured to 
  know how to verify certificates issued by specific CAs, we can 
verify the signature.  No key-cert is necessary.

But if we decide to allow any certficate, including self-signed, then 
we need some way to allow users to store this information in the 
database, for example key-cert objects.  Unfortunately, this may cause 
problems, because (for instance) someone could create a key-cert 
object for a CA run by another organisation with bogus data, 
preventing users from using certificates *actually* issued by that CA.

We could possibly require these sort of key-cert objects be reviewed 
by some method, for example RIPE DBM.  However, if the RIPE NCC has no 
relationship with the CA, we have no real way to know the validity of 
any one request.

> - will the RIPE NCC make avaiable, at the time of implementation, 
> documentation to guide use of this feature by users with a couple of the 
> most popular clients?

We are planning on including documenting use for popular clients as 
part of our research into S/MIME compatibility.  This is expected 
before we add X.509 support for the RIPE NCC hostmasters.  I would 
rather not delay implementing the X.509 authentication to the Database 
for this.

-- 
Shane Kerr
RIPE NCC

(*) We used to also maintain a GnuPG key ring with this information, 
but now we build a temporary key ring each time we verify a signature, 
to avoid data synchronisation issues.