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