Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote:
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.
Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this?
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).
For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism?
- 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.
Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726
Joao Luis Silva Damas wrote:
Why do you need to verify the certificate.
Good question. We thought about this, and talked about this here at the RIPE NCC, and realised that there is no real reason to verify the certificate, other than insuring that it matches some user-specified entry in the database (meaning a key-cert object). Not keeping certificate objects in the database fits in well with the X.509 model, but as I pointed out, has some limitations. Using certificate objects allows LIR certificates, certificates issued by $random CA, and also self-signed certificates. It does mean we'll need to modify our proposal a bit, as well as add more intelligence to the LIR Portal to maintain this data as transparently to the user as possible. We'll be sending out an updated proposal ASAP. We also decided that it makes sense to proceed with the S/MIME comparison on e-mail clients before we implement anything. We're working on this now, and will have some results before the RIPE meeting.
Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features?
I wasn't really aware that this was a goal of the DB. AFAIK, the database is not intended as a generic key repository, for instance. One of the key pieces missing from the RIPE Database is a document describing what the philosophy of the Database is. The RIPE NCC staff working in the DB group have a feeling for what parts of the philosophy are, and certainly people involved in the community for a time know the history. I'm talking about things like, "the data belongs to the users, not the RIPE NCC" and "all of the data in the database is public". I think it would be useful to have a document that describes this. If other people think this could be useful, perhaps we can convince some people to author some text for this. Volunteers? :) -- Shane Kerr RIPE NCC
On Wednesday, Aug 20, 2003, at 19:10 Europe/Amsterdam, Shane Kerr wrote:
Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features?
I wasn't really aware that this was a goal of the DB. AFAIK, the database is not intended as a generic key repository, for instance.
No, it is not, and that is a good feature, I think.
One of the key pieces missing from the RIPE Database is a document describing what the philosophy of the Database is. The RIPE NCC staff working in the DB group have a feeling for what parts of the philosophy are, and certainly people involved in the community for a time know the history. I'm talking about things like, "the data belongs to the users, not the RIPE NCC" and "all of the data in the database is public".
Perhaps, maybe an item for the agenda in 2 weeks time? Wilfried?
I think it would be useful to have a document that describes this. If other people think this could be useful, perhaps we can convince some people to author some text for this. Volunteers? :)
I am willing to contribute within my limited understanding of the DB :) Joao
participants (3)
-
Joao Damas -
Joao Luis Silva Damas -
Shane Kerr