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

From: Wei Chuang <[email-masked]>
Date: Fri, 13 May 2016 12:09:02 -0700

[Restarting and moving this thread to spasm]

Hi all,

I think there's general interest in using draft-ietf-pkix-eai-addresses-00
<https://tools.ietf.org/html/draft-ietf-pkix-eai-addresses-00> to document
supporting EAI local part i.e. to use a new GeneralNames otherNames type
with UTF8 email address local part.  That said, there are some remaining
issues from the previous thread:

On Wed, Apr 6, 2016 at 3:48 PM, Sean Leonard <[email-masked]> wrote:

> To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is a
> sensible path forward. That is how GeneralName was designed to be extended
> all along.
>
> Russ corrected me offline and pointed out that GeneralName is “owned”
> (well, created originally anyway) by ITU-T X.509. It is not an
> IETF-originated extension.
>

In order to add a new otherName type in GeneralName which appears to be
"owned" by ITU-T, does this then requires coordination with ITU-T?

>
> Any EAI mechanism will have consider the impact of Name Constraints, the
> functionality of which needs to be preserved.
>
> Additionally, the EAI document should say something about whether A-labels
> (i.e., Punycode) or U-labels ought to be used on the domain side. I believe
> that U-labels should be used on the domain side when in the otherName
> UTF8String. There are three solid reasons:
>

The draft very clearly matches RFC5280 pattern of using A-labels (ACE) for
the domain names.  While understandably its more convenient to process the
domain part in UTF8 display format, for validation purposes it would seem
to me to make sense to keep domain name validation consistent with the rest
of the RFC5280 handling to reduce the likelihood of implementation
differences.

I wonder if an update to this draft should say something about mitigating
homograph attacks in the security section?  I think this is an ideal time
to mitigate some of the likely security attacks.   In another thread it was
mentioned that using PRECIS (RFC7564) could help, and following that up the
RFC points <http://unicode.org/reports/tr39/#General_Security_Profile> at
Unicode Security Mechanism.  Some ideas are to restrict obsolete or
specialized character set and to restrict the local part to a single script
type e.g. Russian Cyrillic only or ASCII only.

-Wei

> #1 Since it’s UTF8String, it’s simply “more correct” to use U-labels
> instead of A-labels. The requirements of RFC 5280 regarding IDN don’t
> really apply because those are about stuffing U-labels into ASCII protocol
> slots (i.e., by making them A-labels).
> #2 When displayed to a user, U-labels are going to make sense; A-labels
> will not. (Note: there are homograph attacks. But that is not a problem
> specific to this choice, and IDNA procedures are supposed to mitigate that.)
> #3 U-labels are supposed to be compared “AS-IS” (RFC 5891), but A-labels
> are case-insensitive. Since the local-part is case-sensitive, this opens
> the possibility that e-mail address strings in certificates can (under the
> proper circumstances) be compared using a binary comparison operation
> (i.e., exact equality).
>
> Back to the alternatives: I am not withdrawing my suggestion but merely
> proposing it as an alternative that should be empirically examined before
> being dismissed, especially since CHOICE { IA5String, UTF8String } is (or
> was?) on the table at the time.
>
> Best regards,
>
> Sean
>
> On Apr 5, 2016, at 5:05 PM, Wei Chuang <[email-masked]> wrote:
>
>
> On Tue, Apr 5, 2016 at 10:30 AM, Jim Schaad <[email-masked]>
> wrote:
>
>>
>> *From:* pkix [mailto:[email-masked]] *On Behalf Of *Russ Housley
>> *Sent:* Tuesday, April 05, 2016 9:18 AM
>> *Cc:* IETF PKIX <[email-masked]>; IETF SMIME <[email-masked]>
>> *Subject:* Re: [pkix] [smime] Support for email address
>> internationalization in RFC5280 certificates
>>
>>
>>
>> On Apr 4, 2016, at 6:20 PM:
>>
>>
>>
>>
>>
>> On Feb 7, 2016, at 12:15 PM, Wei Chuang <[email-masked]> wrote:
>>
>>
>>
>> On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen <[email-masked]> wrote:
>>
>> 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.
>>
>>
>>
>> Up until now, I have tried to lay low on this topic. However, having
>> reviewed the relevant standards and implementations in the field, I have my
>> 22¢:
>>
>>
>>
>> The proposed methods are to create an otherName form and assign a new
>> object identifier for it (A. Melnikov, ed., draft-ietf-pkix-eai-addresses-00),
>> and to encode the local part in base64 with “:” as an escape signal (L.
>> Baudoin, et. al., draft-lbaudoin-iemax-02). There is also a counterproposal
>> on the agenda, which I will label as #3, to make rfc822Name a CHOICE
>> {IA5String, UTF8String}. There are two other methods that deserve
>> serious consideration. My 0.2¢ is on #4 and my 21.8¢ is on #5:
>>
>>
>>
>> *#4* Extend GeneralName with a new name type:
>>
>>
>>
>> GeneralName ::= CHOICE {
>>
>>   otherName [0] INSTANCE OF OTHER-NAME,
>>
>>   rfc822Name [1] IA5String,
>>
>>   dNSName [2] IA5String,
>>
>>   x400Address [3] ORAddress,
>>
>>   directoryName [4] Name,
>>
>>   ediPartyName [5] EDIPartyName,
>>
>>   uniformResourceIdentifier [6] IA5String,
>>
>>   iPAddress [7] OCTET STRING,
>>
>>   registeredID [8] OBJECT IDENTIFIER,
>>
>>   *eaiName [9] UTF8String*
>>
>>   ... }
>>
>>
>>
>> The advantage of this approach is that it conforms to X.509:2012, which
>> uses … syntax to show that the CHOICE is extensible. However, the IETF
>> invented GeneralName (RFC 2459), and the latest ASN.1 (RFC 5912) does not
>> use … syntax for extensibility. (Basically I think most implementations
>> would barf on this CHOICE, and would cause the overall ASN.1 decoding op to
>> fail, meaning all places where GeneralName is directly encoded, would cause
>> implementations to barf.)
>>
>>
>>
>> *#5* Change GeneralName so that rfc822Name is actually just UTF8String:
>>
>>
>>
>>    GeneralName ::= CHOICE {
>>
>>         otherName                   [0]  INSTANCE OF OTHER-NAME,
>>
>>         rfc822Name                  [1]  *UTF8String*,
>>
>>         dNSName                     [2]  IA5String,
>>
>>         x400Address                 [3]  ORAddress,
>>
>>         directoryName               [4]  Name,
>>
>>         ediPartyName                [5]  EDIPartyName,
>>
>>         uniformResourceIdentifier   [6]  IA5String,
>>
>>         iPAddress                   [7]  OCTET STRING,
>>
>>         registeredID                [8]  OBJECT IDENTIFIER
>>
>>    }
>>
>>
>>
>> GeneralName is in the IMPLICIT TAGS part of PKIX. That means that on the
>> wire, a GeneralName will (almost always) just be serialized as the
>>
>> application tag in the choice, followed by the length and the data. The
>> counterproposal of a CHOICE {IA5String, UTF8String} is flawed in that it
>> will force ALL rfc822Names to include an additional tag UNIVERSAL 22 in the
>> case of IA5String, because the choice is ambiguous without the tag (so a
>> proper ASN.1 compiler will force the serialization and de-serialization of
>> the tag). Note: UTF8String (in a CHOICE) would force serialization of the
>> tag UNIVERSAL 12.
>>
>>
>>
>> With this proposal #5, UTF8String is just a superset of IA5String.
>> Therefore, new implementations will “just work” with virtually no further
>> coding. The high-octet data in UTF8String will violate expectations for
>> older implementations that are looking for IA5String. But enforcement of
>> octets 00-7F is almost never done in the decoding step, or if it is done,
>> it does not cause the entire ASN.1 decoding op to fail. (Note: this would
>> be an “ASN.1 value constraint violation.”) If most implementations will
>> continue to decode the ASN.1 and simply skip over what it perceives to be
>> “invalid ASCII” (or simply rejects that particular alternative when doing
>> name comparisons), we are good to go. This basically mirrors the way that
>> EAI itself works in RFCs 6530-6532.
>>
>>
>>
>> To test this, one would want to construct a signed certificate with
>> “invalid” IA5String data that actually contains valid Unicode octets, and
>> see what happens with various implementations.
>>
>>
>>
>> I am not saying that this is the “right” approach, but I do think that it
>> deserves serious consideration when evaluating alternatives. An example of
>> an advantage is that it should preserve name constraints with no additional
>> coding.
>>
>>
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 13 May 2016 16:09:47 -0400

