Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

From: "Stefan Santesson" <[email-masked]>
Date: Thu, 6 May 2004 01:18:25 +0100

Steve,

There is one unfortunate side effect that makes this requirement worse
than other evolutions of standards.

It is almost never feasible to replace all certificates in a hierarchy
at once. This means that you over time will have a mixed environment
where e.g. the same organization name will exist in different encoding
in many places of your hierarchy.

It will then be virtually impossible to apply name constraining in such
environment because RFC 3280 does not mandate the full X.500 name
matching rules and a client may subsequently decide that names with
different encoding is a no-match.

This seams to be an unsolvable problem that, looking in the mirror, is
inadequately addressed and shouldn't have passed in its current form. In
fact it is probably a defect that needs to be addressed in sonOfRfc3280
in one way or the other.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 5 maj 2004 13:36
> To: Santoni Adriano
> Cc: [email-masked]'; [email-masked]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> >A rule that is "at odds with reality" should not be expressed in
terms of
> >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
3280
> >reached the status of an official IETF standard, if it contains one
or
> more
> >areas that are "at odds with reality".
> >
> >I suppose the answer is one of these:
> >- RFC 3280 does not really contain areas that are "at odds with
reality"
> -
> >it's just that we do not understand them;
> 
> RFC 3280 established a requirement for a change in how DNs are
> encoded, for a future point in time. Thus, at the time the RFC was
> published as a standard of course it did not match "reality." since
> it was calling for a change.  By the way, this change was not the
> idea of the PKIX WG but rather is consistent with the overall IETF
> mandate to better accommodate character sets for a wide range of
> languages.
> 
> >- containing areas that are "at odds with reality" is not an obstacle
to
> >becoming a standard;
> 
> Think of the implication of your comment. if we were never able to
> call for a change in how things are done when we update a standard,
> then we could never make any changes.  obviously this would be unduly
> limiting.
> 
> >- expressions like "MUST" in IETF standard are really to be taken as
mere
> >suggestions;
> 
> IETF standards are voluntary. failure to comply is not punishable :-)
> 
> >- nobody really cares.
> 
> one might say that in environments where a few vendors or service
> providers control a significant market share, their deviation from
> standards, or failure to accommodate changes in standards, can have
> profound impacts.
> 
> Steve

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Thu, 6 May 2004 14:39:51 +0800

RFC 3280 does not ask CAs to replace all certificates at once for
migrating to UTF8String encoding. Instead, it suggest that
   "CAs MAY issue "name rollover" certificates to support an
     orderly migration to UTF8String encoding."

I believe that if relying parties use 3280-compliant certification path
validation modules, then they will not have problem for processing
"name rollover" certificates, and thus the migration to UTF8String
encoding will not be a problem.

One thing should be noted: a "name rollover" certificate is essentially
a "self-issued certificate" but its issuer name and subject name is in
different encoding. Therefore, the definition of "self-issued certificate"
should be changed a little. Also, since a "name rollover" certificate may
contains a NameConstraints extension in which the permittedSubtrees
and excludedSubtrees will be in a new encoding (e.g., UTF8String),
the path validation in RFC 3280 also need to be revised. I hope all of
these should be addressed in sonOfRfc3280.

I don't think that RFC 3280 mandates the support for UTF8String
encoding is "at odds with reality". There are many countries/regions
in the world where it is impossible to encode names in Printable String.
In Taiwan, we have already millions of certificates with issuer names
and subject names encoded in UTF8String.

Three years ago, I tested some VPN devices and found most of them
can not accept certificates with UTF8String (One of them even crashed
if received a certificate with UTF8String). Recently, I test many VPN
devices
again and amazingly found the all of them can normally handle certificates
with
UTF8String. All of them can chain and validate certificte paths that
contains
certificates with UTF8String. (Although, most of them still can not display
the
UTF8String in Chinese correctly. It is a pity.)

The truth is that there are more and more applications that can handling
UTF8String encoding. I think the credit should give to RFC 3280 for its
mandating  for UTF8String encoding.

Wen-Cheng Wang

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Stephen Kent" <[email-masked]>; "Santoni Adriano"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, May 06, 2004 8:18 AM
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs