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

From: Santoni Adriano <[email-masked]>
Date: Wed, 12 May 2004 10:39:27 +0200

Thank you for this additional contribution.

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

This is exactly the point, IMHO. UTF-8 is a clever encoding, probably the
best when we CAs have to put names like "Papadopulos" or "Wen-Cheng Wang"
into a certificate in its original and "true" character set.

"...and that it never should have made it to more than a RECOMMENDATION."

This sounds very sensible. I buy it!

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[email-masked]] 
Inviato: martedì 11 maggio 2004 15.33
A: Wen-Cheng Wang; Stephen Kent; Santoni Adriano
Cc: [email-masked]; [email-masked]; Steve Hanna
Oggetto: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs

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

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof.