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

From: Santoni Adriano <[email-masked]>
Date: Wed, 21 Apr 2004 12:12:37 +0200

Dear RFC3280 Authors,

Sorry for bothering, and please forgive me if I am asking an old question.

RFC 3280 reads (§4.1.2.4): "...all certificates issued after December 31,
2003 MUST use the UTF8String encoding of DirectoryString...".

Is that sentence meant to be intepreted in the following way?  :

"All RDNs (having a DirectoryString syntax) of the issuer and subject
certificate fields, in all certificates issued after December 31, 2003, MUST
be encoded as UTF8Strings EVEN if they could be correctly encoded as a
PrintableStrings."

If the answer is YES, I would like your personal opinion about the great
majority (sai 99,9%) of all CAs all over the planet not being conformant to
RFC 3280 and neither to RFC 2459, as far as this particular PKIX
prescription is concerned.

Thank you for any feedback on this issue.

Regards,
  Adriano

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per
conto di Jean-Marc Desperrier
Inviato: martedì 13 aprile 2004 15.12
A: [email-masked]
Oggetto: Re: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

Santoni Adriano wrote:

> Well, it turns out that - despite the topic has been debated in the
> past - there is not much consense on the "true" intepretation of RFC 
> 3280, §4.1.2.4. The sentence " all certificates issued after December 
> 31, 2003 MUST use the UTF8String encoding of DirectoryString (except 
> as noted below) " is a prescriptive one, if I am not mistaken.
>  
> Nontheless, Glassey says "you have to do so, full-stop", while Gutman
> and Desperrier says "you'd better not" because  a) some application 
> would not handle UTF-8 properly and b) the CA should not "alter" the 
> name if a certificate already exists for the same subject.

I feel I have to say my post was not at all an interpretation of the 
meaning of RFC3280, and I did not intend to say that part of RFC3280 is 
not prescriptive.
It was just a remark about the state of current applications. They are other
aspects of RFC3280 that are certainly no more well 
supported in practice.

This said, AFAIR when the topic was debated in the past, it was 
concluded that renewal cert were one of the "except as noted below" case.

> Regarding point a), I personally agree that some applications will not
> behave properly when encountering UTF8Strings, but that should have 
> been taken into account when drafting RFC 3280, not today!

That part of RFC3280 was copied without any change (and I strongly 
suspect without discussion, or rereading) from RFC2459.

At the time RFC2459 was drafted, 2003 was far in the future, and the 
redactors surely hoped UTF8String would be widely in use before the 
deadline, so that this deadline would not be much a constraint.

> I am sure many of you have noticed that most CAs (all over the planet)
> claiming conformance to RFC3280 have not started issuing certificates 
> with subject names encoded as UTF8String, after 31 december 2003. I 
> dare to say one of the reasons might be a little ambiguity in RFC 3280 
> and probably insufficient debate on this specific topic.

I'm not sure the problem is due to any ambiguity in RFC3280.
I think some of the problem might be related to few people really trying 
to implement RFC3280 fully and carefully, many just implementing support 
for what they see the most often in use. If there is no UTF-8 around, 
they don't do it, and therefore nobody starts doing it.

I'm afraid all what one can hope is that some people will start to 
implement it because it's written in the RFC, will meet interoperability 
problems, will tell other implementors they are the one who don't 
respect the norm, and the other implementators will progressively 
correct any problem related to that in their code.
I now think expecting implementors to prepare for the future, or 
beginning to implement something until they are forced to is a lost 
cause, so the prescriptive aspect of RFC3280, and the fact applying it 
will break a few things, is a good thing if we really want certificates 
to support internationalization one day.

What I also think in relation to that is that there should be a 
normalized, pkix approved test suite for RFC3280 as complete as possible 
so that it would be very easy to ask anybody claiming RFC3280 
conformance what the result of the test suite is.

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

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 23 Apr 2004 14:33:29 +1200

Santoni Adriano <[email-masked]> writes:

>RFC 3280 and neither to RFC 2459, as far as this particular PKIX prescription
>is concerned.

Here we go again... this really should be an FAQ, given the number of times
it's come up, and will no doubt continue to come up.  So the standard answer
is:

  Most people are ignoring the UTF-8 requirement because of backwards-
  compatibility concerns, both for existing certs and for existing
  applications.  Don't worry about it, it's quite normal, this is just another
  area where the RFC is at odds with reality.

Peter.