Subject: Re: RFC 3280bis and URI schemes without hostname

From: Stephen Farrell <[email-masked]>
Date: Sat, 01 Dec 2007 15:13:11 +0000

Hi Dave,

David A. Cooper wrote:
> 
> Early this year, there was a email thread about a similar topic under
> the subject line "URN in subjectAltName" (see
> http://www.imc.org/ietf-pkix/mail-archive/msg02513.html).  I thought the
> rough consensus in that discussion was against changing the rules for
> the uniformResourceIdentifier choice in subjectAltName and that if there
> is a need to include such names in a certificate then a new name form
> should be defined (in a document other than 3280bis).
> 
> As for the specific proposal, I have two concerns with the proposed text
> for the name constraints extension:
> 
>   For URIs, the constraint applies to the host part of the name so
>   a name constraint URI can only match a subjetAltName URI where the
>   scheme-specific-part includes a fully qualified domain name or IP
>   address as the host. If a certificate contains a URI with no host
>   part then that certificate cannot match the permittedSubtrees of
>   a name constraint. If a certificate contains a URI with no host
>   part then that certificate always matches the excludedSubtrees of
>   any URI name constraint.
> 
> 1) The first sentence states that a match between a constraint and a
> subject name may occur when the subject name includes an IP address, but
> the second paragraph only explains how to specify DNS name constraints. 
> If a name constraint uses DNS names to specify a constraint, can that be
> compared against a subject name that has an IP address?

I'm not getting how this concern relates to the proposed change. Isn't
the above concern something that'd apply to the current I-D text?

> 2) While the rules for dealing with subject names that do not specify a
> host fail safe, they result in different matching rules (i.e., rules for
> determining whether a given name falls within a given subtree) depending
> on whether the comparison is being performed for a name that appears as
> a permitted or excluded subtree.

Yep. I think that's needed though but if you've a way to avoid it I'd
go for that.

S.

> 
> Dave
> 
> Stephen Farrell wrote:
>> Sam Hartman wrote:
>>  
>>> RFC 3286 does not require that schemes have an authority component.
>>> For example take a look at RFC 4622.  It does support authority
>>> components, but if I were going to issue a certificate for an XMPP
>>> identity I would actually expect that which server the end user
>>> authenticates to would not be important for the whether they were
>>> reaching a given subject.  Other URIs simply don't use authority.
>>> However the URI in subjectAltName requires the host portion to be
>>> present, which requires an authority section.
>>>     
>>
>> Good catch.
>>  
>>> I'd like the WG to consider what to do about this.  Options include:
>>>
>>> * Decide that this name type is not appropriate for URI schemes that
>>> tend not to use authorities. 
>>> * Relax the rules.
>>>     
>>
>> I think relaxing is probably the better approach.
>>
>> So that'd mean removing the requirement that the host part be present in
>> subjectAltName URIs and adding something to NameCosntraints that says
>> that URIs can only really match when the subjectAltName does in fact
>> contain a host part.
>>
>> That seems to mean that a name constraint with an excludedSubtrees
>> URI will always match a subjectAltName URI that has no host part
>> and a name constraint with a permittedSubtrees URI will never
>> match a subjectAltName URI that has no host part.
>>
>> I reckon that that's ok.
>>
>> Some proposed edits reflecting that are below.
>>
>>   I strongly urge the WG not to take on the task of name constraints for
>> URIs without authority in this document.
>>
>> Absolutely agree.
>>
>> Regards,
>> Stephen.
>>
>> Possible Edits:
>>
>> -----
>>
>> 4.2.1.6, paragraphs 7 & 8 OLD:
>>
>>    When the subjectAltName extension contains a URI, the name MUST be
>>    stored in the uniformResourceIdentifier (an IA5String).  The name
>>    MUST NOT be a relative URL, and it MUST follow the URL syntax and
>>    encoding rules specified in [RFC 3986].  The name MUST include both a
>>    scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
>>    scheme-specific-part MUST include a fully qualified domain name or IP
>>    address as the host.  Rules for encoding internationalized resource
>>    identifiers (IRIs) are specified in section 7.4.
>>
>>    As specified in [RFC 3986], the scheme name is not case-sensitive
>>    (e.g., "http" is equivalent to "HTTP").  The host part is also not
>>    case-sensitive, but other components of the scheme-specific-part may
>>    be case-sensitive.  Rules for comparing URIs are specified in section
>>    7.4.
>>
>> 4.2.1.6, paragraphs 7 & 8 NEW:
>>
>>    When the subjectAltName extension contains a URI, the name MUST be
>>    stored in the uniformResourceIdentifier (an IA5String).  The name
>>    MUST NOT be a relative URL, and it MUST follow the URL syntax and
>>    encoding rules specified in [RFC 3986].  The name MUST include both a
>>    scheme (e.g., "http" or "ftp") and a scheme-specific-part. Rules for
>>    encoding internationalized resource identifiers (IRIs) are specified
>>    in section 7.4.
>>
>>    As specified in [RFC 3986], the scheme name is not case-sensitive
>>    (e.g., "http" is equivalent to "HTTP").  The host part, if present,
>>    is also not case-sensitive, but other components of the
>>    scheme-specific-part may be case-sensitive.  Rules for comparing URIs
>>    are specified in section 7.4.
>>
>> -----
>>
>> 4.2.1.10, 6th paragraph, OLD:
>>
>>    For URIs, the constraint applies to the host part of the name.  The
>>    constraint MAY specify a host or a domain.  Examples would be
>>    "host.example.com" and ".example.com".  When the the constraint
>>    begins with a period, it MAY be expanded with one or more subdomains.
>>    That is, the constraint ".example.com" is satisfied by both
>>    host.example.com and my.host.example.com.  However, the constraint
>>    ".example.com" is not satisfied by "example.com".  When the
>>    constraint does not begin with a period, it specifies a host.
>>
>> 4.2.1.10, 6th paragraph, NEW:
>>
>>    For URIs, the constraint applies to the host part of the name so
>>    a name constraint URI can only match a subjetAltName URI where the
>>    scheme-specific-part includes a fully qualified domain name or IP
>>    address as the host. If a certificate contains a URI with no host
>>    part then that certificate cannot match the permittedSubtrees of
>>    a name constraint. If a certificate contains a URI with no host
>>    part then that certificate always matches the excludedSubtrees of
>>    any URI name constraint.
>>
>>    The constraint MAY specify a host or a domain.  Examples would be
>>    "host.example.com" and ".example.com".  When the the constraint
>>    begins with a period, it MAY be expanded with one or more subdomains.
>>    That is, the constraint ".example.com" is satisfied by both
>>    host.example.com and my.host.example.com.  However, the constraint
>>    ".example.com" is not satisfied by "example.com".  When the
>>    constraint does not begin with a period, it specifies a host.
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Dec 2007 13:44:59 -0500

