crypto/x509: don't count self-signed certs in pathlen budget

[cpu]

RFC 5280 §4.2.1.9 when spec'ing Basic Constraints and the pathLenConstraint for the 5280 profile says (emphasis mine):

In this case, it gives the maximum number of non-self-issued intermediate
certificates that may follow this certificate in a valid certification path

This is tested by the x509-limbo pathlen::self-issued-certs-pathlen testcase.

Go crypto/x509 should not include self-issued intermediates in the path len budget when evaluating this constraint.

Relates to #65085 & https://go-review.googlesource.com/c/go/+/783980

[gabyhelp]

Related Issues

• crypto/x509: don't apply name constraints to non-terminal self-issued certs #79746
• crypto/x509: can set pathlen in certificate when not CA #38216 (closed)
• crypto/x509: reject end-entity certs w/ name constraint ext. #79742
• crypto/x509: reject CA w/ empty subject #79744
• crypto/x509: AuthorityKeyId on self-signed certificates #15194 (closed)
• crypto/x509: disallow negative path length #60706 (closed)
• crypto/x509: Certificate.Verify does not enforce name constraints correctly #59171 (closed)
• crypto/x509: ParseCertificate returns a certificate with MaxPathLen of -1 if pathLenConstraint is not set #19285 (closed)
• crypto/x509: reject misencoded empty EKU #79743

Related Code Changes

• crypto/x509: disallow setting MaxPathLen without IsCA

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[AGWA]

OTOH, the spec-conformant behavior is pretty unintuitive and neutralizes the security value of pathlen, since an attacker who can get the CA to sign arbitrary data (or exploit a hash collision) can now mint themselves a usable CA:TRUE certificate even if the CA has pathlen:0. I think it would be pretty reasonable for Go to keep the noncomformant behavior, unless there's actually a need for the conformant behavior in the WebPKI. Note mozilla::pkix deliberately chose the nonconformant behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=926265

[cpu]

I think it would be pretty reasonable for Go to keep the noncomformant behavior,

I find this argument sensible 👍 I'll close this issue and update the x509-limbo exception with rationale.

Thanks for the input.