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: 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
On 2011/09/18 03:15 PDT, Ralph Holz (TUM) wrote: > does NSS check the pathlength extension in an issuing certificate? I am > particularly wondering if pathlen:0 is honoured. Yes and Yes. NSS 3.12 claims compliance with RFC 3280. -- 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
On 09/19/2011 08:34 PM, From Robert Relyea: If you really want pathlen of '0', then just set the isCA bit to FALSE;). Well wellNSS (or PSM) doesn't even accept an end user certificate with CA=TRUE as we found out recently. And that's very good IMO. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- 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
>
> On 09/18/2011 03:15 AM, Ralph Holz (TUM) wrote:
> > Hi,
> >
> > does NSS check the pathlength extension in an issuing certificate?
> yes.
> > I am particularly wondering if pathlen:0 is honoured.
> According to the spec, which means no limit. NSS limits the size of the
> total chain to prevent loop attacks, so in practice you can't have an
> 'infinite' pathlen, but our chain limit is quite large, and you are
> likely to run into protocol issues using chains of that size.
>
> If you really want pathlen of '0', then just set the isCA bit to
> FALSE;).
>
Bob, is that a correct reading of pathlen:0?
RFCs 3280 4.2.1.10 reads:
The pathLenConstraint field is meaningful only if the cA boolean is
asserted and the key usage extension asserts the keyCertSign bit
(section 4.2.1.3). In this case, it gives the maximum number of non-
self-issued intermediate certificates that may follow this
certificate in a valid certification path. A certificate is self-
issued if the DNs that appear in the subject and issuer fields are
identical and are not empty. (Note: The last certificate in the
certification path is not an intermediate certificate, and is not
included in this limit. Usually, the last certificate is an end
entity certificate, but it can be a CA certificate.) ***A
pathLenConstraint of zero indicates that only one more certificate
may follow in a valid certification path.*** Where it appears, the
pathLenConstraint field MUST be greater than or equal to zero. Where
pathLenConstraint does not appear, no limit is imposed.
An absent pathLenConstraint means "unlimited", but a pathLenConstraint of 0
is "0 or 1 more certs". (Emphasis in ***)
RFC 5280 4.2.1.9 tweaks the text, with the following change to the starred
text:
A pathLenConstraint of zero indicates that no non-
self-issued intermediate CA certificates may follow in a valid
certification path.
This just restates the same requirement - the chain from a CA with a pathLen
of 0 must terminate in the issued cert - it may not contain any
intermediates.
Further, in context of Ralph's conversations on the Cryptography mailing
list, the pathLenConstraint only matters if cA is TRUE. cA being FALSE and
asserting pathLenConstraint makes no sense/is not conformant. For that, see
the remainder of 4.2.1.10/4.2.1.9:
CAs MUST NOT include the pathLenConstraint field unless the cA
boolean is asserted and the key usage extension asserts the
keyCertSign bit.
So if you're looking at certs, they assert cA is TRUE, and have a pathLen of
0, they MAY be used to issue certificates with cA FALSE ("end-entity
certificates"), but MAY NOT be used to issue certificates with cA TRUE
("intermediates").
--
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
On 09/18/2011 03:15 AM, Ralph Holz (TUM) wrote: Hi, does NSS check the pathlength extension in an issuing certificate? yes. I am particularly wondering if pathlen:0 is honoured. According to the spec, which means no limit. NSS limits the size of the total chain to prevent loop attacks, so in practice you can't have an 'infinite' pathlen, but our chain limit is quite large, and you are likely to run into protocol issues using chains of that size. If you really want pathlen of '0', then just set the isCA bit to FALSE;). bob 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
Yes. NSS has two different ways to verify certificates - "original" and libpkix (the new way). Firefox uses "original" (as probably do most NSS apps), Chromium uses libpkix. "Original" source pointer: http://mxr.mozilla.org/mozilla/source/security/nss/lib/certhigh/certvfy.c?ma rk=514,519,527,531,532#505 libpkix source pointer: http://mxr.mozilla.org/mozilla/source/security/nss/lib/libpkix/pkix/certsel/ pkix_certselector.c?mark=185,203-216#121 > -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: Sunday, September 18, 2011 6:15 AM > To: mozilla-dev-tech-cry...@lists.mozilla.org > Subject: Question about pathlen extension checked > > Hi, > > does NSS check the pathlength extension in an issuing certificate? I am > particularly wondering if pathlen:0 is honoured. > > 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