Folks,

There has been discussion on the list of how to revise 3280bis to 
address the issue raised by Sam during IETF last call.

>>     constraint does not begin with a period, it specifies a host.

I am initiating a 2-week PKIX WG last call on the proposed text, so 
that David Cooper can submit this as a WG-approved response to Sam's 
last call comment if the WG concurs.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 04 Dec 2007 17:11:43 -0800

All,

During the PKIX meeting yesterday, there did not seem to be any 
objection to allowing subjectAltName extensions to include URIs, in the 
uniformResourceIdentifier field, that do not include fully qualified 
domain names.  I would propose the following text for section 4.2.1.6, 
which is a slight modification to Stephen's proposal:

   When the subjectAltName extension contains a URI, the name MUST be
   stored in the uniformResourceIdentifier (an IA5String).  The name
   MUST NOT be a relative URI, and it MUST follow the URI syntax and
   encoding rules specified in [RFC 3986].  The name MUST include both a
   scheme (e.g., "http" or "ftp") and a scheme-specific-part.  URIs that
   include an authority ([RFC 3986], section 3.2) MUST include a fully
   qualified domain name or IP address as the host.  Rules for encoding
   internationalized resource identifiers (IRIs) are specified in 
section 7.4.

   As specified in [RFC 3986], the scheme name is not case-sensitive
   (e.g., "http" is equivalent to "HTTP").  The host part, if present, is
   also not case-sensitive, but other components of the scheme-specific-part
   may be case-sensitive.  Rules for comparing URIs are specified in 
section 7.4.

If this change is adopted, then as I read RFC 3986, we need to consider 
three types of URIs that may appear in the uniformResourceIdentifier field:

1) URIs that include an authority component in which the host is 
specified as a fully qualified domain name.

2) URIs that include an authority component in which the host is 
specified as an IP address.

3) URIs that do not include an authority component.

At the moment, the name constraints section of 3280bis only addresses 
the first case.  While I don't like the idea of applying different 
matching rules depending on whether the constraint is specified as an 
excludedSubtree or as a permittedSubtree, that seems to be the best 
option in this case.  The question then becomes, if name constraints 
extension specifies a constraint on URIs, how should URIs in the 
subjectAltName extension of type 2) or 3) be treated?  Should such names 
be ignored or should the presence of such names cause the certification 
path to be rejected.

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.

For URIs that include an authority with the host specified as an IP 
address, I think 3280bis should that that they should be ignored, unless 
3280bis specifies how to apply IP address based constraints on URIs.

What do others think?  What should the name constraints section of 
3280bis state about the treatment of URIs that do not include an 
authority or that use an IP address for the host?  I'd be particularly 
interested in knowing how current implementations process name 
constraints on URIs when the host in the subject name is specified using 
an IP address.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 12 Dec 2007 15:36:57 -0500

All,

