Subject: [pkix] How to handle organizational subordinate CA's when I want to stop the flow of trust?

From: Jeffrey Walton <[email-masked]>
Date: Tue, 7 Apr 2015 19:31:33 -0400

Hi Everyone,

In the case of an organization subordinate CA certified by a public
CA, I'd like to know how to stop the flow of trust when a name
constraint is not present.

Non-constrained organizational CAs seem to be a special case that
defies reasoning. They do away with the independent 3rd party auditor
that validates the signing request (the RA), and they are not
subjected to traditional public review/discussion process. Yet the
certificates they issue (like for domains and properties that they *do
not* control) are chained to a public CA which entitles them to all
the privileges of membership.

Are there any means to identify organizational level subordinate CAs
that are not constrained? How can we stop the flow of trust so that
when we have to use a public CA, we can terminate the trust when we
encounter a non-constrained subordinate CA?

Or are there other solutions to the problem? Building an offline list
of {Organizational Subordinate CAs,Domains} does not appear to be
feasible because CAs are not reporting their certification of them or
the names they are supposed to be issuing for.

I don't think its possible because the IETF cannot identify EV
certificates due to lack of Cert Policies extension (thanks Stephen,
http://www.ietf.org/mail-archive/web/pkix/current/msg33057.html). But
it never hurts to ask.

Thanks in advance.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 8 Apr 2015 13:08:40 +0000

If you're operating a subordinate to a public PKI and need to control who gets to bind what kinds of names, then what you should be doing is operating a private PKI.  

If you *also* need public trust paths to the private PKI, that's what bridging is for.  You'd assert allowed and denied nameConstraints in the cross certs as appropriate.  A one-way bridge cert would probably be all you'd want in this case--from the public CA to the private CA (sub or root)--this would allow external verifiers to chain certs issued by the private CA, but would prevent internal verifiers from chaining certs issued by the public CA (unless that public CA is directly trusted) [1].  Which is what I think you want.  

If you're operating a private PKI and want to carve out internal namespaces for some reason (e.g., merged corps or partnerships, or to enable a development org room to experiment in production) you *can* assert name constraints in the subordinate CA certs.  AFAIK only Microsoft Certificate Services has this as an explicit feature (look up "qualified subordination"), and YMMV with validators--it *should* work with any library that supports name constraints, but constraints don't exist for all possible subjectAltNames and there are plenty of proprietary and dangerous name types (e.g., Microsoft's UPN name type) that will naturally have uneven support.  You can work around this by making nameConstraints critical but this can and will break some use cases, and even then there's variation on how nameConstraints is interpreted.

If you're operating or interacting with any portion of a PKI that lacks any kind of CPS (which is how I take "do away with the independent 3rd party auditor that validates the signing request")  then you have much bigger problems and shouldn't be trusting that PKI for anything even if you could apply a constraint.  Even private PKIs need rules.

We probably need a companion "PKI best practices" list.  :)

-- T
[1] US DoD has successfully used one-way trust with the FedPKI for similar purpose.

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Tuesday, April 07, 2015 7:32 PM
To: PKIX
Subject: [pkix] How to handle organizational subordinate CA's when I want to stop the flow of trust?

Hi Everyone,

In the case of an organization subordinate CA certified by a public CA, I'd like to know how to stop the flow of trust when a name constraint is not present.

Non-constrained organizational CAs seem to be a special case that defies reasoning. They do away with the independent 3rd party auditor that validates the signing request (the RA), and they are not subjected to traditional public review/discussion process. Yet the certificates they issue (like for domains and properties that they *do
not* control) are chained to a public CA which entitles them to all the privileges of membership.

Are there any means to identify organizational level subordinate CAs that are not constrained? How can we stop the flow of trust so that when we have to use a public CA, we can terminate the trust when we encounter a non-constrained subordinate CA?

Or are there other solutions to the problem? Building an offline list of {Organizational Subordinate CAs,Domains} does not appear to be feasible because CAs are not reporting their certification of them or the names they are supposed to be issuing for.

I don't think its possible because the IETF cannot identify EV certificates due to lack of Cert Policies extension (thanks Stephen, http://www.ietf.org/mail-archive/web/pkix/current/msg33057.html). But it never hurts to ask.

Thanks in advance.

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 10:06:11 -0400

Jeff,
> the privileges of membership.
The problem you cite is one of the unfortunate aspects of the current
Web PKI environment. It is less of a technical limitation than a business
issue. I've heard that there is an effort to push for more
organizational CAs to be name constrained, but it will take a while
to make that transition.

Steve

---

From: Gervase Markham <[email-masked]>
Date: Wed, 8 Apr 2015 15:13:43 +0100

> organizational CAs to be name constrained, but it will take a while

Mozilla requires all third party intermediate CAs chaining to roots in
its program to be either:

a) name constrained; or
b) publicly disclosed and audited to the same standards as the CA.

The root CA is also held responsible for the activities of the holder of
the intermediate (a point which was relevant recently), which
incentivises them to make sure that said holder behaves appropriately.

This requirement was introduced (to a reasonable amount of wailing and
gnashing of teeth, I might add) a couple of years ago and became binding
on all CAs in the program in May 2014. My understanding is that some
enterprises chose to switch to a managed PKI model (where the CA holds
the private key), and some chose audit. Very few chose name constraints,
as the list of domains which they wanted to issue for changed frequently.

Gerv

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 10:28:16 -0400

Gervase,

Thanks for the statement re Mozilla's policy. I was going to cite Mozilla
on this, but was not absolutely sure.

Still, this is a problem, in general, since it is a per-browser policy, and
I think my characterization of this as a business vs. technical issue is 
accurate.
If folks who want to change domain names frequently were willing to get
a cert per domain, rather than acting as an intermediate CA with the ability
to issue any subordinate certs, this would not be a problem, right?

Steve

---

From: Gervase Markham <[email-masked]>
Date: Wed, 8 Apr 2015 15:47:25 +0100

> to issue any subordinate certs, this would not be a problem, right?

Basically what you are saying is that they should use Managed PKI
(original CA holds the keys) rather than Enterprise PKI (enterprise
holds the keys). You would need to ask enterprises which prefer the
second model why they prefer it, and why the first model would be a
problem for them.

Gerv

---

From: Stephen Kent <[email-masked]>
Date: Wed, 08 Apr 2015 11:59:00 -0400

Gerv,

> second model why they prefer it, and why the first model would be a
no, I am saying that they should get a new, name-constrained cert for each
domain, using the wildcard feature to accommodate different hosts within the
domain. This would be a preferable solution, since it prevents 
acceptance of
mis-issued certs (by RPs that enforce name constraints) rather than relying
on procedural means to remedy problems ex post facto. I assume that the 
major
impediment to this approach is cost, which is a business issue.

Steve