-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Domi,
domi wrote: > which is helpful but not exactly what I had in mind ;) You couldn’t know > this because I forgot to mention my aims. I’m trying to realise the > following scenario: > The CRL shall be kept on the server of the SSL-website and not within the > servers of the CA in order to reduce the huge amount of traffic which goes > hand in hand with the periodic CRL-update. The CRL has to be created and > signed by the CA and then send to server of the SSL-website where the CRL is > stored and can be accessed by the rest of the SSL-world. > As you can see, an environment variable goes in the right direction but > having a variable for each client of the CA is not yet ideal. > I know that this scenario is probably not realisable today but that should > not care us in the meantime. > > I’m anxious to read comments about “my” scenario or probably a solution for > my problem. I think your security model is broken. A CRL and with that the server clients can download it from is part of the chain of security of the CA. So theses servers must be on (best case) dedicated servers that are specially hardened for this usage. These servers are a (potentially outsourced) part of the CA. So the CA needs this list anyway and can incorperate it into all certificates. Letting the client set the crlDistributionPoints may lead to something like: To check if the security of www.server.net is compromised, go to www.server.net and download the CRL. But if the security of this site is compromised, you can't trust any data you downloaded from it. What you can do is something like: * The CA generates the CRLs. * The CA sends the CRLs to a (fixed) known list of external servers clients can download them from. * On signing the CA incorperates this list of CRL download servers into the certificates. * Clients that want to download the CRL contact one of these servers. The server the client contacts to download the CRL is decided on the client. Bye Goetz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFweRj2iGqZUF3qPYRAt8yAJ9KIiafdYfyVF6kUoDKLUnhIp/RbwCeNsil wQmAMl5lc0ynf6vz22zwnuc= =mbmi -----END PGP SIGNATURE----- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]