Subject: Re: [pkix] URI Name Constraint and URN

From: Santosh Chokhani <[email-masked]>
Date: Wed, 27 Mar 2013 18:04:08 -0400

David and Piyush,

Thanks.

I agree with you for the most part.  But, the first sentence in that paragraph can be used to think otherwise: "For URIs, the constraint applies to the host part of the name".

Anyway, that is not my primary point.  I think the URI schemes that cannot have host name component should be exempt from name constraint since there is nothing to constrain.

Today, we have actual certificates that have URN in them and rejecting them on the basis of upstream URI constraints (which typically apply to URL) does not make sense to me.

My question is was that simply an oversight or is there a reason URN should be rejected.  One could also argue when using URN scheme, the name is not hierarchical and there is no point in constraining it.

From: Piyush Jain [mailto:[email-masked]]
Sent: Tuesday, March 26, 2013 6:07 PM
To: Santosh Chokhani; 'pkix'
Subject: RE: [pkix] URI Name Constraint and URN

>From 5280
(e.g., if the URI either
   does not include an authority component or includes an authority
   component in which the host name is specified as an IP address), then
   the application MUST reject the certificate.

It clearly says that if authority component is missing, certificate must be rejected.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Santosh Chokhani
Sent: Tuesday, March 26, 2013 2:47 PM
To: 'pkix'
Subject: [pkix] URI Name Constraint and URN

I have been wrestling with what one should with a certificate if the SAN in the certificate contains URN and when you get to the certificate, the name constraint state variable indicates permitted and/or excluded values for the URI name form.

I think name constraint is not applicable to URN since it does not have an "authority" and thus "host" component by definition.  Thus, regardless of the name constraint state variable, presence of URN should not cause name constraint violation.

But, when I read 5280, I find the text implying otherwise or ambiguous.

Santosh Chokhani
CygnaCom Solutions, Inc.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 28 Mar 2013 17:07:52 +0100

Santosh,

Clearly URN can't be expressed as a constraint.
If there is a constraint expressing .example.com and the SAN holds a URN
value, I'd say that this is a violation of that constraint.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Wednesday, March 27, 2013 11:04 PM
To:  Piyush Jain <[email-masked]>, 'pkix' <[email-masked]>
Subject:  Re: [pkix] URI Name Constraint and URN

> David and Piyush,
>  
> Thanks.
>  
> I agree with you for the most part.  But, the first sentence in that paragraph
> can be used to think otherwise: ³For URIs, the constraint applies to the host
> part of the name².
>  
> Anyway, that is not my primary point.  I think the URI schemes that cannot
> have host name component should be exempt from name constraint since there is
> nothing to constrain.
>  
> Today, we have actual certificates that have URN in them and rejecting them on
> the basis of upstream URI constraints (which typically apply to URL) does not
> make sense to me.
>  
> My question is was that simply an oversight or is there a reason URN should be
> rejected.  One could also argue when using URN scheme, the name is not
> hierarchical and there is no point in constraining it.
>  
> 
> From: [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of
> Santosh Chokhani
> I have been wrestling with what one should with a certificate if the SAN in
> the certificate contains URN and when you get to the certificate, the name
> constraint state variable indicates permitted and/or excluded values for the
> URI name form.
>  
> I think name constraint is not applicable to URN since it does not have an
> ³authority² and thus ³host² component by definition.  Thus, regardless of the
> name constraint state variable, presence of URN should not cause name
> constraint violation.
>  
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 28 Mar 2013 12:11:33 -0400

Stefan,

So, even though constraining URN is meaningless, all URN certificates should be rejected.   Did I get you right?

Make no sense at all to me.  May be you can explain why this is useful or right aside from 5280 having missed the scenario.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, March 28, 2013 12:08 PM
To: Santosh Chokhani; Piyush Jain; 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

Santosh,

Clearly URN can't be expressed as a constraint.
If there is a constraint expressing .example.com and the SAN holds a URN value, I'd say that this is a violation of that constraint.

/Stefan

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 27, 2013 11:04 PM
To: Piyush Jain <[email-masked]<mailto:[email-masked]>>, 'pkix' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] URI Name Constraint and URN

David and Piyush,

Thanks.

(e.g., if the URI either

Santosh Chokhani
CygnaCom Solutions, Inc.

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 28 Mar 2013 17:21:31 +0100

Not all URN certificates.

Only certificates with a URN where a CA certificate in the current path has
provided a constraints for URI:s according to the standard as a
permittedSubtree constraint.

RFC 5280 states:
   The name constraints extension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located.

I simply can't see how "urn:com:contoso:whatever"  can be claimed to fit
within the permitted subtree constraint ".example.com"

If ".example.com" is an excluded subtree, then I have no problem accepting
the cert, because the URN is not excluded.

/Stefan

From:  Santosh Chokhani <[email-masked]>
Date:  Thursday, March 28, 2013 5:11 PM
To:  Stefan Santesson <[email-masked]>, Piyush Jain
<[email-masked]>, 'pkix' <[email-masked]>
Subject:  Re: [pkix] URI Name Constraint and URN

> Make no sense at all to me.  May be you can explain why this is useful or
> right aside from 5280 having missed the scenario.
>  
> 
>> I agree with you for the most part.  But, the first sentence in that
>> paragraph can be used to think otherwise: ³For URIs, the constraint applies
>> to the host part of the name².
>>  
>> Today, we have actual certificates that have URN in them and rejecting them
>> on the basis of upstream URI constraints (which typically apply to URL) does
>> not make sense to me.
>>  
>> My question is was that simply an oversight or is there a reason URN should
>> be rejected.  One could also argue when using URN scheme, the name is not

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 28 Mar 2013 12:24:21 -0400

Stefan,

URN by definition do not have "authority" component are not hierarchical.

You are simply parroting what 5280 says and not explaining what the use of meaning of doing this is.

May be you should explain how an upstream CA will permit URN and still constrain URL.

From: Stefan Santesson [mailto:[email-masked]]
Sent: Thursday, March 28, 2013 12:22 PM
To: Santosh Chokhani; Piyush Jain; 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

Only certificates with a URN where a CA certificate in the current path has provided a constraints for URI:s according to the standard as a permittedSubtree constraint.

RFC 5280 states:

I simply can't see how "urn:com:contoso:whatever"  can be claimed to fit within the permitted subtree constraint ".example.com"

If ".example.com" is an excluded subtree, then I have no problem accepting the cert, because the URN is not excluded.

/Stefan

From: Santosh Chokhani <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 5:11 PM
To: Stefan Santesson <[email-masked]<mailto:[email-masked]>>, Piyush Jain <[email-masked]<mailto:[email-masked]>>, 'pkix' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [pkix] URI Name Constraint and URN

Stefan,

Santosh,

/Stefan

David and Piyush,

Thanks.

(e.g., if the URI either

Santosh Chokhani
CygnaCom Solutions, Inc.

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 28 Mar 2013 10:37:52 -0700

Santosh,

I think I agree with you that constraining URN based on authority does not
make sense.

The text - "For URIs, the constraint applies to the host part of the name."
from 5280 indicates that the author assumed that URIs will always have the
authority component, which is a wrong assumption.

There may be some value in applying the constraint after using a resolver to
map the URN to a location, or constraining the namespace of the URN itself.

So here are the possible scenarios

1)      Constraint is a URL, name is URN. This is what you came across. It
does not make sense to apply authority constraints unless URN is resolved to
a URL

2)      Constraint is URN, name is URL. Not sure if this is useful at all.
5280 is silent on this.

3)      Constraint is URN, name is URN. It might be useful to define
matching rules for this scenario.

4)      Constraint is URL, name is URL. This is the only case 5280 handles
today.

-Piyush

From: Santosh Chokhani [mailto:[email-masked]] 
Sent: Thursday, March 28, 2013 9:24 AM
To: Stefan Santesson; Piyush Jain; 'pkix'
Subject: RE: [pkix] URI Name Constraint and URN

Stefan,

You are simply parroting what 5280 says and not explaining what the use of
meaning of doing this is.

May be you should explain how an upstream CA will permit URN and still
constrain URL.

RFC 5280 states:

/Stefan

Stefan,

So, even though constraining URN is meaningless, all URN certificates should
be rejected.   Did I get you right?

Santosh,

/Stefan

David and Piyush,

Thanks.

I agree with you for the most part.  But, the first sentence in that
paragraph can be used to think otherwise: "For URIs, the constraint applies
to the host part of the name".

Anyway, that is not my primary point.  I think the URI schemes that cannot
have host name component should be exempt from name constraint since there
is nothing to constrain.

(e.g., if the URI either

It clearly says that if authority component is missing, certificate must be
rejected.

From:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Tuesday, March 26, 2013 2:47 PM
To: 'pkix'
Subject: [pkix] URI Name Constraint and URN

I think name constraint is not applicable to URN since it does not have an
"authority" and thus "host" component by definition.  Thus, regardless of
the name constraint state variable, presence of URN should not cause name
constraint violation.

 

Santosh Chokhani

CygnaCom Solutions, Inc.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 28 Mar 2013 14:03:55 -0400

On 03/28/2013 01:37 PM, Piyush Jain
wrote:

Santosh,

I think I agree
with you that constraining URN based on authority does not
make sense.

The text – “For URIs, the constraint applies to the host part of the name.” from 5280 indicates that the author assumed that URIs will always have the authority component, which is a wrong assumption.

RFC 5280 says:

If a constraint is applied to the
uniformResourceIdentifier name form and a subsequent certificate
includes a subjectAltName extension with a
uniformResourceIdentifier that does not include an authority
component with a host name specified as a fully qualified domain
name (e.g., if the URI either does not
include an authority component or includes an authority
component in which the host name is specified as an IP address),
then the application MUST reject the certificate.

This indicates quite clearly that the author did not assume
that URIs will always have the authority component.

See also
http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html ("RFC
3280bis and URI schemes without hostname").

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 28 Mar 2013 11:49:23 -0700

My apologies to the author(s) for being presumptuous and thank David for
pointing to the discussion thread.

So it seems that WG consciously refrained from defining matching rules for
URNs. 

This implies if a CA has a permitted subtree constraint, any descendent
certificate cannot have a URN name. Seems like a limitation which cannot be
addressed without defining matching rules for URNs.

From: David A. Cooper [mailto:[email-masked]] 
Sent: Thursday, March 28, 2013 11:04 AM
To: Piyush Jain
Cc: 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

On 03/28/2013 01:37 PM, Piyush Jain wrote:

Santosh,

RFC 5280 says:

If a constraint is applied to the uniformResourceIdentifier name form and a
subsequent certificate includes a subjectAltName extension with a
uniformResourceIdentifier that does not include an authority component with
a host name specified as a fully qualified domain name (e.g., if the URI
either does not include an authority component or includes an authority
component in which the host name is specified as an IP address), then the
application MUST reject the certificate.

This indicates quite clearly that the author did not assume that URIs will
always have the authority component.

See also http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html
("RFC 3280bis and URI schemes without hostname").

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 29 Mar 2013 13:26:36 +0000

So perhaps the problem is there's no way to apply a single NC rule to URIs
since the sub-types of URIs conflict in how names are constructed.  I.e.,
the right fix is to discard the URI type and treat the sub-type of URLs
and URNs separately.  This would permit separate NC processing for each,
which seems to be what Santosh is asking for.

-- T

On 3/28/13 1:49 PM, "Piyush Jain" <[email-masked]> wrote:

>So it seems that WG consciously refrained from defining matching rules
>for URNs.
>
>certificate cannot have a URN name. Seems like a limitation which cannot
>be addressed without defining matching rules for URNs.
> 
>I think I agree with you that constraining URN based on authority does
>not make sense.
> 
>The text  ³For URIs, the constraint applies to the host part of the
>name.² from 5280 indicates that the author assumed that URIs will always
>have the authority component, which is a wrong assumption.
>
>
>RFC 5280 says:
>If a constraint is applied to the uniformResourceIdentifier name form and
>a subsequent certificate includes a subjectAltName extension with a
>uniformResourceIdentifier
> that does not include an authority component with a host name specified
>as a fully qualified domain name (e.g., if the
>URI either does not include an authority component or includes an
>authority component in which
> the host name is specified as an IP address), then the application MUST
>reject the certificate.
>
>This indicates quite clearly that the author did not assume that URIs
>will always have the authority component.
>
>See also 
>http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html
><http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html> ("RFC

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 09:21:32 -0700

Yes. Applying location constraints to URNs is the problem which must be
fixed.
Defining processing rules for URN constrains is probably nice to have.

> -----Original Message-----
> From: Miller, Timothy J. [mailto:[email-masked]]
> Sent: Friday, March 29, 2013 6:27 AM
> To: Piyush Jain; 'David A. Cooper'; Santosh Chokhani
> Cc: 'pkix'
the
> right fix is to discard the URI type and treat the sub-type of URLs and
URNs
> separately.  This would permit separate NC processing for each, which
seems
> to be what Santosh is asking for.
> 
> -- T
> 
> >My apologies to the author(s) for being presumptuous and thank David
> >for pointing to the discussion thread.
> >
> >certificate cannot have a URN name. Seems like a limitation which
> >cannot be addressed without defining matching rules for URNs.
> >
> >name.² from 5280 indicates that the author assumed that URIs will
> >always have the authority component, which is a wrong assumption.
> >
> >
> >RFC 5280 says:
> >If a constraint is applied to the uniformResourceIdentifier name form
> >and a subsequent certificate includes a subjectAltName extension with a
> >uniformResourceIdentifier  that does not include an authority component
> >with a host name specified as a fully qualified domain name (e.g., if
> >the URI either does not include an authority component or includes an
> >authority component in which  the host name is specified as an IP
> >address), then the application MUST reject the certificate.
> >

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 29 Mar 2013 12:28:25 -0400

David,

1.       Can you explain what harm is does to accept a certificate if the upstream CA has URL constrained?

2.       Can you explain how a CA that wishes to constrain URL, but permit URN would do so.  Note that this is a real scenario as you know?

3.       Note that SAN description in 5280 already require FQDN for the host for URI that require authority.  So, why are you hung up on the text in 5280 which most likely did not consider URN scenario.  If it did, please explain why a name constraint is meaningful to URN which not a hierarchical name in the first place.

4.       I read the post you sent below and I read it as supporting what I am saying.  Do not constrain the URI that cannot have authority component to it.

"* Decide that this name type is not appropriate for URI schemes that tend not to use authorities.

* Relax the rules.  I strongly urge the WG not to take on the task of name constraints for URIs without authority in this document."

From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Thursday, March 28, 2013 2:04 PM
To: Piyush Jain
Cc: 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

I think I agree with you that constraining URN based on authority does not make sense.

The text - "For URIs, the constraint applies to the host part of the name." from 5280 indicates that the author assumed that URIs will always have the authority component, which is a wrong assumption.

RFC 5280 says:
If a constraint is applied to the uniformResourceIdentifier name form and a subsequent certificate includes a subjectAltName extension with a uniformResourceIdentifier that does not include an authority component with a host name specified as a fully qualified domain name (e.g., if the URI either does not include an authority component or includes an authority component in which the host name is specified as an IP address), then the application MUST reject the certificate.

This indicates quite clearly that the author did not assume that URIs will always have the authority component.

See also http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html ("RFC 3280bis and URI schemes without hostname").

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 29 Mar 2013 12:29:26 -0400

There is nothing to constrain when URN is UUID.

-----Original Message-----
From: Piyush Jain [mailto:[email-masked]] 
Sent: Friday, March 29, 2013 12:22 PM
To: 'Miller, Timothy J.'; 'David A. Cooper'; Santosh Chokhani
Cc: 'pkix'
Subject: RE: [pkix] URI Name Constraint and URN

Yes. Applying location constraints to URNs is the problem which must be fixed.
Defining processing rules for URN constrains is probably nice to have.

> So perhaps the problem is there's no way to apply a single NC rule to 
> URIs since the sub-types of URIs conflict in how names are 
> constructed.  I.e.,
the
URNs
seems
> >So it seems that WG consciously refrained from defining matching 
> >rules for URNs.
> >
> >This implies if a CA has a permitted subtree constraint, any 
> >descendent certificate cannot have a URN name. Seems like a 
> >limitation which cannot be addressed without defining matching rules for URNs.
> >
> >and a subsequent certificate includes a subjectAltName extension with 
> >a uniformResourceIdentifier  that does not include an authority 
> >component with a host name specified as a fully qualified domain name 
> >(e.g., if the URI either does not include an authority component or 
> >includes an authority component in which  the host name is specified 
> >as an IP address), then the application MUST reject the certificate.
> >

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 29 Mar 2013 17:30:09 +0100

Date:  Thursday, March 28, 2013 5:24 PM

> 
> Stefan,
>  
> URN by definition do not have ³authority² component are not hierarchical.
>  

I wish I could but I can't. Not given the current definition of name
constraints.

If you contrain URL in permitted subtree, I can't see given the current
standard, how you could allow a URN as matching that constraint.
Other than of course stick it into a new otherName instead of the SAN URI.

Maybe that would be your best bet as you in any case can't rely on standard
client behaviour to handle this.

/Stefan

---

From: "Piyush Jain" <[email-masked]>
Date: Fri, 29 Mar 2013 09:44:48 -0700

That is true.  In this case there will be no NC constraining the URNs.

A URN NC would only make sense for hierarchical URNs.

> Sent: Friday, March 29, 2013 9:29 AM
> To: Piyush Jain; 'Miller, Timothy J.'; 'David A. Cooper'
> Cc: 'pkix'
> > >limitation which cannot be addressed without defining matching rules
for

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 29 Mar 2013 13:39:17 -0400

Santosh,

On 03/29/2013 12:28 PM, Santosh Chokhani wrote:

So, why are
you hung up on the text in 5280 which most likely did not
consider URN scenario.  If it did, please explain why a name
constraint is meaningful to URN which not a hierarchical name
in the first place.

The text in 5280 most definitely did consider the URN scenario.
That is why 5280 includes a sentence that says "if the URI either
does not include an authority component...."

I also pointed to an thread on the PKIX mail list with the subject
"RFC 3280bis and URI schemes without hostname"
(http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html),
and in one of the messages in that thread
(http://www.ietf.org/mail-archive/web/pkix/current/msg02171.html),
I referred to a thread from early 2007 with the subject "URN in
subjectAltName"
(http://www.imc.org/ietf-pkix/mail-archive/msg02513.html).  I did
a quick look at the "URN in subjectAltName" thread and saw that
there was at least one message in that thread
(http://www.imc.org/ietf-pkix/mail-archive/msg02641.html) that
specifically mentioned URNs and name constraints.

I even checked my interoperability testing spreadsheet (from about
4 years ago) and see that I tested this scenario and found two
path validation implementations that implemented this aspect of
name constraints:

Issued end entity certificate
(ValidNoAuthorityURI.cer) under SampleRoot.cer and verified
that both clients would accept a URI without an authority
component in the absence of a name constraint.  Created a
subordinate (URInameConstraintsIntermediateCA.cer) that
specifies a permitted subtree for URIs and three end entities,
one with a URI that satisfies the constraint
(ValidURInameConstraints.cer), one with a URI with no
authority component [urn:uuid:...]
(NoAuthorityURInameConstraints.cer), and one with a URI that
uses an IP address to specify the host
(InvalidURIIPaddress.cer).  Both clients accepted the
certificate with the valid URI and rejected the other two
certificates.

Can you explain to me how all of those things happened if 5280 did
not consider URN scenario?

As to your other questions, I will simply point you to
http://www.ietf.org/mail-archive/web/pkix/current/msg02132.html,
where I said:

I am inclined to
think that URIs that do not include an authority should be
ignored. That is, they should be treated just as if they had
been included in a different name form for which name
constraints have not been defined.

So, unless I changed my mind later, I didn't even agree with the
requirements that were put into 5280.  However, as editor it would
have been my responsibility to reflect working group consensus in
the document, not my own personal opinion.  So, I will not attempt
to respond to your other questions, which seem to be asking me to
defend the current text in 5280.  I am simply rebutting
suggestions that URNs were never considered when the name
constraints rules in 5280 were written.  I have no interest in
either supporting or arguing against the current rules.

Dave

On 03/29/2013 12:28 PM, Santosh Chokhani wrote:

David,

1.       Can you explain what harm is does to
accept a certificate if the upstream CA has URL constrained?

2.       Can you explain how a CA that wishes
to constrain URL, but permit URN would do so.  Note that
this is a real scenario as you know?

3.       Note that SAN description in 5280
already require FQDN for the host for URI that require
authority.  So, why are you hung up on the text in 5280
which most likely did not consider URN scenario.  If it did,
please explain why a name constraint is meaningful to URN
which not a hierarchical name in the first place.

4.       I read the post you sent below and I
read it as supporting what I am saying.  Do not constrain
the URI that cannot have authority component to it.

“* Decide that this name type is
not appropriate for URI schemes that tend not to use
authorities.

* Relax the rules.  I strongly
urge the WG not to take on the task of name constraints for
URIs without authority in this document.”

From:
[email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper

To: Piyush Jain

Cc: 'pkix'

Santosh,

I think I
agree with you that constraining URN based on authority
does not make sense.

RFC 5280 says:

If a constraint is applied to
the uniformResourceIdentifier name form and a subsequent
certificate includes a subjectAltName extension with a
uniformResourceIdentifier that does not include an authority
component with a host name specified as a fully qualified
domain name (e.g., if the URI either does
not include an authority component or includes an authority
component in which the host name is specified as an IP
address), then the application MUST reject the certificate.

This indicates quite clearly that the author did not
assume that URIs will always have the authority component.

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 29 Mar 2013 13:45:15 -0400

David,

Thank you very much.

From: David A. Cooper [mailto:[email-masked]]
Sent: Friday, March 29, 2013 1:39 PM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

Santosh,

So, why are you hung up on the text in 5280 which most likely did not consider URN scenario.  If it did, please explain why a name constraint is meaningful to URN which not a hierarchical name in the first place.

The text in 5280 most definitely did consider the URN scenario.  That is why 5280 includes a sentence that says "if the URI either does not include an authority component...."

I also pointed to an thread on the PKIX mail list with the subject "RFC 3280bis and URI schemes without hostname" (http://www.ietf.org/mail-archive/web/pkix/current/msg02179.html), and in one of the messages in that thread (http://www.ietf.org/mail-archive/web/pkix/current/msg02171.html), I referred to a thread from early 2007 with the subject "URN in subjectAltName" (http://www.imc.org/ietf-pkix/mail-archive/msg02513.html).  I did a quick look at the "URN in subjectAltName" thread and saw that there was at least one message in that thread (http://www.imc.org/ietf-pkix/mail-archive/msg02641.html) that specifically mentioned URNs and name constraints.

I even checked my interoperability testing spreadsheet (from about 4 years ago) and see that I tested this scenario and found two path validation implementations that implemented this aspect of name constraints:
Issued end entity certificate (ValidNoAuthorityURI.cer) under SampleRoot.cer and verified that both clients would accept a URI without an authority component in the absence of a name constraint.  Created a subordinate (URInameConstraintsIntermediateCA.cer) that specifies a permitted subtree for URIs and three end entities, one with a URI that satisfies the constraint (ValidURInameConstraints.cer), one with a URI with no authority component [urn:uuid:...] (NoAuthorityURInameConstraints.cer), and one with a URI that uses an IP address to specify the host (InvalidURIIPaddress.cer).  Both clients accepted the certificate with the valid URI and rejected the other two certificates.

Can you explain to me how all of those things happened if 5280 did not consider URN scenario?

As to your other questions, I will simply point you to http://www.ietf.org/mail-archive/web/pkix/current/msg02132.html, where I said:

I am inclined to think that URIs that do not include an authority should be ignored. That is, they should be treated just as if they had been included in a different name form for which name constraints have not been defined.

So, unless I changed my mind later, I didn't even agree with the requirements that were put into 5280.  However, as editor it would have been my responsibility to reflect working group consensus in the document, not my own personal opinion.  So, I will not attempt to respond to your other questions, which seem to be asking me to defend the current text in 5280.  I am simply rebutting suggestions that URNs were never considered when the name constraints rules in 5280 were written.  I have no interest in either supporting or arguing against the current rules.

Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Thursday, March 28, 2013 2:04 PM
To: Piyush Jain
Cc: 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

RFC 5280 says:

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 29 Mar 2013 20:18:52 +0000

If the NC for URIs included the scheme-part, then a NC could apply to a URL (or other URI with a host-part in the hierarchical-part) without impacting a URN (which lacks a hierarchical-part entirely).  Unfortunately I don't see a way to do this in a backward compatible way.

Alternatively an exclusion clause for the URN scheme in 4.2.1.10 would have a similar effect, but that seems ugly to me.

-- T

________________________________
From: [email-masked] [[email-masked]] on behalf of Stefan Santesson [[email-masked]]
Sent: Friday, March 29, 2013 11:30
To: Santosh Chokhani; Piyush Jain; 'pkix'
Subject: Re: [pkix] URI Name Constraint and URN

Stefan,

URN by definition do not have “authority” component are not hierarchical.

I wish I could but I can't. Not given the current definition of name constraints.

If you contrain URL in permitted subtree, I can't see given the current standard, how you could allow a URN as matching that constraint.
Other than of course stick it into a new otherName instead of the SAN URI.

Maybe that would be your best bet as you in any case can't rely on standard client behaviour to handle this.

/Stefan

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 29 Mar 2013 16:25:12 -0400

Tim,

I think using URN is risky.  May be the profile owners can be convinced to put these name in other names as Stefan suggested and transition over time to newer profiles.

From: Miller, Timothy J. [mailto:[email-masked]]
Sent: Friday, March 29, 2013 4:19 PM
To: Stefan Santesson; Santosh Chokhani; Piyush Jain; 'pkix'
Subject: RE: [pkix] URI Name Constraint and URN

-- T

From: [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of Stefan Santesson [[email-masked]]

Stefan,

/Stefan