(replying via IBM-MAIN; where'd my IBMTCP-L subscription go?)
Apologies that I don't have a *solution*. But hopefully this observation
is more than just bitch-n-moan.
> The fix was to update the root certificate used by the server to add
the required Critical value for Basic Constraints (henceforth "BC" as a
shorthand).
That would seem to throw the burden on the CAs. Not your problem anymore?
As an industry, we have a problem with planned obsolescence. We think
it's healthy. (And "we" used to think smoking tobacco was healthy. Go
figure.)
Some changes as the protocols evolve (and code evolves) carry
intentional breakage, trying to force you to get away from old stuff.
(Doesn't matter if the risk from the "old stuff" is acceptable, you're a
heretic for staying back-level. We're gonna make it hurt.)
Linus Torvalds has a reputation for being hard to work with. It's been
said that he regularly berates other kernel developers ... publicly ...
with invective.
But to his credit, it's also been said that he comes down harder on
developers who break the non-kernel experience. In one example, if
people depend on a bug in your ABI, it's no longer a bug but a feature.
Carry this to TCP land: So then we're all happily up-to-date with TLS
1.2 and along comes TLS 1.3 and ... bzzzttt!!!
IBM gets an extra hour in detention over this.
They're known to follow the rules ... to a fault. I confess that I
haven't read "the rules" (e.g., RFC 5280, et al), but there have been
significant cases where other systems worked fine but the IBM system did
not. (I'm thinking of an certain problem with the AIX TCP stack versus
F5 load balancers which Phil might remember.)
Other vendors deliver wares which behave more as expected, rightly or
wrongly.
In trying to help, the question which comes to mind is: where do you see
the error? Is it on z/OS or on the other end?
And does it really help to fix the root cert? Have you uncovered a bug
in TLS 1.3? (And do the TLS 1.3 lords consider it a bug or a feature?)
-- R; <><
On 12/8/23 11:36, Phil Smith III wrote:
(Cross-posted to IBM-MAIN and IBMTCP-L)
Our z/OS product acts as a client to our non-z/OS server. As such, it makes TLS
connections to fetch Policy and keys.
As I've written previously, we had a problem when we added TLSv1.3 support to
the z/OS product, getting errors:
ERROR check_cert_extensions_3280_and_later(): Basic Constraints extension must
be critical for CA Certificate
The fix was to update the root certificate used by the server to add the required
Critical value for Basic Constraints (henceforth "BC" as a shorthand).
This happened again here this week when a certificate was updated (someone used
the wrong internal CA, which was old). Once we got it straightened out, I
started wondering why this only happened once we added TLSv1.3 support. Some
reading of RFC5280 (which obsoleted 3280) suggests that a PKIX-compliant
certificate should ALWAYS be rejected if not BC. But this doesn't seem to be
true until we add the TLSv1.3 support.
I say "seems to" because I don't have an easy way to test all combinations. The
older version of our z/OS product didn't support TLSv1.3. The changes to implement 1.3
support added three calls to the stack:
* One that says "Yeah, we do 1.3":
gsk_attribute_set_enum(pSSI->hEnviron, GSK_PROTOCOL_TLSV1_3,
GSK_PROTOCOL_TLSV1_3_ON);
* One to add the 1.3 key shares:
gsk_attribute_set_buffer(pSSI->hEnviron, GSK_CLIENT_TLS_KEY_SHARES,
"00230024002500290030", 0);
* One to add the 1.3 ciphers (I think?):
sslStatus = vsgsk_attribute_set_buffer(pSSI->hSocket, GSK_V3_CIPHER_SPECS_EXPANDED,
"C030C02FC028C027C014130113021303003500380039002F00320033", 0);
There was another change that added SNI support, but that was backported to the
old version, so I don't think it nets out as a difference between what I had
available to test. And of course the cert is fixed now, so I couldn't easily
test more if I wanted to.
Anyone (Wai? Charles?) have any domain knowledge here? Should gsk be
categorically rejecting a root certificate that claims to be PKIX-compliant, or
only if TLSv1.3 is supported?
I'm less interested in getting it fixed if it's wrong, since there's obvious significant
risk of breaking a lot of existing, working connections-plus as folks move to TLSv1.3
they'll fix it anyway-than I am in feeling that we can confidently tell customers who hit
this "Yes, that's a requirement of [TLSv1.3? TLS in general, but IBM only enforces
it for 1.3? something else?]", and not that it's a peculiarity of our
implementation. Put another way, the surprise (after reading the RFC and thinking I
understand it!) is that it breaks when it does-that a non-BC certificate ever works.
Should it?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
