Subject: Re: DN Encoding by UTF8String

From: Russ Housley <[email-masked]>
Date: Sat, 06 Dec 2003 13:29:28 -0500

This was added to RFC 2459, and retained in RFC 3280, based on comments 
from Harald Alvestrand.   As most of the recipients know, Harald is the 
Chair of the IETF, and a member of the  IESG.  Tim Polk spent a lot of time 
on this issue, negotiating the exact words with Harald and any others.  The 
desire is for certificate issuers to embrace international character sets.

Beyond this recap of the history, I will let Harald speak for himself.

Russ

----------------------- Original Message -----------------------
From:    Masaki SHIMAOKA <[email-masked]>
To:      Tim Polk <[email-masked]>, Stephen Kent <[email-masked]>, 
[email-masked], [email-masked], [email-masked]
Date:    Fri, 05 Dec 2003 16:09:10 +0900
Subject: DN Encoding by UTF8String

Dear Authors and WG Chairs,

RFC3280 mentioned that "all certificates issued after Dec 31, 2003 MUST
use UTF8String encoding".

However, it seems that some applications do not yet support UTF8String
respectably and the detail of name comparison rule does not consider
UTF8String sufficiently.

Therefore, existing CAs using except UTF8String for DN encoding SHOULD
do the following actions until solving these UTF8String problem.

     An encoding for issuer field of the certificates issued after 2004
     SHOULD be same as an encoding for subject field of CA certificate
     already issued.

Is this correct?

Of course, when the UTF8String problem solves, all certificates
issuedMUST use UTF8String encoding.
I worry that some confused CAs issue wrong certificates using UTF8String
encoding forcibly, even though the CA had used another encoding till now.

Best regards,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8498 (ext.3605)
Fax: +81 422 45 0536
e-mail: [email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 07 Dec 2003 23:51:59 -0800

I must admit that I am not surprised.....

The encodings supported by older applications are many and various, but 
nearly all of them share one of two properties:

- They are US-ASCII compatible
- When using non-US-ASCII characters, they are violating the X.509 
standards that they claim conformance to

If declaring that a number of applications are violating the IETF 
standards, and not just the ITU standards, on January 1, 2004 will help 
bring that day closer, I'm all for it.

Sooner or later, the industry, IMHO, will have to embrace UTF-8 fully; 
supporting the mess we've created for ourselves forever is not in the best 
long term interest of the network.

As far as I know, there will be nobody coming to punish people issuing 
non-UTF-8 certificates after Jan 1, 2004 that contain non-UTF8 encoding. 
And people will violate the standards to keep their legacy applications 
running; that is how networks have always operated.

But IMHO, they should be ashamed of themselves when they do so, and strive 
towards eliminating the need for doing so as soon as possible. Not because 
I say so, but because it's for the long term good of the Internet.

My opinion.

                 Harald Alvestrand

--On 6. desember 2003 13:29 -0500 Russ Housley <[email-masked]> wrote:

> Chair of the IETF, and a member of the  IESG.  Tim Polk spent a lot of
> time on this issue, negotiating the exact words with Harald and any
> others.  The desire is for certificate issuers to embrace international
> character sets.
>

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Tue, 09 Dec 2003 09:47:43 +0900

Harald,

Thanks for your comment.

> long term interest of the network.

Basically I agree with you, we MUST move to UTF-8 soon.
But, still now we are facing to some issues about UTF8string, e.g., name
comparison rule, and it seems that hard to solve yet them.
AFAIK, there will be a little PKI applications who are compliant with
the transition to UTF-8.

> non-UTF-8 certificates after Jan 1, 2004 that contain non-UTF8 encoding. 

I believe it;)

> running; that is how networks have always operated.

While we cannot solve or address the UTF8String issues, I think such
violations are unavoidable.

> I say so, but because it's for the long term good of the Internet.

Sure.

To achieve the transition to UTF8 shortly, we should break the UTF8
issues, then the transition to UTF-8 is the next.
Which do you think should do first?

And one question to authors:
Do you have some plan to update the description in clause 4.1.2.4 of son
of RFC3280?

Regards,
shima

On Sun, 07 Dec 2003 23:51:59 -0800

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.