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

From: Santoni Adriano <[email-masked]>
Date: Tue, 13 Apr 2004 08:42:40 +0200

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.
 
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! 
 
Regarding point b), I think the problem may largely vary depending on
specific circumstances. It depends very much on what the user asks and pays
for, and what the CA offers (only certificates or software as well?) and
claims (e.g. interoperability?).
 
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. 
 
AS

-----Messaggio originale-----
Da: todd glassey [mailto:[email-masked]] 
Inviato: venerdì 9 aprile 2004 15.32
A: Santoni Adriano; [email-masked]
Cc: [email-masked]
Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs

Peter - Santoni, the RFC is the RFC and it says MUST, and it addresses the
NameRollover issues as well with commentary about 
 
      (a)  CAs MAY issue "name rollover" certificates to support an
      orderly migration to UTF8String encoding.  Such certificates would
      include the CA's UTF8String encoded name as issuer and and the old
      name encoding as subject, or vice-versa.

... http://www.faqs.org/rfcs/rfc3280.html
<http://www.faqs.org/rfcs/rfc3280.html> 
 
So my reading is that UTF8 is not optional.
 
Todd Glassey

----- Original Message ----- 
From: Santoni Adriano <mailto:[email-masked]>  
To: [email-masked]' <mailto:[email-masked]'>  
Cc: [email-masked] <mailto:[email-masked]>  
Sent: Friday, April 09, 2004 3:35 AM
Subject: R: RFC3280: doubt on the use of UTF8String in encoding RDNs

Thanks for replying, although it seems a reply to another question (my
fault, I presume). 

I was referring to new certificates, issued "from today on" (so to speak). 

As a CA, we do not handle DNs "encoded by the originator"; which
"originator" at any rate? 

We register people, collecting their own true names, and then we build the
DNs to be inserted into certificates. The names can be e.g. the ASCII-safe
name "Peter Gutman", or the polish name "Anna Kręglewska", or the greek
"Ανδρεασ Ανδρεοπουλοσ" or whatever else - can you read? :-). In the case of
your name, a PrintableString would be "safe", as it would retain all the
original information. In the latter cases, it would not and so it makes more
sense to use Unicode encoded as UTF8String.

Maybe I am just not getting what you mean... 

Adriano 

-----Messaggio originale----- 
Da: pgut001 [ <mailto:[email-masked]>
mailto:[email-masked]] Per conto di
[email-masked] 
Inviato: mercoledì 7 aprile 2004 15.55 
A: [email-masked]; [email-masked] 
Oggetto: Re: RFC3280: doubt on the use of UTF8String in encoding RDNs 

Santoni Adriano <[email-masked]> writes: 

>I am probably asking an old question, so ... please be patient. 
> 
>Rfc3280 states (<A7>4.1.2.4): "...all certificates issued after 
>December 31, 2003 MUST use the UTF8String encoding of 
>DirectoryString...". 
> 
>Does that mean that it is mandatory to always encode all RDNs (having a 
>type of DirectoryString) of the issuer and subject (and still other) 
>certificate fields as UTF8Strings _even if they could be correctly 
>encoded as a PrintableStrings_ ? 

Hmm, see the previous thread on this a few months ago... in theory you're
supposed to do this, but that violates the primary rule of DN encoding,
which is "Never change the DN once it's been encoded by the originator".  If
you break that rule, you get to discover all the apps that reject re-encoded
DNs. If you're lucky, this will happen before your product ships and not
after.

Peter. 

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

*******************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: Richard Levitte - VMS Whacker <[email-masked]>
Date: Tue, 13 Apr 2004 11:43:34 +0200 (CEST)

In message <[email-masked]> on Tue, 13 Apr 2004 08:42:40 +0200, Santoni Adriano <[email-masked]> said:

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

A question, what does X.509 say about this?  It may be that some
people confuse X.509 with RFC3280, thinking they are interchangeable
(they seem to be, more or less, at least last time I looked at the
ASN.1 module).

Having X.509 and RFC3280 differ on this point may be another cause for
confusion...

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 52
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 13 Apr 2004 15:12:00 +0200

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.

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

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

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 15 Apr 2004 14:56:05 -0400

Jean-Marc Desperrier wrote:

> normalized, pkix approved test suite for RFC3280 as complete as 
> possible so that it would be very easy to ask anybody claiming RFC3280 

Last year NIST, in conjunction with DigitalNet and NSA, developed the 
Public Key Interoperability Test Suite (PKITS): a path validation test 
suite that is available at 
http://csrc.nist.gov/pki/testing/x509paths.html.  This test suite 
includes over 200 tests and was designed to cover most of the features 
in RFC 3280.  I would like to see PKITS adopted for use as you suggest 
above.

If you are interested in using a path validation test suite to test path 
validation implementations, I would suggest that you look at this test 
suite.  If you believe that new tests would need to be added in order 
for PKITS to meet your needs, please let me know what new tests you 
think would be needed and I will consider adding them.

The test suite by itself will not be enough to ensure interoperability.  
RFC 3280 includes many rather obscure features and I don't expect 
vendors to implement all of them.  For the U.S. Government, NIST is 
trying to address this by creating profiles.  We are creating document 
that specifies the set of features from RFC 3280 that we believe are 
needed for use within the Federal PKI.  In order to achieve 
interoperability, we will encourage agencies use path validation 
implementations that implement all of these features and we will 
encourage them not to use any other features in the certificates and 
CRLs that they issue.

The document specifying which features need to be implemented will also 
then indicate how PKITS can be used to verify that a path validation 
implementation implements those features correctly (it will also 
indicate how to verify that any other feature that is implemented is 
implemented correctly).  The more features that a path validation 
implementation implements, the more tests from PKITS will need to be run 
in order to demonstrate correct implementation.  However, in no case 
will the document require that every one of the tests from PKITS be run.

As I said above, it is my hope that others will adopt PKITS as well even 
those who have decided that they need a different set of features than 
what we believe will be needed within the U.S. Federal PKI.  Vendors 
would just have to run a different subset of PKITS to demonstrate that 
they implement this different set of features.

Dave