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

+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.
>
> I agree with the use of the OtherName extension.
>
> Jim
>
> *From:*pkix [mailto:[email protected]] *On Behalf Of *Russ Housley
> *Sent:* Tuesday, April 05, 2016 9:18 AM
> *To:* Sean Leonard <[email protected]>
> *Cc:* IETF PKIX <[email protected]>; IETF SMIME <[email protected]>
> *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 protected] 
> <mailto:[email protected]>> wrote:
>
>
>
>         On Feb 7, 2016, at 12:15 PM, Wei Chuang <[email protected]
>         <mailto:[email protected]>> wrote:
>
>         On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen <[email protected]
>         <mailto:[email protected]>> wrote:
>
>             On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang
>             <[email protected] <mailto:[email protected]>> 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
>
>     _______________________________________________
>     smime mailing list
>     [email protected] <mailto:[email protected]>
>     https://www.ietf.org/mailman/listinfo/smime
>
>
>
> _______________________________________________
> pkix mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/pkix
>
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix