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

From: Sean Leonard <[email-masked]>
Date: Mon, 4 Apr 2016 19:20:10 -0300

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

Regards,

Sean

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2016 08:18:05 -0400

I am opposed to extending GeneralName with a new item in the CHOICE because the syntax in RFC5280.  That syntax is aligned with X.509.  We would need to work with ITU-T to make an addition to the CHOICE, otherwise the ITU-T could make a change to their specification in the future that causes interoperability problems.

I am strongly opposed to changing the type of rfc822name.  As above, this syntax belongs to X.509.  In addition, this change would cause decode errors for existing software, and we have seen decode errors lead to very surprising user experiences.

I believe that using the otherName extension mechanism does not have any of the problems with these two proposals.

Russ

On Apr 4, 2016, at 6:20 PM, Sean Leonard <[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,
>> >
> _______________________________________________
> smime mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/smime

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 5 Apr 2016 14:30:32 -0300

It would also be a good way to have all existing implementations crash as
they see an option in the choice they do not support.

I agree with the use of the OtherName extension.

Jim

From: pkix [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Tuesday, April 05, 2016 9:18 AM
To: Sean Leonard <[email-masked]>
Cc: IETF PKIX <[email-masked]>; IETF SMIME <[email-masked]>
Subject: Re: [pkix] [smime] Support for email address internationalization
in RFC5280 certificates

I am opposed to extending GeneralName with a new item in the CHOICE because
the syntax in RFC5280.  That syntax is aligned with X.509.  We would need to
work with ITU-T to make an addition to the CHOICE, otherwise the ITU-T could
make a change to their specification in the future that causes
interoperability problems.

I am strongly opposed to changing the type of rfc822name.  As above, this
syntax belongs to X.509.  In addition, this change would cause decode errors
for existing software, and we have seen decode errors lead to very
surprising user experiences.

I believe that using the otherName extension mechanism does not have any of
the problems with these two proposals.

Russ

On Apr 4, 2016, at 6:20 PM, Sean Leonard <[email-masked]
<mailto:[email-masked]> > wrote:

On Feb 7, 2016, at 12:15 PM, Wei Chuang <[email-masked]
<mailto:[email-masked]> > wrote:

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

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

GeneralName ::= CHOICE {

  dNSName [2] IA5String,

  directoryName [4] Name,

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

   GeneralName ::= CHOICE {

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.

Regards,

Sean

_______________________________________________
smime mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/smime

---

From: Wei Chuang <[email-masked]>
Date: Tue, 5 Apr 2016 13:05:56 -0700

> I agree with the use of the OtherName extension.

FWIW I pinged someone in OpenSSL about extending OtherName for
international email address, and the reply was that it won't be an issue to
support this modulo their long release cycle (about one a year), and
current OpenSSL won't of course recognize the extension but won't break
either.  Depending on the situation it may be possible to get a change
faster too, and of course supplying a patch could help.

-Wei

>
>
> Jim
>
>
>
>
>
> *From:* pkix [mailto:[email-masked]] *On Behalf Of *Russ Housley
> *Sent:* Tuesday, April 05, 2016 9:18 AM
> *To:* Sean Leonard <[email-masked]>
> *Cc:* IETF PKIX <[email-masked]>; IETF SMIME <[email-masked]>
> *Subject:* Re: [pkix] [smime] Support for email address
> internationalization in RFC5280 certificates
>
>
>
> I am opposed to extending GeneralName with a new item in the CHOICE
> because the syntax in RFC5280.  That syntax is aligned with X.509.  We
> would need to work with ITU-T to make an addition to the CHOICE, otherwise
> the ITU-T could make a change to their specification in the future that
> causes interoperability problems.
>
>
>
> syntax belongs to X.509.  In addition, this change would cause decode
> errors for existing software, and we have seen decode errors lead to very
> I believe that using the otherName extension mechanism does not have any
> of the problems with these two proposals.
>
>
>
> Russ
>
>
>
>
>
> 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 {
>
>   *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
> *#5* Change GeneralName so that rfc822Name is actually just UTF8String:
>
>
>
>    GeneralName ::= CHOICE {
>
>         rfc822Name                  [1]  *UTF8String*,
>
>         dNSName                     [2]  IA5String,
>
> 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.
>
>
>
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
>

---

From: George Michaelson <[email-masked]>
Date: Tue, 5 Apr 2016 18:02:39 -0300

IIRC OpenSSL choses the most compact syntactically acceptable ASN.1
alphabet to represent strings. So, if your labels fit in IA5String,
thats what it is. But if tomorrow you re-issue and they no longer fit,
then it promotes to the next minimally correct ASN.1 alphabet.

For compact encoding stuff, this probably makes sense. for POLA its
pretty awful. We got hit by this in RPKI implementation with
non-conforming names and other things, because the OpenSSL library
detected we were writing hex chars, and down-graded to IA5 when we
didn't expect it.

So, if the intent is to have the stringfield encompass UTF-8 bear in
mind, it often won't be marked as UTF8 on the wire, if you don't force
it to be.

-G

On Tue, Apr 5, 2016 at 5:05 PM, Wei Chuang <[email-masked]> wrote:
> FWIW I pinged someone in OpenSSL about extending OtherName for international
> email address, and the reply was that it won't be an issue to support this
> modulo their long release cycle (about one a year), and current OpenSSL
> won't of course recognize the extension but won't break either.  Depending
> on the situation it may be possible to get a change faster too, and of
> course supplying a patch could help.
>
> -Wei
>
>
>>
>>
>>
>> Jim
>>
>>
>>
>>
>>
>> because the syntax in RFC5280.  That syntax is aligned with X.509.  We would
>> need to work with ITU-T to make an addition to the CHOICE, otherwise the
>> ITU-T could make a change to their specification in the future that causes
>> 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:
>>
>>
>>

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 6 Apr 2016 00:53:57 +0100

> then it promotes to the next minimally correct ASN.1 alphabet.

It can do that if it is configured to do so and the API is used with appropriate
flags. However that is not mandatory behaviour and if you don't want that you
don't have to use it.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 06:32:38 -0300

Oh, if its not the *default* thats much better. I had assumed from how
the problem presented this was because of default settings, but if we
shot ourselves in the foot by selecting this mode, then there isn't an
issue.

Thanks for the clarification Stephen.

-George

---

From: Sean Leonard <[email-masked]>
Date: Wed, 6 Apr 2016 19:48:54 -0300

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.

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:
#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] <mailto:[email-masked]>> wrote:
> 
> 
> From: pkix [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Russ Housley
> Cc: IETF PKIX <[email-masked] <mailto:[email-masked]>>; IETF SMIME <[email-masked] <mailto:[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] <mailto:[email-masked]>> wrote:
> 
>  
>

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 7 Apr 2016 18:44:38 -0300

+1

On 4/5/16 2:30 PM, Jim Schaad wrote:
>
> It would also be a good way to have all existing implementations crash 
> as they see an option in the choice they do not support.
>
> *From:*pkix [mailto:[email-masked]] *On Behalf Of *Russ Housley
> would need to work with ITU-T to make an addition to the CHOICE, 
> otherwise the ITU-T could make a change to their specification in the 
> future that causes interoperability problems.
>
> I am strongly opposed to changing the type of rfc822name.  As above, 
> this syntax belongs to X.509.  In addition, this change would cause 
> decode errors for existing software, and we have seen decode errors 
> lead to very surprising user experiences.
>
> I believe that using the otherName extension mechanism does not have 
> any of the problems with these two proposals.
>
> Russ
>
> <mailto:[email-masked]>> wrote:
>
>
>
>         <mailto:[email-masked]>> wrote:
>
>         <mailto:[email-masked]>> wrote:
>
>             On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang
>             <[email-masked] <mailto:[email-masked]>> wrote:
>             > PKIX community,
>             >
>     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:
>
>     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
>              rfc822Name                  [1]*UTF8String*,
>
>              dNSName                     [2]  IA5String,
>
>     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.
>
>     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.
>
>     Regards,
>
>     Sean
>
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca