> 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@xxxxxxxxxxxx> wrote: > > > 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
