Subject: RFC 2459 and internationalized domain names

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 3 Jul 2000 19:10:01 -0700

Greetings again. There is active work in the IETF to allow non-ASCII 
characters in doamin names. This is being considered in the IDN 
Working Group (see 
<http://www.ietf.org/html.charters/idn-charter.html> for the WG 
charter). There is a strong desire for these names in many parts of 
the world.

If the wire format for the new domain names includes non-ASCII 
characters (which seems likely to me), then we probably should change 
2459 to handle these new names. Fortunately, son-of-2459 is still not 
finished.

Please note that:
- The IDN WG may not come up with a protocol
- The protocol may be ASCII-only, using an encoding scheme that maps 
to the current rules for domain names
- If there is a binary protocol, it is likely (but not definitely) 
going to be UTF-8

Given that, it might be wise of us to either change how domain names 
are represented 2459 or to put warnings into the text about this  in 
son-of-2459. It is likely that son-of-2459 will be finished well 
before the IDN WG is finished.

Oh, and if the IDN WG creates a binary protocol, there will be a 
strong demand for changes to the email protocols to handle binary 
domain names in headers. There will also be a strong demand for 
binary on the left-hand side of the addr-spec. We may wan to consider 
these as well.

Thoughts?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Marc Branchaud <[email-masked]>
Date: Tue, 04 Jul 2000 11:45:44 -0700

Hi Paul...

My main comment is that PKIX would be unwise to try to anticipate how other
protocols might evolve.  PKIX should really wait until the IDN, email, or any
other group, figures out what they're going to do before making any changes
in a PKIX RFC.

My secondary comment is that PKIX really shouldn't be in the business of
specifying altName formats and semantics at all.  The definition of what
constitutes a valid email address, DNS name, IP address, and so forth, has no
place in a PKIX RFC.  The same goes for name-matching rules: it's not up to
PKIX to define these.  It's a loser's game, where PKIX will have to be
maintained indefinitely in order to keep up with the evolving Internet.

What PKIX should do is provide generic space for altNames in PKIX certs and
protocols, but leave the definition and handling of these to other groups. 
If an Internet group wants to be compatible with PKIX, it should be up to
them to define a PKIX sub-profile on what it means to conform to their stuff.

PKIX hasn't gone this way in the past though, despite these arguments, so I
doubt it'll change now.

		Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 4 Jul 2000 11:57:37 -0700

>other group, figures out what they're going to do before making any changes

Agree.

>maintained indefinitely in order to keep up with the evolving Internet.

Agree.

>protocols, but leave the definition and handling of these to other groups.

Agree.

>them to define a PKIX sub-profile on what it means to conform to their stuff.

The problem with this is, as you point out below, that PKIX already 
*does* describe what a domain name is, what an email address is, and 
so on. If any the standards for these evolves (and we can expect they 
will), one of two situations arises:

- PKIX has to be revised to change with the standard.
- PKIX prevents users from identifying themselves using the revised standard.

>PKIX hasn't gone this way in the past though, despite these arguments, so I

Agree.

--Paul Hoffman, Director

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 05 Jul 2000 11:40:40 +0200

> >maintained indefinitely in order to keep up with the evolving Internet.

The current version of RFC2459 serves two purposes : defining the format of the
certificate and defining some "best practices" for implementations of what
everyone must be able to support.
This best practices are needed, an ASN1 based format has just too many
possibilities.

> >them to define a PKIX sub-profile on what it means to conform to their stuff.

And this would be a big problem because there would several different PKIX
sub-profiles.

If the standard of PKIX defines both the format and the best practices, that means
it must be able to evolve easily to adapt to new practices.

Or there must be two separate documents for each of theses aspects.

Now if the RFC2459 wasn't so strict about the email format, url format, etc...
this would be a good thing.

The format of GeneralName is :
GeneralName ::= CHOICE {
        otherName                   [0] INSTANCE OF OTHER-NAME,
        rfc822Name                  [1] IA5String,
        dNSName                     [2] IA5String,
        x400Address                 [3] ORAddress,
        directoryName               [4] Name,
        ediPartyName                [5] EDIPartyName,
        uniformResourceIdentifier   [6] IA5String,
        iPAddress                   [7] OCTET STRING,
        registeredID                [8] OBJECT IDENTIFIER }

As these are implicits tags, this  is closed to evolutions in the format of the
data, it is not possible to modify the standard to allow rfc822Name to be a CHOICE
between UTF8strings, and IA5String, as could be done with explicit tags. It seems
we need to create something like :
        rfcSonOf822Name                  [9] UTF8strings,

The same applies to dNSName, and uniformResourceIdentifier.

It seems to me using a CHOICE format similar to DirectoryString for rfc822Name,
dNSName, uniformResourceIdentifier, and a recommendation to use IA5String in the
current state of things would have been a better solution.

---

From: Russ Housley <[email-masked]>
Date: Wed, 05 Jul 2000 12:31:35 -0400

Paul:

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.

Russ

At 07:10 PM 07/03/2000 -0700, Paul Hoffman / IMC wrote:
>characters in doamin names. This is being considered in the IDN Working 
>Group (see <http://www.ietf.org/html.charters/idn-charter.html> for the WG 
>charter). There is a strong desire for these names in many parts of the world.
>
>If the wire format for the new domain names includes non-ASCII characters 
>(which seems likely to me), then we probably should change 2459 to handle 
>these new names. Fortunately, son-of-2459 is still not finished.
>
>Please note that:
>- The protocol may be ASCII-only, using an encoding scheme that maps to 
>the current rules for domain names
>- If there is a binary protocol, it is likely (but not definitely) going 
>to be UTF-8
>
>Given that, it might be wise of us to either change how domain names are 
>represented 2459 or to put warnings into the text about this  in 
>son-of-2459. It is likely that son-of-2459 will be finished well before 
>the IDN WG is finished.
>
>Oh, and if the IDN WG creates a binary protocol, there will be a strong 
>demand for changes to the email protocols to handle binary domain names in 
>headers. There will also be a strong demand for binary on the left-hand 
>side of the addr-spec. We may wan to consider these as well.
>
>Thoughts?
>
>--Paul Hoffman, Director

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Wed, 5 Jul 2000 09:44:13 -0700

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.

--Paul Hoffman, Director

---

From: Russ Housley <[email-masked]>
Date: Thu, 06 Jul 2000 11:00:58 -0400

Paul:

I agree.  A forward pointer that this issue needs to be addresses once the 
IDN WG finishes their work is fine.

Russ

At 09:44 AM 07/05/2000 -0700, Paul Hoffman / IMC wrote:
>>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.
>
>--Paul Hoffman, Director