Well, the subject says it all. Wouldn’t it be cool to allow people serve their own Intermediate/Signing CA, limited to their domain? Of course, this would require, at least, a name constraint for my domain, e.g., *.example.com, marked as a critical extension on the Intermediate CA’s certificate.
What’s the reason for nobody offering that?
The commercial CAs do offer that, for a price. Comodo for example provide this name-constrained CA certificate to Intel:
https://crt.sh/?sha1=d50c68fdcb0c3315eb9951f2444fd9e48ba34829
For Let’s Encrypt I don’t think this is necessarily a good use of their resources. Also under ACME it’s easy to imagine a provider (not Let’s Encrypt) being set up to auto-issue for “your” domains, so that there’s no practical advantage to the name constrained intermediate. LE people have talked about the idea of setting a “master token” for a 2LD or eTLD+1 name, so that all names in that hierarchy can be issued based on proof of control of that token, that’s not something that exists, but it has been discussed.
By the way even with the name constraint the parent CA will probably feel (and may even legally be) obliged to check you’re behaving properly, and they typically do that by requiring all the infrastructure for your CA lives in their data centres not yours, so they can run their own audit trail and do their own logging. That’s another reason Let’s Encrypt wouldn’t want to get into this game - it will be expensive to do it.
One of the problems with name constraints today is that they’re not supported across all platforms, for example on Apple devices. This leads to the following problem: In order to protect all platforms against misissued certificates from name constrained intermediates, the name constraint extension would have to be marked critical. This would tell TLS clients that do not implement this extension to fail. This, however, means that you could not use any name constrained certificates on any Apple device (there are some other examples, but Apple is the only one with significant market share IIRC), which would make them useless in practice.
I believe CAs that offer constrained intermediate certificates to their customers usually keep the private key, unless they’re cross-sign for another CA (such as IdenTrust signing Let’s Encrypt’s intermediate certificate). I’m not quite sure if the Baseline Requirements allow for this kind of setup without obligating you to essentially run your own CA (as in: get audited, etc.) The existing contracts with IdenTrust might also prevent this from happening (at least with regards to the IdenTrust cross-signed intermediate; this would not affect the ISRG root).
Thanks for your answers.
Sure. If I’d go for that path I’d have to live with this hopefully time-limited limitation. Any news on Apple’s progress on supporting that feature?
Yes, I pointed that limitation to a critical extension in my opening post. Anything else is obviously dangerous.
What’s the reason for this step? If my CA issues bad certificates for whichever reason, they can only be for my own domain, so that should be solely my problem, shouldn’t it?
So it’s just a contractual/legal topic then? For which reason? I can already issue certificates for random domains, they are just not valid for one or the other reason, so nobody should trust them. If I’d be allowed to create certificates for my domain, why should that require more scrutiny if I can only shoot myself into the foot?
Are there other technical topics than the Apple etc. feature support topic? Perhaps browser developers planning to enforce certificates must be on a CT chain which might not want to trust my –non-audited– Signing CA’s chain update posts?
Furthermore, this feature could be combined with other features, namely OCSP Must Staple RFC 7633 - X.509v3 Transport Layer Security (TLS) Feature Extension for the Signing CA certificate: Just as with disclosed keys for host certificates, OCSP Stapling could manage to get rid of detected misuse in relatively short time.
So, other than ‘no sufficient support for it in browsers’ and rules that have not been updated to reflect the possibilities of the freedom if correctly used, and perhaps business topics of even more angry CAs losing money, I only see benefits of this approach: I would have full freedom of my domain by creating certificates as I like, would stop eating up public Signing CA resources for each certificate, and if something goes wrong it’s just my fault.
I'm by no means an expert on the Baseline Requirements, so I'm not certain whether the existing language would allow this use-case without being in scope for audits and such. I imagine the reasoning for not doing it would be the lack of platform support - this limitation makes it mostly a "Hey, this would be cool" thing, as opposed to something that would actually be useful in practice. Not something you'd expect a body mostly made up of commercial CAs to be particularly interested in (and vote for).
I believe CT servers are happy to take any certificate that chains up to a root the CT server accepts, so the intermediate should not be the problem here. A bigger problem would be that CT submissions would be up to you in this scenario, so there's no (technical) way for a CA to say "all my leaf certificates will be logged" once they issue intermediates to subscribers.
Must-Staple is only supported by one browser, and the Chrome team has stated that they currently have no plans to adopt it (IIRC). Just like name constraints, this is going to take years to get adopted by a sufficiently large percentage of the internet, and only then would a body such as the CA/B Forum begin to even consider this a viable solution for misuse.
Not saying that I wouldn't like this possibility in general, but this is an area where I'd definitely want CAs and browser vendors to move carefully and conservatively and weigh the risks to the Web PKI as a whole against the benefits of such a proposal.
@pfg, thanks for the discussion.
So we have to wait. First for technical support in servers and browsers for both the name constraint and probably OCSP Must Staple, and before that, the decision by the developers to actually implement the related features. Then the working group has to agree on the use-case of customer self-hosted, non-audited Signing CAs with all current and future constraints, like CT. Finally the market can open up and show whether it is commercially attractive to appear and possibly sustain.
Great conversation all around here. You’ve hit the main points - under current BRs, a name constrained subordinate has to meet all the same requirements an unconstrained subordinate does, which means secured storage and audits. It would be quite a lot of work and expense!
However, I agree that in a future world with better support for name constraints, it might make sense for the BRs to be amended to lower the bar for name constrained subordinates.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.