Some of the 3280bis editors met last week to discuss this issue. The 
text below represents the editors' proposed changes to 3280bis to 
address the URI issue. For convenience, I have included the proposed 
changes in both plain text and as an HTML diff file (attached).

Dave

---------------------------------------

section 4.2.1.6 (Subject Alternative Name), paragraphs 7 and 8:

OLD:

NEW:

As specified in [RFC 3986], the scheme name is not case-sensitive
(e.g., "http" is equivalent to "HTTP"). The host part, if present,
is also not case-sensitive, but other components of the scheme-
specific-part may be case-sensitive. Rules for comparing URIs are
specified in section 7.4.

-------------

section 4.2.1.10 (Name Constraints), paragraph 6:

OLD:

NEW:
For URIs, the constraint applies to the host part of the name. The
constraint MUST be specified as a fully qualified domain name and MAY
specify a host or a domain. Examples would be "host.example.com" and
".example.com". When the the constraint begins with a period, it MAY
be expanded with one or more subdomains. That is, the constraint
".example.com" is satisfied by both host.example.com and
my.host.example.com. However, the constraint ".example.com" is not
satisfied by "example.com". When the constraint does not begin with
a period, it specifies a host. 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.

-------------

10 (Security Considerations), add the following paragraph:

In general, using the nameConstraints extension to constrain one name
form (e.g. DNS names) offers no protection against use of other name
forms (e.g. electronic mail addresses).

-------------

Appendix B (ASN.1 Notes), add the following paragraph:

The content specific rules for encoding GeneralName field values in
the nameConstraints extension differ from rules that apply in other
extensions. In all other certificate, CRL, and CRL entry extensions
specified in this document the encoding rules conform to the rules
for the underlying type. For example, values in the
uniformResourceIdentifier field must contain a valid URI as specified
in [RFC 3986]. The content specific rules for encoding values in the
nameConstraints extension are specified in section 4.2.1.10, and
these rules may not conform to the rules for the underlying type.
For example, when the uniformResourceIdentifier field appears in a
nameConstraints extension, it must hold a DNS name (e.g.,
"host.example.com" or ".example.com") rather than a URI.

4.2.1.6 Subject Alternative Name (paragraphs 7 and 8)

When the subjectAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String). The name
MUST NOT be a relative URL URI, and it MUST follow the URL URI syntax and
encoding rules specified in [RFC 3986]. The name MUST include both a
scheme (e.g., "http" or "ftp") and a scheme-specific-part. The
scheme-specific-part URIs that include an authority ([RFC 3986], section 3.2)
MUST include a fully qualified domain name or IP address as the host.
Rules for encoding internationalized resource identifiers (IRIs) are
specified in section 7.4.

As specified in [RFC 3986], the scheme name is not case-sensitive
(e.g., "http" is equivalent to "HTTP"). The host part, if present,
is also not case-sensitive, but other components of the scheme-
specific-part may be case-sensitive. Rules for comparing URIs are
specified in section 7.4.

4.2.1.10 Name Constraints (paragraph 6)

For URIs, the constraint applies to the host part of the name. The
constraint MUST be specified as a fully qualified domain name and MAY
specify a host or a domain. Examples would be "host.example.com" and
".example.com". When the the constraint begins with a period, it MAY
be expanded with one or more subdomains. That is, the constraint
".example.com" is satisfied by both host.example.com and
my.host.example.com. However, the constraint ".example.com" is not
satisfied by "example.com". When the constraint does not begin with
a period, it specifies a host. 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.

10 Security Considerations (add the following paragraph)

In general, using the nameConstraints extension to constrain one name
form (e.g. DNS names) offers no protection against use of other name
forms (e.g. electronic mail addresses).

Appendix B. ASN.1 Notes (add the following paragraph)

The content specific rules for encoding GeneralName field values in
the nameConstraints extension differ from rules that apply in other
extensions. In all other certificate, CRL, and CRL entry extensions
specified in this document the encoding rules conform to the rules
for the underlying type. For example, values in the
uniformResourceIdentifier field must contain a valid URI as specified
in [RFC 3986]. The content specific rules for encoding values in the
nameConstraints extension are specified in section 4.2.1.10, and
these rules may not conform to the rules for the underlying type.
For example, when the uniformResourceIdentifier field appears in a
nameConstraints extension, it must hold a DNS name (e.g.,
"host.example.com" or ".example.com") rather than a URI.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 20 Dec 2007 11:10:27 -0500

All,

Since there has been no further discussion on this issue, I submitted 
draft -10 of 3280bis with the changes that I proposed in my previous 
email (below).

As usual, I have posted a diff file highlighting the changes between 
drafts -09 and -10, however, no changes were made to the document other 
than the ones noted below.  The diff file is available at 
http://www.csrc.nist.gov/groups/ST/crypto_apps_infra/documents/draft3280bis-09todraft3280bis-10_diff.html.

Dave