Subject: RE: 3280bis: name constraints

From: "Manger, James H" <[email-masked]>
Date: Thu, 18 Nov 2004 11:07:38 +1100

Actually, the path will be valid in most cases.  The unsupported name
will usually match the unsupported constraint -- it's just that the code
cannot confirm that (as it is unsupported).  The code thinks "validity
unknown" so, to be fail-safe, it (reluctantly) says "treat as invalid".
 
Path validation logic in a generic toolkit could, in fact, take into
account the names an application intends to use... just ask the app or
allowed the app to tell you.  Consider an app only interested in a
particular policy id, key usage and name form.  Only the policy id can
be specified as an input to the standardised path processing rules.
Microsoft Crypto API still allows the key usage to be passed to that
toolkit, however.  It is not that much of a stretch to imagine a toolkit
API accepting a list of name forms.
 
Alternatively (or additionally), 3280bis could RECOMMEND that path
processing toolkits provide a mechanism to allow users to plugin new
modules to handle name constraints on otherwise unsupported name forms.

  _____  

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, 17 November 2004 8:25 PM
To: Manger, James H; [email-masked]
Subject: RE: 3280bis: name constraints

It is not the end entity certificate that is valid or invalid in case of
a breach of name constraints. It is the path that is invalid.

A CA certificate that contains a name constraints extension makes a
statement that this CA certificate is ONLY valid in a path if subsequent
certificates fall within these name boundaries.

You may choose to trust the EE certificates anyway, but you can't use
that name constrained CA certificate as the means to do it.

You have to either.

1) Directly trust the EE cert, or;

2) Find another path using another CA certificate.

Since few applications have native support for path validation and
instead rely on toolkits to do the work, there is no means for the path
validation logic in the generic toolkit to do take into account what
name forms the application intends to make use of. 

Stefan Santesson 
Microsoft Security Center of Excellence (SCOE) 

  _____  

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Manger, James H
Sent: den 17 november 2004 03:00
To: [email-masked]
Subject: RE: 3280bis: name constraints

I agree with Terry -- having to reject a cert due to the presence of a
name (& name-constraint) of a type that you are going to completely
ignore is unnecessarily restrictive.  There is no attack that is
prevented by this rejection.  It just hinders the uptake of useful new
features as they can break backward compatibility.

Consider a directory that strongly authenticates users.  It is only
interested in the user's DN.  It never does anything with email address,
URI, DNS etc.  Yet if it doesn't implement the rules for processing name
constraints on those names (which I believe have never been detailed in
X.509, only RFC 3280) then it cannot accept any cert chain that includes
(in addition to a DN) an email address, URI, DNS etc and an associated
constraint.

Similarly an email application that is only interested in email
addresses; a TLS proxy that is only interested in DNS names...

The subjectAltName extension says any unrecognised or unsupported names
can be ignored (even if critical only one name from the extension needs
to be supported).  The nameConstraints extension basically contradicts
this by saying you can't actually ignore these names as they affect
whether the cert is acceptable or not.

David Cooper's suggestion of issuing separate certs for each name form
that you want to constrain sounds ungainly.  Company A certifying
company B may well want to constrain directoryNames to "c=AU, o=Company
B" and URIs, DNS names and email addresses to ".companyB.com.au".
Should it issue 1 cross-cert (with all constraints), 4 cross-certs to
the one company B CA, 4 cross-certs to 4 separate CA hierarchies in
company B...

...but the problem lies with X.509's text & limitations for name
constraints .. so perhaps 3280bis cannot fix it.

---

From: Steve Hanna <[email-masked]>
Date: Thu, 18 Nov 2004 11:01:08 -0500

James points out several ways that a path validation
toolkit can interface with a relying party application
to allow certs to contain names that have not been
properly checked against name constraints while ensuring
that the relying party does not rely on those names.

One big problem with this is that it is prohibited
by X.509. If the toolkit does this, then it's not
conforming to X.509. We can't allow it in 3280bis
because then we wouldn't be a profile of X.509.
We could try to convince the X.509 folks, but I
don't think that's in scope for the 3280bis effort.

Instead, I suggest that we leave the language in 3280
as is (maybe clarifying it to explain this problem).
And toolkits should allow applications to specify
their own name constraint processing code, adding
support for new name forms.

Providing such extension capabilities will help a bit
with the problem described by Terry, but it certainly
won't solve it. If you include new name forms in a
critical name constraints extension in a CA cert, then
relying parties who don't understand those forms will
reject that cert. You'll need to upgrade those relying
parties before you can use name constraints with the
new name form. Unfortunately, I think it's the best
we can do unless someone is willing to try to get X.509
changed.

This does add support to the view that 3280bis should
REQUIRE support for name constraints on all the name
forms where name constraints semantics are described in
3280bis. Writing name constraints code isn't hard. Adding
it later is.

Thanks,

Steve

Manger, James H wrote:
> ------------------------------------------------------------------------
> *From:* Stefan Santesson [mailto:[email-masked]]
> *Sent:* Wednesday, 17 November 2004 8:25 PM
> *To:* Manger, James H; [email-masked]
> *Subject:* RE: 3280bis: name constraints
> 
>     It is not the end entity certificate that is valid or invalid in
>     case of a breach of name constraints. It is the path that is invalid.
> 
>      
> 
>     statement that this CA certificate is ONLY valid in a path if
>     subsequent certificates fall within these name boundaries.
> 
>      
> 
>     You may choose to trust the EE certificates anyway, but you can’t
>     use that name constrained CA certificate as the means to do it.
> 
>     You have to either.
> 
>      
> 
>     instead rely on toolkits to do the work, there is no means for the
>     path validation logic in the generic toolkit to do take into account
>     what name forms the application intends to make use of.
> 
>      
> 
>     *Stefan Santesson*
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked]
>     [mailto:[email-masked]] *On Behalf Of *Manger, James H
>     *Sent:* den 17 november 2004 03:00
>     *To:* [email-masked]
>     *Subject:* RE: 3280bis: name constraints
> 
>      
> 
>     I agree with Terry -- having to reject a cert due to the presence of
>     a name (& name-constraint) of a type that you are going to
>     completely ignore is unnecessarily restrictive.  There is no attack
>     that is prevented by this rejection.  It just hinders the uptake of
>     useful new features as they can break backward compatibility.
> 
>      
> 
>     interested in the user's DN.  It never does anything with email
>     address, URI, DNS etc.  Yet if it doesn't implement the rules for
>     processing name constraints on those names (which I believe have
>     never been detailed in X.509, only RFC 3280) then it cannot accept
>     any cert chain that includes (in addition to a DN) an email address,
>     URI, DNS etc and an associated constraint.
> 
>     The subjectAltName extension says any unrecognised or unsupported
>     names can be ignored (even if critical only one name from the
>     extension needs to be supported).  The nameConstraints extension
>     basically contradicts this by saying you can't actually ignore these
>     names as they affect whether the cert is acceptable or not.
> 
>      
> 
>     David Cooper's suggestion of issuing separate certs for each name
>     form that you want to constrain sounds ungainly.  Company
>     A certifying company B may well want to constrain directoryNames to
>     "c=AU, o=Company B" and URIs, DNS names and email addresses to
>     ".companyB.com.au".  Should it issue 1 cross-cert (with all
>     constraints), 4 cross-certs to the one company B CA, 4 cross-certs
>     to 4 separate CA hierarchies in company B...
> 
>      
>