Subject: [pkix] Support for email address internationalization in RFC5280 certificates

From: Wei Chuang <[email-masked]>
Date: Thu, 4 Feb 2016 11:05:34 -0800

PKIX community,

We've observed a limitation for specifying internationalized email
addresses as the local part which is restricted to essentially ASCII.  That
is subject or issuer email addresses which should be stored as
subject-alt-name or issuer-alt-name rfc822Name and are encoded as
IA5String.  This is despite the internationalization in email usage as
specified by internationalization of email headers in RFC6532 allowing
Unicode in To, From, etc fields and becoming fairly commonplace.  RFC5280
already specifies internationalization of the domain but lacks any
specification for the local-part.  We propose a brief draft to specify an
encoding of email UTF-8 local part to base64.  This described in:
http://www.ietf.org/id/draft-lbaudoin-iemax-02.txt
One goal of that draft is to be compatible with existing PKI practices such
as path constraints with email address as this draft refines the existing
rfc822Name rather than specifies a new location for email addresses.

There are some other alternatives that probably should be mentioned for
discussion.  Instead of base64, another possibility is percent encoding as
done in RFC3987.  Our proposal is likely to be more compact and easier to
identify, but would welcome feedback.  Another direction is to specify a
SAN/IAN otherName compatible with Unicode for internationalized email.  A.
Melnikov specified this in an earlier draft
<https://www.ietf.org/archive/id/draft-ietf-pkix-eai-addresses-00.txt>.

Another thing to consider is whether there are other RFC5280 types that
need updating for internationalization.  Please consider looking into
uniformResourceIdentifier
as well.

-Wei

---

From: Peter Bowen <[email-masked]>
Date: Fri, 5 Feb 2016 16:46:11 -0800

On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang <[email-masked]> wrote:
> PKIX community,
>
> We've observed a limitation for specifying internationalized email addresses
> as the local part which is restricted to essentially ASCII.  That is subject
> or issuer email addresses which should be stored as subject-alt-name or
> issuer-alt-name rfc822Name and are encoded as IA5String.  This is despite
> the internationalization in email usage as specified by internationalization
> of email headers in RFC6532 allowing Unicode in To, From, etc fields and
> becoming fairly commonplace.  RFC5280 already specifies internationalization
> of the domain but lacks any specification for the local-part.  We propose a
> brief draft to specify an encoding of email UTF-8 local part to base64.
> This described in:
> Melnikov specified this in an earlier draft.

One thing to note is that rfc822Name is confusingly named.  RFC5280
defines it as

  a "Mailbox" as defined in Section 4.1.2 of [RFC2821]

2821 has been obsoleted by 5321.  So the proper reference for adding
Internationalized Email addresses is probably RFC6531.

That being said, did you consider the approach of redefining
rfc822Name as being of type Rfc822Name and defining Rfc822Name as

Rfc822Name ::= CHOICE {
  ia5string IA5String,
  utf8string UTF8String
}

If it is required that the domain-part only consist of A-labels even
when using the utf8string choice, then all existing name constraints
will still work.

The obvious tradeoff here is potential incompatibility.  Systems that
use ASN.1 grammar (as opposed to blind encoding parsing) may reject
certificates with UTF8String for rfc822Name type GeneralNames.

Thanks,
Peter

---

From: Wei Chuang <[email-masked]>
Date: Sun, 7 Feb 2016 07:15:26 -0800

On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen <[email-masked]> wrote:

> addresses
Thanks for pointing this out, and reinforcing the point about the confusion

> Internationalized Email addresses is probably RFC6531.

I pointed out the counter part RFC6532 internalized headers
whereas RFC6531 is the update for the SMTP protocol.  We certainly agree
about the issue.

> rfc822Name as being of type Rfc822Name and defining Rfc822Name as

This particular approach, no.  Using a new type has been explored by A.
Melnikov in his draft-ietf-pkix-eai-addresses-00 draft.  As you point out
it has the possibility of incompatibility but has advantages like
compactness and simpler implementation.  Our approach tries to retrofit
UTF-8 into rfc822Name through encoding to lessen compatibility issues but
how important that is depends on input the community.  Our perspective is
that we just want standardization and quite happy to move forward with any
reasonable approach.

> certificates with UTF8String for rfc822Name type GeneralNames.

Thanks!
-Wei