Ok.
RFC 5820 is clear (not necessarily cristal clear) but anyway:
1: Read the introduction about extensions. In short and by doing some boolean
logic manip:
If you know how to treat an extension, the criticality bit is irrelevant for
the verification.
Since the implementation in question knows about BC, it should never ever look at the critbit in
*ANY* cert. It just looks whether it is a CA, and if path length is ok.
2: The verification algorithm is outlined in detail. Look at the input. It is basically a public
key+algo + an identity. Not a cert. No extensions, etc.
One should be able to use X509 version 1 cert as a container for the root
pubkey.
On 10/12/2023 04:17, Phil Smith III wrote:
Peter Sylvester wrote, in part:
T
what is suggesting this?
If by "this" you mean "what is suggesting 'But this doesn't seem to be true until we
add the TLSv1.3 support'" then it's that the old version, which doesn't do TLSv1.3, didn't get
the BC error with the
You wrote that there is a suggesting to reject non-pkix conformant certs. Where is that? Not in the
path verification.
Does you product work with TLS 1.2?
Yes. Has for years. Both old and new versions.
Good.
So to recap, my perception is that if the client doesn't say "I can do
TLSv1.3", BC doesn't matter; if it does say so, BC matters.
I think you should ask IBM about this change in behaviour.
I have not followed the CA forum btw. I prefer to go to the beach (200m) or
the alpes (25km) :-)
best
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
