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

[Peter Bowen <[e-mail]>]

On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang <[e-mail]> 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:
> 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.

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