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

[Wei Chuang <[e-mail]>]

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

> 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.
>
>
Thanks for pointing this out, and reinforcing the point about the confusion


> 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.
>

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


>
> 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
> }
>

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.


>
> 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
>

Thanks!
-Wei