RFC 4630

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

📅 published August 2006, from ietf

RFC 4630 📜✨

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

Okay bestie, the header is giving: it's by Russell Housley (Vigil Security) and Stefan Santesson (Microsoft) 🎀 It's Standards Track 🦋 It's dated August 2006 🌸 and it updates RFC 3280. The header doesn't list anything it obsoletes. 💅

Status of This Memo

This one's an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements 🫶 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (2006) 🩷

Abstract ✨

This doc updates how DirectoryString gets handled in the Internet X.509 PKI Certificate and CRL Profile, which is RFC 3280 🎀 UTF8String and PrintableString are now the preferred encodings 💜 And the rule that made UTF8String exclusive after December 31, 2003 is gone 💀

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

1. Introduction 🍓

Okay so, when RFC 3280 [PKIX1] came out, nobody was really sure how international character sets should work 😭 Since then, people have implemented it and deployed it, so the picture is way clearer now 🔥 This update lines the doc up with that experience and with where the IETF PKIX Working Group is heading 👑

UTF8String and PrintableString are the preferred encodings now. UTF8String handles international character sets, and PrintableString keeps working for the huge pile of certificates that are already out there in the wild 🫶

2. Terminology 💅

The key words are used like this, and it's giving rule book:

"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 🎀

Here's the original RFC 3280 text for Section 4.1.2.4, so you can see what's getting swapped out 👀

      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 the old 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 gets replaced with the following:

      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, 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: Subject 🦋

Next up is Section 4.1.2.6. Here's what RFC 3280 says now 🌸

      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 gets replaced with the following:

      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 attributes encoded
      using the TeletexString, BMPString, or UniversalString, 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. Update to RFC 3280, Section 4.2.1.7: Subject Alternative Name 💜

Last one. This is the original Section 4.2.1.7 text 💀

      When the subjectAltName extension contains a DN in the
      directoryName, the DN MUST be unique for each subject entity
      certified by the one CA as defined by the issuer name field.  A CA
      MAY issue more than one certificate with the same DN to the same
      subject entity.

This block of text gets replaced with the following:

      When the subjectAltName extension contains a DN in the
      directoryName, the encoding preference is defined in Section
      4.1.2.4.  The DN MUST be unique for each subject entity certified
      by the one CA as defined by the issuer name field.  A CA MAY issue
      more than one certificate with the same DN to the same subject
      entity.

6. Security Considerations 🚨

Okay, this part is serious, so listen up 🫢 Using consistent encoding for name components is what makes sure the name constraints in [PKIX1] actually work the way they're supposed to ✨

Now the visual stuff. When strings get mapped from their internal form to what people see, two different strings can end up looking the same or super similar 😱 That happens for lots of reasons: similar-looking glyphs, and composed characters (like e + ' making U+00E9, Korean composed characters, and vowels stacked above consonant clusters in some languages) 🙈 So people doing visual comparisons between two different names might think they match when they really don't. People can also mix one string up with another. Both certificate issuers and relying parties need to be aware of this, periodt 🚨💀

7. 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]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses 🧚

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

EMail: housley@vigilsec.com


Stefan Santesson
Microsoft
Tuborg Boulevard 12
2900 Hellerup
Denmark

EMail: stefans@microsoft.com

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.

Intellectual Property 🔐

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Info on procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org.

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🌈

Okay bestie, that's the whole RFC! 🎀✨ Go slay your certificate parsing 💅🦋

📦 where this page comes from