Subject: [pkix] A different question on NC...

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 11 Jun 2012 13:50:05 +0000

Just to change a recent topic, if I wanted to completely prohibit a
subordinate CA from issuing a particular name type (as opposed to
restricting a name space), how would this be accomplished?  IOW, if I
wanted to restrict a sub-CA from issuing certificates containing any
rfc822Name at all, what can I assert in the sub-CA cert?

Would a critical NC with a null string in a permittedSubtrees base value
work?  Something else?  Not possible under the spec?  Enquiring minds want
to know!  :)

Ignore implementations for the moment; theory only is fine for my current
(nefarious?) purposes.
 
-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 11 Jun 2012 10:33:45 -0400

Including a nameConstraints extension in a certificate does not prohibit 
the subject CA from issuing certificates with certain contents; it 
prevents the issuing CA's relying parties from accepting such 
certificates.  It is an important distinction that seems to be lost on 
many people on this list.

The nameConstraints extension wasn't really designed to allow the 
issuing CA to indicate that any certificate containing a name of a 
particular name form should be rejected.  However, there may be ways to 
accomplish what you want.

For name forms for which nameConstraints semantics have been defined, 
the solution is straightforward.  Just specify the same or overlapping 
values for permitted and excluded subtrees.  For example, for rfc822Name 
an excluded subtree of ".com" and a permitted subtree of ".com" or 
"example.com" or "[email-masked]"  Since no rfc822Name can 
satisfy both the permitted and excluded subtrees, the presence of any 
rfc822Name in the subjectAltName extension of a subsequent certificate 
will cause certification path validation to fail.

If no nameConstraints semantics have been defined for the name type, 
then the situation is more tricky.  RFC 5280 says:

    If a name constraints extension that is marked as critical
    imposes constraints on a particular name form, and an instance of
    that name form appears in the subject field or subjectAltName
    extension of a subsequent certificate, then the application MUST
    either process the constraint or reject the certificate.

This implies that path validation software may accept a certification 
path even if it contains a nameConstraint that it cannot process as long 
as that name form does not appear in any subsequent certificate in the 
certification path.  So, it might be possible to just use some arbitrary 
value for the nameConstraints extension (perhaps placing the same value 
in both a permitted and excluded subtree), but I can't say how well that 
would work with real-world implementations.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 11 Jun 2012 14:56:34 +0000

>many people on this list.

Fair enough.  Suffice to say that this may be good enough for my purposes.

>particular name form should be rejected.

As a side question--should it be (re)designed(/interpreted) with this in
mind?  Would such a control alleviate any currently known risks?

>will cause certification path validation to fail.

Now why didn't I think of that?  Good observation; thanks much.

>would work with real-world implementations.

Obviously implementations do what implementations do (even with defined
semantics), and testing would be needed to assess any residual risk from
adding these kinds of constraints.

-- T

---

From: Thierry Moreau <[email-masked]>
Date: Mon, 11 Jun 2012 12:01:59 -0400

> rfc822Name at all, what can I assert in the sub-CA cert?

Quick solution ("your mileage may vary")

a) let the subordinate CA establish a signature key pair

b) DO NOT issue a certificate for the subordinate

c) establish an automated system that
c.1) receives a certificate issued by the subordinate using the above 
key pair
c.2) validate the certificate signature
c.3) validate any of your prohibitions with regard to the certificate 
contents
c.4) if OK so far, remove subordinate signature from the certificate and 
apply yours (you are the CA)
c.5) release the certificate

The problem is who collects the money^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H

The problem is being slightly off the PKI dogma that everything ends up 
as an certificate extension and then blame the relying party software.

Regards,

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

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 11 Jun 2012 12:30:26 -0400

You've just reinvented the registration authority!  I'm not aware of any 
"PKI dogma" that is against the use of RAs.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 11 Jun 2012 18:52:18 +0000

> You've just reinvented the registration authority!

One of the problems I'm facing is I need an automated device solution
(since I don't have the manpower to validate each and every device CSR)
but I'm constrained by a lack of a common authentication framework.  In
short, I need a distributed CA function to leverage all the local authN
systems, but I don't necessarily trust each of these local regions to act
as CA Admins--and a CA Admin could screw the entire Enterprise (the org,
not the ship :) by intentionally creating multiple types of name
collisions.

Re-siging and re-publishing is a concept I could work with to build an
automated RA and bootstrap local authN into something the Enterprise can
reasonably accept.  It's certainly something to think about.

-- T