At 12:29 PM +0100 2/1/09, Ian G wrote: >On 31/1/09 17:08, Paul Hoffman wrote: >>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?
No. The certificate is not expired, and it is not revoked. Saying so is a lie. Trusted implementations should not lie, particularly when the lie comes from their own inabilities. > 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. It is drastic, but it is honest. >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". Not curious. See RFC 2119 for the definition of "MUST". There is no interoperability issue with having this be lower-case "needs to". > 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. Correct. >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. It is discouraging that the people who run CAs don't understand the standards that they are supposedly upholding. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
