On 31/1/09 17:08, Paul Hoffman wrote:
On 31/1/09 03:56, Kyle Hamilton wrote:
The PKIX standard can deal with problems of this extent.
If an implementation of the standard cannot, then the implementation
is nonconforming, and cannot be expected to interoperate.
Do you mean, an implementation should be able to deal with a CRL of any size?
I don't know whether it is what Kyle meant, but it is certainly what I meant.
Yep, he confirmed it in other email.
If a trust anchor has a CRL that is too large for for the implementation to
handle, the implementation MUST remove that trust anchor from its pile.
Wouldn't it be better to mark those certificates in the same way as
expired and/or revoked? If a new CRL turns up and it is now readable
(because it is smaller, or because it doesn't have any the bug in the
earlier one), it seems drastic that the software MUST have removed the
trust anchor.
I thought the whole OCSP thing was about the realisation that CRLs were
basically impractical out in userland?
You thought wrong, then.
OK.
Don't get me wrong, I'm not trying to start an argument here, but it seems
pretty tough to blame an application for not being able to cope for something
we've already moved on from.
We have not moved on from CRLs, as RFC 5280 makes clear.
OK.
On the primary question, I found this:
"... and compromise or suspected
compromise of the corresponding private key. Under such
circumstances, the CA needs to revoke the certificate."
Curiously, it doesn't say "MUST revoke". And:
" Once the CA accepts a revocation report as
authentic and valid, any query to the on-line service will correctly
reflect the certificate validation impacts of the revocation.
The way I read that RFC 5280's, revocation is a CA decision and
responsibility (and consequent liability). Which makes sense, liability
being the subject of a business arrangement between CAs, subscribers and
RPs.
A funny thing happened over at CAcert a while back. Someone asked
whether they could get their certificate, and then publish the private
key on the net as part of a demo pair in a software distro (or
something). The request was denied, but nobody could quite pinpoint why
the request should be denied.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
