Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
draft-ietf-pkix-cert-utf8-03
Approval announcement
Draft of message to be sent after approval:
Announcement
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
Ballot Text
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.