Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates
"Dr. Pala" <director@openca.org> Thu, 07 April 2016 21:44 UTC
Return-Path: <director@openca.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B3212D719 for <pkix@ietfa.amsl.com>; Thu, 7 Apr 2016 14:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Level:
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_NAME_DR=1, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWV3pXlFR_bt for <pkix@ietfa.amsl.com>; Thu, 7 Apr 2016 14:44:45 -0700 (PDT)
Received: from mail.katezarealty.com (unknown [IPv6:2607:5501:1000:1ff::87c4]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9C12D10C for <pkix@ietf.org>; Thu, 7 Apr 2016 14:44:45 -0700 (PDT)
Received: from iMassi.local (unknown [IPv6:2001:67c:1231:998:e441:1876:7519:1b0a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 2FF973743B8F for <pkix@ietf.org>; Thu, 7 Apr 2016 17:44:39 -0400 (EDT)
To: pkix@ietf.org
References: <CAAFsWK0F6K_9VrDL7aX0QN56mWdhHsq0KV_1moR9pJ=A4E1BaA@mail.gmail.com> <CAK6vND-nAztjm9DzKNdCf1Hm2rbN5zAN4GWKuu5PiF49LeRSsw@mail.gmail.com> <CAAFsWK0yYrEJkazOcyc+hOUTaihcBi6Aa31g9g3TyxvVzxyF5A@mail.gmail.com> <C726CA9F-369B-4EC9-BB0E-8AE38553858D@seantek.com> <DD5CD1E9-1031-468C-8AA3-D1E2FEAD0B6F@vigilsec.com> <028101d18f60$dd6262e0$982728a0$@augustcellars.com>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <5706D4C6.5080003@openca.org>
Date: Thu, 07 Apr 2016 18:44:38 -0300
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <028101d18f60$dd6262e0$982728a0$@augustcellars.com>
Content-Type: multipart/alternative; boundary="------------010901020704010300010700"
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/hWHSror7bOJEPYEvgPQP_r1tXhI>
Subject: Re: [pkix] [smime] Support for email address internationalization in RFC5280 certificates
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2016 21:44:48 -0000
+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:pkix-bounces@ietf.org] *On Behalf Of *Russ Housley > *Sent:* Tuesday, April 05, 2016 9:18 AM > *To:* Sean Leonard <dev+ietf@seantek.com> > *Cc:* IETF PKIX <pkix@ietf.org>; IETF SMIME <smime@ietf.org> > *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 <dev+ietf@seantek.com > <mailto:dev+ietf@seantek.com>> wrote: > > > > On Feb 7, 2016, at 12:15 PM, Wei Chuang <weihaw@google.com > <mailto:weihaw@google.com>> wrote: > > On Fri, Feb 5, 2016 at 4:46 PM, Peter Bowen <pzbowen@gmail.com > <mailto:pzbowen@gmail.com>> wrote: > > On Thu, Feb 4, 2016 at 11:05 AM, Wei Chuang > <weihaw@google.com <mailto:weihaw@google.com>> 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 > smime@ietf.org <mailto:smime@ietf.org> > https://www.ietf.org/mailman/listinfo/smime > > > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Massimiliano Pala, PhD > Director at OpenCA Labs > twitter: @openca
- Re: [pkix] Support for email address internationa… Wei Chuang
- Re: [pkix] Support for email address internationa… Peter Bowen
- [pkix] Support for email address internationaliza… Wei Chuang
- Re: [pkix] Support for email address internationa… Sean Leonard
- Re: [pkix] [smime] Support for email address inte… Russ Housley
- Re: [pkix] [smime] Support for email address inte… Jim Schaad
- Re: [pkix] [smime] Support for email address inte… Wei Chuang
- Re: [pkix] [smime] Support for email address inte… George Michaelson
- Re: [pkix] [smime] Support for email address inte… Dr Stephen Henson
- Re: [pkix] [smime] Support for email address inte… George Michaelson
- Re: [pkix] [smime] Support for email address inte… Sean Leonard
- Re: [pkix] [smime] Support for email address inte… Dr. Pala