> 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"
Bonjour,
The prospective certification path excludes the Trust Anchor.
Therefore, the « max_path_length=0 » step is attained only when dealing with
your EvilCA cert.
Cordialement,
Erwann Abalea
> Le 8 oct. 2018 à 14:47, Peter Magnusson a
> écrit :
>
> That is not correct behaviour as far as
> On Oct 8, 2018, at 8:47 AM, Peter Magnusson
> 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
Tested mbedtls to see how other code bases handle thus.
mbedtls rejects the EvilCA certificate when connecting to openssl
s_server (as opposed to openssl c_client -verify that accepts the
connection).
Verify requested for (Depth 1):
cert. version : 3
serial number : 10:00
issuer name
sorry, typo on the verify line, this was what I should have written:
VERIFY(max_path_length>0) error upon preparing transition from i=2
(EvilCA) to i=2 (EvilServer).
On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
wrote:
>
> That is not correct behaviour as far as I can understand.
>
> RFC5280
That is not correct behaviour as far as I can understand.
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
It was my interpretation that 0 pathlen on the root self signed meant
infinite.
The pathlen only applies on the certs between root and the leaf (which
obviously can be 0, and CA true or not, but bad form to say true I'd
imagine.)
On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <
One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have
