Re: RFC 3280bis and URI schemes without hostname

[Stephen Farrell <stephen.farrell@xxxxxxxxx>]

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