Subject: Re: RFC 2459 and internationalized domain names

From: [email-masked] (Peter Gutmann)
Date: Thu, 6 Jul 2000 05:04:10 (NZST)

Paul Hoffman / IMC <[email-masked]> writes:
>At 12:31 PM -0400 7/5/00, Russ Housley wrote:
>>I agree that certificates should accommodate non-ASCII domain names
>>once they are finalized.  I do not understand why anything should be
>>done before IDN finishes their work.

>Because someone will be reading the PKIX RFC at some point after IDN is done.
>They may say "gee, this is stupid that they said to use IA5String for domain
>name, I'll just use UTF8String". Putting in an acknowledgement that the PKIX WG
>knows of some of the formats that we have locked down possibly changing might
>help promote future interoperability.

You could also do what a certain Spanish CA did and unilaterally extend the
string type which is causing problems to AnythingIWantString (so you can put
cedillas in a string-formerly-known-as-PrintableString for example).

Peter :-).

---

From: [email-masked]
Date: Wed, 5 Jul 2000 13:14:41 -0400

This question may be premature, but we will need to ask it sometime -
if the Internet definitions of the three IA5String's in GeneralName get
extended for internationalization, should we: 1) Add OTHER-NAME's for the
internationalized string types, 2) Add extra CHOICE values to GeneralName;
3) Change the IMPLICIT type of each of these three strings to UTF8String on
the grounds that every legal IA5String is also a legal UTF8String with the
same meaning, although not vice versa?
     If we pick option 2 or option 3, will every certificate and CRL
extension currently including GeneralName get assigned a new OID for use
with the new GeneralName definition?  The answers to these questions are as
much under the control of X.509 as of PKIX.

          Tom Gindin

Jean-Marc Desperrier <[email-masked]> on 07/05/2000
12:17:49 PM

To:   [email-masked]
cc:
Subject:  Re: RFC 2459 and internationalized domain names

[email-masked] wrote:

> The format of GeneralName is :
> GeneralName ::= CHOICE {
>         otherName                   [0] INSTANCE OF OTHER-NAME,
>         rfc822Name                  [1] IA5String,
>         dNSName                     [2] IA5String,

> ...

>         uniformResourceIdentifier   [6] IA5String,
>
> It seems
> we need to create something like :
>         rfcSonOf822Name                  [9] UTF8strings,
>
> [Tom Gindin] I think it's rfc822I18N [9] UTF8String, but that's minor.

> The same applies to dNSName, and uniformResourceIdentifier.
>
> [Tom Gindin] I have one basic question here.  Does adding new members to
> this choice mean we have to change OID's for the extensions using it (not
> just SubjectAltName, but IssuerAltName, AuthorityKeyIdentifier,
> NameConstraints, CRLDistributionPoint, CertificateIssuer,
> IssuingDistributionPoint and AuthorityInfoAccess in RFC 2459 alone - and
I
> might have missed one)?  If it does, should we and X.509 bite that
> particular bullet or define OTHER-NAME's as DirectoryString's instead?

OK, OTHER-NAME is the way to go.

It is clearly a lot better to define a specific OID for rfc822I18N and then
insert that kind of thing as an otherName element, and *not* to change the
syntax of GeneralName.

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

[Tom Gindin] Two points.  First, I was really asking our X.509 committee
types (Sharon, Hoyt, are you listening?) whether adding a new choice in
GeneralName would cause both X.509 and PKIX-1 to have to renumber all of
the extensions cited; if not, it's not clear to me that adding OTHER-NAME
is really better.  Second, what I meant by "OTHER-NAME's as
DirectoryString's" was OTHER-NAME's with values which are DirectoryString's
- there's no need for a new string type here.

(snip)