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

From: Santoni Adriano <[email-masked]>
Date: Fri, 9 Apr 2004 12:35:08 +0200

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.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 09 Apr 2004 14:36:18 +0200

> "originator" at any rate?
_You_ are the originator, it's the CA that fixes what the name is when 
creating the X509 cert, and anybody using that name after that never 
should change it. (But if you generate a cross -certificate or find 
yourself  in a similar situation where another CA has already created 
the name, you shouldn't change it at all if you want to get good 
inter-operability).

Peter is not of that mind, I understood he thinks it's important to 
preserve the name that is created in the request where the client 
presented you his public key, and I had no time to argue about that the 
last time he raised it on the list.

But I'm positive clients *never* check if the response cert is coherent 
with the name in the request they sent, that anyway most CA just dump to 
the trash the name that whas included in the request and generate the 
name with a completely independant algorithm (they often use 
registration pages with a fixed name for the request), that in some case 
there is no request (pre-generated keys in tokens, the client just sends 
the token id, and the CA has OOB ways to know the corresponding public key).

So when you CA issue the very first cert for a user, you are free to fix 
the name, and it can be good to normalize it.
One this first cert is there, his "primary rule of DN encoding" actually 
applies, and application should better never touch the name and never 
use any transformation when doing comparisons to avoid problems, this 
including CA if renewing or cross-certificating.

---

From: "todd glassey" <[email-masked]>
Date: Fri, 9 Apr 2004 06:31:46 -0700

R: RFC3280: doubt on the use of UTF8String in encoding RDNsPeter - 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

So my reading is that UTF8 is not optional.

Todd Glassey

  ----- Original Message ----- 
  From: Santoni Adriano 
  To: [email-masked]' 
  Cc: [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). 

  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.

  Adriano 

  -----Messaggio originale----- 
  Da: pgut001 [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 

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

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 10 Apr 2004 23:33:33 +1200

Santoni Adriano <[email-masked]> writes:

>DNs to be inserted into certificates.

In that case you're the originator, so you can encode them in whatever way you
want, and other apps will preserve the encoding.  So encoding as UTF-8 should
be fine, although some apps (particularly older ones) may not be able to
display it very well, and old (4.x) versions of Netscape will crash when they
encounter it.  You can probably ignore that though, although there are some
CAs that still use 4.x-compatibility as an excuse for doing weird things with
certs.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 10 Apr 2004 23:54:57 +1200

Jean-Marc Desperrier <[email-masked]> writes:

>But I'm positive clients *never* check if the response cert is coherent with
>the name in the request they sent

Some do.  I know of client apps that reject the cert if the cert DN doesn't
match the request DN (by "match" I mean if memcmp() reports that they differ).

Peter.