Re: Question about pathlen extension checked
Hi, Thanks for the replies, it's very much appreciated. It takes careful reading of RFC 3280 if you don't want to miss the crucial distinction between intermediate certificate on the path and certificate on the path - thanks for the highlighting. My conclusion from all this is that the many certs with CA:TRUE and pathlen:0 are not conformant, but not able to operate as CAs, either. Right? Interesting that there are so many, tho. Thanks, Ralph -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: Question about pathlen extension checked
My reading of RFC 3280/5280 and from implementation experience with NSS, CryptoAPI, OpenSSL, and other implementations is that no, that is not correct. CA:TRUE with a pathlen:0 is conformant to RFCs 3280/5280. The most common cause for this would be for a CA certifying an intermediate, but that intermediate should not be allowed to further mint new intermediates. The intermediate will be flagged with CA:TRUE, pathlen:0. CA:FALSE with a pathlen:anything is non-conformant. CA:TRUE with pathlen omitted indicates there are no constraints on the length of the path (pathlen: -1). basicConstraints MUST NOT be omitted for CA certificates (or more aptly, certificates which sign other certificates). It MUST be present and MUST be critical. basicConstraints MAY be omitted for end-entity certificates, and if present, it MAY be critical. The absence of basicConstraints is the same as CA:FALSE with no pathlen. Again, CA:TRUE, pathlen:0 = A CA certificate that can mint any number of certificates, but none of those certificates may be used to sign other certificates (aka: no certificate issued may be used as an intermediate) -Original Message- From: dev-tech-crypto-bounces+ryan- mozdevtechcrypto=sleevi@lists.mozilla.org [mailto:dev-tech-crypto- bounces+ryan-mozdevtechcrypto=sleevi@lists.mozilla.org] On Behalf Of Ralph Holz (TUM) Sent: Tuesday, September 20, 2011 1:51 PM To: mozilla-dev-tech-cry...@lists.mozilla.org Cc: mozilla's crypto code discussion list Subject: Re: Question about pathlen extension checked Hi, Thanks for the replies, it's very much appreciated. It takes careful reading of RFC 3280 if you don't want to miss the crucial distinction between intermediate certificate on the path and certificate on the path - thanks for the highlighting. My conclusion from all this is that the many certs with CA:TRUE and pathlen:0 are not conformant, but not able to operate as CAs, either. Right? Interesting that there are so many, tho. Thanks, Ralph -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Restricting which CAs can issue certs for which hostnames
On 2011/09/01 06:12 PDT, Sean Leonard wrote: Looks like there is some discussion on mozilla.dev.security; I wanted to respond from more of an NSS point of view. On 8/30/2011 9:46 AM, Boris Zbarsky wrote: I was looking at our CA root list, and a lot of them seem like specialist CAs that would only issue certs for a limited range of hostnames. Could we formalize this, and have CAs indicate any such restrictions as part of their application, then enforce it on our end? The proper way to enforce this is through the Name Constraints extension, which is a part of the PKIX profile for certificates. See RFC 5280, section 4.2.1.10, http://www.apps.ietf.org/rfc/rfc5280.html#sec-4.2.1.10, and section 6.1.1, http://tools.ietf.org/html/rfc5280#section-6.1.1. Note that while it is part of the standard, it is not required to be implemented. It seems that the time has finally come to implement it. Yes, the time has come for CA's to start constraining their subordinates using name constraints. If Mozilla operated an uber-root CA, cross certifying the CAs that now appear in Mozilla's trusted CA list, rather than including those CAs' self-signed roots, Mozilla could impose name constraints on each and every one of those CAs. [snip] My own estimate is that it would take a developer with a high degree of familiarity with NSS approximately one and a half man-months, plus an additional man-month for testing. NSS already fully supports RFC 3280 name constraints. Has for a long time. Name constraints extensions in CA certs are rare things indeed. [snip] A lot of people like to complain that there are hundreds of roots in their browser stores. But this is not really true. There is only one trust anchor that matters for 99.9% of the population: the browser vendor itself (Mozilla). A more appropriate way to think about it is that Mozilla/the cert repository maintainers operate the main trust anchor, but have traditionally lacked the tools or the will to enforce fine-grained constraints on the CA certificates in the stable. Agreed. Tools are not lacking, IMO. Mozilla has said it doesn't want to operate its own Uber-CA. But as you noted, operating its own root CA list is quite equivalent. [snip] I suggest continuing this discussion in m.d.security.policy. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
