Subject: 3280bis internationalization section

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Mar 2005 12:04:41 -0600

Greetings again. The new section 7 on internationalization in 3280bis 
is very good. A few comments:

- In 7.2, the bulleted lists make it seem like you don't have to do 
step 2, which you do. New wording might be:

       * perform step 1 with the domain name treated as a "stored
       string";
       * perform step 2;
       * perform step 3 with the flag called "UseSTD3ASCIIRules" set;
       * perform step 4 by processing each label with the "ToASCII" operation;
       * perform step 5 by changing all label separators to U+002E (full stop).
...and...
       * perform step 1 with the domain name treated as a "stored
       string";
       * perform step 2;
       * perform step 3 with the flag called "UseSTD3ASCIIRules" set;
       * perform step 4 by processing each label with the "ToUnicode" operation;
       * step 5 is not needed.

- Section 7.5 should be removed. There is nothing currently being 
considered in the IETF that relates to this. If there is later an 
IETF standard for internationalized left-hand-sides in email 
addresses, that standard can also extend the PKIX format.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Wed, 09 Mar 2005 11:57:37 -0500

Paul:

I disagree that this section should be removed.

I believe this also has an impact on S/MIME and OpenPGP.  How are the 
comparison of the email address in the certificate and the FROM field on 
the email message handled?  memcmp?

Russ

At 01:04 PM 3/8/2005, Paul Hoffman wrote:
>considered in the IETF that relates to this. If there is later an IETF 
>standard for internationalized left-hand-sides in email addresses, that 
>standard can also extend the PKIX format.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Mar 2005 12:32:25 -0600

At 11:57 AM -0500 3/9/05, Russ Housley wrote:
>I believe this also has an impact on S/MIME and OpenPGP.  How are 
>the comparison of the email address in the certificate and the FROM 
>field on the email message handled?  memcmp?
>
>Russ
>
>

Whoops, I stopped reading at the second paragraph. It is clear that 
some of the section is still relevant, but assert some of it is not. 
For example, the current text says:

    Where the local-part of the addr-spec contains an internationalized
    name, ...

That is *not* allowed by any current RFC, nor of any 
actively-discussed Internet draft that I know of. Internationalized 
characters can only appear in the host-part as a full-fledged (and 
legal) IDN.

Thus, I propose that, instead of removing the section as I previously 
suggested, it should be replaced with:

7.5  Internationalized Electronic Mail Addresses

    Electronic Mail addresses may be included in certificates and CRLs in
    the subjectAltName and issuerAltName extensions, the name constraints
    extension, authority information access extension, subject
    information access extension, or CRL distribution points extension.
    Each of these extensions uses the GeneralName construct; GeneralName
    includes the rfc822Name choice, which is defined as type IA5String.
    To accommodate internationalized names in email addresses using the
    current structure, conforming implementations MUST convert the
    addresses into an ASCII representation.

    If the host-part (the domain of the addr-spec) contains an
    internationalized name, the domain name MUST be converted from an IDN
    to the ASCII Compatible Encoding (ACE) format as specified in section
    7.2.

    Two email addresses are considered to match if:

       1) the local-part of each name is an exact match, AND
       2) the host-part of each name matches using a case-insensitive
       ASCII comparison.

    Implementations should convert internationalized email addresses
    specified in these extensions to Unicode before display.
    Specifically, conforming implementations should convert the
    host-part in the adder-spec as described in section 7.2.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Wed, 9 Mar 2005 13:33:34 -0500

Paul,

Thanks for the review.  I will be happy to make the suggested changes in 
Section 7.2.  

I am also concerned about the email address syntax, but my worries were focued 
on the local part.  I hadn't considered dropping the entire section 7.5, but 
that might be the safest course!  I had made some assumptions about handling 
the host part; incorrect assumptions would have a very bad result.

I hope to corner Patrik Falstrom to discuss this before leaving Minneapolis, 
and will report his opinions to the list.

Thanks,

Tim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Mar 2005 19:39:47 +0000

Paul,

Probably trivial nit with this:

 >    addresses into an ASCII representation.

To:

To accommodate internationalized names in email addresses using the
current structure, conforming implementations MUST, before creating
the certificate, or comparing against a certificate field, convert
the addresses into an ASCII representation.

Since there was slight confusion in the meeting on this (or else,
it was me that was confused:-),
Stephen.

Paul Hoffman wrote:

>> comparison of the email address in the certificate and the FROM field 
>> on the email message handled?  memcmp?
>>
>> Russ
>>
>>
> Whoops, I stopped reading at the second paragraph. It is clear that some 
> of the section is still relevant, but assert some of it is not. For 
> example, the current text says:
> 
> That is *not* allowed by any current RFC, nor of any actively-discussed 
> Internet draft that I know of. Internationalized characters can only 
> appear in the host-part as a full-fledged (and legal) IDN.
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Mar 2005 14:09:28 -0600

>the addresses into an ASCII representation.

That sounds better and clearer. Slight editorial weenie nit: no comma 
after "...creating the certificate".

--Paul Hoffman, Director
--VPN Consortium