Closed Bug 554442 Opened 15 years ago Closed 15 years ago

Provide a safe way for CAs to issue name-constrained intermediate CA certificates

Categories

(NSS :: Libraries, enhancement)

Product:
NSS
Component:
Libraries
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: matt, Unassigned)

References

Details

It would be great if a Mozilla-recognized CA would be willing to give me, as the registrant of mattmccutchen.net, an intermediate CA certificate with a critical name constraint limiting it to mattmccutchen.net. That would give me unlimited flexibility to issue certificates for subdomains without bothering the CA. It currently is not safe for the CA to do so because of bug 394919: NSS honors common names without subjecting them to name constraints, so I could impersonate sites outside of the mattmccutchen.net domain. Once bug 394919 is fixed, whether by properly constraining common names or ultimately dropping support for them altogether (see bug 552346), we still have a compatibility problem. If CAs just start issuing certificates with critical name constraints, NSS versions before the fix for bug 394919 will suddenly become vulnerable, which I don't think we want. CAs need a way to issue name-constrained certificates that will be rejected by NSS versions that would handle them insecurely. I see two ways to achieve this: new roots that are only trusted by the new NSS, or a new critical extension that is only recognized by the new NSS.
(In reply to comment #0) > It would be great if a Mozilla-recognized CA would be willing to give me, as > the registrant of mattmccutchen.net, an intermediate CA certificate with a > critical name constraint limiting it to mattmccutchen.net. For testing purpose you should set up your own CA.
(In reply to comment #1) > For testing purpose you should set up your own CA. This is for real, not for testing. In the future, I might want to let other people that I don't fully trust operate secure servers at subdomains of a domain that I register. With current browsers, such a setup poses risks such as cross-subdomain cookie forcing, but I plan to address those.
You can make your own CA root trusted as for real. I suspect that no CA will give you such a certificate at the moment.
(In reply to comment #3) > I suspect that no CA will give you such a certificate at the moment. Right. I'm trying to clear what I believe is the sole technical obstacle for them to do so.
Not really, it's by the nature of an intermedaite CA certificate. You probably would have difficulty complying to the requirements for such certificate.
If the certificate is constrained to my domain, I don't see why there should be any requirement but domain validation. It's simply a more flexible alternative to a wildcard certificate.
Yes, except that it doesn't work currently for most browsers, making it effectively an intermediate CA certificate. Additionally, naming constraints will be most likely also applied to TLDs and wild cards match only the innermost space beneath the domain. E.g. *.domain.com doesn't match sub.sub.domain.com. Anyway, suggest to use your own root for this purpose.
(In reply to comment #7) > Yes, except that it doesn't work currently for most browsers, making it > effectively an intermediate CA certificate. No, they should reject the unknown critical extension. > Additionally, naming constraints > will be most likely also applied to TLDs I don't understand your point here. > and wild cards match only the > innermost space beneath the domain. E.g. *.domain.com doesn't match > sub.sub.domain.com. Indeed: a constrained intermediate CA certificate is more powerful than a wildcard certificate in that it supports multiple levels of subdomains. That's fine. > Anyway, suggest to use your own root for this purpose. It would be really great if the sites just worked for everyone. If I did use my own root, it would be unfair to ask visitors to trust it for the entire web and thereby let me impersonate other sites. Bug 501697 would let them trust it for my domain. Without that enhancement, every visitor would have to generate their own root and sign mine with a name constraint, which would be a pain.
Sorry, I thought that you requested such a certificate from a Mozilla-recognized CA for the purpose of testing the naming constraints which are in the making. Probably I misunderstood.
I have not requested a real name-constrained CA certificate. I will test bug 394919 and this bug with my own root. After this bug is fixed, I will see about evangelizing CAs to offer name-constrained CA certificates. Eddy, I'd be very thankful if you could point out any other problems you foresee at this point with domain-validated name-constrained CA certificates (of course, it would not be an official statement from StartCom). One problem is that if chains of two more certificates below the public-CA-issued one are allowed, then the registrant can put a misleading Organization value in the lowest CA cert and have it appear in the SSL badge tooltip. For example: "Some Mozilla-recognized CA" \_ "Matt's CA" (name constraint: mattmccutchen.net) \_ "your evil twin" \_ foo.mattmccutchen.net +------------------------------+ +-----------------------------+ | [icon] foo.mattmccutchen.net | ---> | Verified by: your evil twin | +------------------------------+ +-----------------------------+ Maybe I will enter a separate bug for this.
The CA would have to constraint the path length too. You also asked about constraining TLDs, this use-case is foreseen to limit certain CAs to specific TLDs (for example regional or country focused CAs) which will be only allowed to issue server certs to particular TLDs.
(In reply to comment #11) > The CA would have to constraint the path length too. That would work, though it would be great if the organization name problem could be solved properly so it isn't necessary. Perhaps by showing the organization name of the root CA instead of the lowest CA? After all, the root CA is responsible for all the intermediate certificates it issues. > You also asked about > constraining TLDs, this use-case is foreseen to limit certain CAs to specific > TLDs (for example regional or country focused CAs) which will be only allowed > to issue server certs to particular TLDs. Cool! This sounds like an additional use case for name constraints rather than a problem posed by them.
Matt, The discussion that you and Eddy are having belongs in one of Mozilla's mailing list or newsgroups, not in this bug. The bug report should stay focused on the topic of the immediate problem to be fixed. In your comment 0, you write: > If CAs just start issuing certificates with critical name constraints, NSS > versions before the fix for bug 394919 will suddenly become vulnerable, > which I don't think we want. That happens all the time. Vulnerabilities are found. New versions are released which fix the vulnerability. All older versions remain forever vulnerable. No need to bend over backwards to treat it any differently in this situation. I was going to write a lot more here, but it belongs in mozilla.dev.tech.crypto. Please start a thread there for this topic.
(In reply to comment #13) > That happens all the time. Vulnerabilities are found. New versions are > released which fix the vulnerability. All older versions remain forever > vulnerable. No need to bend over backwards to treat it any differently > in this situation. OK. Marking invalid.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INVALID
(In reply to comment #13) > Matt, The discussion that you and Eddy are having belongs in one of Mozilla's > mailing list or newsgroups, not in this bug. You are right. Sorry. > I was going to write a lot more here, but it belongs in > mozilla.dev.tech.crypto. Please start a thread there for this topic. https://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/c0edf8ec534537bf I invite you to add your comments.
You need to log in before you can comment on or make changes to this bug.