Subject: 3280bis: name constraints

From: Stephen Henson <[email-masked]>
Date: Mon, 15 Nov 2004 21:33:51 +0000

IMHO some clarification of the nameConstraints extension should be 
included in RFC3280bis.

I can recall there being a number of threads discussing the meaning of 
name constraints for various types including the interpretation of the 
rfc822Name and dNSName fields. At the time various people had come to 
different conclusions based on the existing text.

I've not seen a description of how directoryName types are handled or a 
discussion on this.

IIRC X509 includes a note that if an unhandled constraint type is 
encountered the certificate should be rejected: should RFC3280bis 
include this too?

What about the minimum and maximum fields: should an implementation 
reject a certificate where these are present?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 17 Nov 2004 12:59:56 +1100

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: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
Sent: Wednesday, 17 November 2004 2:19 AM
To: Terry Hayes
Cc: [email-masked]
Subject: Re: 3280bis: name constraints

...
my opinion, the answer to your concern is not to change the semantics of
name constraints, but to be careful in your use of name constraints and
alternative names.  At the moment, in the U.S. Federal PKI, we only
impose name constraints on the directoryName form and I have not seen a
compelling reason to impose constraints on other name forms.

If you do feel the need to impose name constraints on some name form for
which many applications may not be able to process the constraint, then
I would suggest issuing separate certificates for the application(s)
that use that name form.  For example, if you have an application that
uses X.400 names and you feel the need to impose name constraints on
X.400 names, issue subscribers two certificates:  one certificate with
an X.400 name for use with the application that uses the X.400 name
(presumably this application can process the X.400 name constraints) and
a second certificate without an X.400 name.  If a CA imposes a
constraint on a particular name form, but no subsequent certificate
includes a subject name or subjectAltName of that form, then there is no
processing to be done so the application can accept the path despite not
being able to process constraints for that name form.

Terry Hayes wrote:

In my opinion, a requirement such as this is too restrictive, and will
prevent additional capabilities from being added to a PKI.

As long as an application never makes use of a particular name form, it
should be free to ignore constraints that apply to that name form.
Notice that to do this, it must recognize and process the name
constraint extension as required by the extension processing rules.

If applications are required to reject certificates paths with
constraints for name forms that they do not recognize, they will be
prevented from using certificates that have those name forms added to
them for other applications.  This will impede the use of certificates
for these new applications, since older clients will not be able to
function.

Terry Hayes

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 17 Nov 2004 09:25:09 -0000

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

	 

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of David A. Cooper
	Sent: Wednesday, 17 November 2004 2:19 AM
	To: Terry Hayes
	Cc: [email-masked]
	Subject: Re: 3280bis: name constraints

	...
	my opinion, the answer to your concern is not to change the
semantics of name constraints, but to be careful in your use of name
constraints and alternative names.  At the moment, in the U.S. Federal
PKI, we only impose name constraints on the directoryName form and I
have not seen a compelling reason to impose constraints on other name
forms.
	
	If you do feel the need to impose name constraints on some name
form for which many applications may not be able to process the
constraint, then I would suggest issuing separate certificates for the
application(s) that use that name form.  For example, if you have an
application that uses X.400 names and you feel the need to impose name
constraints on X.400 names, issue subscribers two certificates:  one
certificate with an X.400 name for use with the application that uses
the X.400 name (presumably this application can process the X.400 name
constraints) and a second certificate without an X.400 name.  If a CA
imposes a constraint on a particular name form, but no subsequent
certificate includes a subject name or subjectAltName of that form, then
there is no processing to be done so the application can accept the path
despite not being able to process constraints for that name form.
	
	Terry Hayes wrote:

	In my opinion, a requirement such as this is too restrictive,
and will prevent additional capabilities from being added to a PKI.
	 
	As long as an application never makes use of a particular name
form, it should be free to ignore constraints that apply to that name
form.  Notice that to do this, it must recognize and process the name
constraint extension as required by the extension processing rules.

	Terry Hayes

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 19 Nov 2004 20:39:18 -0000

I just wanted to point out that this is a source of misunderstanding when implementing name constraints.

I do however agree with your conclusion.

Stefan Santesson 
  
________________________________________
From: David A. Cooper [mailto:[email-masked]] 
Sent: den 18 november 2004 18:02
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: 3280bis: name constraints

Stefan Santesson wrote:

I totally agree with David that the current defined name comparison rules are not logical and do not follow the subtree principle (i.e. to allow all descendent entries but not parallel entries. This is also the case for the concept that xyz.com should be limited to the host (i.e. that [email-masked] is a violation of xyz.com. In my mind, [email-masked] is a perfectly valid subtree of xyz.com. The standard is thus not logical in this aspect.
  
While I agree that the rules for name constraints on rfc822Name is not entirely proper, but I don't see a compelling reason to change them.

RFC 3280 provides three ways to specify name constraints for rfc822Name:
1. specify a particular mailbox: this one seems to be consistent with the general rules for specifying name constraints.
2. A constraint of the form "xyz.com":  This is really indicating a constraint of "xyz.com" with a minimum of 0 or 1 (it doesn't matter since "xyz.com" is not itself a valid email address) and a maximum of 1.
3. A constraint of the form ".xyz.com":  This is really indicating a constraint of "xyz.com" with a minimum of 2 (must add at least one subdomain plus a local-part to the specified subtree) and no maximum.
In order to get the "normal" meaning of "xyz.com" one would need to include two subtree specifications:  "xyz.com" and ".xyz.com".

This seems to have been a way to introduce some flexibility in the specification of name constraints for rfc822Name without introducing the added complexity of the minimum and maximum fields.

Since the rules for specifying constraints on rfc822Name have remain unchanged since RFC 2459, I think it would be best not to change them.

Dave