Subject: [pkix] Clarification on support for internationalization

From: "David A. Cooper" <[email-masked]>
Date: Thu, 25 Mar 2010 13:06:22 -0700

All,

This is just to clarify a couple of issues about the RFC 5280 
implementation report, as described in the most recent meeting minutes 
(http://www.ietf.org/proceedings/10mar/minutes/pkix.htm).

    The encoding rules for the explicitText field of the userNotice
    policy qualifier need to be revised to "redeem" VisibleString (make
    it a MAY), and deprecate IA5String for a userNotice in a policy
    qualifier. We will conduct a straw poll on the list to decide
    whether to make BMPString a MAY here (a co-equal alternative), to
    accommodate what appears to be common Microsoft CA practice, or
    leave it as a deprecated alternative. Note that support for
    UTF8String is the SHOULD here, but no support was found for that
    capability. David's report suggests relegating it to MAY status.

I should clarify that I made no attempt to use different CA products to 
create certificates with user notices.  I only looked for certificates 
with user notices in the certificates that I obtained from signed emails 
and from TLS protected web servers.  All of the user notices that I 
found were encoded in VisibleString, but they were also all in English, 
so I don't think my findings should be used to address the preferred way 
to encode user notices that make use of characters that are not part of 
VisibleString.  I would be inclined to leave UTF8String as the SHOULD 
since this seems to be the encoding that is generally recommended for 
use by the IETF (and RFC 5280) whenever there is a need to be able to 
encode strings with non-ASCII characters.

    Tim said that we could probably get an exception for progressing the
    document despite the lack of support for internationalized names.
    Paul Hoffman suggested that we check with CAs in Japan that would
    serve as an example of support for this function. He also offered to
    generate certificates based on example.com (where the first e in
    example has an accent). David also identified a lack of support for
    the string prep processing of internationalized names, especially
    for domains names in domain component attributes in DNs. Although
    this has not yet proved to be a significant operational problem, it
    is an example of a MUST for which we have filed to find
    implementation support. Stefan Santesson raised the question whether
    the internationalization could be moved to an informative annex
    since the fields that contain internationalized characters are
    opaque with respect to the certificate syntax. This will be
    investigated.

I've copied below the set of requirements that I extracted from Section 
7 of RFC 5280.  Section 7.1 imposes requirements on client software with 
respect to comparing attributes that use DirectoryString.  This is the 
requirement for which I tried a few implementations and determined that 
none of them were performing StringPrep prior to comparing strings.

I did not look into the internationalized domain names, but there is an 
argument that these requirements are less important since issuers could 
receive these names as input after they have been converted to ASCII, 
and relying parties are only required to perform case insensitive 
matches on the ASCII encodings of the names.  There are also 
requirements about performing scheme based normalization on URIs, but I 
didn't perform any testing on this.

Dave

Section
	Requirement
7.1 	Conforming implementations MUST use the LDAP StringPrep profile 
(including insignificant space handling), as specified in [RFC4518], as 
the basis for comparison of distinguished name attributes encoded in 
either PrintableString or UTF8String. Conforming implementations MUST 
support name comparisons using caseIgnoreMatch.
7.1 	Before comparing names using the caseIgnoreMatch matching rule, 
conforming implementations MUST perform the six-step string preparation 
algorithm described in [RFC4518] for each attribute of type 
DirectoryString, with the following clarifications:

* In step 2, Map, the mapping shall include case folding as
specified in Appendix B.2 of [RFC3454].

* In step 6, Insignificant Character Removal, perform white space
compression as specified in Section 2.6.1, Insignificant Space
Handling, of [RFC4518].

When performing the string preparation algorithm, attributes MUST be 
treated as stored values.
7.2 	To accommodate internationalized domain names in the current 
structure, conforming implementations MUST convert internationalized 
domain names to the ASCII Compatible Encoding (ACE) format as specified 
in Section 4 of RFC 3490 before storage in the dNSName field. 
Specifically, conforming implementations MUST perform the conversion 
operation specified in Section 4 of RFC 3490, with the following 
clarifications:

* in step 1, the domain name SHALL be considered a "stored
string". That is, the AllowUnassigned flag SHALL NOT be set;

* in step 3, set the flag called "UseSTD3ASCIIRules";

* in step 4, process each label with the "ToASCII" operation; and

* in step 5, change all label separators to U+002E (full stop).
7.2 	When comparing DNS names for equality, conforming implementations 
MUST perform a case-insensitive exact match on the entire DNS name.
7.2 	When evaluating name constraints, conforming implementations MUST 
perform a case-insensitive exact match on a label-by-label basis.
7.2 	Implementations should convert IDNs to Unicode before display. 
Specifically, conforming implementations should perform the conversion 
operation specified in Section 4 of RFC 3490, with the following 
clarifications:

* in step 1, the domain name SHALL be considered a "stored
string". That is, the AllowUnassigned flag SHALL NOT be set;

* in step 3, set the flag called "UseSTD3ASCIIRules";

* in step 4, process each label with the "ToUnicode" operation; and

* skip step 5.
7.2 	Note: Implementations MUST allow for increased space requirements 
for IDNs. An IDN ACE label will begin with the four additional 
characters "xn--" and may require as many as five ASCII characters to 
specify a single international character.
7.3 	Each domainComponent attribute represents a single label. To 
represent a label from an IDN in the distinguished name, the 
implementation MUST perform the "ToASCII" label conversion specified in 
Section 4.1 of RFC 3490. The label SHALL be considered a "stored 
string". That is, the AllowUnassigned flag SHALL NOT be set.
7.3 	Conforming implementations shall perform a case-insensitive exact 
match when comparing domainComponent attributes in distinguished names, 
as described in Section 7.2.
7.3 	Implementations should convert ACE labels to Unicode before 
display. Specifically, conforming implementations should perform the 
"ToUnicode" conversion operation specified, as described in Section 7.2, 
on each ACE label before displaying the name.
7.4 	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.
7.4 	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.
7.4 	Implementations should convert URIs to Unicode before display. 
Specifically, conforming implementations should perform the conversion 
operation specified in Section 3.2 of [RFC3987].
7.5 	Where the host-part (the Domain of the Mailbox) contains an 
internationalized name, the domain name MUST be converted from an IDN to 
the ASCII Compatible Encoding (ACE) format as specified in Section 7.2.
7.5 	Two email addresses are considered to match if:

1) the local-part of each name is an exact match, AND

2) the host-part of each name matches using a case-insensitive
ASCII comparison.
7.5 	Implementations should convert the host-part of internationalized 
email addresses specified in these extensions to Unicode before display. 
Specifically, conforming implementations should perform the conversion 
of the host-part of the Mailbox as described in Section 7.2.