-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
domi wrote:
> Goetz wrote:
>
> 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.
> Hello Goetz,
>
> Thank you for your comments and critics concerning my scenario. I’m
> analysing and trying to built up this scenario by order of my professor. So
> “it doesn’t make any sense” is an acceptable result as well ;)
In the security context (and especially with certificates)
the question is not "Is it possible to do something ?" but it is
"Is it adviseable to do something ?"
What do you gain ? What risks do you get ?
> --“I think your security model is broken….”
> In this scenario the CRL shall be kept on the www.server.net. And this
> server is NOT a part of the CA’s security chain. The CA creates, signs and
> stores the CRL as usual. But in addition the CA also sends a copy of the CRL
> to www.server.net, which stores the CRL wherever it wants. (Pushing or
> pulling the CRL is not important to me.)
The crlDistributionPoints extension (roundabout) says:
"I (the CA) declare that certificates issued by me can be verified with
CRLs that can be loaded from the following addresses:..."
The server MUST in some way be part of the CA infrastructure.
It MAY be a server that is not at the same location than the CA is.
> --“But if the security of this site is compromised, you can't trust any data
> you downloaded from it.”
> For this reason the CA has to sign the CRL before sending it to
> www.server.net. When the site is compromised it won’t publish the current
> CRL. And a missing up-to-date CRL tells everbody that this site is
> compromised.
Only in your context.
In general it only says that there is (at the moment) no CRL available.
Imagine the following situation:
For some reason the CA is unable to issue a new CRL.
(Administrator forgot the passphrase, network connection to CA is down,
CA is on fire, a plane crashed into the CA,...)
With the moment the last CRL expires all sites the CA issued
certificates for become compromised (in the eyes of the clients).
> I hope this idea is not too strange and I’m not telling to much nonsense ;)
In general:
It is definitively a bad idea to let the client set a
crlDistributionPoints extension with data from the request.
The client may only set a very small subset of the possible extensions
in a certificate.
The subjectAltName extension would be a possible extension
the client may set in the request.
Guys/Girls: Any other idea what the client may set ?
> So I still have got the problem, that the certificate request shall include
> the CRL distribution point and that the CA has to “copy” it when signing the
> certificate without knowing the CRL DP in the forefront.
What you can do is to generate the extension section in
the openssl config on the fly with the crlDistributionPoint extension
parsed from the request.
This will require a small script and no change of the openssl binary.
But again:
do this only if you really know what you are doing
and only after a carefull analysis of the security requirements
of the special situation.
As far as I see it:
+ storing CRLs on each server reduces load on the CA infrastructure.
But:
* CRLs need only to be loaded once in the lifetime of a CRL
and this lifetime should be in the range of days
* as long you aren't operating a big CA CRLs are small
so the load is small.
If the lifetime of the CRL is shorter than a day or CRLs become
big you need something like OCSP.
- - assuming a server is compromised if it hasn't an actual CRL will
invalidate all certificates the moment the CA can't generate and
distribute the CRLs to the servers.
Bye
Goetz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFFwiB12iGqZUF3qPYRArKgAJoCrS/ruxsacM9j8eOoJBLfiAPnigCdHNDl
Cmo/qYhrX+0kvF/XdBIWDtU=
=AXIJ
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
