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