[openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[Peter Magnusson]

> trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

Yes that seems to be aligned with how the intended the path validation
algorithm should be applied, i.e. first certificate processed is the
cert of the trust anchor.  But it could be clearer, and wording
"recommended" (lowercase) does seem to imply implementers SHOULD
process trust anchor cert rather than MUST process it.

"  In Section 6.1, the text describes basic path validation.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA's name, and any
   constraints upon the set of paths that may be validated using this
   key."

...

" Where a CA distributes self-signed certificates to specify trust
   anchor information, certificate extensions can be used to specify
   recommended inputs to path validation.  For example, a policy
   constraints extension could be included in the self-signed
   certificate to indicate that paths beginning with this trust anchor
   should be trusted only for the specified policies."


> https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
> Does that address your concerns?

I think so! I'll integrate it into my tests and try to do Q/A on the
change, see if I can figure out any other edge case.

Best Regards
//P
On Mon, Oct 8, 2018 at 6:15 PM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
> > On Oct 8, 2018, at 8:47 AM, Peter Magnusson <blaufish.public.email at gmail.com> wrote:
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
>
> Well, strictly speaking, the trust-anchor is not part of the certificate
> chain in RFC5280, it is a public key and an issuer name, not a certificate
> in the chain.  However, when the trust-anchor is in the form of a self-signed
> CA certificate, one might take the view that this is a self-issued certificate
> to be included in the chain:
>
>  trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)
>
> in which case the "path lenth: 0" in the self-issed root CA cert precludes
> the root from issuing any subsidiary CAs that can in turn issue further
> EE certs.  That is perhaps reasonable, so I updated PR #7353 with
> a further commit:
>
>   https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
>
> Does that address your concerns?
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users