sub-CA's are covered by the standard CRL - they can be revoked by the top-level CA. However, nothing can revoke the top-level CA.
once again: in the case of cross certification the other CA can.
Already covered. The CRL itself defines how long it's valid for. run:
openssl crl -in file.crl -inform DER -nextupdate -noout
It will show you when the CA has defined the next update of the CRL is due. If the CA sets that interval to one month - then one month it is.
nothing is covered. i know that you can implement it in some way, it has been done. i do not say, it is impossible to do it. i'm describing you the problem with current solutions. there is a dilemma between setting this time too high and too low. the only solution is constant online check. this adds another protocol (complexity) and puts the CA('s crl) into permanent online state.
yes, i know! that's the whole point: it can't do that, this is incorrect, because in an "a posteriori check" the signatures suddently appear perfectly valid! it's a big miss for e.g. audit trials.
Huh? If the cert is past it's use-by-date, then it is no longer valid - what's the problem? There is no way it suddenly appears valid again.
ok, i actually already described it, but one last time. please forget apache servers and all this means-nothing stuff. think more generally.
Mallory got a valid certificate from a big well-known CA. She makes credit card payments by using her certificate, the payments take some time to be really debited from its account. One day the CA notices that something is wrong with Mallory and revokes her certificate. Then some short period after, Mallorys certificate gets expired anyway. The CA deletes Mallorys certificate from its CRL - like you suggest is sufficient. Now, the credit card payments signed with Mallorys certificate keep on coming in. The problem is: are those valid or not?
The correct answer is: if the payments were done before the revocation - they are correct. If the payments were done after the expiration they are of course invalid. The real problem are the payments done between the revocation and expiration. Those appear valid now (certificate was valid to the time of payment and it is not in the CRL) though they are not.
Ok?
Ah wording - I call that the PKI :-)
ok, you are probably even right... the problem is that the stand alone CA without any PKI around it - in your terminology - ain't worth nothing :) so...
What do you mean by CRLs? Do you mean all the CRLs of all the CAs in the world? No-one would ever do TLS with all the CAs. We run client-certs
now i mean one CRL of one given CA.
internally, and they are signed by our CA - no-one elses are trusted.
ok, what i say: you can do the same with a kerberos server.
Our CRL contains < 200 revokes at any one point in time - and that's 90% me testing revocation! :-)
we are talking a little bit on different levels. see, i'm in a research branch. it's not sufficient for me to know that there is a situation where some solution X perfectly works out for a while. i'm looking for solutions which scale good and always work perfectly - big or small, online or offline, have-to-be-fast or have-enough-time, etc.
of course, talking more practically, i would never doubt that there is a situation where the PKIs in their current state represent a sufficient solution. (i would however doubt that it's necessarily the best).
One thing CRLs give you is explained by the following senario:
1> Corporate network has sensible policy that remote access to the network must be protected by "strong authentication" - either token or client certs.
2> Laptop uses VPNclient software to log into corporate network over the
Internet (or WLAN...). VPN server requires client-cert plus RADIUS
authorization.
3> Laptop is stolen. Baddie uses laptop with cert to now be in a position to brute force accounts.
If the client cert could be revoked, part 3 couldn't happen...
talking about EAP/TLS here: i simply put the name of the user in the more or less obligatory RADIUS server with something like Auth-Type := Reject. that's all. from this moment on, TLS wouldn't even start - the user is denied BEFORE i exchange any complicated and CPU-heavy TLS messages. no CRLs. so: it's not an advantage of the CRLs.
See above: we use Cisco VPNclient and we do both. I agree that CRLs really don't scale over the Internet - but they scale over our world-wide WAN in 30 different countries with roaming users...
see above. "it could work in some given situation".
however, given an existing central authorization server, i don't get what you need CRLs for. in my opinion it's even theoretically more correct to let the authentication occur since you still - correctly - identify the (stolen) laptop (authentication is the proof of the identity). why should the authentication fail? it should much more say to you - "it's the laptop X" - which is true! THEN you can decide what to do with it - you think it's valid? give it basic access. you think it's the boss? give it full access or whatever. you think it's stolen? don't give it access or try to trap it.
No - I mean the concepts of a CA. The idea of TRUST. If the banks cert is compromised, how do all the banks customers find that out? How does their browser know that when they connect to https://misspelled/ that the cert protecting that server is now 0wNed by a hacker instead of the bank? That's what CRLs are good for. In fact, remember in 2001 when Microsoft discovered
i know what CRLs should be good for :-) however, Netscape does not check it and other browser don't do so neither. I don't know about IE.
that someone had managed to con Verisign into signing their cert claiming
they were Microsoft? How did Microsoft manage to update EVERY WINDOWS BOX IN
THE WORLD [yeah, right] to not trust that cert? Well they put out a security
patch with an updated CRL in it - that's how.
yes i know. it would suggest, the IE really looks it up. but in fact, it does not look up any CRL. it looks up in the local store, if the certificate is trusted or not. that's not CRL, that's ridiculous. basically comparable to SSH rejecting some public key - that's all. but packed in some nice terminology.
As we both agree to: CRLs actually don't work on the Internet scale (hence the gross kludge that M$ had to do), but they do work at the corporate level.
yes, on "some corporate level". i tend to think that the CRLs are not really existent. in the specific case of 802.1X & EAP/TLS they are not even needed :-)
Oi! Leave my personal history out of it ;-)
i knew it ;-)
ciao artur
-- Artur Hecker D�partement Informatique et R�seaux, ENST Paris http://www.infres.enst.fr/~hecker
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
