Re: 3280bis internationalization section

[Paul Hoffman <paul.hoffman@xxxxxxxx>]

At 11:57 AM -0500 3/9/05, Russ Housley wrote:
> 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:
> > - 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.

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