Mark wrote:
As I see it it's more or less a matter of taste wether you implement such things using certificate extenstions or use the database approach. Some things to consider:Hi All,Thanks again to all here who helped me with my understanding of Certificates. It is likely that we would want to embed some additional data in client certificates to further enhance security. For example we may wish to include a (list of) IP address(es) that the client can connect from and reject those not on the list. Alternatively we could create a database of clients and their IP addresses on the server and perform a lookup based on some unique identifier in the client certificate. I would be greatful for ideas on the way to go here and how to implement it. I am trying to allow for the case that the client may have their private key lost or stolen. TIA for any help... Best Regards, Mark
- You can't modify certificate extensions, you'll have to create a new certificate if the user gets a new IP-Adress - Using certificate extensions may be preferable if you have many servers and many (changing) users since then you won't have to distribute the database to the servers - Certificate extensions may cause compatibility problems if the certificate is also to be used for other applications (like S/MIME) - With the database approach it is much easier to "outsource" the certificate creation (and renewal) process to some trusted third party CA.
IMHO certificates are for authentication and not for defining access rights. The certificate says that I am "Bernhard Fröhlich" and if you trust my CA you can trust in that. The database defines that "Bernhard Fröhlich" has access to this and that thing, so it maps a CN to access rights.
Lost or stolen certs should be handled by certificate revocation, at least that's why certificate revocation and revocation checking was implemented. But as I said, there may be people with other opinions. Or situations where immaculate theory is not the decisive factor. ;)
Hope it helps. Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26
smime.p7s
Description: S/MIME Cryptographic Signature
