Re: Policy: revoke on private key exposure
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
Re: Policy: revoke on private key exposure
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
most secure algorithms
good evening, what are currently the most secure algorithms? (also hash algorithms).. Michael -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: most secure algorithms
Michael Kohler wrote, On 2009-02-01 12:34: good evening, what are currently the most secure algorithms? (also hash algorithms).. I suggest you consult http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf Tables 2 and 2, pages 63 64, and surrounding text. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
