>
> 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
