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.