Internet Draft                                          Paul Hoffman
draft-hoffman-pkix-stringmatch-00.txt       Internet Mail Consortium
July 7, 2004                                             Steve Hanna
Expires in six months                               Sun Microsystems

                Matching Text Strings in PKIX Certificates

By submitting this Internet-Draft, we certify that any applicable patent
or other IPR claims of which we are aware have been disclosed, or will
be disclosed, and any of which we become aware will be disclosed, in
accordance with RFC 3668.

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

Abstract

Strings of text appear in many fields in PKIX certificates. Some
applications need to compare the values in these fields to strings
from other certificates, or to values obtained in other manners.
For many string encodings, this can be done in an octet-by-octet
fashion. Other encodings, however, require preparation before the
strings can be compared. This document describes that preparation
and when it needs to be applied.

. Introduction

Because of the shared background of PKIX, LDAP, and X.500, matching
strings from PKIX certificates uses the same principles as matching
strings from X.500 directories. Therefore, this document simply refers
to the specification for matching LDAP strings. The [LDAP-STRINGPREP]
document fully specifies all the steps needed for string comparison.
This specification applies to all string encodings supported by PKIX.

When matching names in certificates, having consistent and well-defined
matching rules is important. Otherwise, many security problems can
occur, as described in the Security Considerations section of this
document. In addition to these security problems, there will likely be
usability problems. In Unicode, there are often several valid ways to
encode a string. For example, the character for "e with an accent" can
be represented either as a single character, or as a string of two
characters: the letter "e" followed by the combining accent character.
These should be considered equivalent. With stringprep, they are, but
with binary comparison, they are not.

1.1 Terminology

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


. String Comparison

To compare a string from a PKIX certificate to another string, both
strings MUST be prepared as specified in section 2 of [LDAP-STRINGPREP].
All six sub-sections of that specification MUST be performed, and they
MUST be performed in the order specified.

2.1 Applicability of this specification

The most important certificate fields that this specification applies to
are those with names that are created by and for people. These include
any place a Name, GeneralName, or GeneralNames structures. The most
commonly used fields in an X.509 certificate that use these structures
are issuer, subject, subjectAltName, NameConstraints, and
DistributionPoint.

This algorithm SHOULD NOT be used for matching CRL distribution point
names or cRLIssuer. A binary comparison SHOULD be used for such mapping.
There is no reason why a distribution point name or cRLIssuer should not
match exactly because they are both generated by the same party or its
CRL issuer. Also, an interloper might use an inexact match to forge a
CRL by getting a certificate whose subject name matches the cRLIssuer
contained in another certificate due to the inexact match.



. Security considerations

All security considerations from [LDAP-STRINGPREP] are inherited. In
addition to the security considerations mentioned in [LDAP-STRINGPREP],
there are several others specific to certificates.

Matching of X.500 names currently varies widely in different
implementations. Some do a binary comparison for UTF8String. Some
attempt to do a more sophisticated case-insensitive comparison but use
an algorithm different than the one given in this specification. Some
will soon be using this algorithm. We can expect that such wide
variations will continue in the future during a transition period and
even beyond this period if bugs are present.

Often, such variations will cause systems to fail safe. Path validation
will fail when a relying party uses binary comparison to match X.500
names that differ slightly if the match is performed as part of
subject-issuer name chaining or permittedSubtrees processing.

However, security vulnerabilities may be opened if the CA assumed binary
comparison would be used and the relying party uses the more lenient
matching for subject-issuer name chaining or permittedSubtrees
processing. For subject-issuer name chaining, the signature check should
catch the problem, but for permittedSubtrees processing, the problem
remains. In specific, an X.500 name that the CA did not intend to
include in the permittedSubtrees might be allowed. It is not clear that
this is a substantial problem since the name will likely be very similar
in appearance to a name that was meant to be allowed.

More substantial problems can occur if a relying party uses binary
comparison to determine that an X.500 name does not match
excludedSubtrees and the CA expected that it would match because of the
more lenient processing. However, this problem is probably already
present since some relying parties do not perform case-insensitive
comparisons of PrintableString components in a DirectoryString, even
though it is required by RFC 3280. To avoid these problems, systems need
to avoid the use of excludedSubtrees unless they are satisfied with a
binary match against subject names and subject alternative names.


. References

4.1 Normative references

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

[LDAP-STRINGPREP] Zeilenga, K., LDAP: Internationalized String Preparation
draft-ietf-ldapbis-strprep, work in progress


. Author's address

Paul Hoffman
Internet Mail Consortium
phoffman@imc.org

Steve Hanna
Steve.Hanna@Sun.COM


. Open issues

Should this specification apply to all names in an X.509 certificate, or
only DirectoryStrings in X.500 names?

Should this spec apply to self-signed certificates, or should they
be an exception?


. Notices

Copyright (C) The Internet Society (2004).  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.

</x-flowed>