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 14:32:41 +0100

Name rollover certificates only takes care of CA name changes.
It doesn't solve the problem if subject names have mixed encoding in the
forest of user certificates, while the CAs names are intact.

Neither does it solve when the constraint is placed above the CA
rollover.

Finally, CA name rollover will most likely bust path validation using
other constraining mechanisms because they may just not be recognized as
self issued due to different name encoding. 

Stefan Santesson
Program Manager, Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 5 maj 2004 23:40
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> 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
> 
> 
> >
> >
> > 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: Steve Hanna <[email-masked]>
Date: Thu, 06 May 2004 10:25:15 -0400

A better solution is to require (or at least recommend)
the ability to properly compare PrintableString and
UTF8String encodings. Paul Hoffman and I are working
on an Internet Draft describing how to do this (based
on the IDN and LDAP documents on the same topic).
This handles name constraints earlier in the path, etc.

Thanks,

Steve

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 06 May 2004 17:47:45 +0200

Steve Hanna wrote:

> UTF8String encodings.

This still leave to the CA the task of enforcing the user certs only use 
PrintableString or UTF8String.
Either by refusing requests with other encodings or converting them.
Given the current text of RFC3280 this is probably the best choice.

But an application like openssl is currently shipped with the default of 
authorizing either of PrintableString and T61String and nothing else.
If some people do emit T61String (it does happen at least on a small 
scale), they'll need to be able to compare to UTF8String.
And this does require actual convertion whereas equality comparison of 
PrintableString and UTF8String could be done by just ignoring the asn1 
type tag.
The above reminds me how important it is that implementers correctly 
reject invalid UTF-8 sequences, and that it's not garanteed to happen.

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 7 May 2004 10:29:09 +0800

I do'nt see why name rollover certificates can not solve the
mixed encoding problem if the definition of a self-issued
certificate and the path validation algorithm in RFC 3280
is revised?

Let me use an example to explain this.

Suppose the original certificate chain is:

   Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert

where "p-p" means "issuer name in PrintableString" and
"subject name in PrintableString".

Suppose CA2 take the name rollover, it will issue the
following two self-issued certificates:
         CA2-CA2-p-u-cert
             (i.e., issuer name in PrintableString,
                     subject name in UTF8String)
         CA2-CA2-u-p-cert
             (i.e., issuer name in UTF8String,
                     subject name in PrintableString)

Suppose CA1 also take the name rollover, it will issue
the following two self-issued certificates:
         CA1-CA1-p-u-cert
             (i.e., issuer name in PrintableString,
                     subject name in UTF8String)
         CA1-CA1-u-p-cert
             (i.e., issuer name in UTF8String,
                     subject name in PrintableString)

Suppose CA2 start to issue EE certificate with UTF8String
encoding, and it issues the following EE certificate:
         CA2-EE2-u-u-cert

Then,
EE1 can still be reached by the original certificate chain:

Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert

EE1 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
         CA2-EE1-p-p-cert
(Assume there is another CA issues a cross-certificate to CA1
in UTF8String encoding.)

EE2 can be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
         CA2-EE2-u-u-cert

One day, if CA1 renews the cross-certificate to CA2 and
adopts UTF8String encoding in the new cross-certificate, it
will issue the following cross-certificate:
         CA1-CA2-u-u-cert

Then,
EE1 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
         CA2-CA2-u-p-cert CA2-EE1-p-p-cert

EE2 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert

As you can see, in theory you can always find at least one certificate
chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new cert
with UTF8String). However, as I said before, we should discuss how
to amend RFC 3280 to support such certificate chaining.

Wen-Cheng Wang

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