PKIX Working Group                           R. Housley (Vigil Security)
Updates: 3280 (once approved)                   S. Santesson (Microsoft)
Expires August 2006                                        February 2006



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


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than a "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   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.











Housley & Santesson                                             [Page 1]


INTERNET DRAFT     DirectoryString Update to RFC 3280      February 2006


1.  Introduction

   At the time that RFC 3280 [PKIX1] was published, it was very unclear
   how international character sets ought to be supported.
   Implementation experience and deployment experience have made the
   picture much less fuzzy.  This update to RFC 3280 aligns the document
   with this experience and the direction of the IETF PKIX Working
   Group.

   The use of UTF8String and PrintiableString are the preferred
   encoding.  UTF8String provides support for international character
   sets, and PrintiableString preserves support for the vast bulk of the
   certificates that have already been deployed.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [STDWORDS].

3.  Update to RFC 3280, Section 4.1.2.4

   In section 4.1.2.4, RFC 3280 says:

|  The DirectoryString type is defined as a choice of PrintableString,
|  TeletexString, BMPString, UTF8String, and UniversalString.  The
|  UTF8String encoding [RFC 2279] is the preferred encoding, and all
|  certificates issued after December 31, 2003 MUST use the UTF8String
|  encoding of DirectoryString (except as noted below).  Until that
|  date, conforming CAs MUST choose from the following options when
|  creating a distinguished name, including their own:
|
|     (a)  if the character set is sufficient, the string MAY be
|     represented as a PrintableString;
|
|     (b)  failing (a), if the BMPString character set is sufficient the
|     string MAY be represented as a BMPString; and
|
|     (c)  failing (a) and (b), the string MUST be represented as a
|     UTF8String.  If (a) or (b) is satisfied, the CA MAY still choose
|     to represent the string as a UTF8String.
|
|  Exceptions to the December 31, 2003 UTF8 encoding requirements are as
|  follows:
|
|     (a)  CAs MAY issue "name rollover" certificates to support an
|     orderly migration to UTF8String encoding.  Such certificates would
|     include the CA's UTF8String encoded name as issuer and and the old



Housley & Santesson                                             [Page 2]


INTERNET DRAFT     DirectoryString Update to RFC 3280      February 2006


|     name encoding as subject, or vice-versa.
|
|     (b)  As stated in section 4.1.2.6, the subject field MUST be
|     populated with a non-empty distinguished name matching the
|     contents of the issuer field in all certificates issued by the
|     subject CA regardless of encoding.
|
|  The TeletexString and UniversalString are included for backward
|  compatibility, and SHOULD NOT be used for certificates for new
|  subjects.  However, these types MAY be used in certificates where the
|  name was previously established.  Certificate users SHOULD be
|  prepared to receive certificates with these types.
|
|  In addition, many legacy implementations support names encoded in the
|  ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as
|  TeletexString.  TeletexString encodes a larger character set than ISO
|  8859-1, but it encodes some characters differently.  Implementations
|  SHOULD be prepared to handle both encodings.

   This block of text is replaced with:

|  The DirectoryString type is defined as a choice of PrintableString,
|  TeletexString, BMPString, UTF8String, and UniversalString.  CAs
|  conforming to this profile MUST use either the PrintableString or
|  UTF8String encoding of DirectoryString, with one exception.  When
|  CAs have previously issued certificates with issuer fields with
|  attributes encoded using the TeletexString, BMPString, or
|  UniversalString, then the CA MAY continue to use these encodings
|  of the DirectoryString to preserve the backward compatibility.

4.  Update to RFC 3280, Section 4.1.2.6

   In section 4.1.2.6, RFC 3280 says:

|  The subject name field is defined as the X.501 type Name.
|  Implementation requirements for this field are those defined for the
|  issuer field (section 4.1.2.4).  When encoding attribute values of
|  type DirectoryString, the encoding rules for the issuer field MUST be
|  implemented.

   This block of text is replaced with:

|  The subject name field is defined as the X.501 type Name.
|  Implementation requirements for this field are those defined
|  for the issuer field (section 4.1.2.4).  CAs conforming to
|  this profile MUST use either the PrintableString or UTF8String
|  encoding of DirectoryString, with one exception.  When CAs
|  have previously issued certificates with subject fields with



Housley & Santesson                                             [Page 3]


INTERNET DRAFT     DirectoryString Update to RFC 3280      February 2006


|  with attributes encoded using the TeletexString, BMPString, or
|  UniversalString, then the CA MAY continue to use these encodings
|  of the DirectoryString in new certificates for the same subject
|  to preserve backward compatibility.
|
|  Since name comparison assumes that attribute values encoded in
|  different types (e.g., PrintableString and UTF8String) are
|  assumed to represent different strings, any name components that
|  appear in both the subject field and the issuer field SHOULD
|  use the same encoding throughout the certification path.

5.  Security Considerations

   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.

6.  Normative References

   [PKIX1]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
               X.509 Public Key Infrastructure Certificate and
               Certificate Revocation List (CRL) Profile", RFC 3280,
               April 2002.

   [STDWORDS]  S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

7.  IANA Considerations

   None.  Please remove this section prior to publication as an RFC.




















Housley & Santesson                                             [Page 4]


INTERNET DRAFT     DirectoryString Update to RFC 3280      February 2006


Authors' Addresses


   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley(at)vigilsec.com


   Stefan Santesson
   Microsoft
   Tuborg Boulevard 12
   2900 Hellerup
   Denmark

   EMail: stefans(at)microsoft.com

Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















Housley & Santesson                                             [Page 5]