Wei:

> In order to add a new otherName type in GeneralName which appears to be "owned" by ITU-T, does this then requires coordination with ITU-T?

No.

The syntax for General name (from page 128 of RRC5280):

   GeneralName ::= CHOICE {
        otherName                 [0]  AnotherName,
        rfc822Name                [1]  IA5String,
        dNSName                   [2]  IA5String,
        x400Address               [3]  ORAddress,
        directoryName             [4]  Name,
        ediPartyName              [5]  EDIPartyName,
        uniformResourceIdentifier [6]  IA5String,
        iPAddress                 [7]  OCTET STRING,
        registeredID              [8]  OBJECT IDENTIFIER }

   -- AnotherName replaces OTHER-NAME ::= TYPE-IDENTIFIER, as
   -- TYPE-IDENTIFIER is not supported in the '88 ASN.1 syntax

   AnotherName ::= SEQUENCE {
        type-id    OBJECT IDENTIFIER,
        value      [0] EXPLICIT ANY DEFINED BY type-id }

So, anyone can assign an object identifier and the syntax that goes with it.

In fact, the PKIX WG has already established an IANA registry for the assignment of object identifiers for otherNames.  They have this prefix:

   id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) 
               dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

   id-on   OBJECT IDENTIFIER ::= { id-pkix 8 }    -- other name forms

The registry is here:

   http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

In my view, we just need to add a new object identifiers to this registry ...

Have a great weekend,
  Russ

---

From: Sean Leonard <[email-masked]>
Date: Sun, 15 May 2016 01:41:22 -0700

> On May 13, 2016, at 12:09 PM, Wei Chuang <[email-masked]> wrote:
> 
> I think there's general interest in using draft-ietf-pkix-eai-addresses-00 <https://tools.ietf.org/html/draft-ietf-pkix-eai-addresses-00> to document supporting EAI local part i.e. to use a new GeneralNames otherNames type with UTF8 email address local part.  That said, there are some remaining issues from the previous thread:
> 
> On Wed, Apr 6, 2016 at 3:48 PM, Sean Leonard <[email-masked] <mailto:[email-masked]>> wrote:
> To be clear, the otherName form (draft-ietf-pkix-eai-addresses-00) is a sensible path forward. That is how GeneralName was designed to be extended all along.
> 
> Russ corrected me offline and pointed out that GeneralName is “owned” (well, created originally anyway) by ITU-T X.509. It is not an IETF-originated extension.
> 

No, it does not.

However, once some EAI mechanism is finalized, the ITU-T should be informed because X.509 directs people to encode e-mail addresses in rfc822Name.

(See also Russ Housley’s response.)

Sean