I have a somewhat generic question regarding verifying CRL signature, which is not specifically wrt Netscape or Mozilla, but it is crypto related, so I was hoping that someone here could provide some guidance... My apologies in advance, as I know that this is off-topic...
My understanding is that CRLs are signed by the CA.
They're signed by SOME ca. In the simplest model, the same CA that issues the certs issues the CRL for those certs. But the PKI standards permit a CA to delegate the CRL issuance task to another CA. The certs tell the verifier where/how to get the relevant CRL (or OCSP). The CRL itself names its own issuer. The signature on the CRL is checked using its issuer's cert, just as the signatures on the EE certs are checked using their respective issuers' certs.
In our case, we have a 2-level CA hierarchy, with a root CA, and a sub-root CA. The sub-root CA is issuing both client and server certs, and thus the sub-root CA also produces a CRL.
I'm assuming that in the above scenario, the sub-root CA, and not the root CA, signs the CRL with its private key. I believe that this is correct.
Your setup sounds like *one* of the correct ways of doing it. There are lots of details to get right, such as the cert extensions that tell the verifier where to find the CRL, without which the verifier might not even be checking the CRL at all.
Now, our server is using the CRL from the sub-root CA for checking for client certificate revocation. But, in order to check the signature of the CRL from the sub-root CA, doesn't the server need the sub-root CA's certificate?
In order to check the signature on the CRL, the verifier needs the cert of the CRL's issuer, who may or may not be the same as the CA that issued the certs whose revocation is being checked.
The reason that I'm asking this is that I did an experiment:
1) Originally, I had the CRL and the certs from both the root CA and the sub-root CA installed on our server, which is configured for both client and server authentication, and everything was working fine.
2) I then removed the sub-root CA cert completely from the server. This, I thought, would break the chain of trust, and more specifically,
would cause the server to no longer be able to use the CRL, since it
couldn't check the CRL signature.
3) I was kind of surprised that even after removing the sub-root CA cert from the server, everything still seemed to be working, including the server checking the revocation status of client certs.
Let's assume for the sake of this discussion that you did indeed remove
the CA cert that is needed to verify the CRL's signature from a running
server's permament store of certificates (as opposed to from its in memory
store of certs, whose contents change with each new incoming SSL client
authentication), without restarting that server. The server has probably already checked the signature on the CRL once, and remembered that result.
The server need not check the signature on the CRL over and over. So, the server can remember that the CRL is valid even after the CRL's issuer CA
cert is removed.
If the authenticating SSL clients are following the SSL3 orTLS standards they will send in not only their EE certs, but also the cert chain for their EE certs, including the issuer of their EE cert. So, at the time that the server goes to validate the client's cert and cert chain, it probably has a copy of the CA cert that issued the client's EE cert, which just happens to be the same CA cert that issued the CRL. So, the cert is available for whatever needed purposes for the course of the EE cert verification.
I guess that "where I am" is that I'm coming close to the conclusion
that the server is not checking the CRL signature,
I wouldn't guess that.
> but I keep wondering
if there may some other possible way that the server could be getting the public key of the sub-root CA for doing CRL signature checking?
I hope that someone might be able to clarify this...
If the CRL's issuer was NOT also the EE certs' issuer, and you removed the CRL issuer's cert, AND you restarted the server process, so that it could not have a previous copy still in memory, and it STILL worked, then I'd say something's fishy. But as long as the server has access to the CRL issuer's cert (e.g. because the clients are sending it in), and as long as it is possible that the CRL's signature was validated before you removed the issuer's cert, then I don't think you can conclude that the CRL's signature is going unchecked.
/Nelson
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
