Subject: New I-D on Intl Strings in Certs

From: Steve Hanna <[email-masked]>
Date: Mon, 12 Jul 2004 08:39:25 -0400

Among the recent flurry of Internet Draft
announcements was the one below. This is
the long-promised document by Paul Hoffman
and myself on how to handle Unicode and
other international strings in certificates.

Please review the document, considering
especially the open issues highlighted
therein. We will lead a discussion on
these topics at IETF 60, but it would be
great to get an email discussion going
first.

We have coordinated with the ISO, ldapbis,
and idn folks on this effort. We want to
make sure all our documents are compatible
so that you can use the same techniques
(and the same code) for comparing X.500
names with all these standards. That's why
this document is fairly small, pointing
people to the ldapbis specs for details.

So please review this document and send
comments to the PKIX list.

Thanks,

Steve

-------- Original Message --------
Subject: I-D ACTION:draft-hoffman-pkix-stringmatch-00.txt
Date: Fri, 09 Jul 2004 15:26:26 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Matching Text Strings in PKIX Certificates
	Author(s)	: P. Hoffman, S. Hanna
	Filename	: draft-hoffman-pkix-stringmatch-00.txt
	Pages		: 0
	Date		: 2004-7-9
	
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-pkix-stringmatch-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-hoffman-pkix-stringmatch-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hoffman-pkix-stringmatch-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

---

From: Russ Housley <[email-masked]>
Date: Mon, 12 Jul 2004 13:29:58 -0400

Many thanks to Steve and Paul for generating this document.

I would like to see an additional section in this document.  When otherName 
forms are registered, some of these will in include text strings.  However, 
they will probably not make use of GeneralName or Name.  Therefore, I think 
it would be useful to list the ASN.1 types where these rules should be 
applied.  UTF8String is obvious.  What esle?

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 12 Jul 2004 15:22:32 -0700

All,

Please consider and comment on the following.
Discussions will be held on the IPSEC list.

Michael Myers

-----Original Message-----
From: [email-masked]
Sent: Monday, July 12, 2004 12:36 PM

A New Internet-Draft is available from the on-line
Internet-Drafts directories.

	Title		: OCSP Extensions to IKEv2
	Author(s)	: M. Myers, H. Tschofenig
	Filename	: draft-myers-ipsec-ikev2-oscp-00.txt
	Pages		: 8
	Date		: 2004-7-12

While IKEv2 supports public key based authentication (PKI), the
corresponding use of in-band CRLs is problematic due to
unbounded CRL
size.  The size of an OCSP response is however well-bounded and
small.
This document defines two extensions to IKEv2 which enable the
use of
OCSP for in-band signaling of certificate revocation status.
Two new
content encodings are defined for use in the CERTREQ and CERT
payloads:
OCSP Responder Hash and OCSP Response.  An OCSP Responder Hash
CERTREQ
payload triggers transmission of an OCSP Response CERT payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp
-00.txt

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 17 Jul 2004 03:31:20 +1200

Steve Hanna <[email-masked]> writes:

>So please review this document and send comments to the PKIX list.

Here's mine.

>This algorithm SHOULD NOT be used for matching CRL distribution point names
>or cRLIssuer. A binary comparison SHOULD be used for such mapping.

Is there any reason why binary comparison is OK for finding who issued a CRL,
but not for who issued a cert?

>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.

This begs the question of "Why the &*^#&$# would any CA in its right mind ever
issue a certificate where the issuer.suject DN gratuitously differs from the
subject.issuer DN by an extra space or something similar?".  You'd have to
deliberately add code to break the DN as it goes from parent to child.  Why
not say:

  Any CA that issues certificates where the issuer.suject DN gratuitously
  differs from the subject.issuer DN should be considered broken, with
  handling of its certs not guaranteed by this specification.

(you can rephrase that as MUST and whatnot if you want).

>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.

It doesn't matter what algorithm they use, you can always escape
excludedSubtrees by clever encoding of your DNs (see the X.509 style guide for
the details).  The draft should warn (like the RFC currently does) that you
can't rely on excludedSubtrees to exclude certs from non-cooperating cert
issuers (that is, ones that will create DNs with strings encoded so as to
avoid the exclusion).

Peter.

---

From: Steve Hanna <[email-masked]>
Date: Thu, 29 Jul 2004 16:15:14 -0400

Russ Housley wrote:
 > I would like to see an additional section in this document.  When
 > otherName forms are registered, some of these will in include text
 > strings.  However, they will probably not make use of GeneralName or
 > Name.  Therefore, I think it would be useful to list the ASN.1 types
 > where these rules should be applied.  UTF8String is obvious.  What
 > else?

In my experience, many name forms have their own matching
rules. For instance, DNS names are case-insensitive.
RFC822Names use receiver-specific matching conventions in
the localpart and case-insensitive matching for the domain.

I'd be reluctant to specify any rules for future name forms,
but maybe we can come up with some guidelines. For instance,
we could say that name forms that include Unicode strings
(BMPString, UnicodeString, or UTF8String) SHOULD consider
using a variant of the stringprep algorithm and MUST specify
a clear, well-defined algorithm for name matching or
prohibit the use of these name forms in name constraints.

Would that address your concern?

Thanks,

Steve

P.S. Maybe this document should describe how to handle
international characters when matching DNS names, URIs,
and RFC 822 names in certificates (in name constraints).
But I'd be inclined to specify these in separate documents,
especially since internationalization of email addresses
is not settled yet.

---

From: Steve Hanna <[email-masked]>
Date: Thu, 29 Jul 2004 16:15:05 -0400

Peter,

I apologize for taking so long to respond to
your email. I'm changing jobs (moving from
Sun to a small software company, Funk Software).
Arranging the changeover has kept me busy.
Unfortunately, I won't be able to attend
IETF 60 next week since that will be my first
week at Funk. But I hope things will continue
smoothly on Monday. My new email address will
be [email-masked]. Anyway, on to business.
Let me respond to your comments.

> (you can rephrase that as MUST and whatnot if you want).

In general, I agree that it's best to avoid any
differences between the subject name of one
certificate and the issuer name of the next.
However, there are times when such a difference
is inevitable. For example, some CAs require
(because of technical or policy reasons) that
a particular encoding be used in all certs
that they issue. This encoding may differ from
the one used by other CAs for the same names.

More important is the problem of name constraints.
It's common for a certificate to include a name
constraint which applies to subject names and
subject alternative names in many other certificates.
These certificates may use different encodings for
those subject names and subject alternative names
than the one used in the name constraint. They may
also have minor differences in capitalization or
spacing. Therefore, it's important to support matching
distinguished names while ignoring unimportant
differences (as described in X.509).

 >>This algorithm SHOULD NOT be used for matching CRL
 >>distribution point names or cRLIssuer. A binary
 >>comparison SHOULD be used for such mapping.
 >
 > Is there any reason why binary comparison is OK for finding
 > who issued a CRL, but not for who issued a cert?

As you said above, its better to use binary matching
when possible. In this case, I don't see any reason
not to. A CA should easily be able to provide an
exact binary value for CRL distribution point name
and cRLIssuer. Also, the only binding between a
certificate and its CRL issuer is the name (cRLIssuer).
With subject-issuer name chaining, the subject public
key of a certificate must verify the signature on the
subsequent certificate. This reinforces the need to
avoid malicious or accidental mismatches with cRLIssuer.

> issuers (that is, ones that will create DNs with strings encoded so as to

I agree that using excludedSubTrees is not a good idea.
We'll strengthen the wording in the next revision.

Thanks,

Steve