3 ms·

In this scenario, most (not all) stacks will stop when they reach ISRG Root X1, which is trusted because it's in your trusted roots store. You're correct, ther

In this scenario, most (not all) stacks will stop when they reach ISRG Root X1, which is trusted because it's in your trusted roots store. You're correct, there is no reason to continue validating because we have run into a cert that is explicitly trusted. That should be fine. The chain only needs to continue until it hits an explicitly-trusted cert. My recollection of the TLS RFC is that it will stop there. In fact, the Certificates message doesn't even need to have an ordered chain, and the entire chain doesn't even have to be relevant. You can have your end entity cert, some random irrelevant intermediate, the root cert, and then the intermediate and (again, this is from memory, it's been a while since I actually read it carefully) RFC says that you just must be able to build and verify the cert path up to a trusted root by finding all the intermediates in that list of certs. The fact that some software stacks also happen to insist that that final step lands on a self-signed cert is the problem that will cause this cert validation to continue up the chain past ISRG Root X1 and blow up at the expired DST Root CA X3. It's not wrong because it's validating the expiration date on the root cert, it's wrong that it's ever reaching that root cert at all. If you have references that say I'm wrong about this, I'm honestly interested. I just don't think the solution to this type of problem is ignoring the expiration dates, I think it's pushing out a trusted cert that's further down the chain, a la ISRG Root X1.

tialaramex 5y ago
> In this scenario, most (not all) stacks will stop when they reach ISRG Root X1, which is trusted because it's in your trusted roots store. That isn't what you wrote. Machine don't do "What I really meant", only what you actually wrote. Unfortunately the people who programmed libraries like OpenSSL had the same attitude as you (until e.g. OpenSSL 1.1), and so in about a week a bunch of people are going to reget that. > My recollection of the TLS RFC is that it will stop there. The TLS RFCs don't offer any opinion about how you should make trust decisions. Accordingly even before RFC 8446 was finished, the most important clients (the web browsers) treat Certificates as one end-entity certificate plus some number of other documents which might be useful or might be irrelevant. This also makes them robust against the most common misconfiguration which is failure to provide the intermediates. Since they don't care they will soldier on anyway, either by AIA chasing or, in the case of Firefox, by including the entire set of trusted unconstrained intermediates in every install. > The fact that some software stacks also happen to insist that that final step lands on a self-signed cert is the problem that will cause this cert validation to continue up the chain past ISRG Root X1 That's not really key. They just don't stop, the self-signed certificates are a coincidence not a necessary element. > If you have references that say I'm wrong about this, I'm honestly interested. What does it mean to be "wrong"? I'm sure you will continue to believe you were correct, and yet the exact steps you wrote down are going to blow up for people in just a few days. As a programmer, I call that "wrong" but I'm quite sure you feel you weren't wrong at all, just misunderstood.
- hamburglar 5y ago
  > That isn't what you wrote. Machine don't do "What I really meant", only what you actually wrote. This isn't code for a machine, it's a conversation. If you interpreted it in a way that sounds broken to you, please tell me exactly how and I'll either clarify or learn something new. All I'm doing is casually describing the RFC, and yes, I may have stated something ambiguously or incorrectly. Help me out here. Are you saying the RFC describes a bad algorithm or that I've described it badly? > The TLS RFCs don't offer any opinion about how you should make trust decisions The TLS RFCs refer you to RFC 5280 for validation, which does explicitly specify the algorithm. > I'm sure you will continue to believe you were correct, and yet the exact steps you wrote down are going to blow up for people in just a few days I'm not seeing how my steps will blow up, although the phrase "eventually end in a valid cert that you trust a priori" could be interpreted differently than I meant it. "Eventually end in" here is referring to the validation algorithm ending, not the cert chain. Can you elaborate on how you think this algorithm fails? > As a programmer, I call that "wrong" but I'm quite sure you feel you weren't wrong at all, just misunderstood. Could I ask you to be a little less aggressive in this conversation? We aren't having a fight here. Edit: I think we're actually in violent agreement here. Your statement "But wait, after step 2 we reached ISRG Root X1, which we know is trustworthy. We were actually done!" is exactly my point. You don't need to ignore the expiration date on the old root if you have issued a new trusted authority below that root and the validation can stop there. You aren't ignoring the expiration on the old root, you're ignoring the entire old root cert because you found a new trusted cert that supercedes it. if you did still have an end entity cert that was issued via a path to the old root that did not include the newer, explicitly trusted cert lower down the chain, THAT end entity validation would fail.

tialaramex 5y ago

> In this scenario, most (not all) stacks will stop when they reach ISRG Root X1, which is trusted because it's in your trusted roots store. That isn't what you wrote. Machine don't do "What I really meant", only what you actually wrote. Unfortunately the people who programmed libraries like OpenSSL had the same attitude as you (until e.g. OpenSSL 1.1), and so in about a week a bunch of people are going to reget that. > My recollection of the TLS RFC is that it will stop there. The TLS RFCs don't offer any opinion about how you should make trust decisions. Accordingly even before RFC 8446 was finished, the most important clients (the web browsers) treat Certificates as one end-entity certificate plus some number of other documents which might be useful or might be irrelevant. This also makes them robust against the most common misconfiguration which is failure to provide the intermediates. Since they don't care they will soldier on anyway, either by AIA chasing or, in the case of Firefox, by including the entire set of trusted unconstrained intermediates in every install. > The fact that some software stacks also happen to insist that that final step lands on a self-signed cert is the problem that will cause this cert validation to continue up the chain past ISRG Root X1 That's not really key. They just don't stop, the self-signed certificates are a coincidence not a necessary element. > If you have references that say I'm wrong about this, I'm honestly interested. What does it mean to be "wrong"? I'm sure you will continue to believe you were correct, and yet the exact steps you wrote down are going to blow up for people in just a few days. As a programmer, I call that "wrong" but I'm quite sure you feel you weren't wrong at all, just misunderstood.

hamburglar 5y ago
> That isn't what you wrote. Machine don't do "What I really meant", only what you actually wrote. This isn't code for a machine, it's a conversation. If you interpreted it in a way that sounds broken to you, please tell me exactly how and I'll either clarify or learn something new. All I'm doing is casually describing the RFC, and yes, I may have stated something ambiguously or incorrectly. Help me out here. Are you saying the RFC describes a bad algorithm or that I've described it badly? > The TLS RFCs don't offer any opinion about how you should make trust decisions The TLS RFCs refer you to RFC 5280 for validation, which does explicitly specify the algorithm. > I'm sure you will continue to believe you were correct, and yet the exact steps you wrote down are going to blow up for people in just a few days I'm not seeing how my steps will blow up, although the phrase "eventually end in a valid cert that you trust a priori" could be interpreted differently than I meant it. "Eventually end in" here is referring to the validation algorithm ending, not the cert chain. Can you elaborate on how you think this algorithm fails? > As a programmer, I call that "wrong" but I'm quite sure you feel you weren't wrong at all, just misunderstood. Could I ask you to be a little less aggressive in this conversation? We aren't having a fight here. Edit: I think we're actually in violent agreement here. Your statement "But wait, after step 2 we reached ISRG Root X1, which we know is trustworthy. We were actually done!" is exactly my point. You don't need to ignore the expiration date on the old root if you have issued a new trusted authority below that root and the validation can stop there. You aren't ignoring the expiration on the old root, you're ignoring the entire old root cert because you found a new trusted cert that supercedes it. if you did still have an end entity cert that was issued via a path to the old root that did not include the newer, explicitly trusted cert lower down the chain, THAT end entity validation would fail.