> On Oct 8, 2018, at 8:47 AM, Peter Magnusson <blaufish.public.email@xxxxxxxxx> 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
