Subject: son-of-rfc3280 (grandson-of-rfc2459)

From: Russ Housley <[email-masked]>
Date: Wed, 11 Jun 2003 09:55:28 -0400

Dear PKIX WG:

I believe that an update to RFC 3280 is needed.  There are three major 
reasons that I believe an update is necessary:

1.  ITU-T is looking at changes to X.509 key usage extension.  The text in 
RFC 3280 section 4.2.1.3 has lead to a debate, which is not completely 
resolved.  Hoyt Kesterson has agreed to let the PKIX WG comment on the 
proposed text prior to publication.  So, once everyone is equally unhappy 
with the text, then both the ITU-T and the IETF should update their 
respective documents.

2.  Issues with UTF8 needs to be handled more clearly.  I believe that this 
should not be done until all of the issues associated with the use of UTF8 
in DNS are resolved.  I believe that certificates must use many of the same 
string comparison mechanisms as the DNS, and two solutions are unacceptable.

3.  Correct the error in section 6.3.3.  (see 
http://www.rfc-editor.org/errata.html).

Speaking as a co-author of RFC 3280, not as the Security Area Director,
    Russ

---

From: "todd glassey" <[email-masked]>
Date: Wed, 11 Jun 2003 09:05:09 -0700

I support Russ' assertion and also agree that a new revision of 3280 is
necessary too.

Todd

---

From: Steve Hanna <[email-masked]>
Date: Wed, 11 Jun 2003 11:19:06 -0400

Russ Housley wrote:
> I believe that an update to RFC 3280 is needed.

I think this is a great idea. As RFC 3280 interoperability
testing proceeds, we will have a list of minor glitches and
clarifications for RFC 3280 that need to be fixed. In fact,
I have a long list already. As long as we avoid making any
disruptive changes to the document (and assuming that
interoperability testing goes well), maybe son-of-3280 can be
published as a Draft Standard. I hope so!

As for UTF8 handling, I'm not sure that RFC 3280 is unclear.
It's just not very demanding (since it allows people to just
do a binary comparison when matching UTF8Strings). Maybe it
could/should be clearer in saying that relying parties MUST
support UTF8String. Right now it says that UTF8String is the
preferred encoding and that all certs issued after December
31, 2003 MUST use UTF8String. It seems to follow pretty clearly
that relying parties MUST be able to handle UTF8String. But
maybe that isn't clear enough. It would be nice if it was
explicit.

I do think that we should have another document that talks
about how to handle UTF8String properly, beyond binary matching.
Binary matching for UTF8String was OK in 1999 (maybe), but
it's certainly not any more. PKI usage in Japan and Korea is
moving along quickly and poor support for UTF8String is holding
it back.

Fortunately, a lot of work has already been done on defining
proper handling for UTF8String in X.500 names. Kurt Zeilenga
and others from the IETF have been working with the ITU/ISO
X.500 team to develop a clear algorithm for UTF8String matching,
based on the work of the Internationalized Domain Names working
group (RFC 3454, etc.). The ldapbis working group has a new
Internet Draft (draft-ietf-ldapbis-strprep-00.txt) that describes
this algorithm and how it should be used in LDAP. Something
similar should be done for PKIX. I don't think this is ready
to jump into son-of-3280, since I don't think we have enough
implementation and deployment experience yet. But it could go
Proposed Standard while son-of-3280 goes Draft Standard. And
maybe it could catch up eventually.

Who will be the primary editor for son-of-3280? Will you be
able to fit it into your busy schedule? I hope so. You did
a great job with RFC 3280.

Thanks,

Steve Hanna