headers
Miller, Timothy J. | 11 Jun 2012 15:50
Picon
Favicon

A different question on NC...

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

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix
Permalink | Reply |
headers
David A. Cooper | 11 Jun 2012 16:33
Favicon

Re: A different question on NC...

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 "fake.mailbox <at> example.com"  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
(Continue reading)

Permalink | Reply |
headers
Miller, Timothy J. | 11 Jun 2012 16:56
Picon
Favicon

Re: A different question on NC...

On 6/11/12 9:33 AM, "David A. Cooper" <david.cooper <at> nist.gov> wrote:

>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.

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

>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.

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

>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 "fake.mailbox <at> example.com"  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.

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

>This implies that path validation software may accept a certification
>path even if it contains a nameConstraint that it cannot process as long
(Continue reading)

Permalink | Reply |
headers
Thierry Moreau | 11 Jun 2012 18:01

Re: A different question on NC...

Miller, Timothy J. wrote:
> 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?

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,
(Continue reading)

Permalink | Reply |
headers
David A. Cooper | 11 Jun 2012 18:30
Favicon

Re: A different question on NC...

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

On 06/11/2012 12:01 PM, Thierry Moreau wrote:
> Miller, Timothy J. wrote:
>> 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?
> 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.
(Continue reading)

Permalink | Reply |
headers
Miller, Timothy J. | 11 Jun 2012 20:52
Picon
Favicon

Re: A different question on NC...

On 6/11/12 11:30 AM, "David A. Cooper" <david.cooper <at> nist.gov> wrote:

>>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

> 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.
(Continue reading)

Permalink | Reply |

Gmane