Welcome to the staging ground for new communities! Each proposal has a description in the "Descriptions" category and a body of questions and answers in "Incubator Q&A". You can ask questions (and get answers, we hope!) right away, and start new proposals.
Are you here to participate in a specific proposal? Click on the proposal tag (with the dark outline) to see only posts about that proposal and not all of the others that are in progress. Tags are at the bottom of each post.
Post History
I only have a working knowledge of TLS. TLS today supports name constraints, to restrict which domains a CA can issue certs for: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 I've seen ...
#2: Post edited
by
matthewsnyder
·
2024-03-05T16:33:55Z (9 months ago)
- I only have a working knowledge of TLS.
- TLS today supports name constraints, to restrict which domains a CA can issue certs for: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10
I've seen people claim that certain software doesn't support this feature: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 I think that NCs were not always part of the standard, or at least not always commonly used in the past, so it would not surprise me if there's legacy software out there that pretends they don't exist.- Suppose that:
- 1. User navigates to `https://example.com`
- 2. Host presents TLS cert signed by Acme Root CA
- 3. User has Acme Root CA installed
- 4. However, the installed cert has a name constraint that does not allow it to sign `example.com`
- 5. The user's program does not have proper support for name constraints
- What will happen? Will the cert be refused or accepted?
- I understand it's not possible for answers to have comprehensive knowledge of every TLS misimplementation out there. I am asking:
- * What is the logical way to future proof TLS code against future features like NCs?
- * What is common practice for TLS devs dealing with possible future features?
- * Does TLS itself have any built-in mechanism for handling new features that did not exist when a given client was developed?
- Basically, what I'm trying to understand is: When I use NCs, is legacy or poorly developed software very vulnerable because they did not explicitly handle NCs, or will it probably fail gracefully?
- I only have a working knowledge of TLS.
- TLS today supports name constraints, to restrict which domains a CA can issue certs for: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10
- I've seen people claim that certain software doesn't support this feature: https://serverfault.com/questions/670725/is-it-possible-to-restrict-the-use-of-a-root-certificate-to-a-domain/764699#comment1029498_764699 I think that NCs were not always part of the standard, or at least not always commonly used in the past, so it would not surprise me if there's legacy software out there that pretends they don't exist.
- Suppose that:
- 1. User navigates to `https://example.com`
- 2. Host presents TLS cert signed by Acme Root CA
- 3. User has Acme Root CA installed
- 4. However, the installed cert has a name constraint that does not allow it to sign `example.com`
- 5. The user's program does not have proper support for name constraints
- What will happen? Will the cert be refused or accepted?
- I understand it's not possible for answers to have comprehensive knowledge of every TLS misimplementation out there. I am asking:
- * What is the logical way to future proof TLS code against future features like NCs?
- * What is common practice for TLS devs dealing with possible future features?
- * Does TLS itself have any built-in mechanism for handling new features that did not exist when a given client was developed?
- Basically, what I'm trying to understand is: When I use NCs, is legacy or poorly developed software very vulnerable because they did not explicitly handle NCs, or will it probably fail gracefully?
#1: Initial revision
by
matthewsnyder
·
2024-03-05T16:33:35Z (9 months ago)
What happens to TLS name constraints when the client does not support them?
I only have a working knowledge of TLS. TLS today supports name constraints, to restrict which domains a CA can issue certs for: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 I've seen people claim that certain software doesn't support this feature: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10 I think that NCs were not always part of the standard, or at least not always commonly used in the past, so it would not surprise me if there's legacy software out there that pretends they don't exist. Suppose that: 1. User navigates to `https://example.com` 2. Host presents TLS cert signed by Acme Root CA 3. User has Acme Root CA installed 4. However, the installed cert has a name constraint that does not allow it to sign `example.com` 5. The user's program does not have proper support for name constraints What will happen? Will the cert be refused or accepted? I understand it's not possible for answers to have comprehensive knowledge of every TLS misimplementation out there. I am asking: * What is the logical way to future proof TLS code against future features like NCs? * What is common practice for TLS devs dealing with possible future features? * Does TLS itself have any built-in mechanism for handling new features that did not exist when a given client was developed? Basically, what I'm trying to understand is: When I use NCs, is legacy or poorly developed software very vulnerable because they did not explicitly handle NCs, or will it probably fail gracefully?