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 [RFC3986]. The name MUST include both a

scheme (e.g., "http" or "ftp") and a scheme-specific-part. URIs that

include an authority ([RFC3986], 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.

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 constraint begins with a period, it MAY be

expanded with one or more labels. 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.

To accommodate IRIs in the current structure, conforming

implementations MUST map IRIs to URIs as specified in Section 3.1 of

[RFC3987], with the following clarifications:

* in step 1, generate a UCS character sequence from the original

IRI format normalizing according to the NFC as specified in

Variant b (normalization according to NFC);

* perform step 2 using the output from step 1.

Implementations MUST NOT convert the ireg-name component before

performing step 2.

Before URIs may be compared, conforming implementations MUST perform

a combination of the syntax-based and scheme-based normalization

techniques described in [RFC3987]. Specifically, conforming

implementations MUST prepare URIs for comparison as follows:

* Step 1: Where IRIs allow the usage of IDNs, those names MUST be

converted to ASCII Compatible Encoding as specified in Section

7.2 above.

* Step 2: The scheme and host are normalized to lowercase, as

described in Section 5.3.2.1 of [RFC3987].

* Step 3: Perform percent-encoding normalization, as specified in

Section 5.3.2.3 of [RFC3987].

* Step 4: Perform path segment normalization, as specified in

Section 5.3.2.4 of [RFC3987].

* Step 5: If recognized, the implementation MUST perform scheme-

based normalization as specified in Section 5.3.3 of [RFC3987].

Conforming implementations MUST recognize and perform scheme-based

normalization for the following schemes: ldap, http, https, and ftp.

If the scheme is not recognized, step 5 is omitted.

When comparing URIs for equivalence, conforming implementations shall

perform a case-sensitive exact match.

Implementations should convert URIs to Unicode before display.

Specifically, conforming implementations should perform the

conversion operation specified in Section 3.2 of [RFC3987].

URI-ID = a subjectAltName entry of type

uniformResourceIdentifier whose value includes both (i) a

"scheme" and (ii) a "host" component (or its equivalent) that

matches the "reg-name" rule (where the quoted terms represent

the associated [ABNF] productions from [URI]); see [PKIX] and

[URI]