Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates
"Jim Schaad" <ietf@augustcellars.com> Tue, 05 April 2016 17:30 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: smime@ietfa.amsl.com
Delivered-To: smime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED412D1D2; Tue, 5 Apr 2016 10:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 tsqULvEDhhkb; Tue, 5 Apr 2016 10:30:39 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18A712D7B2; Tue, 5 Apr 2016 10:30:37 -0700 (PDT)
Received: from hebrews (dhcp-aae6.meeting.ietf.org [31.133.170.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 75EE92CA95; Tue, 5 Apr 2016 10:30:35 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>, 'Sean Leonard' <dev+ietf@seantek.com>
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>
In-Reply-To: <DD5CD1E9-1031-468C-8AA3-D1E2FEAD0B6F@vigilsec.com>
Date: Tue, 05 Apr 2016 14:30:32 -0300
Message-ID: <028101d18f60$dd6262e0$982728a0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01D18F47.B81AF740"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLOjVDltmejIMpm0/V7VsO85IxshwHtG1NEAiFZuIcCIOHxwQIN1F2GnT+9coA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/smime/eXN6uO1kBsstrritDbZHf_gHWt0>
Cc: 'IETF PKIX' <pkix@ietf.org>, 'IETF SMIME' <smime@ietf.org>
Subject: Re: [smime] [pkix] Support for email address internationalization in RFC5280 certificates
X-BeenThere: smime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SMIME Working Group <smime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/smime>, <mailto:smime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/smime/>
List-Post: <mailto:smime@ietf.org>
List-Help: <mailto:smime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smime>, <mailto:smime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2016 17:30:43 -0000
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
- Re: [smime] [pkix] Support for email address inte… Sean Leonard
- Re: [smime] [pkix] Support for email address inte… Russ Housley
- Re: [smime] [pkix] Support for email address inte… Jim Schaad
- Re: [smime] [pkix] Support for email address inte… Wei Chuang
- Re: [smime] [pkix] Support for email address inte… Dr Stephen Henson
- Re: [smime] [pkix] Support for email address inte… George Michaelson
- Re: [smime] [pkix] Support for email address inte… George Michaelson
- Re: [smime] [pkix] Support for email address inte… Sean Leonard