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

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 11 May 2004 14:33:19 +0100

Yes, you can do a lot of cool things in theory.

The cruel truth is that your name encoding roll-over certs (e.g.
CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

RFC 3280 section 6.1:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty. 

RFC 3280 section 4.1.2.4:
      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

So in current implementations of RFC 3280, many valid certificates will
fail after introduction of name rollover certs in the chain, because
path validation will not treat them as self-issued.

Further, the name constraint problem persists, adds to this but also
exist regardless of this problem.

RFC 3280 section 4.2.1.11
   When applying restrictions of the form directoryName, an
   implementation MUST compare DN attributes.  At a minimum,
   implementations MUST perform the DN comparison rules specified in
   Section 4.1.2.4.

Fixing next version of RFC 3280 to include better name matching rules is
a good thing but far from enough to take care of real problems with
current infrastructure.

We have to try to keep in mind what we make all this hassle for!!

This is NOT about whether we should use UTF-8 or not to accommodate
complex character sets!! This is about what we are prepared to do to
make sure NOTHING is encoded as PrintableString WHEN PrintableString is
sufficient.

This old transition rule was created in RFC 2459 before the modern path
validation algorithm was invented and before self-issued certificates
was a special case.

Let's just admit that we overlooked this issue when we created RFC 3280
and reshaped path validation. It was an understandable human error,
which lead to a defect.

So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are
measured, and that it never should have made it to more than a
RECOMMENDATION.

Whatever we say here, this is a requirement that many implementers will
have to ignore for a many years to come.

Stefan Santesson
Program Manager, Windows Security
> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[email-masked]]
> Sent: den 7 maj 2004 04:29
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [email-masked]; [email-masked]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 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
> 
> 
> >
> > 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
> >

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Wed, 12 May 2004 17:10:35 +0800

> CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

That is why I said that the definition of self-issued certificates in RFC
3280 (or maybe its definition in the X.509 standard itself) should
be revised or be clarified in son-of-3280 (or in an amendment of
the X.509 standard as well).

>       PrintableString and BMPString) MAY be assumed to represent

Remenber that RFC 3280 section 4.1.2.4 also said:

   Implementations of this profile are permitted to use the comparison
   algorithm defined in the X.500 series.

In that respect, you can not said that name rollover certificates are not
self-issued.

> path validation will not treat them as self-issued.

I admit that most CURRENT implementations of RFC 3280 path
validation will fail to treat name rollover certificates as self-issued, but
it does not mean that we should not recommend FUTURE revisions
of those implementations and new implementations to treat them as
self-issued.

>    implementations MUST perform the DN comparison rules specified in

That is why I said RFC 3280 path validation algorithm should also be
revised.

> a good thing but far from enough to take care of real problems with

Fixing next version of RFC 3280 does not magically take care of real
problems with current infrastructure, but it encourge current infrastructure
to migrate to solve the problems.

> validation algorithm was invented and before self-issued certificates

That does not mean that name rollover certificates can not solve the
mixed name-encoding  problem.

> and reshaped path validation. It was an understandable human error,

Yes, RFC 3280 indeed overlooked this issue. That is why it should be
revised.

> measured, and that it never should have made it to more than a

Isn't it the IETF policy to encourge all new implementations to migrate
to support UTF-8? The philosophy is that if one encoding is sufficient to
cover universal characters, why should we recommend two?

> have to ignore for a many years to come.

Conformance to any IETF RFC is all voluntary. No one can enfoce any
implementer for that if the implementer chooses to ignore the requirement
or recommendation of any IETF RFC. RFC 3280 might not have the
power to enforce all implementation to migrate to UTF-8 encoding.
However, as an IETF RFC, it definitely has a great effect. At least, I
see more and more applications can correctly handle certificates with
named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
continue requiring conformant implementations to migrate to UTF-8
encoding.

Wen-Cheng Wang