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.