datatracker.ietf.org
Sign in
Version 5.6.2.p3, 2014-07-31
Report a bug

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

Document type: RFC - Proposed Standard (August 2006; No errata)
Obsoleted by RFC 5280
Updates RFC 3280
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4630 (Proposed Standard)
Responsible AD: Sam Hartman
Send notices to: pkix-chairs@tools.ietf.org, housley@vigilsec.com, stefans@microsoft.com

Network Working Group                                         R. Housley
Request for Comments: 4630                                Vigil Security
Updates: 3280                                               S. Santesson
Category: Standards Track                                      Microsoft
                                                             August 2006

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

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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.  The
   use of UTF8String and PrintableString are the preferred encoding.
   The requirement for exclusive use of UTF8String after December 31,
   2003 is removed.

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Update to RFC 3280, Section 4.1.2.4: Issuer .....................2
   4. Update to RFC 3280, Section 4.1.2.6: Subject ....................3
   5. Update to RFC 3280, Section 4.2.1.7: Subject
      Alternative Name ................................................4
   6. Security Considerations .........................................4
   7. Normative References ............................................5

Housley & Santesson         Standards Track                     [Page 1]
RFC 4630           DirectoryString Update to RFC 3280        August 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 PrintableString are the preferred encoding.
   UTF8String provides support for international character sets, and
   PrintableString 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: Issuer

   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.

Housley & Santesson         Standards Track                     [Page 2]
RFC 4630           DirectoryString Update to RFC 3280        August 2006

   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 the old name encoding as subject,
              or vice-versa.

         (b)  As stated in section 4.1.2.6, the subject field MUST be

[include full document text]