[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC 3280bis and URI schemes without hostname




Folks,

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

Stephen Farrell posted the proposed 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.



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