Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 4630

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    pkix mailing list <ietf-pkix@imc.org>, 
    pkix chair <pkix-chairs@tools.ietf.org>
Subject: Protocol Action: 'Update to DirectoryString Processing 
         in the Internet X.509 Public Key Infrastructure Certificate and 
         Certificate Revocation List (CRL) Profile' to Proposed Standard 

The IESG has approved the following document:

- 'Update to DirectoryString Processing in the Internet X.509 Public Key 
   Infrastructure Certificate and Certificate Revocation List (CRL) 
   Profile '
   <draft-ietf-pkix-cert-utf8-04.txt> as a Proposed Standard

This document is the product of the Public-Key Infrastructure (X.509) 
Working Group. 

The IESG contact persons are Sam Hartman and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cert-utf8-04.txt

Technical Summary
 
  This document updates the handling of DirectoryString in the Internet
  X.509 Public Key Infrastructure Certificate and Certificate Revocation
  List (CRL) Profile, which is published in RFC 3280.  This update to
  RFC 3280 aligns support for international character sets with recent
  implementation and deployment experience, and the direction of the
  IETF PKIX Working Group.  This specification establishes UTF8String
  and PrintableString as the preferred encodings.  UTF8String provides
  support for international character sets, and PrintableString
  preserves support for the vast bulk of the certificates that have
  already been deployed.

 
Working Group Summary
 
   The WG has a strong consensus behind this document.
 
Protocol Quality
 
  This specification aligns RFC 3280 with current implementations,
  reflecting the international PKI community's deployment experience.

  This specification has been reviewed by Sam Hartman for the IESG.

Note to RFC Editor
 
Please revise the first sentence in the replacement text in Section 5.

OLD:

|  When the subjectAltName extension contains a DN in the directoryName,
|  the same encoding preference as in 4.1.2.4.

NEW:

|  When the subjectAltName extension contains a DN in the directoryName,
|  the encoding preference is defined in 4.1.2.4.


In section 6:
OLD:

   The replacement text is much clearer.  The direction is much less
   prone to implementation error.  Also, the use of consistent encoding
   for name components will ensure that name constraints work as
   expected.

NEW:

   The use of consistent encoding for name components will ensure that name
   constraints specified in [PKIX1] work as expected.

   When strings are mapped from internal representations to visual
representations,
   sometimes two different strings will have the same or similar visual represe
ntations.
   This can happen for many different reasons, including use of similar glyphs
and
   use of composed characters (such as e + ' equaling U+00E9, the Korean
   composed characters, and vowels above consonant clusters in certain language
s).
   As a result of this situation, people doing visual comparisons between two
   different names may think they are the same when in fact they are not.  Also
,
   people may mistake one string for another.  Issuers of certificates and rely
ing
   parties both need to be aware of this situation.