From hotz@jpl.nasa.gov Tue Jun 1 11:40:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC433A699C for ; Tue, 1 Jun 2010 11:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afxlNU0D5O-X for ; Tue, 1 Jun 2010 11:40:23 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id DC6753A696F for ; Tue, 1 Jun 2010 11:40:22 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.1) with ESMTP id o51IdiUD006392; Tue, 1 Jun 2010 11:39:45 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <20100531185813.GA32106@eltex.net> Date: Tue, 1 Jun 2010 11:39:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <465A9C16-F5BF-47B5-A534-25C68CB2988F@jpl.nasa.gov> References: <4C00FEC0.3080808@edelweb.fr> <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> <20100531185813.GA32106@eltex.net> To: ArkanoiD X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "certid@ietf.org" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 18:40:27 -0000 This looks to me like a case of "violent agreement". On May 31, 2010, at 11:58 AM, ArkanoiD wrote: > On Mon, May 31, 2010 at 05:18:17PM +0200, Martin Rex wrote: >>>=20 >>> example, you a Common Name attribute containing the server's name >>> and if the cert has a subjectAltName, have I 'represented' the >>> server's name in the Common Name or not? I have put it in, >>> I don't expect that someone verifies it there, but still, I have >>> can think I have represented it in two places. >>=20 >> There is going to be software that will check the CN=3D RDName of the >> certificate subject name for a match, even when subjectAltName of >> type dNSName are present. Either because they're fully backwards >> compatible or because they do not check subjectAltNames at all. >=20 > Actually it should not, though i do not see any harm in behaving that > way. His observation was not w.r.t. what SHOULD happen, but a pragmatic = observation of what WILL happen in the real world. >> While there have been few implementations checking for multiple >> CN=3D parts, the guideline in rfc-2818 for subjectAltNames seems >> to be much clearer, that there can be more than one, and more >> than one needs to be checked. >=20 > ..and multiple CNs are likely to be an error. I'd better reject this > certificate as invalid. He says there are "few" implementations that accept what you consider an = error. Possibly there are zero, but I hope it's few enough we can = ignore them. (Life's complex enough as it is.) >> Example: https://www.entrust.com =20 >>=20 >> It contains a CN=3Dwww.entrust.com and two subjectAltNames >> type dNSName with the values "www.entrust.com" and = "secure.entrust.com" >>=20 >> And a reasonable, fully backwards compatible approach to server = endpoint >> identification would be to check all names for a match sequentially, >> and succeed when any one matches. >=20 > But we may safely ignore CN in this case, and that's what we probably = intend > to do. Agreed. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From matt@mattmccutchen.net Tue Jun 1 12:39:37 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E483A6A6C for ; Tue, 1 Jun 2010 12:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh7S1w7ChQNb for ; Tue, 1 Jun 2010 12:39:33 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id E67773A6A72 for ; Tue, 1 Jun 2010 12:38:57 -0700 (PDT) Received: from [192.168.1.41] (pool-74-96-44-249.washdc.east.verizon.net [74.96.44.249]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id 93A09BCDAB for ; Tue, 1 Jun 2010 12:38:45 -0700 (PDT) From: Matt McCutchen To: certid@ietf.org In-Reply-To: <465A9C16-F5BF-47B5-A534-25C68CB2988F@jpl.nasa.gov> References: <4C00FEC0.3080808@edelweb.fr> <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> <20100531185813.GA32106@eltex.net> <465A9C16-F5BF-47B5-A534-25C68CB2988F@jpl.nasa.gov> Content-Type: text/plain; charset="UTF-8" Date: Tue, 01 Jun 2010 15:38:43 -0400 Message-ID: <1275421123.1918.7.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 19:39:37 -0000 On Tue, 2010-06-01 at 11:39 -0700, Henry B. Hotz wrote: > >> While there have been few implementations checking for multiple > >> CN= parts, the guideline in rfc-2818 for subjectAltNames seems > >> to be much clearer, that there can be more than one, and more > >> than one needs to be checked. > > > > ..and multiple CNs are likely to be an error. I'd better reject this > > certificate as invalid. > > He says there are "few" implementations that accept what you consider > an error. Possibly there are zero, but I hope it's few enough we can > ignore them. (Life's complex enough as it is.) For some test results for implementation support for multiple CNs (possibly outdated by now), see: http://wiki.cacert.org/VhostTaskForce#Interoperability_Test -- Matt From mrex@sap.com Wed Jun 2 15:37:30 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F004F3A6A25 for ; Wed, 2 Jun 2010 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.499 X-Spam-Level: X-Spam-Status: No, score=-7.499 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeZvKnI-SbpZ for ; Wed, 2 Jun 2010 15:37:29 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id DF1BB3A67ED for ; Wed, 2 Jun 2010 15:37:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o52MbEm4022853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jun 2010 00:37:14 +0200 (MEST) From: Martin Rex Message-Id: <201006022237.o52MbEuR000805@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Thu, 3 Jun 2010 00:37:13 +0200 (MEST) In-Reply-To: <1275421123.1918.7.camel@mattlaptop2.local> from "Matt McCutchen" at Jun 1, 10 03:38:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 22:37:31 -0000 Matt McCutchen wrote: > > For some test results for implementation support for multiple CNs > (possibly outdated by now), see: > > http://wiki.cacert.org/VhostTaskForce#Interoperability_Test Thanks for that link! I'm puzzled why the list shows IE. AFAIK, the hostname matching is entirely performed inside of SChannel SSP (Microsoft's TLS implementation), and that is a part of the operating system since at least Windows 2000, and _not_ a part of the MSIE browser. And even today, the installed base of Windows XP outnumbers the installed base of Windows Vista and Windows 7 combined, so talking about particular versions of MSIE instead of specific combinations of the Windows Operating System plus a particular version of the MSIE browser is confusing/misleading. -Martin From mrex@sap.com Wed Jun 2 15:51:09 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256FC28C169 for ; Wed, 2 Jun 2010 15:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.518 X-Spam-Level: X-Spam-Status: No, score=-7.518 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UAV2UcAX69A for ; Wed, 2 Jun 2010 15:51:05 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3C03328C139 for ; Wed, 2 Jun 2010 15:51:04 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o52MooWk004160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jun 2010 00:50:50 +0200 (MEST) From: Martin Rex Message-Id: <201006022250.o52Moncr001727@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 3 Jun 2010 00:50:49 +0200 (MEST) In-Reply-To: <201006022237.o52MbEuR000805@fs4113.wdf.sap.corp> from "Martin Rex" at Jun 3, 10 00:37:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 22:51:09 -0000 Martin Rex wrote: > > Matt McCutchen wrote: > > > > For some test results for implementation support for multiple CNs > > (possibly outdated by now), see: > > > > http://wiki.cacert.org/VhostTaskForce#Interoperability_Test > > Thanks for that link! > > I'm puzzled why the list shows IE. AFAIK, the hostname matching > is entirely performed inside of SChannel SSP > (Microsoft's TLS implementation), and that is a part of the operating > system since at least Windows 2000, and _not_ a part of the MSIE browser. > > And even today, the installed base of Windows XP outnumbers the > installed base of Windows Vista and Windows 7 combined, so talking > about particular versions of MSIE instead of specific combinations > of the Windows Operating System plus a particular version of > the MSIE browser is confusing/misleading. Background info: http://msdn.microsoft.com/en-us/library/aa375924%28VS.85%29.aspx See description of function parameter pszTargetName in the API description of the SSPI call InitializeSecurityContext(SChannel). The pszTargetName input parameter is necessary to make client side session caching work, so it is likely always asserted by all versions of MSIE -- causing the SChannel SSP to perform the certificate verification against this name -- if the documentation is correct. However, MSIE could add additional checks on top of that, which I am not aware of. -Martin From stpeter@stpeter.im Thu Jun 3 14:12:37 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF1A28C122 for ; Thu, 3 Jun 2010 14:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4R-NY2r7lM-T for ; Thu, 3 Jun 2010 14:12:36 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 20FB928C104 for ; Thu, 3 Jun 2010 14:12:36 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5005640E26 for ; Thu, 3 Jun 2010 15:12:22 -0600 (MDT) Message-ID: <4C081AB5.8050705@stpeter.im> Date: Thu, 03 Jun 2010 15:12:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C015310.5030708@edelweb.fr> In-Reply-To: <4C015310.5030708@edelweb.fr> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070609010103070500090904" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:12:38 -0000 This is a cryptographically signed message in MIME format. --------------ms070609010103070500090904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/29/10 11:46 AM, Peter Sylvester wrote: > some more details. >=20 > In 1.1: >=20 >=20 > There is the possibility to indicate several identities: >=20 > "Only a match between the client's reference identity and the server's > presented identity enables the client to be sure that the certificate > can legitimately be used to secure the connection." > =3D=3D> > "In general, a match between the client's reference identity and one of= > the server's > presented identities is required to enable the client to be sure that > the certificate > can legitimately be used to authenticate the connection." Ah, I see what you're getting at. Yes, the existing text is rather informal, since later in the document we talk more precisely about identifiers, not identity. I've reworded that paragraph as follows: When a client connects to an application server using Transport Layer Security [TLS] (or, less commonly, [DTLS]), it references some conception of the server's identity while attempting to establish a secure connection (e.g., "the web site at example.com"). Likewise, during TLS negotiation the server presents its conception of the server's identity in the form of a public-key certificate that was issued by a certification authority in the context of the Internet Public Key Infrastructure using X.509 [PKIX]. Informally, we can think of these identities as the client's "reference identity" and the server's "presented identity" (these rough ideas are defined more precisely later in this document through the concept of particular identifiers). In general, a client needs to verify that the server's presented identity matches its reference identity so that it can be sure that the certificate can legitimately be used to authenticate the connection. > (see: "The application server is identified by a name or names carried = in > the subject field and/or the subjectAltName extension of the > certificate.") >=20 > "The Internet Public Key Infrastructure" sounds ambiguous quite right t= o > me. > - The only thing of a PKI in question that is ever transmitted > and visible in the Internet might be the server's certificate. > - There is no "Internet PKI" (like the DNS). >=20 RFC 5280 has the title "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". We're simply inheriting from that, because it is a common baseline for this proposed BCP and defines terms that are familiar to those who will use this proposed BCP. If you have problems with RFC 5280, please take that up with the authors of RFC 5280. > "in the context of the Internet Public Key Infrastructure using X.509" > =3D=3D> > "in the context of a Public Key Infrastructure using X.509". See above. > Likewise, during TLS negotiation the server presents > its conception of the server's identity >=20 > Application protocols have traditionally specified their own rules > for representing and verifying server identities. >=20 > I suggest to replace "represent" by "present". (The word represent seem= s > to be used interchangeable with present in the current text). I'd prefe= r > even 'indicate' instead. Your distinctions are quite subtle. The server has a certificate. It presents (gives, hands over, shows, offers) the certificate to the client during TLS negotiation. Thus "present" seems appropriate in the first quoted sentence. The server's certificate contains various information (e.g., subjectAltName extensions). That information is intended to represent (depict, describe, symbolize, embody) the server's identity. Thus "representing" seems appropriate in the second quoted sentence. IMHO "indicate" is not a good substitute for "present" in the first sentence or "represent" in the second sentence, because "indicate" is a bit ambiguous -- it can mean either "point, show" (roughly equivalent to "present") or "be a sign of" (roughly equivalent to "represent"). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms070609010103070500090904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzIxMTIyMVowIwYJKoZIhvcNAQkEMRYEFJG6tAkV8Bz0/h6LL36P 6hYjr805MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAX3DF0ECVyh1F5Vi+tCnFpBMyHRgPabnHfQPhEDmA U7RLPfT2swGd3/pYx1kFgeImQK7snpzbnYMwOhfyTsKl9yuCz9uqriCAqPd8oTIjAKFovsie PFgC8/OxTqSIdKPNPyFB7uh7mvLu+ie2F0pHHdTPcq9y31ItSZs2Jk+AolryflZaiPxK1s/C yCG6KEtW1jwvMsKWLjh54r4wHFu8egjIlFfuK6mbem2cWbslEEKYDxbC72h3l4WDiQKY4PSg yUep6uCMu9mx6kHN/E4pfj8FCat6i7Ck2yw5tB4R2ts2JoMtJjyoF9jbeY3aTB+uWGQYf5Xv xEjnpn4RwR4QugAAAAAAAA== --------------ms070609010103070500090904-- From stpeter@stpeter.im Thu Jun 3 14:53:07 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6178028C132 for ; Thu, 3 Jun 2010 14:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[AWL=-1.862, BAYES_50=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6ct8ZDgD3jO for ; Thu, 3 Jun 2010 14:53:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0C91928C123 for ; Thu, 3 Jun 2010 14:53:04 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7F37E40E26; Thu, 3 Jun 2010 15:52:50 -0600 (MDT) Message-ID: <4C082431.3050900@stpeter.im> Date: Thu, 03 Jun 2010 15:52:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Sylvester References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> In-Reply-To: <4C00FEC0.3080808@edelweb.fr> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020709090802030800040704" Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:53:07 -0000 This is a cryptographically signed message in MIME format. --------------ms020709090802030800040704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/29/10 5:47 AM, Peter Sylvester wrote: > On 05/29/2010 12:00 AM, Peter Saint-Andre wrote: >> On 5/14/10 2:48 AM, Peter Sylvester wrote: >> =20 >>> >>> =20 >>>> In particular here's what RFC 2818 sez (in section 3.1 Server >>>> Identity).. >>>> >>>> If a subjectAltName extension of type dNSName is present, that M= UST >>>> be used as the identity. Otherwise, the (most specific) Common N= ame >>>> field in the Subject field of the certificate MUST be used. ... >>>> >>>> ..which is ambiguous because X.501 does not explicitly state which R= DN >>>> in the DN sequence is the most specific (it's implied) and there >>>> allegedly exist non-trivial slices of current practice don't >>>> necessarily follow that stipulation anyway (for whatever reasons). >>>> =20 >>> DNs as a sequences of RDNs form a hierarchical name space similar to = the >>> DNS name space. >>> with the difference that the "labels" are not just a piece of texts b= ut >>> are structured , i.e. >>> SET OF of attribute/values assertions. >>> >>> If one writes "a.b.c" then this is something that can be described as= a >>> string folling DNS name syntax, >>> and I could use it in whatever environment. >>> >>> What is ambiguous in 2818 is that you may have a set of AVAs with mo= re >>> than one >>> occurence of an AVA with common name. In theory... >>> =20 > The sentence starting with 'What" was the comment. OK. If you think that text in RFC 2818 is problematic, then feel free to express the need for fixing RFC 2818. If the ambiguities in RFC 2818 have leaked into this proposed BCP, then that's something we can fix. >>> Using the term 'field' is somewhat sloppy wording. >>> =20 >> =20 > There are two usages of field. There is no 'Common namefield". >> We borrowed that wording from RFC 5280. Do you have a suggestion for >> improvement? And, from the perspective of this proposed BCP, does it >> make a material difference? >> =20 > There is a subsject field, but such thing as a 'Common name field'. I don't think that the term "Common name field" is used in this proposed BCP. > Using vocabulary which is undefined is not the best way to explain > best practices, i.e. to clarify usages, IMO. Agreed. But splitting hairs or coming up with new terminology might not be a productive use of our time. >>>> Also, we should note that the current rev of "CA/Browser Forum: >>>> Guidelines For The Issuance And Management Of Extended Validation >>>> Certificates (version 1.2)"= >>>> specifies using CN (commonName) containing the host domain name /or/= >>>> dNSName in subjectAlternativeName (see section 8.1.1(2) therein), >>>> rather than deprecating use of subject:commonName (in that doc's >>>> notation). that doc also doesn't specify where in the DN's RDN >>>> sequence an RDN of type commonName should/must be placed. >>>> =20 >>> Indeed. This is not surprising, if one looks at certification policie= s, >>> they are also pretty unprecise in that area. >>> >>> But: what is deprecated in RFC 2818 is the fact not using >>> a subjectAltName: RFC 2818 didn't deprecate much. >>> If a subjectAltName extension of type dNSName is present, that MU= ST >>> be used as the identity. Otherwise, the (most specific) Common Na= me >>> field in the Subject field of the certificate MUST be used. Altho= ugh >>> the use of the Common Name is existing practice, it is deprecated= >>> and >>> Certification Authorities are encouraged to use the dNSName inste= ad. >>> >>> At least, if I understand the "otherwise" correctly and apply >>> Boolean an IETF logic. >>> >>> As soon as one adds a subjectAltName, a verifier conformant >>> to 2818 doesn't even look for a common name. >>> >>> As a "best practice", one may say that having >>> exactly one common name AVA in a single value RDN with >>> ensures that the cert is recognized as one belonging >>> to the intended host. >>> >>> and to have an identical value in a subjectAltName >>> >>> One may add that putting it as the last element in the >>> sequence covers the 0.000001% of very strange things, >>> I'd rather say that it is not necessary for this RDN >>> to be the last (i.e. explicitely tell verifiers so) >>> >>> =20 > No comment here?? Your point was too subtle for me to understand, so I didn't comment. >>>> (so we have some evangelizing to do with the CABForum folk...) >>>> =20 >>> Well, my hourly fee is ... negotiable :-) >>> >>> I (really don't) wonder how many of the CAs in that forum allow a >>> certificate request with two common names... >>> >>> I think it is very important that the RFC use clear wording that >>> is also easy to understand by non native English. >>> >>> 7. The certificate SHOULD NOT represent the server's DNS domain >>> name >>> in a Relative Distinguished Name (RDN) of type Common Name (C= N) >>> (see [LDAP-SCHEMA]) within the subjectName field, even though= it >>> is recognized that many deployed clients still check for this= >>> legacy identifier configuration within certificate subjectNam= e. >>> >>> I do not see any reason for this unless one adds 'only' before the >>> within. see above. >>> =20 >> How about removing the words "within the subjectName field"? >> =20 > The point is not (since already said) that there is no such thing > as 'an RDN of type Common Name', there are only AVAs but: >=20 > The SHOULD NOT may be misleading for a non-native English. > It may be understood as "It is not a good idea at all to put > an attribute of type Common Name in any RDN since it can be > misunderstood as the server's name independantly of what > is put in the subjectAltname extension." =20 I fail to see the ambiguity. This says "You can include a CN, but you should not make the content of that CN a DNS domain name". > 'represent' is ambiguous > here. See my other message to the list (sent a few minutes ago). > exampe, you a Common Name attribute containing the server's name > and if the cert has a subjectAltName, have I 'represented' the > server's name in the Common Name or not? I have put it in, > I don't expect that someone verifies it there, but still, I have > can think I have represented it in two places. What is "the server's name"? Let's take a concrete example, say the Google Talk service hosted at talk.google.com. I would say that you have: O=3DGoogle CN=3DGoogle Talk dNSName=3Dtalk.google.com Here the name of the service is "Google Talk" and that's represented in the Common Name (because it is a human-friendly name for the service). We are recommending against putting "talk.google.com" in the CN. >>> However, if this legacy identifer configuration is employed, >>> then >>> the server's DNS domain name MUST be placed in the last (most= >>> specific) RDN within the RDN sequence making up the >>> certificate's >>> subjectName, as the order of RDNs is determined by the DER- >>> encoded Name within the server's PKIX certificate. >>> >>> If one takes the text without saying that subjectAltName has precedec= e, >>> I think the message is wrong. >>> =20 >> Does this proposed BCP say that the subjectAltName has precedence? If >> that is not clear, then we need to clarify it. I meant "doesn't", not "does". > As I said, here you have room for clarification. You essentially > rewrite 2818=20 This proposed BCP is not limited to HTTP so it does not (only) rewrite RFC 2818, but yes it is intended (in part) to provide more up-to-date guidelines. > (the most specific) without clarifying the > amiguity of multiple AVAs and without mentioning that > is is a BAD idea to have several attributs with type Common > Name. Because you are the first person to raise that issue. What exactly is the problem with multiple CNs? What is the attack? > "However, if this legacy identifier configuration is employed, > in order to be surely recognizable, there SHOULD only > be one attribute of type Common Name, and that ava > SHOULD occur in a single element RDN." Something like that seems sensible. The significance of the last clause is not clear to me. >>> The subject field of a PKIX Certificate is defined as a X.501 type= >>> Name [PKIX] and known as a Distinguished Name (DN). See also >>> [X.501] >>> A DN is an ordered sequence of attribute type and attribute value= >>> pairs (termed "attribute value assertions (AVAs)"), where the >>> attributes are to be those of the subject. Each AVA is also >>> termed a >>> "Relative Distinguished Name (RDN)". The RDNs are ordered in the= DN >>> sequence from most general to most specific. >>> >>> this is simply wrong. >>> >>> DistinguishedName ::=3D RDNSequence >>> >>> RDNSequence ::=3D SEQUENCE OF RelativeDistinguishedName >>> >>> RelativeDistinguishedName ::=3D SET SIZE (1..MAX) OF >>> AttributeTypeAndValue >>> >>> AttributeTypeAndValue ::=3D SEQUENCE { >>> type AttributeType, >>> value AttributeValue } >>> =20 >> Our working copy of version -05 currently says: >> >> The subject field of a PKIX certificate is defined as an X.501 typ= e >> Name and known as a Distinguished Name (DN) -- see [X.501] and >> [PKIX]. A DN is an ordered sequence of Relative Distinguished Nam= e >> (RDNs), where an RDN is a set (i.e., an unordered group) of type-a= nd- >> value pairs [LDAP-DN], each of which asserts some attribute about = the >> subject of the certificate. The RDNs are ordered in the DN sequen= ce >> from most general to most specific. >> =20 > Ok. >> =20 >>> Often such a >>> DN string representation is ordered from left-to-right, most >>> specific >>> to most general. See [LDAP-AUTH] for details. >>> =20 >> OK. In fact do we need to say anything about the order (specific to >> general or general to specific)? >> =20 > The RDN order is the only thing clearly defined. What one should say > is that unfortunately there are the two orders in textual representatio= ns > multiplied by the two ways of reading them and that when tools > are displaying rdns in windows, things may be worse. >=20 > "When creating DNs, care must be taken in order to be sure that > the desired order of the RDN sequence is obtained." Thanks for the text, I've added that sentence (but I changed "obtained" to "enforced"). >>> I'd rather say that unfortunately both orderings occur and >>> it not always obvious to see which is used. I know about a >>> institude's CA that has country (C=3DDE) as last element >>> got that certified. :-) >>> =20 >> So: >> >> ... In practice, the RDNs can be ordered in >> the DN sequence from most general to most specific or most specifi= c >> to general, and the order cannot be relied upon. >> >> Better? >> =20 > In the DN encoding, the first element is the most significant > (for the decoding party). OK. > The encoding party MUST be careful that the first element > is encoding receives the intended attribute. Right. >>> 8. The certificate MUST NOT represent the server's DNS domain na= me >>> by means of a series of Domain Component (DC) attributes >>> (because >>> the order of Domain Components is not guaranteed, certain >>> attacks >>> are possible if DC attributes are included). >>> >>> I think that this is also not nice wording. What is ment IMO is >>> that the server MUST NOT assume that whatever is put in DCs >>> is recognized as a domain name. >>> =20 >> This section is about certificate issuance, not client processing (or >> server interpretation of the certificate, which so far is utterly out = of >> scope for this proposed BCP). >> =20 > "Certain attacks", IMO, that's not something to be used to justify > a MUST NOT. >=20 > The point is the word "represent". As above. >> =20 >>> One should be careful about such words, sine it may be that >>> some extremely strict verifier misinterprets it. Talking about >>> 'certain attacks' doesn't seem a useful information. >>> =20 >> Consider: >> >> 1. DC=3Dcom, DC=3Dexample, DC=3Dcn >> >> vs. >> >> 2. DC=3Dcn, DC=3Dexample, DC=3Dcom >> >> Clearly com.example.cn !=3D cn.example.com, but if one interpreted DCs= >> then both of those DNS domain names would match #1 and #2. >> =20 > And you can have dc=3Dcn.example.com Or perhaps dc=3Dcn.example, dc=3Dcom (or whatever)? In any case it seems like a bad idea to allow DCs and I've added a security consideration about this. >>> 2. After the server provides its presented identifiers in the fo= rm >>> of an PKIX certificate, the client checks each of its referen= ce >>> identifiers against the presented identifiers for the purpose= of >>> finding a match. >>> >>> 'presents its' instead of 'provides its presented' >>> and remove 'after'. It maybe present out of band >>> =20 >> Sure. Changed. >> =20 > Ok >> =20 >>> The reference identifiers is matched with identifiers >>> included/present/provided/electable in a PKIX certificate >>> belonging to the server, i.e. by which the intended >>> communication of data verification can be authenticated >>> cryptograhically. >>> >>> I don't really like PKIX here, one may have an X509 cert that is not >>> conformant to the PKIX profile. >>> =20 >> One may, but we're not trying to cover every possible profile of X.509= v3 >> here, only those conformant to the PKIX profile. >> =20 > fair. >=20 >> =20 >>> In addition to checking identifiers, a client MAY complete further= >>> checks to ensure that the server is authorized to provide the >>> requested service. However, methods for doing so (e.g., consulti= ng >>> local policy information) are out of scope for this document. >>> >>> The chapter talks about Server identity verification. This paragraph >>> doesn't belong to this imo. >>> =20 >> It's just an implementation note. I've added some clarifying text. >> =20 > will see. >> =20 >>> o The list SHOULD NOT include a CN-ID; however, the CN-ID (if >>> included) MUST be constructed only from the source domain and >>> never from a target domain. >>> >>> Note: A client MUST NOT construct a reference identifier >>> corresponding to Relative Distinguished Names (RDNs) other tha= n >>> the Common Name and MUST NOT check for such RDNs in the presen= ted >>> identifiers. In particular, this means that a client MUST NOT= >>> check a series of Domain Component (DC) attributes if included= in >>> the certificate (because the order of Domain Components is not= >>> guaranteed, certain attacks are possible if DC attributes are >>> checked). >>> >>> since a CN-ID is: >>> >>> CN-ID =3D a Relative Distinguished Name (RDN) of type Common Na= me >>> (CN) >>> >>> what is the purpose of the note? >>> =20 >> The purpose of the note is to warn client developers against using DCs= =2E >> =20 > Hm, need to think more. See the security considerations in -05 (will publish soon). >>> 3.4.4 seems to have a lot of redundant information and not the >>> same as already presented elsewhere. >>> =20 >> Repetition is not necessarily a bad thing. We assume that client >> developers will read only section 3, not section 4. >> =20 > You seem to consider this as a matter of style, I don't. > We may be in violant disagreement, I don't fight. :-) OK. >>> All text starting from >>> thesecond paragraph can be replaced by >>> >>> Therefore, if and only if the identity set does not include >>> subjectAltName extensions of type dNSName, SRVName, or >>> uniformResourceIdentifier (or any application-specific >>> subjectAltName >>> extensions), the client MAY as a fallback check cfor a CN-ID. >>> =20 >> Maybe, but I think the repetition is useful. I'll double-check this wh= en >> I have more time. >> >> =20 > Hm, if you succeed to get more time, tell me the recipe. :-) GTD. :) >>> The examples may be put into the description of the certificate subje= ct >>> structure. >>> >>> >>> 3.6: There may also be the case where the server does not present a c= ert >>> at all. not the case of tls etc, but one may verify signatures of OCS= P, >>> TSAs etc. >>> =20 >> Out of scope. We might write another spec about such use cases, but in= >> this case we think we're covering at least 80% of the usage. >> =20 > Why out of scope? what has the interpretation of a cert to do with > the way it is detected/communicated? Out of scope because we're trying to limit this proposed BCP to exactly what is described in the Scope section. An OSCP responder is not an application service as described in this proposed BCP. Feel free to write your own BCP for such a scenario, but it's out of scope for this on= e. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020709090802030800040704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzIxNTI0OVowIwYJKoZIhvcNAQkEMRYEFMOFWHQj66qXl+OU4i3B tIsosO6dMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAGAe1RlFcrQD/bsqvlU1MEbqRMwz3akfi9kVqCWel N9/ok8fmALMfgF9onk4RkoIWOTutUyVX+cTTQ+X4eIJmhQOA3Ah+yNnWM6XH5ymxh7fVH0yX 7t5b5znHT8SZGe+zv6Q9z9cPLvCoxtJkClNhR7dqFEgWkN0nPINxzVEZdDbjqKPGiED517+F EEU/88v0mSGODMdZoQRsizhQuKRLpl277RQEz95GsUfhqWJxJbaV/swvF4sJlsoNYUR936xN Yy47riwS5bTvREGYneG09UW62vVx3RYbF3EIOq2KslQASkY275Zy8ZsbXT4U5lFeqsV5mHgL Wx4POZLXP4aKUgAAAAAAAA== --------------ms020709090802030800040704-- From nelson@bolyard.me Thu Jun 3 14:53:33 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A8228C140 for ; Thu, 3 Jun 2010 14:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME5cBLQnw+ao for ; Thu, 3 Jun 2010 14:53:32 -0700 (PDT) Received: from p3plsmtpa01-07.prod.phx3.secureserver.net (p3plsmtpa01-07.prod.phx3.secureserver.net [72.167.82.87]) by core3.amsl.com (Postfix) with SMTP id 528CE28C12C for ; Thu, 3 Jun 2010 14:53:32 -0700 (PDT) Received: (qmail 9784 invoked from network); 3 Jun 2010 21:53:18 -0000 Received: from unknown (74.121.22.10) by p3plsmtpa01-07.prod.phx3.secureserver.net (72.167.82.87) with ESMTP; 03 Jun 2010 21:53:18 -0000 Message-ID: <4C08244D.9010809@bolyard.me> Date: Thu, 03 Jun 2010 14:53:17 -0700 From: Nelson B Bolyard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> In-Reply-To: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:53:33 -0000 On 2010/05/31 08:18 PDT, Martin Rex wrote: > While there have been few implementations checking for multiple > CN= parts, the guideline in rfc-2818 for subjectAltNames seems > to be much clearer, that there can be more than one, and more > than one needs to be checked. That is precisely what it says NOT to do. It says > If a subjectAltName extension of type dNSName is present, that MUST > be used as the identity. Otherwise, the (most specific) Common Name > field in the Subject field of the certificate MUST be used. The phrease "the (most specific) Common Name field in the subject field" is not plural. There is at most one Common Name attribute in the name that is *the* most specific one. The words "most specific" refer to its position in the list of RDNs, which are arranged (as encoded in the certificate Name field) from most general (first) to most specific (last). So, the most specific Common Name is the last of the Common Name attributes in the sequence of RDNs, as encoded in the certificate. From turners@ieca.com Thu Jun 3 14:59:29 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721DF28C123 for ; Thu, 3 Jun 2010 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.885, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4isMZkOgqyHq for ; Thu, 3 Jun 2010 14:59:26 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 11C593A69F3 for ; Thu, 3 Jun 2010 14:59:25 -0700 (PDT) Received: (qmail 15509 invoked from network); 3 Jun 2010 21:59:10 -0000 Received: from thunderfish.local (turners@71.191.5.250 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 03 Jun 2010 14:59:10 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: fzeO4wQVM1nyrM819DClr4wZFo.uyhLTmz1W8T5eabt9kAH3wwCKuowG73WqnZPzh.fexv.gdmdqQG77z6len65aLMzvXUBRmUJ6pj7oMHTDsYNCYCXCAIvEiwJmGahUanVLJv.HY3CSt01chnKUSA.8k5HWg36wsNmxTmeLd1mhaUjqHgJyXZOpNmaDGw2WF1fqpIxiaVhrc5glIIZ39ioJ1llxS2T_iwrH8UiL0vvOSV3i0s8WFRayP1FWlrBcWWCCACwHdLbh4YUZSeXPUzywRBmN0XZPo82eTJsLw7OGAgKWT7ymZBDfY75PyG.mmEqkShd.ZfrcYcLFff4kmLfikVEv2ug84cdTPc.mqKAiqaVL_.S43MLZsAkQVD5rNgeJi5lsxw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0825AD.1020309@ieca.com> Date: Thu, 03 Jun 2010 17:59:09 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C082431.3050900@stpeter.im> In-Reply-To: <4C082431.3050900@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 21:59:29 -0000 >> As I said, here you have room for clarification. You essentially >> rewrite 2818 > > This proposed BCP is not limited to HTTP so it does not (only) rewrite > RFC 2818, but yes it is intended (in part) to provide more up-to-date > guidelines. Should we add a section that moves 2818 to historic? (sorry if this has been asked before) spt From stpeter@stpeter.im Thu Jun 3 15:04:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824E628C122 for ; Thu, 3 Jun 2010 15:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kBnUKW97Dn2 for ; Thu, 3 Jun 2010 15:04:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3AE513A680A for ; Thu, 3 Jun 2010 15:04:48 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D89C2403F3 for ; Thu, 3 Jun 2010 16:04:34 -0600 (MDT) Message-ID: <4C0826F1.8000608@stpeter.im> Date: Thu, 03 Jun 2010 16:04:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060504080402050708040400" Subject: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-05.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 22:04:49 -0000 This is a cryptographically signed message in MIME format. --------------ms060504080402050708040400 Content-Type: multipart/mixed; boundary="------------050909060905070005030803" This is a multi-part message in MIME format. --------------050909060905070005030803 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI, -05 has been published. There are still a few open issues, and feedback is welcome. I'll post a diff once tools.ietf.org has the new version. /psa -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-05.txt Date: Thu, 3 Jun 2010 15:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representation and Verification of Domain-Based Application Server Identity in Certificates Used with Transport Layer Security Author(s) : P. Saint-Andre, J. Hodges Filename : draft-saintandre-tls-server-id-check-05.txt Pages : 38 Date : 2010-06-03 Many application technologies enable a secure connection between two entities using certificates in the context of Transport Layer Security (TLS). This document specifies best current practices for representing and verifying the identity of application servers in such interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-= 05.txt --------------050909060905070005030803 Content-Type: Message/External-body; name="draft-saintandre-tls-server-id-check-05.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-tls-server-id-check-05.txt" Content-Type: text/plain Content-ID: <2010-06-03145547.I-D@ietf.org> --------------050909060905070005030803 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------050909060905070005030803-- --------------ms060504080402050708040400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzIyMDQzM1owIwYJKoZIhvcNAQkEMRYEFJ8+NxCGDrM2bdlT6L0I xCO4iSRiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAZjSY8+8hBbPMOPkziwFjmA8bT3qsNAGAnw411tV0 5diOohsdKolsAU6ZcVZaCGfUKdsypA1o0J2X81f/YKc6cnkq/E0roO2x7TjhMZWjbsK9ybz8 hDD2hjV3cZASvo+RqAiR+OnPq70FJN/Z/5q5ZEIylVRU6KXTfFasQhn2ziqBEteRT0zn29bm dvBsuVaBCiSH4Wf+2Rb3wfyd1LEF3AdcybHTbnO6AdSOQaTAZzpfbSxA45T+GWw19iFvGPbU pWkfbvGRTquUG708/Bt0Zz1ORPRRp1cGNX6NVG8IlkJavh1gjmlSQVbg1Fa3XGe++p1FTu43 N89y9lD2MgeQ5QAAAAAAAA== --------------ms060504080402050708040400-- From stpeter@stpeter.im Thu Jun 3 15:05:57 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9319F3A69F3 for ; Thu, 3 Jun 2010 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6FobeA+TSAB for ; Thu, 3 Jun 2010 15:05:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8AE3E3A6878 for ; Thu, 3 Jun 2010 15:05:56 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 236E9403F3; Thu, 3 Jun 2010 16:05:43 -0600 (MDT) Message-ID: <4C082736.3000509@stpeter.im> Date: Thu, 03 Jun 2010 16:05:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sean Turner References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C082431.3050900@stpeter.im> <4C0825AD.1020309@ieca.com> In-Reply-To: <4C0825AD.1020309@ieca.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000809000407070508060905" Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2010 22:05:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000809000407070508060905 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/3/10 3:59 PM, Sean Turner wrote: >=20 >>> As I said, here you have room for clarification. You essentially >>> rewrite 2818=20 >> >> This proposed BCP is not limited to HTTP so it does not (only) rewrite= >> RFC 2818, but yes it is intended (in part) to provide more up-to-date >> guidelines. >=20 > Should we add a section that moves 2818 to historic? (sorry if this has= > been asked before) I'm not that ambitious. :) Besides, I think this proposed BCP would update one small aspect of RFC 2818, not obsolete it. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000809000407070508060905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwMzIyMDU0MlowIwYJKoZIhvcNAQkEMRYEFOvPDgbb6hSQwzM5vH2z Frf+6FDpMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAaoaVbGtBhKOON8EvDxCOTDDWGDldgsBOoASy6jRn 956i8gM1A5Jr0SLH1kvSPCGlVLUkZGlWCCN5fr+hy9NuvLZzlY9nJ7Zy1m1mRV9heSQdkPo8 dixqEa0OYZcAiYeQj2Tv+4340pHftDSrgTUjZp8D9jXRDfkr7e4e75aQOmZwR/9IvlUmF6Wc Y18utdND8bvu2cTE34NXsIid6DTajLNZ+7IiOmG0CpogKv85KdzAkugr+fTw0g+T5Btd73k7 P8sh9TrC1SyQiQHSA7tbmJyfeFCI1rhFZeISQX0NSzaDgiUtO7Dt5Ra6ykO9xxKvWLWshvIL 7iWDcT5UIO1UcQAAAAAAAA== --------------ms000809000407070508060905-- From peter.sylvester@edelweb.fr Fri Jun 4 02:36:44 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F013A6964 for ; Fri, 4 Jun 2010 02:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMBW4mhXacPj for ; Fri, 4 Jun 2010 02:36:43 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id B4B2A3A6863 for ; Fri, 4 Jun 2010 02:36:42 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 5097188 for ; Fri, 4 Jun 2010 11:35:41 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 3623D1707B for ; Fri, 4 Jun 2010 11:35:41 +0200 (CEST) Received: from [192.168.0.31] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 3503A77D8 for ; Fri, 4 Jun 2010 11:35:41 +0200 (CEST) Message-ID: <4C08C8EC.1050200@edelweb.fr> Date: Fri, 04 Jun 2010 11:35:40 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> <4C08244D.9010809@bolyard.me> In-Reply-To: <4C08244D.9010809@bolyard.me> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 09:36:44 -0000 > The phrease "the (most specific) Common Name field in the subject field" > is not plural. There is at most one Common Name attribute in the name > that is *the* most specific one. The words "most specific" refer to its > position in the list of RDNs, which are arranged (as encoded in the > certificate Name field) from most general (first) to most specific > (last). So, the most specific Common Name is the last of the Common > Name attributes in the sequence of RDNs, as encoded in the certificate. > You can have two AVAs of the same type in the on RDN, i.e. two common names in the same RDN. There the interpretation of most-significant is not clear. There term of 2818 itself is wrong, there is no such thing a 'Common Name field'. If one puts no more than one AVA of type CN into an RDN, and only one of such RDN, the result is ok. The "(most specific)" is a kind of hint not to put more than one unless you want to attack like a \0 :-) /P PS: I "like" the *.ietf.org cert use by the server 'ietf.org' :-) From mrex@sap.com Fri Jun 4 09:38:31 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188B83A69D5 for ; Fri, 4 Jun 2010 09:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.556 X-Spam-Level: X-Spam-Status: No, score=-7.556 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DNE7-Cc8cjC for ; Fri, 4 Jun 2010 09:38:23 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 92A653A69B1 for ; Fri, 4 Jun 2010 09:38:03 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o54Gbhei014200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 18:37:43 +0200 (MEST) From: Martin Rex Message-Id: <201006041637.o54GbgVh024358@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 4 Jun 2010 18:37:42 +0200 (MEST) In-Reply-To: <4C08244D.9010809@bolyard.me> from "Nelson B Bolyard" at Jun 3, 10 02:53:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 16:38:34 -0000 Nelson B Bolyard wrote: > > On 2010/05/31 08:18 PDT, Martin Rex wrote: > > > While there have been few implementations checking for multiple > > CN= parts, the guideline in rfc-2818 for subjectAltNames seems > > to be much clearer, that there can be more than one, and more > > than one needs to be checked. > > That is precisely what it says NOT to do. It says > > > If a subjectAltName extension of type dNSName is present, that MUST > > be used as the identity. Otherwise, the (most specific) Common Name > > field in the Subject field of the certificate MUST be used. > > The phrease "the (most specific) Common Name field in the subject field" > is not plural. There is at most one Common Name attribute in the name > that is *the* most specific one. The words "most specific" refer to its > position in the list of RDNs, which are arranged (as encoded in the > certificate Name field) from most general (first) to most specific > (last). So, the most specific Common Name is the last of the Common > Name attributes in the sequence of RDNs, as encoded in the certificate. I am perfectly well aware of the wording in rfc-2818. But security-wise an X.509 Cert containing CN=host1.example.com, CN=host2.example.com, CN=host3.example.com is significantly less dangerous that an X.509 Cert containing CN=*.example.com and therefore this wording in rfc-2818 is unreasonable in several aspects and I chose to completely and deliberately ignore it in my implementation. Btw. I did not understand the meaning of "most specific" anyway, so I considered it unlikely that this could be interoperably implement by only matching a single CN= entry. While the initial definition of distinguished names might have had a hierarchical directory structure in mind, one does find distinguished names in "unusal" ordering out there, as well as distinguished names entirely without country AVA, even ones with only CN= -Martin From nelson@bolyard.me Fri Jun 4 10:11:48 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF6A3A69D8 for ; Fri, 4 Jun 2010 10:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QydOHHXc2xjm for ; Fri, 4 Jun 2010 10:11:46 -0700 (PDT) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 54AE53A687E for ; Fri, 4 Jun 2010 10:11:45 -0700 (PDT) Received: (qmail 7192 invoked from network); 4 Jun 2010 17:11:31 -0000 Received: from unknown (24.5.142.42) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 04 Jun 2010 17:11:30 -0000 Message-ID: <4C0933C1.4000004@bolyard.me> Date: Fri, 04 Jun 2010 10:11:29 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: Peter Sylvester References: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> <4C08244D.9010809@bolyard.me> <4C08C8EC.1050200@edelweb.fr> In-Reply-To: <4C08C8EC.1050200@edelweb.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 17:11:48 -0000 On 2010-06-04 02:35 PDT, Peter Sylvester wrote: >> The phrease "the (most specific) Common Name field in the subject field" >> is not plural. There is at most one Common Name attribute in the name >> that is *the* most specific one. The words "most specific" refer to its >> position in the list of RDNs, which are arranged (as encoded in the >> certificate Name field) from most general (first) to most specific >> (last). So, the most specific Common Name is the last of the Common >> Name attributes in the sequence of RDNs, as encoded in the certificate. >> > You can have two AVAs of the same type in the on RDN, i.e. > two common names in the same RDN. There the interpretation > of most-significant is not clear. Agreed, in principle. In practice, I've never seen a certificate produced by a real CA with multiple AVAs in a single RDN. I've seen them in certs produced by test scripts, and by people playing with OpenSSL. :) > There term of 2818 itself is wrong, there is no such thing > a 'Common Name field'. Agreed, whole heartedly. Still, we know what they meant. But I'm glad this mistake is not repeated in your draft. > If one puts no more than one AVA of type CN into an > RDN, and only one of such RDN, the result is ok. I agree with the first part of that. Don't see why the second restriction is necessary for the result to be OK. > The "(most specific)" is a kind of hint not to put more > than one unless you want to attack like a \0 :-) Yes, an attach to which software that ignores the "most specific" requirement will be vulnerable. > /P > > PS: I "like" the *.ietf.org cert use by the server 'ietf.org' :-) From stpeter@stpeter.im Fri Jun 4 10:18:29 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B723A6874 for ; Fri, 4 Jun 2010 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BubwRgl6UW9A for ; Fri, 4 Jun 2010 10:18:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AEC9A3A6934 for ; Fri, 4 Jun 2010 10:18:24 -0700 (PDT) Received: from squire.local (dsl-205-108.dynamic-dsl.frii.net [216.17.205.108]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BD04A40E60 for ; Fri, 4 Jun 2010 11:18:09 -0600 (MDT) Message-ID: <4C093550.6050708@stpeter.im> Date: Fri, 04 Jun 2010 11:18:08 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4BDB1F71.2050207@stpeter.im> <4BEBB843.6020600@velox.ch> In-Reply-To: <4BEBB843.6020600@velox.ch> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040703030808080806000604" Subject: Re: [certid] version -04 of CertID draft X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 17:18:29 -0000 This is a cryptographically signed message in MIME format. --------------ms040703030808080806000604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/13/10 2:28 AM, Kaspar Brand wrote: > A few more comments about draft -04: My apologies, I missed this post while making our edits for -05. (Nits skipped in what follows.) >> 2.1. Subject Naming in PKIX Certificates >> [...] >> "string representation" of a DN before being rendered. Often such = a >> DN string representation is ordered from left-to-right, most specif= ic >> to most general. See [LDAP-AUTH] for details. >=20 > I would suggest to replace this with a reference to RFC 4514 (not 4513)= =2E Corrected. >> 2.2. PKIX Certificate Name Rules >> >> The following rules apply to the representation of application serv= er >> identities in PKIX certificates issued by certification authorities= =2E >> >> 1. The certification authority MUST issue the certificate based on= >> the DNS domain name (not an IP address) at which the server wil= l >> provide the relevant service. >=20 > With the current draft, "relative" domain names (such as "www", "mail" > etc.) are also permitted as DNS-IDs or CN-IDs, from what I understand. > Is this a deliberate decision, or should domain names possibly be > required to be fully qualified (or "absolute", in RFC-1034 speak)? If > the latter, then it would probably make sense to add an entry for "DNS > domain name" to section 1.3 and explicitly state that it's required to > be absolute / fully qualified. Our intent was to cover only absolute domain names. Fixed in our working copy. >> Note: A client MUST NOT seek a match for a reference identifier = of >> CN-ID if the presented identifiers include an SRV-ID, URI-ID, >> DNS-ID, or any application-specific subjectAltName extensions, a= nd >> MUST NOT check a Common Name in the certificate if it is other >> than the last Relative Distinguished Name (RDN) in within the >> sequence of RDNs making up the Distinguished Name within the >> certificate's subjectName. >=20 > As already mentioned elsewhere, this requirement is probably too strict= =2E > I suggest changing to something like "must only check against the last > Common Name RDN in the sequence of RDNs making up the Distinguished Nam= e > within the certificate's subjectName". That wording does seem better. Thanks for the text. >> 3.4.4. Checking of DNS Domain Names in Common Names >> >> As noted, a client MUST NOT seek a match for a reference identifier= >> of CN-ID if the presented identifiers include an SRV-ID, URI-ID, >> DNS-ID, or any application-specific subjectAltName extensions. >> >> Therefore, if and only if the identity set does not include >> subjectAltName extensions of type dNSName, SRVName, or >> uniformResourceIdentifier (or any application-specific subjectAltNa= me >> extensions), the client MAY as a fallback check for a DNS domain na= me >> in the value of the last Relative Distinguished Name (RDN), if it i= s >> of type Common Name (CN), within the sequence of RDNs making up the= >> Distinguished Name within the certificate's subjectName. (Note: Th= e >> term "last" refers to the DER order, which is often not the string >> order presented to a user; the order that is applied here MUST be t= he >> DER order.) >=20 > See above - should be adapted accordingly. Done in our working copy. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040703030808080806000604 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwNDE3MTgwOFowIwYJKoZIhvcNAQkEMRYEFNn6BfHOYtCfzeAJK5jM TBHKdCReMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAEbtPxK1am8E/AVT1fq7uJpllFJB3SBk3fOwj+65F /7N16bZmBrgB6edojnCabw8rwjUMKrRDsbjcrv1gzHuv3gKP6Fyk2+rlWCMk25s6ELfkH6e+ TayT7bno8v5FaZGDJwjlPkf1H8gIqzvMzTzR44RWNtgpA7Jbu1F78MZOT5htFwfsKHRNs0ii aSxCEZHD2PHYSFwNJoLXR7vhlu7lPebBTfVnKh+yvlNT13ocif3Dp7jGKT+PJ8+0XuyZF3DP X0lAJoqxYQyGkaiPdUtkNLraNU3RWnbD5P5E8Wo/8OCj9YpvlMTNI1kh1zAoPU7nD2oxgbeY z9IKyHzO2tMKWAAAAAAAAA== --------------ms040703030808080806000604-- From mrex@sap.com Fri Jun 4 11:41:00 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D4228C107 for ; Fri, 4 Jun 2010 11:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.575 X-Spam-Level: X-Spam-Status: No, score=-7.575 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cMRg0B5UyvN for ; Fri, 4 Jun 2010 11:40:58 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D7F4428C0DB for ; Fri, 4 Jun 2010 11:39:25 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o54IcbDV006009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 20:38:42 +0200 (MEST) From: Martin Rex Message-Id: <201006041838.o54IcaNP001191@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Fri, 4 Jun 2010 20:38:36 +0200 (MEST) In-Reply-To: <4C0933C1.4000004@bolyard.me> from "Nelson B Bolyard" at Jun 4, 10 10:11:29 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2010 18:41:00 -0000 Nelson B Bolyard wrote: > > > You can have two AVAs of the same type in the on RDN, i.e. > > two common names in the same RDN. There the interpretation > > of most-significant is not clear. > > Agreed, in principle. In practice, I've never seen a certificate produced > by a real CA with multiple AVAs in a single RDN. I've seen them in certs > produced by test scripts, and by people playing with OpenSSL. :) A few years ago I received a certificate of a productive PKI from a big account customer, and it had RDNames with two AVAs (CN= and SERIALNUMBER= in one RDName SET). The concept of "most significant" only applies to RDName, and not to members of the RDName set (because a SET is specified to be an unordered list, and ASN.1 DER encoding actually enforces a specific canonical ordering for ASN.1 SETs that unconditionally overrules whatever the creator of the distinguished name may have desired). So technically an RDName set with two different CN= are possible. In the sense of the directory hierarchy, both of them are "most significant". So that part of rfc-2818 doesn't make any sense. -Martin From nelson@bolyard.me Mon Jun 7 11:23:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201CC3A6784 for ; Mon, 7 Jun 2010 11:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNWuXH2laOf5 for ; Mon, 7 Jun 2010 11:23:37 -0700 (PDT) Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 84D883A67BD for ; Mon, 7 Jun 2010 11:23:37 -0700 (PDT) Received: (qmail 23229 invoked from network); 7 Jun 2010 18:23:37 -0000 Received: from unknown (24.5.142.42) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 07 Jun 2010 18:23:36 -0000 Message-ID: <4C0D3922.9070104@bolyard.me> Date: Mon, 07 Jun 2010 11:23:30 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: certid@ietf.org References: <201006041637.o54GbgVh024358@fs4113.wdf.sap.corp> In-Reply-To: <201006041637.o54GbgVh024358@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 18:23:39 -0000 (Resending: first copy seems to have bounced off the server.) On 2010-06-04 09:37 PDT, Martin Rex wrote: > I am perfectly well aware of the wording in rfc-2818. > > But security-wise an X.509 Cert containing > > CN=host1.example.com, CN=host2.example.com, CN=host3.example.com > > is significantly less dangerous that an X.509 Cert containing > > CN=*.example.com > > and therefore this wording in rfc-2818 is unreasonable in several aspects > and I chose to completely and deliberately ignore it in my > implementation. I'm not surprised that you say that. It's not the first time you've told us that you've deliberately ignored something in an RFC that you considered unreasonable. But consider that, because of the wording that you ignore, some (many) CAs will only check the DNS name in ONE of the CNs in the cert subject name. Other CNs may contain strings whose contents are unchecked. If you rely on their contents, you're relying on unchecked DNS names. I wouldn't call that "significantly less dangerous" than a wildcard cert whose domain (not host) name part has been checked. Now, as an aside, I think the practice of CAs to put unchecked and unvetted data ("certified nonsense") into the subject names of their certs is reprehensible, and IMO, the RFCs should all explicitly disallow it. Maybe this draft is the place to start. But until then, sadly, it will remain the case that some CAs check only certain specific attributes (and then only the last one) in the names of the certs they issue, and software that chooses to honor other fields will be vulnerable. > Btw. I did not understand the meaning of "most specific" anyway, so I > considered it unlikely that this could be interoperably implement by only > matching a single CN= entry. While the initial definition of > distinguished names might have had a hierarchical directory structure in > mind, The initial, *AND CURRENT*, definitions of DNs still have a hierarchical organization. X.501 is worth a read. > one does find distinguished names in "unusal" ordering out there, as well > as distinguished names entirely without country AVA, even ones with only > CN= True. There's no requirement that any particular attribute types appear in any hierarchy. X.501 talks about this at length. From alexey.melnikov@isode.com Tue Jun 8 08:28:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88BE3A69C7 for ; Tue, 8 Jun 2010 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZHzm9JOcZnX for ; Tue, 8 Jun 2010 08:28:01 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3CD893A697D for ; Tue, 8 Jun 2010 08:28:01 -0700 (PDT) Received: from [172.16.2.123] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 8 Jun 2010 16:28:00 +0100 Message-ID: <4C0E6163.2080509@isode.com> Date: Tue, 08 Jun 2010 16:27:31 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Sean Turner References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C082431.3050900@stpeter.im> <4C0825AD.1020309@ieca.com> In-Reply-To: <4C0825AD.1020309@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: [certid] Moving RFC 2818 to Historic (was Comments on draft-saintandre-tls-server-id-check-04) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 15:28:02 -0000 Hi Sean, Sean Turner wrote: >>> As I said, here you have room for clarification. You essentially >>> rewrite 2818 >> >> This proposed BCP is not limited to HTTP so it does not (only) rewrite >> RFC 2818, but yes it is intended (in part) to provide more up-to-date >> guidelines. > > Should we add a section that moves 2818 to historic? (sorry if this > has been asked before) RFC 2818 contains more information than just the TLS server identity verification procedure for https. Besides RFC 2818 is widely used and I think moving it to historic would be a disservice to the community. Maybe you meant to suggest "obsoleting" it? One year ago I was trying to convince Ekr to update RFC 2818, but he wasn't interested. I still think this would be a good idea. I also think that HTTPBIS is a better place for this activity. From stpeter@stpeter.im Tue Jun 8 08:36:06 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9491328C1A6 for ; Tue, 8 Jun 2010 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asDjUmqmvR9m for ; Tue, 8 Jun 2010 08:36:05 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9462428C1A1 for ; Tue, 8 Jun 2010 08:36:05 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DF51D40CFD; Tue, 8 Jun 2010 09:36:05 -0600 (MDT) Message-ID: <4C0E6363.5010608@stpeter.im> Date: Tue, 08 Jun 2010 09:36:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Alexey Melnikov References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C082431.3050900@stpeter.im> <4C0825AD.1020309@ieca.com> <4C0E6163.2080509@isode.com> In-Reply-To: <4C0E6163.2080509@isode.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010502090803050409040606" Cc: certid@ietf.org Subject: Re: [certid] Moving RFC 2818 to Historic (was Comments on draft-saintandre-tls-server-id-check-04) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 15:36:06 -0000 This is a cryptographically signed message in MIME format. --------------ms010502090803050409040606 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/8/10 9:27 AM, Alexey Melnikov wrote: > Hi Sean, >=20 > Sean Turner wrote: >=20 >>>> As I said, here you have room for clarification. You essentially >>>> rewrite 2818=20 >>> >>> This proposed BCP is not limited to HTTP so it does not (only) rewrit= e >>> RFC 2818, but yes it is intended (in part) to provide more up-to-date= >>> guidelines. >> >> Should we add a section that moves 2818 to historic? (sorry if this >> has been asked before) >=20 > RFC 2818 contains more information than just the TLS server identity > verification procedure for https. Besides RFC 2818 is widely used and I= > think moving it to historic would be a disservice to the community. > Maybe you meant to suggest "obsoleting" it? >=20 > One year ago I was trying to convince Ekr to update RFC 2818, but he > wasn't interested. I still think this would be a good idea. I also thin= k > that HTTPBIS is a better place for this activity. Agreed. After HTTPBIS completes its current work items, naturally. :) /psa --------------ms010502090803050409040606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYwODE1MzYwM1owIwYJKoZIhvcNAQkEMRYEFJwMrq/Y+RVeiCN/+GS7 UwR8MqwzMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEATNI0bEulmYlTi/bNikThHdbhD6eFVSvVCmpwNWyg RzHaKlHplKArpSzbwc5qoXZjH82CfKWk0ph+1MsLJQ309M4PEuXOV6qb1oqi0EsDahYeXyOJ ozMGLg+VhSs6N1G7Y8Z5pO0UEoKDuLj1kqH46YGrqJKZRXw6n73GJnLvvsE8dJ8xl4qRBD5f wZ6Q4+DpnYYdDpfvh5KE7zWM3SHFnlrgHGYUcqdG3qI2pMlsCgZzo3sl4MRFM7Pqf6w/Kygk ylt7Vz8bef7M44q/w5PVAqXWgTQBc+ZF8zqyhsrsgma42R0pxB1nPYx2Zxb7RiOmYaD+Fay8 pJzXlB+WC4/UAQAAAAAAAA== --------------ms010502090803050409040606-- From turners@ieca.com Tue Jun 8 08:44:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB3C3A6805 for ; Tue, 8 Jun 2010 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLQceQIKQI0o for ; Tue, 8 Jun 2010 08:44:48 -0700 (PDT) Received: from smtp111.biz.mail.mud.yahoo.com (smtp111.biz.mail.mud.yahoo.com [209.191.68.76]) by core3.amsl.com (Postfix) with SMTP id 423C73A68C3 for ; Tue, 8 Jun 2010 08:44:48 -0700 (PDT) Received: (qmail 61375 invoked from network); 8 Jun 2010 15:44:38 -0000 Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 08 Jun 2010 08:44:38 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: JLdXoP4VM1n4d5jkpelrDQOap8NsTj5JxDcVB8hyoz_A_IhPYUuWGvKpSdnJJNdW1yPKoMdS3TqOmEYrJvDsnFtiOKyweVc9iEP2Co1Ks4ePmrg24GVcUmaZsqZY_OSGr3z.Hu2pW8H1_ftgbzcWbk1To__NQI04z1rMsxca8RXNohZIJ6X.dJhciMgtEwSKyeSYQlpVizqZQ2j.rsr9H4xFs_8dIA.AsxacJ3qLfGFEd8vp6zfRdmbN.hItl6M8.qLSlnsyTnb0iHHjRVsTTTke_ivjyAWAOBpG4.8mAYStwmABQyb.1EDT X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0E6565.7040807@ieca.com> Date: Tue, 08 Jun 2010 11:44:37 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alexey Melnikov References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C082431.3050900@stpeter.im> <4C0825AD.1020309@ieca.com> <4C0E6163.2080509@isode.com> In-Reply-To: <4C0E6163.2080509@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Moving RFC 2818 to Historic (was Comments on draft-saintandre-tls-server-id-check-04) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 15:44:49 -0000 Alexey Melnikov wrote: > Hi Sean, > > Sean Turner wrote: > >>>> As I said, here you have room for clarification. You essentially >>>> rewrite 2818 >>> >>> This proposed BCP is not limited to HTTP so it does not (only) rewrite >>> RFC 2818, but yes it is intended (in part) to provide more up-to-date >>> guidelines. >> >> Should we add a section that moves 2818 to historic? (sorry if this >> has been asked before) > > RFC 2818 contains more information than just the TLS server identity > verification procedure for https. Besides RFC 2818 is widely used and I > think moving it to historic would be a disservice to the community. > Maybe you meant to suggest "obsoleting" it? Maybe we should be updating the pertinent sections? That would mean adding "Updates: 2818 (once approved) to the header of this document? Also clearly state it doesn't just apply to HTTP. > One year ago I was trying to convince Ekr to update RFC 2818, but he > wasn't interested. I still think this would be a good idea. I also think > that HTTPBIS is a better place for this activity. What Peter said ;) spt From alexey.melnikov@isode.com Tue Jun 8 08:45:50 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F82A3A6805 for ; Tue, 8 Jun 2010 08:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV+hV4HN94WT for ; Tue, 8 Jun 2010 08:45:49 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5B7B43A679F for ; Tue, 8 Jun 2010 08:45:49 -0700 (PDT) Received: from [172.16.2.123] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 8 Jun 2010 16:45:49 +0100 Message-ID: <4C0E658E.6010006@isode.com> Date: Tue, 08 Jun 2010 16:45:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Sean Turner References: <4BEB3870.10904@KingsMountain.com> <4BED0E6E.1090303@edelweb.fr> <4C003D15.4060408@stpeter.im> <4C00FEC0.3080808@edelweb.fr> <4C082431.3050900@stpeter.im> <4C0825AD.1020309@ieca.com> <4C0E6163.2080509@isode.com> <4C0E6565.7040807@ieca.com> In-Reply-To: <4C0E6565.7040807@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Moving RFC 2818 to Historic (was Comments on draft-saintandre-tls-server-id-check-04) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 15:45:50 -0000 Sean Turner wrote: > Alexey Melnikov wrote: > >> Hi Sean, >> >> Sean Turner wrote: >> >>>>> As I said, here you have room for clarification. You essentially >>>>> rewrite 2818 >>>> >>>> This proposed BCP is not limited to HTTP so it does not (only) rewrite >>>> RFC 2818, but yes it is intended (in part) to provide more up-to-date >>>> guidelines. >>> >>> Should we add a section that moves 2818 to historic? (sorry if this >>> has been asked before) >> >> RFC 2818 contains more information than just the TLS server identity >> verification procedure for https. Besides RFC 2818 is widely used and >> I think moving it to historic would be a disservice to the community. >> Maybe you meant to suggest "obsoleting" it? > > Maybe we should be updating the pertinent sections? That would mean > adding "Updates: 2818 (once approved) to the header of this document? > Also clearly state it doesn't just apply to HTTP. Yes, we could do that. From nelson@bolyard.me Tue Jun 8 10:50:16 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5528F3A6813 for ; Tue, 8 Jun 2010 10:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1psJUkYD1fC for ; Tue, 8 Jun 2010 10:50:14 -0700 (PDT) Received: from smtpauth17.prod.mesa1.secureserver.net (smtpauth17.prod.mesa1.secureserver.net [64.202.165.29]) by core3.amsl.com (Postfix) with SMTP id 009933A6767 for ; Tue, 8 Jun 2010 10:50:13 -0700 (PDT) Received: (qmail 25020 invoked from network); 8 Jun 2010 17:50:14 -0000 Received: from unknown (24.5.142.42) by smtpauth17.prod.mesa1.secureserver.net (64.202.165.29) with ESMTP; 08 Jun 2010 17:50:14 -0000 Message-ID: <4C0E826B.3050904@bolyard.me> Date: Tue, 08 Jun 2010 10:48:27 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: certid@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 17:50:16 -0000 There are a large number of CAs that follow the practice of vetting SOME of the information they put into cert subject names, but not all, and in fact deliberately making no attempt to vet certain attributes at all. Examples known to me include: OU names: typically not vetted at all CNs other than the last (most specific) one, if it is a DNS name. Maybe it's pointless to try, but can we write into this RFC that conforming certs contain NO unvetted attributes in the subject name nor in any Subject Alt Name attributes? Since CAs seem to have such a strong desire to do so, maybe we should invent a new extension: unvetted subject alt names, where they can put whatever nonsense they want, and apps that care to use only vetted info can ignore. It MUST NOT be a critical extension. On the other hand, the correct processing of that extension should be defined to ignore it (:-) so that all apps may claim to properly handle it, even if it is critical. From Jeff.Hodges@KingsMountain.com Tue Jun 8 11:50:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A55D3A67C1 for ; Tue, 8 Jun 2010 11:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wYOYg75hm4T for ; Tue, 8 Jun 2010 11:50:19 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 1093B3A67BD for ; Tue, 8 Jun 2010 11:50:19 -0700 (PDT) Received: (qmail 7940 invoked by uid 0); 8 Jun 2010 18:50:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 8 Jun 2010 18:50:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=4ExFCcqBfdx/r1kQSBr2rBxZ8Jroid/D3zOTD+SZ3vc/qlV+qKTubFsY4WdjKrKLbVJokaPv8Xj0qsytkTokabyXIFXpNK09gbgbf0h32XIswPRBm/fdvpH9FN0WeBsW; Received: from c-24-4-121-38.hsd1.ca.comcast.net ([24.4.121.38] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OM3sS-0003do-0W; Tue, 08 Jun 2010 12:50:20 -0600 Message-ID: <4C0E90E9.4050101@KingsMountain.com> Date: Tue, 08 Jun 2010 11:50:17 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity , Kaspar Brand Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.121.38 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 18:50:20 -0000 Martin Rex noted on Wed, 12 May 2010 00:47:30 +0200 (MEST)... > > Further complicating the issue: While DER encoding leaves the ordering > of the contents of an ASN.1 SEQUENCE as is, the ordering of the contents > of an ASN.1 SET is "canonicalized" by DER encoding (based on the > numeric ordering of the final binary encoding of each element). > So the shorter elements will always end up first in RDNames > containing multiple attribute-value pairs in a SET. > > i.e. > > CN=Foo+2.5.4.5=123ABC,O=bar,C=ZZ > 2.5.4.5=227DEF+CN=LongName,O=bar,C=ZZ Nelson B Bolyard wrote on Fri, 04 Jun 2010 10:11:29 -0700 > > On 2010-06-04 02:35 PDT, Peter Sylvester wrote: >> >> You can have two AVAs of the same type in the on RDN, i.e. >> two common names in the same RDN. There the interpretation >> of most-significant is not clear. > > Agreed, in principle. In practice, I've never seen a certificate produced > by a real CA with multiple AVAs in a single RDN. I've seen them in certs > produced by test scripts, and by people playing with OpenSSL. :) And Kaspar Brand had pointed out on Thu, 13 May 2010 09:40:12 +0200 > > Here's some data. It's from a sample of about 90,000 non self-issued > certs (from commercial CAs, most likely reflecting shares like those in > http://news.netcraft.com/SSL-survey). The data are from the beginning > of 2009, but I don't think the situation has considerably changed > in between. > > The second colum shows the RDNs in the order they have in the > ASN.1 subject SEQUENCE, while the first colum gives the number of > occurences of such a cert (only the "top 15" are shown). > > 19464 C, O, OU, OU, OU, CN > 15657 C, ST, L, O, OU, CN > 6859 O, OU, CN > 5603 C, ST, L, O, OU, OU, CN > 4983 C, ST, L, O, OU, OU, OU, OU, CN > 4813 C, ST, L, O, CN I personally seem to recall observing certs in the wild whose string-formatted DNames included the "+" notation as Martin illustrates above, and which denotes an RDN SET, although I don't recall whether such certs were produced by "real CAs" as Nelson terms a certain subclass of CAs. Kaspar -- would information wrt multi-valued RDNames be embodied in the sample you used to generate the above info you shared with the list? If so, are there any occurances, and if so what's the frequency? thanks, =JeffH From phoffman@imc.org Tue Jun 8 12:02:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFBAF3A635F for ; Tue, 8 Jun 2010 12:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7FQZeQ5W8nK for ; Tue, 8 Jun 2010 12:02:02 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 924083A6781 for ; Tue, 8 Jun 2010 12:02:01 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o58J1ufN007890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jun 2010 12:01:58 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C0E826B.3050904@bolyard.me> References: <4C0E826B.3050904@bolyard.me> Date: Tue, 8 Jun 2010 12:01:51 -0700 To: Nelson B Bolyard , certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:02:03 -0000 At 10:48 AM -0700 6/8/10, Nelson B Bolyard wrote: >There are a large number of CAs that follow the practice of vetting SOME >of the information they put into cert subject names, but not all, and in >fact deliberately making no attempt to vet certain attributes at all. > >Examples known to me include: > >OU names: typically not vetted at all > >CNs other than the last (most specific) one, if it is a DNS name. > >Maybe it's pointless to try, but can we write into this RFC that conforming >certs contain NO unvetted attributes in the subject name nor in any Subject >Alt Name attributes? Their vetting practices are supposed to be listed in their CPSs, so a CA can always say "we do exactly what we say we do" because they know that no one reads (or can read) their CPS. Having said that, including this practice as a warning in the document seems like a good idea. From turners@ieca.com Tue Jun 8 12:43:03 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC663A6817 for ; Tue, 8 Jun 2010 12:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HILbCe-dNCGS for ; Tue, 8 Jun 2010 12:43:02 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id 5AD623A6806 for ; Tue, 8 Jun 2010 12:43:02 -0700 (PDT) Received: (qmail 58429 invoked from network); 8 Jun 2010 19:43:01 -0000 Received: from thunderfish.local (turners@96.231.124.63 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 08 Jun 2010 12:43:00 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: dlotgZoVM1nGQOMjrCOwPjkxm_iyi6wL1vu.J0XGWtBhSqEAeBWhO8XH6wpttNvt5gXYGAAr8FKIds88GrQWs5UzHREms9ioPIbUw4KCHQYs3GL59X8EW8VhpP0K5IHVXyH6BH7WZeQweloYW8ofBRGvNrl9XLnwo604Zc62i1WzFMCTEyEeim8azdgp4ebmlBgCZZBoWQn3tVsINBILw_Ai3vRIexCqa2R9rE4isj1tn65gYvLt97eG05zGuPqX4cp.MzfFCmGmrz753_w1nKGG8nfE3wtRDLni5xwohFGxaldf3xaYrDY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C0E9D43.7010908@ieca.com> Date: Tue, 08 Jun 2010 15:42:59 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Hoffman References: <4C0E826B.3050904@bolyard.me> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 19:43:03 -0000 Paul Hoffman wrote: > At 10:48 AM -0700 6/8/10, Nelson B Bolyard wrote: >> There are a large number of CAs that follow the practice of vetting SOME >> of the information they put into cert subject names, but not all, and in >> fact deliberately making no attempt to vet certain attributes at all. >> >> Examples known to me include: >> >> OU names: typically not vetted at all >> >> CNs other than the last (most specific) one, if it is a DNS name. >> >> Maybe it's pointless to try, but can we write into this RFC that conforming >> certs contain NO unvetted attributes in the subject name nor in any Subject >> Alt Name attributes? > > Their vetting practices are supposed to be listed in their CPSs, so a CA can always say "we do exactly what we say we do" because they know that no one reads (or can read) their CPS. > > Having said that, including this practice as a warning in the document seems like a good idea. +1 spt From ietf-certid@velox.ch Wed Jun 9 00:12:08 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203BC3A6903 for ; Wed, 9 Jun 2010 00:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXZ3K+hqJ9Lb for ; Wed, 9 Jun 2010 00:12:06 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id EFBCD3A68FD for ; Wed, 9 Jun 2010 00:12:05 -0700 (PDT) Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o597C1IG026602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Jun 2010 09:12:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1276067524; bh=/SGmyQ7B5MdKcahssh5mbN4N+DJy+zJRmmZ1ODZMSlA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=j9WT/0alzGaK3AcwRhlbnR8/3G5OeiwkyjJ7+3rY2qS/YYce7qpQCftQt1UsrPg9p zf35Y8b5VuyaRWMRxKERcYV4aLOYLLx47807RFFmZ0SYF7eH3jPIwo2Ojl4r32yFO4 clgJ3xTQ4DGIEQuqlQCe+Y9A7AACbc13AhBBaHSIRuDmgys97khuFHzgTif9YpsY9j 7HHAspqoWtbmZXabcpEsjEcKzJ/QJzrSikTwhCTokd1dvb3RVEQQLK8j2yAjcczbPo UhUq0sKENCwZ8ZfhG68TxHGtG3XE4b9/bfY7z/VNR93R8S4N6lGmrFIOYmXwnJl7FR Ob3LHN6oldsFg== Message-ID: <4C0F3EBC.9000902@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1276067521; bh=/SGmyQ7B5MdKcahssh5mbN4N+DJy+zJRmmZ1ODZMSlA=; h=Date:From:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=MFtYonSc4PyJN6COfRcElK6SOwTUSoAy6TIMnh/4+oZ5ZisAQavBvbY6D8uUIeuOq 7Ag1yH8OQzbikO4bRR05w+Dq53q5BP/VmOKmdRmYJ7oIiqlvZBSMZt0La15GfTigrr 1xfWVoOwEKz07O5R/LDnyx/v8Hfvj4zH+x7up33D+/X9TxnBfGVoBq51AL3cIjBs4A T6tcOHeg3Q2Y4WgjbsOvZsnlsU7KRGN+LNE2x/HgRPW4kbxdT2szFzXyqeKUf+QLGE auwwpySJcVddMb13snbYSNvNaF1ZT/h6vqIxdf3lMGKzVhGaWmrGLf+MxdhZ1JoM/d FPdGWpbs/o43w== Date: Wed, 09 Jun 2010 09:11:56 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: IETF cert-based identity References: <4C0E90E9.4050101@KingsMountain.com> In-Reply-To: <4C0E90E9.4050101@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =JeffH Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 07:12:08 -0000 On 08.06.2010 20:50, =JeffH wrote: > I personally seem to recall observing certs in the wild whose string-formatted > DNames included the "+" notation as Martin illustrates above, and which denotes > an RDN SET, although I don't recall whether such certs were produced by "real > CAs" as Nelson terms a certain subclass of CAs. > > > Kaspar -- would information wrt multi-valued RDNames be embodied in the sample > you used to generate the above info you shared with the list? If so, are there > any occurances, and if so what's the frequency? There are 38 occurrences (out of ~90,000), originating from three "real CAs". The vast majority (34) are EV SSL certs from a CA which apparently likes to stuff the CN (2.5.4.3) and the serialNumber (2.5.4.5) attributes into a single RDN. [Not so surprisingly, the remaining 4 certs were issued by two CAs which apparently run their infrastructure with software from that other "real CA" - which is the reason for seeing the same peculiar encoding in their certs.] In the context of this BCP, I consider the discussion about "multi-valued RDNs" an academic thing, mostly. I would not mind, however, to change the last sentence in section 2.2, item 6 to something like "Furthermore, the certificate's subject Distinguished Name SHOULD NOT contain more than one Common Name attribute, and MUST NOT contain RDNs which consist of multiple Common Name attributes" (provided that this wording pleases the ASN.1 terminology experts in the audience here). The definition of "CN-ID" in section 1.3 should probably also be adapted (i.e., it should explicitly forbid multi-CN RDNs). Kaspar From stpeter@stpeter.im Wed Jun 9 19:19:00 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5931928C128 for ; Wed, 9 Jun 2010 19:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 614M+N8Qec2h for ; Wed, 9 Jun 2010 19:18:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id ABA283A6867 for ; Wed, 9 Jun 2010 19:18:56 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C419540E3E for ; Wed, 9 Jun 2010 20:18:57 -0600 (MDT) Message-ID: <4C104B88.1070307@stpeter.im> Date: Wed, 09 Jun 2010 20:18:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C0E90E9.4050101@KingsMountain.com> <4C0F3EBC.9000902@velox.ch> In-Reply-To: <4C0F3EBC.9000902@velox.ch> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060700030309070603060101" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 02:19:00 -0000 This is a cryptographically signed message in MIME format. --------------ms060700030309070603060101 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/10 1:11 AM, Kaspar Brand wrote: > On 08.06.2010 20:50, =3DJeffH wrote: >> I personally seem to recall observing certs in the wild whose string-f= ormatted=20 >> DNames included the "+" notation as Martin illustrates above, and whic= h denotes=20 >> an RDN SET, although I don't recall whether such certs were produced b= y "real=20 >> CAs" as Nelson terms a certain subclass of CAs. >> >> >> Kaspar -- would information wrt multi-valued RDNames be embodied in th= e sample=20 >> you used to generate the above info you shared with the list? If so, = are there=20 >> any occurances, and if so what's the frequency? >=20 > There are 38 occurrences (out of ~90,000), originating from three "real= > CAs". The vast majority (34) are EV SSL certs from a CA which apparentl= y > likes to stuff the CN (2.5.4.3) and the serialNumber (2.5.4.5) > attributes into a single RDN. [Not so surprisingly, the remaining 4 > certs were issued by two CAs which apparently run their infrastructure > with software from that other "real CA" - which is the reason for seein= g > the same peculiar encoding in their certs.] Thanks for the numbers. > In the context of this BCP, I consider the discussion about > "multi-valued RDNs" an academic thing, mostly. I would not mind, > however, to change the last sentence in section 2.2, item 6 to somethin= g > like "Furthermore, the certificate's subject Distinguished Name SHOULD > NOT contain more than one Common Name attribute, and MUST NOT contain > RDNs which consist of multiple Common Name attributes" (provided that > this wording pleases the ASN.1 terminology experts in the audience here= ). Done in our working copy. > The definition of "CN-ID" in section 1.3 should probably also be adapte= d > (i.e., it should explicitly forbid multi-CN RDNs). Is this a more accurate definition? * CN-ID =3D a subject Distinguished Name (DN) whose constituent sequence of Relative Distinguished Names (RDNs) contains one and only one attribute value assertion (AVA) whose attribute type is Common Name (CN) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060700030309070603060101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMDAyMTg0OFowIwYJKoZIhvcNAQkEMRYEFL5tPeYTncsC4Uwvs75F 66DFu7v6MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAOJR99QWFmvwq/lNpjX2YHOsdOhSph3A6ple3gp8T rw/xhbTunIaVuGkESYnGk80XlNxbk0iwPVkFCHN21q+T5pD2vS6RHIo+AZ99EIxiH45qHXgv 1UTGBmJ7yBsegJ4eBqfpKaNrleV1JyGjHmOlpixEqMHToTLl63PW07aFw7sunSsuAaFuOoEC qHfvNQSmG62gb0IjZ8BPOQnYmJOCExNShyaQ/zaG032sHx7lryG2R7heZ0rLdhHUqtah27UZ qQYfZC+Yw4p26kE9XTo1UEsKpasqGVwbDy5HVKXXm12rQWfXwdzggKy5O0ptz27+iM8UEK7A rcYk9164700vVgAAAAAAAA== --------------ms060700030309070603060101-- From stpeter@stpeter.im Wed Jun 9 19:24:04 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 736EF3A6845 for ; Wed, 9 Jun 2010 19:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWwTTiH9kN5C for ; Wed, 9 Jun 2010 19:24:02 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6D5AC3A681F for ; Wed, 9 Jun 2010 19:24:02 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DD0B640E3E for ; Wed, 9 Jun 2010 20:24:03 -0600 (MDT) Message-ID: <4C104CC3.8070602@stpeter.im> Date: Wed, 09 Jun 2010 20:24:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070604030903030101030907" Subject: [certid] Fwd: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 02:24:04 -0000 This is a cryptographically signed message in MIME format. --------------ms070604030903030101030907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Forwarding from the apps-discuss@ietf.org list to maintain continuity. -------- Original Message -------- Subject: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides Date: Wed, 9 Jun 2010 09:46:41 +0800 From: Thomson, Martin To: apps-discuss@ietf.org , psaintan@cisco.com , Jeff.Hodges@PayPal.com In draft-saintandre-tls-server-id-check-05, Sections 3.6.2 and 3.6.3.1 talk about user choice in interactively trusting a certificate. What is missing is discussion on "why" users might need to (or want to) override the default behaviour. Usage practices aren't obvious, so this seems like a good place to expand on this. It would be good if this described what are acceptable types of certificate validation failure and what aren't. Common reasons that are potentially valid are: - not trusted (no CA) - expired certificate - wrong name - revoked certificate Obviously, you aren't going to accept a certificate if the entity providing it could not prove that they possess the corresponding private key. It might help to explain the significance of such an action - the user is trusting the entity that is able to proof possession of the private key that corresponds to the private key in the certificate. All other data in the certificate becomes irrelevant. --Martin p.s. I don't know what happens in practice if a certificate is pinned before expiry and then subsequently expires. Same goes for revocation. I'd be interested in learning what people do. Logic suggests that if a certificate is accepted despite violating one criterion, it does not imply continued acceptance when another criteria are subsequently violate= d. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --------------ms070604030903030101030907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMDAyMjQwM1owIwYJKoZIhvcNAQkEMRYEFDED78ceRu8sl/3PCs6Q sleI3+5PMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAPUCzsPYI2x5cxRxKuAlmnF5F2F9/lk5qwBRBDIXl /mh5lJKBBfbyspaAiqCYKILpkfKsr+WqijBPyQnvhL1GR1q24iDPuTuGrrWQAPcn/AHmzJSi nLvLQM36SGnRJeB4sqSEZlCB5RpR4TiHJyW7vTXsWgZmHdWQmAhkd0S3SpT0mXc0Tcf7r66f 2sRByN2LY58d6RGduEZ+mJ0Z3A0RmRqfMThS0UYDpSWLVHP9QjPiVUl7gNf+9Ndwmh+qNhQs fAoLRZMieCtFineEBOld8plsNo7i+X9DmgbdonFScrbufevhEoRFV4LAMrU4Ca3vVznWLOE6 DsClYx8S0P4oMgAAAAAAAA== --------------ms070604030903030101030907-- From stpeter@stpeter.im Wed Jun 9 19:44:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E56A3A6831 for ; Wed, 9 Jun 2010 19:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zSvujW5PhSB for ; Wed, 9 Jun 2010 19:44:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 64A9F3A6894 for ; Wed, 9 Jun 2010 19:44:00 -0700 (PDT) Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4D4A640E5D; Wed, 9 Jun 2010 20:44:01 -0600 (MDT) Message-ID: <4C10516B.1000400@stpeter.im> Date: Wed, 09 Jun 2010 20:43:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity References: <4C104CC3.8070602@stpeter.im> In-Reply-To: <4C104CC3.8070602@stpeter.im> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090802040003040802070401" Cc: "Thomson, Martin" Subject: [certid] user overrides (was: Re: Fwd: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 02:44:02 -0000 This is a cryptographically signed message in MIME format. --------------ms090802040003040802070401 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/10 8:24 PM, Peter Saint-Andre wrote: > Forwarding from the apps-discuss@ietf.org list to maintain continuity. >=20 > -------- Original Message -------- > Subject: [apps-discuss] draft-saintandre-tls-server-id-check and user > overrides > Date: Wed, 9 Jun 2010 09:46:41 +0800 > From: Thomson, Martin > To: apps-discuss@ietf.org , psaintan@cisco.com > , Jeff.Hodges@PayPal.com >=20 > In draft-saintandre-tls-server-id-check-05, Sections 3.6.2 and 3.6.3.1 > talk about user choice in interactively trusting a certificate. >=20 > What is missing is discussion on "why" users might need to (or want to)= > override the default behaviour. Usage practices aren't obvious, so thi= s > seems like a good place to expand on this. I'm not sure if this is the spec in which to describe why a user might need or want to override the default server identity checking behavior. One example of a spec that provides some guidance in this area is http://www.w3.org/TR/2010/WD-wsc-ui-20100309/ but that doesn't cover non-browser or non-web applications, and in any case this is a matter of providing guidance to client developers regarding user interaction, which is not exactly a matter of expertise in the IETF. However, I'm open to accepting suggested text on this point. > It would be good if this described what are acceptable types of > certificate validation failure and what aren't. Common reasons that ar= e > potentially valid are: > - not trusted (no CA) > - expired certificate > - wrong name > - revoked certificate So far, with regard to client behavior this spec has been limited to the narrow topic of checking server identity, not the broader topic of certificate validation. > Obviously, you aren't going to accept a certificate if the entity > providing it could not prove that they possess the corresponding privat= e > key. >=20 > It might help to explain the significance of such an action - the user > is trusting the entity that is able to proof possession of the private > key that corresponds to the private key in the certificate. All other > data in the certificate becomes irrelevant. >=20 > --Martin >=20 > p.s. I don't know what happens in practice if a certificate is pinned > before expiry and then subsequently expires. Same goes for revocation.= > I'd be interested in learning what people do. Logic suggests that if = a > certificate is accepted despite violating one criterion, it does not > imply continued acceptance when another criteria are subsequently viola= ted. Again, those are interesting and important issues, but somewhat outside the very limited scope that we have set for ourselves. As with other requests for broadening the scope of this spec, I'd like to point out that we might very well write more specs on related topics in the future, and perhaps eventually put them all together into a more general BCP. However, given how contentious these issues can be, I think we'd prefer to do this work in a piecemeal fashion to start with instead of defining a grand unified theory from the beginning (because it's unlikely that we would ever finish that task). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090802040003040802070401 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMDAyNDM1NVowIwYJKoZIhvcNAQkEMRYEFBXlyYWXULrVGwfHu+fo pT13Vl6VMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAFX6I/mvttdWMcT+lu3kkF7wBoihnm1ojkGMK36DY 2arIlPwz0ru7WWcM9A9+CdbkIeJcFWfOtlnbX5zxSAIn9CyG31Xhs6ivNYoL3+9AKEcoUfV0 /67HVZUP/3k+SLmttNZIEts7ZAXqFQ0pJ1YjFTRpnqoyN2UCbeIGAxNUMRLqElyCgHhWpTNB eVC+M2G3xa5bTocxUmefQHYGwE2JPPI07NmIK2GEQEy6204FAIZ82IoZ4H3AHTYzMIiEZQck v0cBAfOp28lJfcIZRpGfZqpR+WgpVWr50AnRVK7Eh0C41Wt466A1E2xfG5jnb+T+xQHu6ZwB 2X992VGb9LRxawAAAAAAAA== --------------ms090802040003040802070401-- From Martin.Thomson@andrew.com Wed Jun 9 22:43:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A815E3A69EB for ; Wed, 9 Jun 2010 22:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[AWL=-2.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2tQAnGLxNp5 for ; Wed, 9 Jun 2010 22:43:19 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id F25623A6982 for ; Wed, 9 Jun 2010 22:43:18 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:6101 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S24314891Ab0FJFnU (ORCPT ); Thu, 10 Jun 2010 00:43:20 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 10 Jun 2010 00:43:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 10 Jun 2010 13:43:17 +0800 From: "Thomson, Martin" To: Peter Saint-Andre , IETF cert-based identity Date: Thu, 10 Jun 2010 13:45:08 +0800 Thread-Topic: user overrides (was: Re: [certid] Fwd: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides) Thread-Index: AcsIRu7MQoJVU4LuR8qxtl79s7FVegAC3x2A Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F1FAC4@SISPE7MB1.commscope.com> References: <4C104CC3.8070602@stpeter.im> <4C10516B.1000400@stpeter.im> In-Reply-To: <4C10516B.1000400@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [certid] user overrides (was: Re: Fwd: [apps-discuss] draft-saintandre-tls-server-id-check and user overrides) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 05:43:20 -0000 WWVzLCBpdCB3b3VsZCBiZSBjb3VudGVyLXByb2R1Y3RpdmUgdG8gaW5jcmVhc2Ugc2NvcGUgYXJi aXRyYXJpbHkuICANCg0KTGV0J3MganVzdCBkcm9wIGFueXRoaW5nIGFib3V0IHRoZSAid2h5Ii4g IFRoZSByYXRob2xlIHRoYXQgb3BlbnMgaXMgc2NhcnkgZGVlcC4NCg0KSSdtIG5vdCBsb29raW5n IGZvciBhbnl0aGluZyBvbiB2YWxpZGF0aW9uIGVpdGhlci4gIFdoYXQgY29uY2VybnMgbWUgaXMg dGhhdCBhKSB0aGUgaW1wbGljYXRpb25zIG9mIHRoZSBvdmVycmlkZSBhcmUgbm90IGFydGljdWxh dGVkOyBhbmQgYikgdGhpcyAicGlubmluZyIgb3Igb3ZlcnJpZGUgZnVuY3Rpb24gYXBwbGllcyB0 byBjZXJ0aWZpY2F0ZXMgcmVnYXJkbGVzcyBvZiB0aGVpciBSRkM1MjgwLWRldGVybWluZWQgdmFs aWRpdHk7IGFuZCBjKSB5b3VyIHJlYWRlcnNoaXAgaXNuJ3QgYmVpbmcgdG9sZCBhbnkgb2YgdGhp cywgbW9zdCBhcmUgd29ya2luZyBpdCBvdXQgZm9yIHRoZW1zZWx2ZXMuDQoNClBlcmhhcHMgSSBj YW4gb2ZmZXIgdGV4dCBmb3IgMy42LjMuMToNCg0KICBBIGNhY2hlZCBvciAicGlubmVkIiBjZXJ0 aWZpY2F0ZSBuZWVkIG5vdCBiZSB2YWxpZCBhY2NvcmRpbmcgdG8gW1BLSVhdLiAgQSBzZXJ2ZXIg dGhhdCBwcmVzZW50cyBhIHBpbm5lZCBjZXJ0aWZpY2F0ZSBpcyBmb3VuZCB0byBtYXRjaCBiYXNl ZCBzb2xlbHkgb24gaXRzIGFiaWxpdHkgdG8gcHJvdmUgdGhhdCBpdCBwb3NzZXNzZXMgdGhlIHBy aXZhdGUga2V5IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlIHB1YmxpYyBrZXkgaW4gdGhlIGNlcnRp ZmljYXRlLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IFBldGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXQ0KPiBTZW50 OiBUaHVyc2RheSwgMTAgSnVuZSAyMDEwIDEyOjQ0IFBNDQo+IFRvOiBJRVRGIGNlcnQtYmFzZWQg aWRlbnRpdHkNCj4gQ2M6IFRob21zb24sIE1hcnRpbg0KPiBTdWJqZWN0OiB1c2VyIG92ZXJyaWRl cyAod2FzOiBSZTogW2NlcnRpZF0gRndkOiBbYXBwcy1kaXNjdXNzXSBkcmFmdC0NCj4gc2FpbnRh bmRyZS10bHMtc2VydmVyLWlkLWNoZWNrIGFuZCB1c2VyIG92ZXJyaWRlcykNCj4gDQo+IE9uIDYv OS8xMCA4OjI0IFBNLCBQZXRlciBTYWludC1BbmRyZSB3cm90ZToNCj4gPiBGb3J3YXJkaW5nIGZy b20gdGhlIGFwcHMtZGlzY3Vzc0BpZXRmLm9yZyBsaXN0IHRvIG1haW50YWluDQo+IGNvbnRpbnVp dHkuDQo+ID4NCj4gPiAtLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+ID4gU3Vi amVjdDogW2FwcHMtZGlzY3Vzc10gZHJhZnQtc2FpbnRhbmRyZS10bHMtc2VydmVyLWlkLWNoZWNr IGFuZCB1c2VyDQo+ID4gb3ZlcnJpZGVzDQo+ID4gRGF0ZTogV2VkLCA5IEp1biAyMDEwIDA5OjQ2 OjQxICswODAwDQo+ID4gRnJvbTogVGhvbXNvbiwgTWFydGluIDxNYXJ0aW4uVGhvbXNvbkBhbmRy ZXcuY29tPg0KPiA+IFRvOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcgPGFwcHMtZGlzY3Vzc0BpZXRm Lm9yZz4sDQo+IAlwc2FpbnRhbkBjaXNjby5jb20NCj4gPiA8cHNhaW50YW5AY2lzY28uY29tPiwJ SmVmZi5Ib2RnZXNAUGF5UGFsLmNvbSA8SmVmZi5Ib2RnZXNAUGF5UGFsLmNvbT4NCj4gPg0KPiA+ IEluIGRyYWZ0LXNhaW50YW5kcmUtdGxzLXNlcnZlci1pZC1jaGVjay0wNSwgU2VjdGlvbnMgMy42 LjIgYW5kDQo+IDMuNi4zLjENCj4gPiB0YWxrIGFib3V0IHVzZXIgY2hvaWNlIGluIGludGVyYWN0 aXZlbHkgdHJ1c3RpbmcgYSBjZXJ0aWZpY2F0ZS4NCj4gPg0KPiA+IFdoYXQgaXMgbWlzc2luZyBp cyBkaXNjdXNzaW9uIG9uICJ3aHkiIHVzZXJzIG1pZ2h0IG5lZWQgdG8gKG9yIHdhbnQNCj4gdG8p DQo+ID4gb3ZlcnJpZGUgdGhlIGRlZmF1bHQgYmVoYXZpb3VyLiAgVXNhZ2UgcHJhY3RpY2VzIGFy ZW4ndCBvYnZpb3VzLCBzbw0KPiB0aGlzDQo+ID4gc2VlbXMgbGlrZSBhIGdvb2QgcGxhY2UgdG8g ZXhwYW5kIG9uIHRoaXMuDQo+IA0KPiBJJ20gbm90IHN1cmUgaWYgdGhpcyBpcyB0aGUgc3BlYyBp biB3aGljaCB0byBkZXNjcmliZSB3aHkgYSB1c2VyIG1pZ2h0DQo+IG5lZWQgb3Igd2FudCB0byBv dmVycmlkZSB0aGUgZGVmYXVsdCBzZXJ2ZXIgaWRlbnRpdHkgY2hlY2tpbmcgYmVoYXZpb3IuDQo+ IE9uZSBleGFtcGxlIG9mIGEgc3BlYyB0aGF0IHByb3ZpZGVzIHNvbWUgZ3VpZGFuY2UgaW4gdGhp cyBhcmVhIGlzDQo+IGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMTAvV0Qtd3NjLXVpLTIwMTAwMzA5 LyBidXQgdGhhdCBkb2Vzbid0IGNvdmVyDQo+IG5vbi1icm93c2VyIG9yIG5vbi13ZWIgYXBwbGlj YXRpb25zLCBhbmQgaW4gYW55IGNhc2UgdGhpcyBpcyBhIG1hdHRlcg0KPiBvZg0KPiBwcm92aWRp bmcgZ3VpZGFuY2UgdG8gY2xpZW50IGRldmVsb3BlcnMgcmVnYXJkaW5nIHVzZXIgaW50ZXJhY3Rp b24sDQo+IHdoaWNoIGlzIG5vdCBleGFjdGx5IGEgbWF0dGVyIG9mIGV4cGVydGlzZSBpbiB0aGUg SUVURi4gSG93ZXZlciwgSSdtDQo+IG9wZW4gdG8gYWNjZXB0aW5nIHN1Z2dlc3RlZCB0ZXh0IG9u IHRoaXMgcG9pbnQuDQo+IA0KPiA+IEl0IHdvdWxkIGJlIGdvb2QgaWYgdGhpcyBkZXNjcmliZWQg d2hhdCBhcmUgYWNjZXB0YWJsZSB0eXBlcyBvZg0KPiA+IGNlcnRpZmljYXRlIHZhbGlkYXRpb24g ZmFpbHVyZSBhbmQgd2hhdCBhcmVuJ3QuICBDb21tb24gcmVhc29ucyB0aGF0DQo+IGFyZQ0KPiA+ IHBvdGVudGlhbGx5IHZhbGlkIGFyZToNCj4gPiAgLSBub3QgdHJ1c3RlZCAobm8gQ0EpDQo+ID4g IC0gZXhwaXJlZCBjZXJ0aWZpY2F0ZQ0KPiA+ICAtIHdyb25nIG5hbWUNCj4gPiAgLSByZXZva2Vk IGNlcnRpZmljYXRlDQo+IA0KPiBTbyBmYXIsIHdpdGggcmVnYXJkIHRvIGNsaWVudCBiZWhhdmlv ciB0aGlzIHNwZWMgaGFzIGJlZW4gbGltaXRlZCB0bw0KPiB0aGUNCj4gbmFycm93IHRvcGljIG9m IGNoZWNraW5nIHNlcnZlciBpZGVudGl0eSwgbm90IHRoZSBicm9hZGVyIHRvcGljIG9mDQo+IGNl cnRpZmljYXRlIHZhbGlkYXRpb24uDQo+IA0KPiA+IE9idmlvdXNseSwgeW91IGFyZW4ndCBnb2lu ZyB0byBhY2NlcHQgYSBjZXJ0aWZpY2F0ZSBpZiB0aGUgZW50aXR5DQo+ID4gcHJvdmlkaW5nIGl0 IGNvdWxkIG5vdCBwcm92ZSB0aGF0IHRoZXkgcG9zc2VzcyB0aGUgY29ycmVzcG9uZGluZw0KPiBw cml2YXRlDQo+ID4ga2V5Lg0KPiA+DQo+ID4gSXQgbWlnaHQgaGVscCB0byBleHBsYWluIHRoZSBz aWduaWZpY2FuY2Ugb2Ygc3VjaCBhbiBhY3Rpb24gLSB0aGUNCj4gdXNlcg0KPiA+IGlzIHRydXN0 aW5nIHRoZSBlbnRpdHkgdGhhdCBpcyBhYmxlIHRvIHByb29mIHBvc3Nlc3Npb24gb2YgdGhlDQo+ IHByaXZhdGUNCj4gPiBrZXkgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgcHJpdmF0ZSBrZXkgaW4g dGhlIGNlcnRpZmljYXRlLiAgQWxsDQo+IG90aGVyDQo+ID4gZGF0YSBpbiB0aGUgY2VydGlmaWNh dGUgYmVjb21lcyBpcnJlbGV2YW50Lg0KPiA+DQo+ID4gLS1NYXJ0aW4NCj4gPg0KPiA+IHAucy4g SSBkb24ndCBrbm93IHdoYXQgaGFwcGVucyBpbiBwcmFjdGljZSBpZiBhIGNlcnRpZmljYXRlIGlz IHBpbm5lZA0KPiA+IGJlZm9yZSBleHBpcnkgYW5kIHRoZW4gc3Vic2VxdWVudGx5IGV4cGlyZXMu ICBTYW1lIGdvZXMgZm9yDQo+IHJldm9jYXRpb24uDQo+ID4gIEknZCBiZSBpbnRlcmVzdGVkIGlu IGxlYXJuaW5nIHdoYXQgcGVvcGxlIGRvLiAgTG9naWMgc3VnZ2VzdHMgdGhhdA0KPiBpZiBhDQo+ ID4gY2VydGlmaWNhdGUgaXMgYWNjZXB0ZWQgZGVzcGl0ZSB2aW9sYXRpbmcgb25lIGNyaXRlcmlv biwgaXQgZG9lcyBub3QNCj4gPiBpbXBseSBjb250aW51ZWQgYWNjZXB0YW5jZSB3aGVuIGFub3Ro ZXIgY3JpdGVyaWEgYXJlIHN1YnNlcXVlbnRseQ0KPiB2aW9sYXRlZC4NCj4gDQo+IEFnYWluLCB0 aG9zZSBhcmUgaW50ZXJlc3RpbmcgYW5kIGltcG9ydGFudCBpc3N1ZXMsIGJ1dCBzb21ld2hhdCBv dXRzaWRlDQo+IHRoZSB2ZXJ5IGxpbWl0ZWQgc2NvcGUgdGhhdCB3ZSBoYXZlIHNldCBmb3Igb3Vy c2VsdmVzLg0KPiANCj4gQXMgd2l0aCBvdGhlciByZXF1ZXN0cyBmb3IgYnJvYWRlbmluZyB0aGUg c2NvcGUgb2YgdGhpcyBzcGVjLCBJJ2QgbGlrZQ0KPiB0byBwb2ludCBvdXQgdGhhdCB3ZSBtaWdo dCB2ZXJ5IHdlbGwgd3JpdGUgbW9yZSBzcGVjcyBvbiByZWxhdGVkIHRvcGljcw0KPiBpbiB0aGUg ZnV0dXJlLCBhbmQgcGVyaGFwcyBldmVudHVhbGx5IHB1dCB0aGVtIGFsbCB0b2dldGhlciBpbnRv IGEgbW9yZQ0KPiBnZW5lcmFsIEJDUC4gSG93ZXZlciwgZ2l2ZW4gaG93IGNvbnRlbnRpb3VzIHRo ZXNlIGlzc3VlcyBjYW4gYmUsIEkNCj4gdGhpbmsNCj4gd2UnZCBwcmVmZXIgdG8gZG8gdGhpcyB3 b3JrIGluIGEgcGllY2VtZWFsIGZhc2hpb24gdG8gc3RhcnQgd2l0aA0KPiBpbnN0ZWFkDQo+IG9m IGRlZmluaW5nIGEgZ3JhbmQgdW5pZmllZCB0aGVvcnkgZnJvbSB0aGUgYmVnaW5uaW5nIChiZWNh dXNlIGl0J3MNCj4gdW5saWtlbHkgdGhhdCB3ZSB3b3VsZCBldmVyIGZpbmlzaCB0aGF0IHRhc2sp Lg0KPiANCj4gUGV0ZXINCj4gDQo+IC0tDQo+IFBldGVyIFNhaW50LUFuZHJlDQo+IGh0dHBzOi8v c3RwZXRlci5pbS8NCj4gDQo+IA0KDQo= From ietf-certid@velox.ch Wed Jun 9 22:52:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFEEF28C120 for ; Wed, 9 Jun 2010 22:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfY4kfQJyfEW for ; Wed, 9 Jun 2010 22:52:25 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id 7853A28C11A for ; Wed, 9 Jun 2010 22:52:25 -0700 (PDT) Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o5A5qPSY015822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 10 Jun 2010 07:52:26 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1276149146; bh=7vixxP4jQ6VqJvgKZND1SlgoqNzbqi9kwPvDKw8kbpY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=mgy2qOjjZ72KOG6NRxeiMwJgFtd/wP/Wp57u8WewHtgVsHOWZaeaFVR/+2teifvwv +0RF204Q2jvxZlaUvX8lUZbH5EkzNtEBPJrKn/S0G1sAfssMX1RwxoYFRRYuD5kMdO eRAI851oyyUxeV3sBe5jTbwodMwUja8Ccrd5zJOuDpU4b0wphIxi2D8KjBghMYICpT uwKkU15CXHFOxF4twGKgqOZ8ELFbawM/WcB6+yhyYfaCqL+QgNAg54rynu+FtN3A9R cVpqJqAk8E6I1WycfsHWFcV3vVfbCPlS5KoqyCRPllOuCCcUNiA3s6LbagcBlf/5kt MCoxlHfHqstTw== Message-ID: <4C107D97.5080501@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1276149144; bh=7vixxP4jQ6VqJvgKZND1SlgoqNzbqi9kwPvDKw8kbpY=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=HzGkGgQWlO2WQGQxjnAww7lj2efawGw7dkqxiyHadqZZhbHRWFH7p+qJIQUdqP1pZ 7w5VoYdWUDbzDlL3I3SR5OvbyuD5yszH1v1Gs0RvUCxQaQZ+7j4kdEnESrQ1sW8B4W l4LLc0L/qCwVNLmZss0NeGmMQEk1UHIVshsaslbud31xBjE2vHftEfoJ+ULgZ3k+7b AwiLH7AZJHp1KXuKlTzZ//o5Cfu9/2kZT+uL1wlTQczBB39DBUo//rAEo+9+WSyiWL GVvOg+q+llKzZn57bkBv6VI5aGA3ttB+sJqUipyUxUuhWBsDfOiYaYJKQoHOlSNtUt HohS9JZuGaEBw== Date: Thu, 10 Jun 2010 07:52:23 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: certid@ietf.org References: <4C0E90E9.4050101@KingsMountain.com> <4C0F3EBC.9000902@velox.ch> <4C104B88.1070307@stpeter.im> In-Reply-To: <4C104B88.1070307@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 05:52:26 -0000 On 10.06.2010 04:18, Peter Saint-Andre wrote: >> The definition of "CN-ID" in section 1.3 should probably also be adapted >> (i.e., it should explicitly forbid multi-CN RDNs). > > Is this a more accurate definition? > > * CN-ID = a subject Distinguished Name (DN) whose constituent > sequence of Relative Distinguished Names (RDNs) contains one > and only one attribute value assertion (AVA) whose attribute > type is Common Name (CN) I think it's better to refer to it at the RDN level (as is the case for -05): * CN-ID = a Relative Distinguished Name (RDN) in the certificate subject which contains one and only one attribute value assertion (AVA) whose attribute type is Common Name (CN) When talking about CN-ID in the text, you would then say that only the (DER-sequence-wise) last CN-ID is to be used for verification purposes. Alternatively, the above definition could be changed to include this "last" property as well, but this really depends on what text you currently have in the working copy. Kaspar From mrex@sap.com Thu Jun 10 07:34:12 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6970F28C108 for ; Thu, 10 Jun 2010 07:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.695 X-Spam-Level: X-Spam-Status: No, score=-7.695 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMZwemBWrhoS for ; Thu, 10 Jun 2010 07:34:11 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 43D593A6837 for ; Thu, 10 Jun 2010 07:34:10 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5AEY505001394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jun 2010 16:34:05 +0200 (MEST) From: Martin Rex Message-Id: <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Thu, 10 Jun 2010 16:34:04 +0200 (MEST) In-Reply-To: <4C0E826B.3050904@bolyard.me> from "Nelson B Bolyard" at Jun 8, 10 10:48:27 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 14:34:12 -0000 Nelson B Bolyard wrote: > > There are a large number of CAs that follow the practice of vetting SOME > of the information they put into cert subject names, but not all, and in > fact deliberately making no attempt to vet certain attributes at all. > > Examples known to me include: > > OU names: typically not vetted at all > > CNs other than the last (most specific) one, if it is a DNS name. > > Maybe it's pointless to try, but can we write into this RFC that conforming > certs contain NO unvetted attributes in the subject name nor in any Subject > Alt Name attributes? > > Since CAs seem to have such a strong desire to do so, maybe we should invent > a new extension: unvetted subject alt names, where they can put whatever > nonsense they want, and apps that care to use only vetted info > can ignore. It MUST NOT be a critical extension. On the other hand, the > correct processing of that extension should be defined to ignore it (:-) > so that all apps may claim to properly handle it, even if it is critical. This description of what some CAs are doing is completely bogus. CAs vouch and are liable for every single bit in the ToBeSigned part of a certificate, no matter what stupid things they claim in any weird and ineffective "certificate practice statement" (CPS). A CA that doesn't is not a CA, but instead a hackers foot in your door. This applies equally to all components of the subject DName, and all X.509v3 extensions, such as all subjectAltNames, all keyUsages, all extendedKeyUsages, all BasicConstraints, AIA, CRL distribution points, and whatever else there is. Blindly copying without validation any data from the PKCS#10 request into the certificate that they sign would be simply irresponsible and an act of gross negligence. -Martin From hotz@jpl.nasa.gov Thu Jun 10 10:23:35 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8503A6992 for ; Thu, 10 Jun 2010 10:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSSSp2CguxHg for ; Thu, 10 Jun 2010 10:23:34 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 791D23A6917 for ; Thu, 10 Jun 2010 10:23:34 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o5AHMx0R003845; Thu, 10 Jun 2010 10:22:59 -0700 Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4C0933C1.4000004@bolyard.me> Date: Thu, 10 Jun 2010 10:22:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <74817296-C5CC-4CB8-85CB-C3740F42F022@jpl.nasa.gov> References: <201005311518.o4VFIHAw022209@fs4113.wdf.sap.corp> <4C08244D.9010809@bolyard.me> <4C08C8EC.1050200@edelweb.fr> <4C0933C1.4000004@bolyard.me> To: Nelson B Bolyard X-Mailer: Apple Mail (2.1078) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "certid@ietf.org" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:23:35 -0000 My NASA PIV card has one. The ambiguity of ordering in the string = representation does in fact cause problems. On Jun 4, 2010, at 10:11 AM, Nelson B Bolyard wrote: >> You can have two AVAs of the same type in the on RDN, i.e. >> two common names in the same RDN. There the interpretation >> of most-significant is not clear. >=20 > Agreed, in principle. In practice, I've never seen a certificate = produced > by a real CA with multiple AVAs in a single RDN. I've seen them in = certs > produced by test scripts, and by people playing with OpenSSL. :) ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From nelson@bolyard.me Thu Jun 10 10:38:19 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E527328C138 for ; Thu, 10 Jun 2010 10:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6f3ZAP4PMlI for ; Thu, 10 Jun 2010 10:38:18 -0700 (PDT) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by core3.amsl.com (Postfix) with SMTP id 8E6A028C12A for ; Thu, 10 Jun 2010 10:38:18 -0700 (PDT) Received: (qmail 32370 invoked from network); 10 Jun 2010 17:38:20 -0000 Received: from unknown (24.5.142.42) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 10 Jun 2010 17:38:20 -0000 Message-ID: <4C112371.3000104@bolyard.me> Date: Thu, 10 Jun 2010 10:40:01 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: certid@ietf.org References: <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> In-Reply-To: <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:38:20 -0000 On 2010-06-10 07:34 PDT, Martin Rex wrote: > Nelson B Bolyard wrote: >> There are a large number of CAs that follow the practice of vetting SOME >> of the information they put into cert subject names, but not all, and in >> fact deliberately making no attempt to vet certain attributes at all. >> >> Examples known to me include: >> >> OU names: typically not vetted at all >> >> CNs other than the last (most specific) one, if it is a DNS name. >> >> Maybe it's pointless to try, but can we write into this RFC that conforming >> certs contain NO unvetted attributes in the subject name nor in any Subject >> Alt Name attributes? >> >> Since CAs seem to have such a strong desire to do so, maybe we should invent >> a new extension: unvetted subject alt names, where they can put whatever >> nonsense they want, and apps that care to use only vetted info >> can ignore. It MUST NOT be a critical extension. On the other hand, the >> correct processing of that extension should be defined to ignore it (:-) >> so that all apps may claim to properly handle it, even if it is critical. > > > This description of what some CAs are doing is completely bogus. I agree that "what some CAs are doing is completely bogus". That's why I'm calling for text in the RFC to ban it. But the description of it is accurate. It has been actively exploited. This all made headlines about a year ago, you may recall. See attack 2a, pages 1,8-14 in Kaminsky's paper http://www.ioactive.com/pdfs/PKILayerCake.pdf. This paper makes it abundantly clear what happens when different implementations check different CNs in names with multiple CNs, and when CAs check different CNs than the libraries check. We should need no further reason to make this crystal clear in a new RFC. Library implementers should need no further reason to follow the standards to the letter. > CAs vouch and are liable for every single bit in the ToBeSigned part > of a certificate, no matter what stupid things they claim in any weird > and ineffective "certificate practice statement" (CPS). I think you'll find that lots of lawyers disagree. To the contrary, they would claim that the expectation that CAs do anything other than what their CPSes say is the stupid part. In most jurisdictions, there's no law that says what CAs must do, so CAs are bound by contract, and the contracts all cite the CPSes. > A CA that doesn't is not a CA, but instead a hackers foot in your door. > > This applies equally to all components of the subject DName, and > all X.509v3 extensions, such as all subjectAltNames, all keyUsages, > all extendedKeyUsages, all BasicConstraints, AIA, CRL distribution points, > and whatever else there is. > > Blindly copying without validation any data from the PKCS#10 request > into the certificate that they sign would be simply irresponsible and > an act of gross negligence. If you remove all the CAs that do that from your trusted list, it's get MUCH smaller. > -Martin From Bruno.Harbulot@manchester.ac.uk Thu Jun 10 10:38:58 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89CB28C12A for ; Thu, 10 Jun 2010 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74Y0LB2H2YWs for ; Thu, 10 Jun 2010 10:38:57 -0700 (PDT) Received: from clarity.mcc.ac.uk (clarity.mcc.ac.uk [130.88.200.144]) by core3.amsl.com (Postfix) with ESMTP id 460243A67F6 for ; Thu, 10 Jun 2010 10:38:57 -0700 (PDT) Received: from rankine.its.manchester.ac.uk ([130.88.25.196]) by clarity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OMliT-000OgH-83; Thu, 10 Jun 2010 18:38:57 +0100 Received: from pulsar.rcs.manchester.ac.uk ([130.88.1.47]:50938 helo=mymachine) by rankine.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OMliT-0006v7-34; Thu, 10 Jun 2010 18:38:57 +0100 Message-ID: <4C112330.5060309@manchester.ac.uk> Date: Thu, 10 Jun 2010 18:38:56 +0100 From: Bruno Harbulot User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: mrex@sap.com References: <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> In-Reply-To: <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: Bruno Harbulot from pulsar.rcs.manchester.ac.uk (mymachine) [130.88.1.47]:50938 X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk Cc: certid@ietf.org Subject: Re: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:38:59 -0000 Hi, On 10/06/10 15:34, Martin Rex wrote: > Nelson B Bolyard wrote: >> >> There are a large number of CAs that follow the practice of vetting SOME >> of the information they put into cert subject names, but not all, and in >> fact deliberately making no attempt to vet certain attributes at all. >> >> Examples known to me include: >> >> OU names: typically not vetted at all >> >> CNs other than the last (most specific) one, if it is a DNS name. >> >> Maybe it's pointless to try, but can we write into this RFC that conforming >> certs contain NO unvetted attributes in the subject name nor in any Subject >> Alt Name attributes? >> >> Since CAs seem to have such a strong desire to do so, maybe we should invent >> a new extension: unvetted subject alt names, where they can put whatever >> nonsense they want, and apps that care to use only vetted info >> can ignore. It MUST NOT be a critical extension. On the other hand, the >> correct processing of that extension should be defined to ignore it (:-) >> so that all apps may claim to properly handle it, even if it is critical. > > > This description of what some CAs are doing is completely bogus. > > CAs vouch and are liable for every single bit in the ToBeSigned part > of a certificate, no matter what stupid things they claim in any weird > and ineffective "certificate practice statement" (CPS). > > A CA that doesn't is not a CA, but instead a hackers foot in your door. > > This applies equally to all components of the subject DName, and > all X.509v3 extensions, such as all subjectAltNames, all keyUsages, > all extendedKeyUsages, all BasicConstraints, AIA, CRL distribution points, > and whatever else there is. > > Blindly copying without validation any data from the PKCS#10 request > into the certificate that they sign would be simply irresponsible and > an act of gross negligence. Agreed, but there's only so much the vetting can achieve. Vetting a piece of information depends on what it entails. Without knowing how some information is going to be used, the concept of vetting can be a bit loose. Vetting CN=the.host.name or subjectAltName=DNS:the.host.name is quite clear because CAs know more or less what it's going to be used for. The DNS system is a rather well-defined global ID system. Beyond that, not much is guaranteed in terms of naming. It starts to be a bit vague even for certificates for users. Should a CA vet "CN=Bill Gates", "CN=William Gates", "CN=William Henry Gates", etc? There are a people who share the same name, even if you include the middle names. If you get something like "O=Apple", is it going to be Apple (computers), Apple (Beatles) or Apple (http://www.apple.co.uk/). Definition of identity and name verification is doable with a hierarchical system like the DNS. Everything else will depend on the CAs policies as to how the do the initial verification of the identity. I think vetting a piece of information really depends on its semantics, and that can be a very difficult problem. Considering that O= or OU= aren't really used for things other than vaguely informative purposes, I'm not sure it would make sense to disallow using them to put some informative but only vaguely verified piece of information. Best wishes, Bruno. From mrex@sap.com Thu Jun 10 10:45:51 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4501428C12A for ; Thu, 10 Jun 2010 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.69 X-Spam-Level: X-Spam-Status: No, score=-7.69 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy2kdRK5Vs6s for ; Thu, 10 Jun 2010 10:45:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 26AC528C10D for ; Thu, 10 Jun 2010 10:45:49 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o5AHjn3U008940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Jun 2010 19:45:49 +0200 (MEST) From: Martin Rex Message-Id: <201006101745.o5AHjn7N022071@fs4113.wdf.sap.corp> To: nelson@bolyard.me (Nelson B Bolyard) Date: Thu, 10 Jun 2010 19:45:49 +0200 (MEST) In-Reply-To: <4C112371.3000104@bolyard.me> from "Nelson B Bolyard" at Jun 10, 10 10:40:01 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Please explicitly disallow unvetted info in subject X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:45:51 -0000 Nelson B Bolyard wrote: > > > CAs vouch and are liable for every single bit in the ToBeSigned part > > of a certificate, no matter what stupid things they claim in any weird > > and ineffective "certificate practice statement" (CPS). > > I think you'll find that lots of lawyers disagree. To the contrary, they > would claim that the expectation that CAs do anything other than what their > CPSes say is the stupid part. In most jurisdictions, there's no law that > says what CAs must do, so CAs are bound by contract, and the contracts all > cite the CPSes. It is the CAs who asked the browser vendors to ship their certs preconfigured as trusted! How many "certificate practice statements" (CPS) have you had to click through before your browser allowed you to establish a TLS-protected communication? For every user, where the count is "none", there is _no_ CPS in effect. -Martin From cantor.2@osu.edu Thu Jun 10 10:55:38 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32C6D28C15D for ; Thu, 10 Jun 2010 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4RkfgTDu3g1 for ; Thu, 10 Jun 2010 10:55:37 -0700 (PDT) Received: from defang2.it.ohio-state.edu (defang2.it.ohio-state.edu [128.146.216.82]) by core3.amsl.com (Postfix) with ESMTP id 4915728C13C for ; Thu, 10 Jun 2010 10:55:37 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang2.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o5AHtcK2014227; Thu, 10 Jun 2010 13:55:38 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o5AHtcXS009180; Thu, 10 Jun 2010 13:55:38 -0400 From: "Scott Cantor" To: References: <4C112371.3000104@bolyard.me> <201006101745.o5AHjn7N022071@fs4113.wdf.sap.corp> In-Reply-To: <201006101745.o5AHjn7N022071@fs4113.wdf.sap.corp> Date: Thu, 10 Jun 2010 13:55:41 -0400 Organization: The Ohio State University Message-ID: <025901cb08c6$248bf550$6da3dff0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQF9lWAyYiKT5YAmI9ykzci3g37NP5MWYGww Content-language: en-us X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.82 Cc: certid@ietf.org Subject: Re: [certid] Please explicitly disallow unvetted info in subject X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 17:55:38 -0000 These are all good arguments (which I subscribe to) for why treating commercial X.509 as a "successful" trust infrastructure that other identity standards should be leveraging in place of new approaches is a really, really stupid idea. But I don't think they're relevant to a document describing how one should verify server identity against X.509 certificate content, particularly with respect to anything that isn't a CN RDN or a sAN. By all means rail against the idiocy of this stuff, and I'll join in since there are still people pushing it constantly and belittling those who disagree, but I don't think it needs to be part of this draft. -- Scott From nelson@bolyard.me Thu Jun 10 12:48:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F8828C149 for ; Thu, 10 Jun 2010 12:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9A49XfOVWpd for ; Thu, 10 Jun 2010 12:48:48 -0700 (PDT) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 7BF833A6359 for ; Thu, 10 Jun 2010 12:48:48 -0700 (PDT) Received: (qmail 21092 invoked from network); 10 Jun 2010 19:48:49 -0000 Received: from unknown (24.5.142.42) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 10 Jun 2010 19:48:49 -0000 Message-ID: <4C11421B.1090209@bolyard.me> Date: Thu, 10 Jun 2010 12:50:51 -0700 From: Nelson B Bolyard Organization: Network Security Services User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre MIME-Version: 1.0 To: certid@ietf.org References: <201006101745.o5AHjn7N022071@fs4113.wdf.sap.corp> In-Reply-To: <201006101745.o5AHjn7N022071@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Please explicitly disallow unvetted info in subject X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 19:48:49 -0000 On 2010-06-10 10:45 PDT, Martin Rex wrote: > Nelson B Bolyard wrote: >>> CAs vouch and are liable for every single bit in the ToBeSigned part >>> of a certificate, no matter what stupid things they claim in any weird >>> and ineffective "certificate practice statement" (CPS). >> I think you'll find that lots of lawyers disagree. To the contrary, they >> would claim that the expectation that CAs do anything other than what their >> CPSes say is the stupid part. In most jurisdictions, there's no law that >> says what CAs must do, so CAs are bound by contract, and the contracts all >> cite the CPSes. > > It is the CAs who asked the browser vendors to ship their certs > preconfigured as trusted! Yes, the browser vendors review the CPSes and determine whether those CPSes meet their minimum requirements or not. Presently the browsers (well, some of the browsers) do not display the values of the attributes that are known not to be vetted by numerous CAs in the main site identity display. (Those attributes may be displayed if the user brings up a dialog that views the entire certificate). > How many "certificate practice statements" (CPS) have you had to click > through before your browser allowed you to establish a TLS-protected > communication? > > For every user, where the count is "none", there is _no_ CPS in effect. You're welcome to that opinion. From md@ssc.lt Thu Jun 10 15:46:44 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DAD3A67AC for ; Thu, 10 Jun 2010 15:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p1BwKBdMY+f for ; Thu, 10 Jun 2010 15:46:41 -0700 (PDT) Received: from mail.ssc.lt (mail.ssc.lt [212.122.83.205]) by core3.amsl.com (Postfix) with ESMTP id A77FA3A6813 for ; Thu, 10 Jun 2010 15:46:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=mail.ssc.lt) by mail.ssc.lt with esmtp (Exim 4.50) id 1OMqW6-0005BQ-B6; Fri, 11 Jun 2010 01:46:30 +0300 Received: from 84.240.23.130 (SquirrelMail authenticated user md@ssc.lt) by mail.ssc.lt with HTTP; Fri, 11 Jun 2010 01:46:30 +0300 (EEST) Message-ID: <65182.84.240.23.130.1276209990.squirrel@mail.ssc.lt> In-Reply-To: <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> References: <4C0E826B.3050904@bolyard.me> from "Nelson B Bolyard" at Jun 8, 10 10:48:27 am <201006101434.o5AEY4NX011362@fs4113.wdf.sap.corp> Date: Fri, 11 Jun 2010 01:46:30 +0300 (EEST) From: "Moudrick M. Dadashov" To: mrex@sap.com User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: certid@ietf.org Subject: Re: [certid] Please explicitly disallow unvetted info in subject names X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: md@ssc.lt List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 22:46:44 -0000 > CAs vouch and are liable for every single bit in the ToBeSigned part > of a certificate, no matter what stupid things they claim in any weird > and ineffective "certificate practice statement" (CPS). > > A CA that doesn't is not a CA, but instead a hackers foot in your door. > > This applies equally to all components of the subject DName, and > all X.509v3 extensions, such as all subjectAltNames, all keyUsages, > all extendedKeyUsages, all BasicConstraints, AIA, CRL distribution points, > and whatever else there is. > I agree with the list above except keyUsage and extendedKeyUsage which are somewhat identity neutral. > Blindly copying without validation any data from the PKCS#10 request > into the certificate that they sign would be simply irresponsible and > an act of gross negligence. 100% agree. M.D. cell: +370-699-26662 > > > -Martin > > > > > > > > > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid > From stpeter@stpeter.im Fri Jun 11 13:54:22 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F301C28C0F8 for ; Fri, 11 Jun 2010 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRWu2j41vTcv for ; Fri, 11 Jun 2010 13:54:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C437E3A6A59 for ; Fri, 11 Jun 2010 13:54:20 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 09ACB40E14 for ; Fri, 11 Jun 2010 14:54:22 -0600 (MDT) Message-ID: <4C12A27D.3070308@stpeter.im> Date: Fri, 11 Jun 2010 14:54:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020609010501090708040406" Subject: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:54:22 -0000 This is a cryptographically signed message in MIME format. --------------ms020609010501090708040406 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Version -05 of draft-saintandre-tls-server-id-check has some warning text about Domain Components (DCs). However, the more I delve the matter the less I think that we need to warn people away from using DCs from a security perspective. The problem with them would arise from confusion about the order of DCs based on the string representation, however that kind of confusion is possible for any RDNs and is not limited to DCs (so follow the DER order, not the string order). There might be other reasons to discourage DCs, but so far I have not heard them, so I'm inclined to remove the warnings from -06. Do speak up if you're concerned about this proposal. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020609010501090708040406 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMTIwNTQyMVowIwYJKoZIhvcNAQkEMRYEFNCTKjoXT5FRfFHP1MDJ KZdHGF+WMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAjdmD+SzvRdmSjRkuWs1O2EYoo0AoatuvPMU+N2dQ GOtNTaa5cCfRw107uXmhzCUf2MYauBYWfVLje4c+xcr7kWQA/ABmorEtNDSgr+yDMp5R+x86 4RqtnNld1GJky/aEV5P6Tgjg0Pio0ZIAdhLwLSgFgAAFCRIk++gIdmzk69tkk/Bbzi+6SS2q pNsKmyrwajHQLkbZfXMP8348RauL37dayzx2eU7DoLd0fy6Ud28LwlOtICWh7wn1tcuznQe8 zl2UCYVuCkQ1C2J8dWQi2xSWiqo8jFU3m9OIRlVbsTjn8gXh66UAuaHygVhD8eTIX1UcxBLg A/uaGvEHUX2Y7gAAAAAAAA== --------------ms020609010501090708040406-- From stpeter@stpeter.im Fri Jun 11 13:56:28 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070F728C0F8 for ; Fri, 11 Jun 2010 13:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvVB9Ecor9y1 for ; Fri, 11 Jun 2010 13:56:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1E5313A6A59 for ; Fri, 11 Jun 2010 13:56:27 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 16AB640E14 for ; Fri, 11 Jun 2010 14:56:28 -0600 (MDT) Message-ID: <4C12A2FB.5040604@stpeter.im> Date: Fri, 11 Jun 2010 14:56:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C0E90E9.4050101@KingsMountain.com> <4C0F3EBC.9000902@velox.ch> <4C104B88.1070307@stpeter.im> <4C107D97.5080501@velox.ch> In-Reply-To: <4C107D97.5080501@velox.ch> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010606020405080408010403" Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 20:56:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010606020405080408010403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/10 11:52 PM, Kaspar Brand wrote: > On 10.06.2010 04:18, Peter Saint-Andre wrote: >>> The definition of "CN-ID" in section 1.3 should probably also be adap= ted >>> (i.e., it should explicitly forbid multi-CN RDNs). >> >> Is this a more accurate definition? >> >> * CN-ID =3D a subject Distinguished Name (DN) whose constituent= >> sequence of Relative Distinguished Names (RDNs) contains one >> and only one attribute value assertion (AVA) whose attribute >> type is Common Name (CN) >=20 > I think it's better to refer to it at the RDN level (as is the case for= > -05): >=20 > * CN-ID =3D a Relative Distinguished Name (RDN) in the certifica= te > subject which contains one and only one attribute value > assertion (AVA) whose attribute type is Common Name (CN) I think that's better, thanks. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010606020405080408010403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMTIwNTYyN1owIwYJKoZIhvcNAQkEMRYEFErDfFe9KT8ANWxz6URa FSrWY6EHMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAlwOouqO9TrOGGKN+TJOr672O3IzMX89oz44kNDU2 qhulZkPOOkrdtyOVo5leRvfvq+yOU/sL+k8bNg2tP0RTs5G9Sy3KgfRxd6CB+FI+iOP/H9nD 1wOKFiAG35cdi6bu78ZTGoa6Ne9SVGXBqhTatDD+e16U3fJks/c0zVJf373Vbq8hSr4Hmeen vG8C0zXhxKZmY1YCVynJRHv0kkpvw1Cp062UiUf8B8sRL2Y2SPc2mKOoREbngmjShjHH4j2L frns7OjkYKIfDRKi+opZ06gkEVN++nNMy94F2DW70EyhIpe1pL/UmF3wQ+VO9L7/MUG7lGwO owI/oHDOCuNa/wAAAAAAAA== --------------ms010606020405080408010403-- From stpeter@stpeter.im Fri Jun 11 14:12:06 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEA83A6A4B for ; Fri, 11 Jun 2010 14:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[AWL=-0.919, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Uw9xRyo5k+o for ; Fri, 11 Jun 2010 14:12:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4FF563A6A20 for ; Fri, 11 Jun 2010 14:12:04 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5570E40E14; Fri, 11 Jun 2010 15:12:06 -0600 (MDT) Message-ID: <4C12A6A5.9060404@stpeter.im> Date: Fri, 11 Jun 2010 15:12:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Thomson, Martin" References: <4C104CC3.8070602@stpeter.im> <4C10516B.1000400@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03E7F1FAC4@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E7F1FAC4@SISPE7MB1.commscope.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030501090207060806050809" Cc: IETF cert-based identity Subject: Re: [certid] user overrides X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:12:06 -0000 This is a cryptographically signed message in MIME format. --------------ms030501090207060806050809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/9/10 11:45 PM, Thomson, Martin wrote: > Yes, it would be counter-productive to increase scope arbitrarily. >=20 > Let's just drop anything about the "why". The rathole that opens is > scary deep. /me pulls back from the edge of the abyss... > I'm not looking for anything on validation either. What concerns me > is that a) the implications of the override are not articulated; and > b) this "pinning" or override function applies to certificates > regardless of their RFC5280-determined validity;=20 That sounds too broad. I don't think we want to let a "pinned" certificate off the hook regarding all aspects of PKIX-validity. All we're saying is that the user has explicitly approved this certificate as acceptable for this application server, despite an identity mismatch. > and c) your > readership isn't being told any of this, most are working it out for > themselves. Yes, and that's not good, so we need to clarify things. > Perhaps I can offer text for 3.6.3.1: >=20 > A cached or "pinned" certificate need not be valid according to > [PKIX]. A server that presents a pinned certificate is found to > match based solely on its ability to prove that it possesses the > private key that corresponds to the public key in the certificate. Again, I think that's probably too lenient. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030501090207060806050809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMTIxMTIwNVowIwYJKoZIhvcNAQkEMRYEFNhYNCj5JVCbNRRtC25C bYeuc0ioMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAXbHG8Z6vzYl0IH2diflq+clfu+uEw08cWkQ+TKA9 Ly7PR52iSBdNcA/MAJH4rBZCN/ozeAWYjv3iuchAWLx+t8WUmb8JZ+TckKo5tKYvcvwZxmbb vh0E78cze3mwcPiLXf6mxkO6GqDhc3RBLdRl3OQ8qrtssvdvZscIdZpVJHou5YwnHxartlgJ 667DFHPXPtCVxPujuDem/dUFuDLg4Iu/moKGTB5Zoge9Qd8CH0RQpoKerMMhv6WkkMMhPye3 K8hBOL3bM2r0FwRKMQp5UQVZ+CGnCR+Rqm7wE9MqAuP49i3uP65qoTx1JNQ5Wx4K8iKYegtQ 2hkXOkiPTAgIlQAAAAAAAA== --------------ms030501090207060806050809-- From stpeter@stpeter.im Fri Jun 11 14:37:50 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E553A67B5 for ; Fri, 11 Jun 2010 14:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtAaWw+vf8aV for ; Fri, 11 Jun 2010 14:37:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7B1083A67A5 for ; Fri, 11 Jun 2010 14:37:47 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DB7FB40E14 for ; Fri, 11 Jun 2010 15:37:49 -0600 (MDT) Message-ID: <4C12ACAC.60405@stpeter.im> Date: Fri, 11 Jun 2010 15:37:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020808080103050903020008" Subject: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-06.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 21:37:50 -0000 This is a cryptographically signed message in MIME format. --------------ms020808080103050903020008 Content-Type: multipart/mixed; boundary="------------020502040701040700090604" This is a multi-part message in MIME format. --------------020502040701040700090604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jeff and I figured it would be helpful to push out a new version with the changes discussed on this list. The diffs will be available from http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-06 once that is posted. -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-06.txt Date: Fri, 11 Jun 2010 14:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representation and Verification of Domain-Based Application Server Identity in Certificates Used with Transport Layer Security Author(s) : P. Saint-Andre, J. Hodges Filename : draft-saintandre-tls-server-id-check-06.txt Pages : 38 Date : 2010-06-11 Many application technologies enable a secure connection between two entities using certificates in the context of Transport Layer Security (TLS). This document specifies best current practices for representing and verifying the identity of application servers in such interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-= 06.txt --------------020502040701040700090604 Content-Type: Message/External-body; name="draft-saintandre-tls-server-id-check-06.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-tls-server-id-check-06.txt" Content-Type: text/plain Content-ID: <2010-06-11142608.I-D@ietf.org> --------------020502040701040700090604 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------020502040701040700090604-- --------------ms020808080103050903020008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYxMTIxMzc0OFowIwYJKoZIhvcNAQkEMRYEFCCD++Mor+lPfqRJVLyH yppOGCFBMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAfXd57dW7lmGrYkN8PB+4IXdw46s4ssEfF4dW2jAU sRrBIOcZIkeXd0zhQudMusYw0ZACy3KabuF+nFy0u0yVCs34HB2N52s8bTfo+cQERmPF/6JA xrJUhtlEkBrvzBriUP0qagJ+5H2Z5FEPDpS1G+G8ncp+imMuQHowofdjHKY61FKftdD3UPOa rG0+8ouYy5FxKWdDnlSpmeG7n9fiXBWa/C/fQqOKSprIYC1s3thzPcHiAkBTY4a1vaCyVJdA +N19ipGvoA3pHMKnOIoOd1kFzemOYzVSK9wPDV/5j2yLLauUTzDvwkU64VdvMiIa+CKX3nab tHmg9GktkEFN+wAAAAAAAA== --------------ms020808080103050903020008-- From phoffman@imc.org Fri Jun 11 15:53:50 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4313B28C0FA for ; Fri, 11 Jun 2010 15:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sd2r9Z2SkIiP for ; Fri, 11 Jun 2010 15:53:48 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id C087A28C0ED for ; Fri, 11 Jun 2010 15:53:48 -0700 (PDT) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5BMrn2e082731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 15:53:50 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C12A27D.3070308@stpeter.im> References: <4C12A27D.3070308@stpeter.im> Date: Fri, 11 Jun 2010 15:53:48 -0700 To: Peter Saint-Andre , IETF cert-based identity From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2010 22:53:50 -0000 At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: >Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020609010501090708040406" > >Version -05 of draft-saintandre-tls-server-id-check has some warning >text about Domain Components (DCs). However, the more I delve the matter >the less I think that we need to warn people away from using DCs from a >security perspective. The problem with them would arise from confusion >about the order of DCs based on the string representation, however that >kind of confusion is possible for any RDNs and is not limited to DCs (so >follow the DER order, not the string order). There might be other >reasons to discourage DCs, but so far I have not heard them, so I'm >inclined to remove the warnings from -06. > >Do speak up if you're concerned about this proposal. Finally decloaking after being off this topic for a while. I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. For example, think about a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains. From paul.hoffman@vpnc.org Fri Jun 11 17:07:52 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9F33A67AC for ; Fri, 11 Jun 2010 17:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.659 X-Spam-Level: X-Spam-Status: No, score=0.659 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyB4O1jQzdCf for ; Fri, 11 Jun 2010 17:07:52 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 73B123A67A1 for ; Fri, 11 Jun 2010 17:07:52 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C07rkn085429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:07:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:07:43 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] Empty subjects X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 00:07:52 -0000 Near the end of 2.1, where you discuss SubjectAltName, please add "It is perfectly acceptable for a PKIX certificate to have an empty subject field as long as the SubjectAltName has at least one AVA in it." --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Jun 11 17:07:52 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48BF3A67A1 for ; Fri, 11 Jun 2010 17:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-U3MtUVRehT for ; Fri, 11 Jun 2010 17:07:52 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A1CD83A67B1 for ; Fri, 11 Jun 2010 17:07:52 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C07rkp085429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:07:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:07:50 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 00:07:52 -0000 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName identifier of type dNSName). 2. If the service using the certificate deploys a technology in which a server is discovered by means of DNS SRV records [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form of otherName from the GeneralName structure in the subjectAltName as specified in [SRVNAME]). If 2 is true, what is the value of the required DNS-ID? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Jun 11 17:10:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370963A67CC for ; Fri, 11 Jun 2010 17:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7+EoRTV3d-Z for ; Fri, 11 Jun 2010 17:10:48 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 79D883A67B1 for ; Fri, 11 Jun 2010 17:10:48 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C0AndL085557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:10:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:10:48 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 00:10:49 -0000 > However, if this > legacy identifer configuration is employed, then the server's > fully-qualified DNS domain name MUST be placed in the last (most > specific) RDN within the RDN sequence making up the certificate's > subjectName, as the order of RDNs is determined by the DER- > encoded Name within the server's PKIX certificate. I always get this wrong, so I assume people less familiar with PKIX do as well. Before you say "(most specific)" as if it was a toss-off, you should define "most specific RDN" as "the last RDN within a sequence", probably in section 1.3. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Jun 11 17:12:52 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BC8B3A67AC for ; Fri, 11 Jun 2010 17:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.641 X-Spam-Level: X-Spam-Status: No, score=0.641 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfz+eR-6qAaa for ; Fri, 11 Jun 2010 17:12:51 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A8C833A67A1 for ; Fri, 11 Jun 2010 17:12:51 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C0CqF0085701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:12:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:12:51 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 00:12:52 -0000 > 6. The certificate SHOULD NOT represent the server's fully-qualified > DNS domain name by means of a DC-ID, i.e., a series of Domain > Component (DC) attributes in the certificate subject, with one > RDN per domain label and one DC in each RDN. Although (for > example) could be used to represent > the DNS domain name "www.example.com", given the fact that the > DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED. This should be a MUST NOT. And the reason for the prohibition is not "DNS-ID can be used instead", but rather "this is insecure because you can interpret the series of RDNs incorrectly". --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Jun 11 17:17:23 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183113A67A1 for ; Fri, 11 Jun 2010 17:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.636 X-Spam-Level: X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UmdmOVe1zyU for ; Fri, 11 Jun 2010 17:17:22 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 5206A3A65A6 for ; Fri, 11 Jun 2010 17:17:22 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C0HNa5085887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:17:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:17:22 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] IDNA2008 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 00:17:23 -0000 > [[ Editorial Note: This section needs to be updated to reflect > [IDNA2008]. ]] Yes. > The term "internationalized domain name" refers to a DNS domain name > that conforms to the overall form of a domain name (dot-separated > labels) but that can include Unicode code points outside the > traditional US-ASCII range, as explained by [IDNA2003] and > [IDNA2008]. remove "[IDNA2003]". It is obsoleted by IDNA2008. > If the source domain of a reference identifier is an > internationalized domain name, then an implementation MUST convert > the domain name to the ASCII Compatible Encoding (ACE) format as > specified in Section 4 of [IDNA2003] before comparison Awaiting publication of IDNA2008 (within weeks) to get this reference. >; specifically, > the conversion operation specified in Section 4 of [IDNA2003] MUST be > performed as follows: > > o In step 1, the domain name SHALL be considered a "stored string". > o In step 3, set the flag called "UseSTD3ASCIIRules". > o In step 4, process each label with the "ToASCII" operation. > o In step 5, change all label separators to U+002E (full stop). > > After performing the "to-ASCII" conversion with regard to an > internationalized domain name, the DNS labels and names MUST be > compared for equality according to the rules specified in Section 3 > of [IDNA2003], i.e. once all label separators are replaced with > U+002E (dot) they are compared in a case-insensitive manner. All of that will disappear, and be replaced by probably one sentence. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Fri Jun 11 17:19:40 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A43D3A67B1 for ; Fri, 11 Jun 2010 17:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.632 X-Spam-Level: X-Spam-Status: No, score=0.632 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJWznUa95d6E for ; Fri, 11 Jun 2010 17:19:39 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 855443A65A6 for ; Fri, 11 Jun 2010 17:19:39 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5C0JeHW085966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Jun 2010 17:19:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 11 Jun 2010 17:19:38 -0700 To: certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [certid] False choice for CN X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 00:19:40 -0000 > 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName > identifier of type dNSName). . . . > Therefore, if and only if the identity set does not include > subjectAltName extensions of type dNSName, SRVName, or > uniformResourceIdentifier (or any application-specific subjectAltName > extensions supported by the client), the client MAY as a fallback > check for a fully-qualified DNS domain name in the last Common Name > RDN in the sequence of RDNs making up the Distinguished Name within > the certificate's subjectName (where the term "last" refers to the > DER order, which is often not the string order presented to a user; > the order that is applied here MUST be the DER order). Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. Please remove it. --Paul Hoffman, Director --VPN Consortium From shuque@isc.upenn.edu Fri Jun 11 18:32:48 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33ACD3A6802 for ; Fri, 11 Jun 2010 18:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6+p5+5qnOnZ for ; Fri, 11 Jun 2010 18:32:47 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 412F73A67EC for ; Fri, 11 Jun 2010 18:32:47 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 7FB3D2E5D; Fri, 11 Jun 2010 21:32:49 -0400 (EDT) Date: Fri, 11 Jun 2010 21:32:49 -0400 From: Shumon Huque To: Paul Hoffman Message-ID: <20100612013249.GA4782@isc.upenn.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 01:32:48 -0000 On Fri, Jun 11, 2010 at 05:07:50PM -0700, Paul Hoffman wrote: > 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName > identifier of type dNSName). > > 2. If the service using the certificate deploys a technology in > which a server is discovered by means of DNS SRV records > [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate > SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form > of otherName from the GeneralName structure in the subjectAltName > as specified in [SRVNAME]). > > If 2 is true, what is the value of the required DNS-ID? I don't think (1) is correct. If someone intends to deploy a certificate with an application specific name form such as SRV-ID or URI-ID, then they typically would not want to have a dNSName in the certificate, to make sure that the cert can't be (mis)used for unrelated application services at that domain name. Of course one might decide to include dNSName too for transition or backwards compatibility reasons. But I don't think that saying the certificate MUST include a dNSName is correct. --Shumon. From Bruno.Harbulot@manchester.ac.uk Sat Jun 12 04:01:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22203A6914 for ; Sat, 12 Jun 2010 04:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npghdUczMqUU for ; Sat, 12 Jun 2010 04:01:42 -0700 (PDT) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by core3.amsl.com (Postfix) with ESMTP id 2361F3A67DB for ; Sat, 12 Jun 2010 04:01:41 -0700 (PDT) Received: from kelvin.its.manchester.ac.uk ([130.88.25.195]) by serenity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ONOT8-0007oE-3R for certid@ietf.org; Sat, 12 Jun 2010 12:01:42 +0100 Received: from 94-192-243-24.zone6.bethere.co.uk ([94.192.243.24]:51867 helo=mymachine) by kelvin.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1ONOT7-0007WC-Rt for certid@ietf.org; Sat, 12 Jun 2010 12:01:42 +0100 Message-ID: <4C136915.8070402@manchester.ac.uk> Date: Sat, 12 Jun 2010 12:01:41 +0100 From: Bruno Harbulot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: Bruno Harbulot from 94-192-243-24.zone6.bethere.co.uk (mymachine) [94.192.243.24]:51867 X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 11:01:43 -0000 On 12/06/2010 01:12, Paul Hoffman wrote: >> 6. The certificate SHOULD NOT represent the server's fully-qualified >> DNS domain name by means of a DC-ID, i.e., a series of Domain >> Component (DC) attributes in the certificate subject, with one >> RDN per domain label and one DC in each RDN. Although (for >> example) could be used to represent >> the DNS domain name "www.example.com", given the fact that the >> DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED. > > This should be a MUST NOT. And the reason for the prohibition is not "DNS-ID can be used instead", but rather "this is insecure because you can interpret the series of RDNs incorrectly". > On this topic in 2.2.5 and 2.2.6, as Peter Sylvester and I said earlier in [1] and [2], I don't think using the word 'represent' is right here. Currently, certificates that have been emitted with the aim that tools will verify them according to RFC 2818 and that have a subject alternative name, what's in the subject distinguished name (including CN) is more or less decorative (with respect to the validation of the identity of the server). In this case, CN=host.name is still quite convenient to have, for humans to be able to sort their certificates. Maybe it's just me, but I keep my backups of my server certificates in tools such as OSX keychains, security stores in the browser or PKCS#12 files. The tools associated with them tend not to display anything about the subject alternative name in their listings (in terms of user interface) and I guess that's not going to change any time soon. (I guess larger systems could also use some sort of LDAP browser for example, in a similar way.) CN=host.name there is convenient, and it doesn't really get in the way of checking the identity of the remote server by an actual client when there's a subject alt. name (so long as the rules specify to ignore CN when there is an alt. name). For this reason, I'm not sure why you'd want to forbid CN=host.name (whatever its RDN position is) in such a certificate. The problem with the way I understand 'represent' in this context, is that you don't really know whether the CA put the CN in the subject DN as an indication (after all, it's a "common name") or with the intent it would be used by clients for verification. Which one of these would be OK? 1. Subject DN : C=UK,CN=the host name is host.name,E=example@example.com SubjectAltName: DNS:host.name Here, the certificate doesn't "represent" the host name in the CN (it's another string instead) 2. Subject DN : C=UK,CN=host.name,E=example@example.com SubjectAltName: DNS:host.name Here, the certificate "represents" the host name. Does it really, or is it just an indication as above? The structure of the subject DNs tend to follow some nomenclature internal to the CA. I'm not sure this specification should interfere with that when the subject DN is made somehow irrelevant by the presence of a subject alternative name. Best wishes, Bruno. [1] http://www.ietf.org/mail-archive/web/certid/current/msg00091.html [2] http://www.ietf.org/mail-archive/web/certid/current/msg00052.html From phoffman@imc.org Sat Jun 12 07:47:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77F93A6936 for ; Sat, 12 Jun 2010 07:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72iQXV+fmXjo for ; Sat, 12 Jun 2010 07:47:26 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id AAB113A68B9 for ; Sat, 12 Jun 2010 07:47:21 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5CElL7f028747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Jun 2010 07:47:22 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <9A1AC060-8079-4856-979B-B4074CB37531@jpl.nasa.gov> References: <4C12A27D.3070308@stpeter.im> <9A1AC060-8079-4856-979B-B4074CB37531@jpl.nasa.gov> Date: Sat, 12 Jun 2010 07:47:20 -0700 To: "Henry B. Hotz" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Sat, 12 Jun 2010 13:35:28 -0700 Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 14:47:28 -0000 At 6:56 PM -0700 6/11/10, Henry B. Hotz wrote: >On Jun 11, 2010, at 3:53 PM, Paul Hoffman wrote: > >> At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: >>> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020609010501090708040406" >>> >>> Version -05 of draft-saintandre-tls-server-id-check has some warning >>> text about Domain Components (DCs). However, the more I delve the matter >>> the less I think that we need to warn people away from using DCs from a >>> security perspective. The problem with them would arise from confusion >>> about the order of DCs based on the string representation, however that >>> kind of confusion is possible for any RDNs and is not limited to DCs (so >>> follow the DER order, not the string order). There might be other >>> reasons to discourage DCs, but so far I have not heard them, so I'm >>> inclined to remove the warnings from -06. >>> >>> Do speak up if you're concerned about this proposal. >> >> Finally decloaking after being off this topic for a while. >> >> I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. For example, think about a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains. > >But is the problem unique to DC's? To the best of my knowledge, yes. It is the "component" part of DC that makes them susceptible to "guess the ordering". All other relevant PKIX identifier fields are the full identifier. From mrex@sap.com Mon Jun 14 07:12:42 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4843A6979 for ; Mon, 14 Jun 2010 07:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.685 X-Spam-Level: X-Spam-Status: No, score=-7.685 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLxin4jVF3ua for ; Mon, 14 Jun 2010 07:12:41 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D36CE3A6924 for ; Mon, 14 Jun 2010 07:12:40 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o5EECbrr010258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jun 2010 16:12:42 +0200 (MEST) From: Martin Rex Message-Id: <201006141412.o5EECbvx026607@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Mon, 14 Jun 2010 16:12:37 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Jun 11, 10 05:19:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] False choice for CN X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 14:12:42 -0000 Paul Hoffman wrote: > > > 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName > > identifier of type dNSName). > > . . . > > > Therefore, if and only if the identity set does not include > > subjectAltName extensions of type dNSName, SRVName, or > > uniformResourceIdentifier (or any application-specific subjectAltName > > extensions supported by the client), the client MAY as a fallback > > check for a fully-qualified DNS domain name in the last Common Name > > RDN in the sequence of RDNs making up the Distinguished Name within > > the certificate's subjectName (where the term "last" refers to the > > DER order, which is often not the string order presented to a user; > > the order that is applied here MUST be the DER order). > > Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. Please remove it. I think this needs to stay. The document under discussion is supposed to be a BCP (Best current practice) document, and it will have to describe how clients should deal with server certificates that do no have subjectAltNames. It does so by describing the common practice that has been in use for certs that do not have subjectAltNames. -Martin From Martin.Thomson@andrew.com Mon Jun 14 16:39:09 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870F928C0DC for ; Mon, 14 Jun 2010 16:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.082 X-Spam-Level: X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=-3.083, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiSFgaAVttnc for ; Mon, 14 Jun 2010 16:39:08 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 824FF3A659A for ; Mon, 14 Jun 2010 16:39:08 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:60988 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S24814684Ab0FNXjL (ORCPT ); Mon, 14 Jun 2010 18:39:11 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 14 Jun 2010 18:39:11 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 15 Jun 2010 07:39:09 +0800 From: "Thomson, Martin" To: Peter Saint-Andre Date: Tue, 15 Jun 2010 07:41:04 +0800 Thread-Topic: user overrides Thread-Index: AcsJqsF9CoMvlKZrQNybtk6BZ9bfXwCbgxEw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F987C5@SISPE7MB1.commscope.com> References: <4C104CC3.8070602@stpeter.im> <4C10516B.1000400@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03E7F1FAC4@SISPE7MB1.commscope.com> <4C12A6A5.9060404@stpeter.im> In-Reply-To: <4C12A6A5.9060404@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: IETF cert-based identity Subject: Re: [certid] user overrides X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2010 23:39:09 -0000 RnJvbTogUGV0ZXIgU2FpbnQtQW5kcmUgW21haWx0bzpzdHBldGVyQHN0cGV0ZXIuaW1dDQo+ID4g V2hhdCBjb25jZXJucyBtZQ0KPiA+IGlzIHRoYXQgYSkgdGhlIGltcGxpY2F0aW9ucyBvZiB0aGUg b3ZlcnJpZGUgYXJlIG5vdCBhcnRpY3VsYXRlZDsgYW5kDQo+ID4gYikgdGhpcyAicGlubmluZyIg b3Igb3ZlcnJpZGUgZnVuY3Rpb24gYXBwbGllcyB0byBjZXJ0aWZpY2F0ZXMNCj4gPiByZWdhcmRs ZXNzIG9mIHRoZWlyIFJGQzUyODAtZGV0ZXJtaW5lZCB2YWxpZGl0eTsNCj4gDQo+IFRoYXQgc291 bmRzIHRvbyBicm9hZC4gSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIGxldCBhICJwaW5uZWQiDQo+ IGNlcnRpZmljYXRlIG9mZiB0aGUgaG9vayByZWdhcmRpbmcgYWxsIGFzcGVjdHMgb2YgUEtJWC12 YWxpZGl0eS4gQWxsDQo+IHdlJ3JlIHNheWluZyBpcyB0aGF0IHRoZSB1c2VyIGhhcyBleHBsaWNp dGx5IGFwcHJvdmVkIHRoaXMgY2VydGlmaWNhdGUNCj4gYXMgYWNjZXB0YWJsZSBmb3IgdGhpcyBh cHBsaWNhdGlvbiBzZXJ2ZXIsIGRlc3BpdGUgYW4gaWRlbnRpdHkgbWlzbWF0Y2guDQoNCkkgbWln aHQgYmUgY29udmluY2VkIHRoYXQgeW91IGFyZSBsaW1pdGluZyBzY29wZSB0byAic2VydmVyIGlk ZW50aXR5IiBhbmQgc28geW91IHdhbnQgdG8gZW51bWVyYXRlIHRoZSBmYXVsdHMgdGhhdCAicGlu bmluZyIgY2FuIGJlIHVzZWQgZm9yLiAgDQoNCklmIHlvdSBkbyBzbywgeW91IHJ1biB0aGUgcmlz ayBvZiBiZWNvbWluZyBpcnJlbGV2YW50LiAgSSBjYW4gcGluIGEgY2VydCBpbiBteSBicm93c2Vy IGZvciBhIG51bWJlciBvZiByZWFzb25zLiAgIFdoeSBpcyBhbiBpZGVudGl0eSBtaXNtYXRjaCBh bnkgbW9yZSBmb3JnaXZhYmxlIHRoYW4gYW4gdW5rbm93biBDQT8NCg0KPiA+IEEgY2FjaGVkIG9y ICJwaW5uZWQiIGNlcnRpZmljYXRlIG5lZWQgbm90IGJlIHZhbGlkIGFjY29yZGluZyB0bw0KPiA+ IFtQS0lYXS4gIEEgc2VydmVyIHRoYXQgcHJlc2VudHMgYSBwaW5uZWQgY2VydGlmaWNhdGUgaXMg Zm91bmQgdG8NCj4gPiBtYXRjaCBiYXNlZCBzb2xlbHkgb24gaXRzIGFiaWxpdHkgdG8gcHJvdmUg dGhhdCBpdCBwb3NzZXNzZXMgdGhlDQo+ID4gcHJpdmF0ZSBrZXkgdGhhdCBjb3JyZXNwb25kcyB0 byB0aGUgcHVibGljIGtleSBpbiB0aGUgY2VydGlmaWNhdGUuDQo+IA0KPiBBZ2FpbiwgSSB0aGlu ayB0aGF0J3MgcHJvYmFibHkgdG9vIGxlbmllbnQuDQoNClllcywgdmVyeS4gIEJ1dCB0aGUgYWx0 ZXJuYXRpdmUgKGVudW1lcmF0aW9uKSBzZWVtcyBib3RoIGhhcmQgYW5kIGNvdW50ZXJwcm9kdWN0 aXZlLg0KDQo+IFBldGVyIFNhaW50LUFuZHJlDQo= From paul.hoffman@vpnc.org Mon Jun 14 19:55:28 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D6E3A6A1B for ; Mon, 14 Jun 2010 19:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV8GRB6Fqwad for ; Mon, 14 Jun 2010 19:55:27 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 495CD3A6994 for ; Mon, 14 Jun 2010 19:55:27 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5F2tTlK097440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jun 2010 19:55:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <201006141412.o5EECbvx026607@fs4113.wdf.sap.corp> References: <201006141412.o5EECbvx026607@fs4113.wdf.sap.corp> Date: Mon, 14 Jun 2010 19:55:27 -0700 To: mrex@sap.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: certid@ietf.org Subject: Re: [certid] False choice for CN X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 02:55:28 -0000 At 4:12 PM +0200 6/14/10, Martin Rex wrote: >Paul Hoffman wrote: >> >> > 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >> > identifier of type dNSName). >> >> . . . >> >> > Therefore, if and only if the identity set does not include >> > subjectAltName extensions of type dNSName, SRVName, or >> > uniformResourceIdentifier (or any application-specific subjectAltName >> > extensions supported by the client), the client MAY as a fallback >> > check for a fully-qualified DNS domain name in the last Common Name >> > RDN in the sequence of RDNs making up the Distinguished Name within >> > the certificate's subjectName (where the term "last" refers to the >> > DER order, which is often not the string order presented to a user; >> > the order that is applied here MUST be the DER order). >> >> Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. Please remove it. > >I think this needs to stay. > >The document under discussion is supposed to be a BCP (Best current practice) >document, and it will have to describe how clients should deal with >server certificates that do no have subjectAltNames. It does so by >describing the common practice that has been in use for certs that >do not have subjectAltNames. That goes counter to the MUST-level statements in the document. You either need to downgrade the MUST-level requirements, or get rid of the sections that say, in essence, "if this MUST-level requirement is not met, then do this". The fact that this is a BCP is irrelevant. BCPs are standards-track documents. Being a BCP doesn't make it OK to have conflicting requirements. --Paul Hoffman, Director --VPN Consortium From hotz@jpl.nasa.gov Mon Jun 14 22:41:32 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93C373A67E5 for ; Mon, 14 Jun 2010 22:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCcFsP+N-4Q8 for ; Mon, 14 Jun 2010 22:41:16 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id 4F8FD3A6862 for ; Mon, 14 Jun 2010 22:41:16 -0700 (PDT) Received: from mail.jpl.nasa.gov (altvirehtstap01.jpl.nasa.gov [128.149.137.72]) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o5F5fID5024294 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified FAIL); Mon, 14 Jun 2010 22:41:19 -0700 Received: from [192.168.2.2] (128.149.137.113) by ums-smtp.jpl.nasa.gov (128.149.137.72) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 14 Jun 2010 22:41:18 -0700 MIME-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset="us-ascii" From: "Henry B. Hotz" In-Reply-To: Date: Mon, 14 Jun 2010 22:41:10 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <9A21C481-00C6-4261-A5E0-157573E838B0@jpl.nasa.gov> References: <201006141412.o5EECbvx026607@fs4113.wdf.sap.corp> To: Paul Hoffman X-Mailer: Apple Mail (2.1078) X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "certid@ietf.org" Subject: Re: [certid] False choice for CN X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 05:41:33 -0000 On Jun 14, 2010, at 7:55 PM, Paul Hoffman wrote: > At 4:12 PM +0200 6/14/10, Martin Rex wrote: >> Paul Hoffman wrote: >>>=20 >>>> 1. The certificate MUST include a "DNS-ID" (i.e., a = subjectAltName >>>> identifier of type dNSName). >>>=20 >>> . . . >>>=20 >>>> Therefore, if and only if the identity set does not include >>>> subjectAltName extensions of type dNSName, SRVName, or >>>> uniformResourceIdentifier (or any application-specific = subjectAltName >>>> extensions supported by the client), the client MAY as a fallback >>>> check for a fully-qualified DNS domain name in the last Common = Name >>>> RDN in the sequence of RDNs making up the Distinguished Name = within >>>> the certificate's subjectName (where the term "last" refers to the >>>> DER order, which is often not the string order presented to a = user; >>>> the order that is applied here MUST be the DER order). >>>=20 >>> Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. = Please remove it. >>=20 >> I think this needs to stay. >>=20 >> The document under discussion is supposed to be a BCP (Best current = practice) >> document, and it will have to describe how clients should deal with >> server certificates that do no have subjectAltNames. It does so by >> describing the common practice that has been in use for certs that >> do not have subjectAltNames. >=20 > That goes counter to the MUST-level statements in the document. You = either need to downgrade the MUST-level requirements, or get rid of the = sections that say, in essence, "if this MUST-level requirement is not = met, then do this". >=20 > The fact that this is a BCP is irrelevant. BCPs are standards-track = documents. Being a BCP doesn't make it OK to have conflicting = requirements. The section in question describes what one party is supposed to do if = the other party does the wrong thing. I see nothing inconsistent or = inappropriate about that. =20 It's just sad that the current (actual, not best) practice is to do "the = wrong thing" so often that we need to worry about it so much. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From michael@stroeder.com Tue Jun 15 01:10:07 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 203EF3A6A39 for ; Tue, 15 Jun 2010 01:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCdfO9kHQItX for ; Tue, 15 Jun 2010 01:10:04 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 0EB733A6883 for ; Tue, 15 Jun 2010 01:10:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 38C9F4E10E for ; Tue, 15 Jun 2010 10:10:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs5M2W58Yhvj for ; Tue, 15 Jun 2010 10:10:00 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 2ACF44E100 for ; Tue, 15 Jun 2010 10:09:59 +0200 (CEST) Message-ID: <4C1714FD.3030202@stroeder.com> Date: Tue, 15 Jun 2010 07:51:57 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 To: IETF cert-based identity References: <4C104CC3.8070602@stpeter.im> <4C10516B.1000400@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03E7F1FAC4@SISPE7MB1.commscope.com> <4C12A6A5.9060404@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03E7F987C5@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E7F987C5@SISPE7MB1.commscope.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [certid] user overrides X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 08:10:07 -0000 Thomson, Martin wrote: > Why is an identity mismatch any more forgivable than an unknown CA? The user might have knowledge about DNS aliases but not about the public key of the unknown CA. Not sure whether that should all be part of this BCP document though... Ciao, Michael. From alexey.melnikov@isode.com Sat Jun 19 03:58:21 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3B13A680A for ; Sat, 19 Jun 2010 03:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4kdGomK6SRu for ; Sat, 19 Jun 2010 03:58:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 55E453A69EB for ; Sat, 19 Jun 2010 03:58:20 -0700 (PDT) Received: from [92.40.172.205] (92.40.172.205.sub.mbb.three.co.uk [92.40.172.205]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 19 Jun 2010 11:58:23 +0100 Message-ID: <4C1CA2B8.9080103@isode.com> Date: Sat, 19 Jun 2010 11:58:00 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 10:58:21 -0000 Hi Paul, Paul Hoffman wrote: >At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: > > >>Version -05 of draft-saintandre-tls-server-id-check has some warning >>text about Domain Components (DCs). However, the more I delve the matter >>the less I think that we need to warn people away from using DCs from a >>security perspective. The problem with them would arise from confusion >>about the order of DCs based on the string representation, however that >>kind of confusion is possible for any RDNs and is not limited to DCs (so >>follow the DER order, not the string order). There might be other >>reasons to discourage DCs, but so far I have not heard them, so I'm >>inclined to remove the warnings from -06. >> >>Do speak up if you're concerned about this proposal. >> >> >Finally decloaking after being off this topic for a while. > >I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. > >For example, think about a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains. > > I personally I don't care if DCs are allowed or not by this document. But if DCs are to be prohibited in this document, I want to make sure that the document gives the right reason for that. The order of RDNs in a DN is fixed. So you are saying that there are buggy implementations (and maybe most of them are buggy) which don't read RDNs in the correct order, that is why we need to prohibit use of DCs in subjectName? From alexey.melnikov@isode.com Sat Jun 19 04:36:24 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328DA3A6A0E for ; Sat, 19 Jun 2010 04:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[AWL=1.563, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjhRxW8+kgMW for ; Sat, 19 Jun 2010 04:36:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 63E883A6A09 for ; Sat, 19 Jun 2010 04:36:15 -0700 (PDT) Received: from [92.40.172.205] (92.40.172.205.sub.mbb.three.co.uk [92.40.172.205]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 19 Jun 2010 12:36:20 +0100 Message-ID: <4C1CABA1.2050205@isode.com> Date: Sat, 19 Jun 2010 12:36:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 11:36:24 -0000 Hi Paul, Paul Hoffman wrote: > 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName > identifier of type dNSName). > > 2. If the service using the certificate deploys a technology in > which a server is discovered by means of DNS SRV records > [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate > SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form > of otherName from the GeneralName structure in the subjectAltName > as specified in [SRVNAME]). > >If 2 is true, what is the value of the required DNS-ID? > One or more hostname for machines that would provide the specified service. I.e. most likely some/all hostnames from the output of DNS SRV lookup, but I can think of some examples where other hostnames can be used in addition to or instead of these. E.g. a machine on internal network, hostname of a NAT box, etc. From phoffman@imc.org Sat Jun 19 07:01:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ADB33A63CA for ; Sat, 19 Jun 2010 07:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrmbfGdtggaS for ; Sat, 19 Jun 2010 07:01:25 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 564C43A69EB for ; Sat, 19 Jun 2010 07:01:25 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5JE1SV2072439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jun 2010 07:01:30 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1CA2B8.9080103@isode.com> References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> Date: Sat, 19 Jun 2010 07:01:26 -0700 To: Alexey Melnikov From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:01:26 -0000 At 11:58 AM +0100 6/19/10, Alexey Melnikov wrote: >Hi Paul, > >Paul Hoffman wrote: > >>At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: >> >> >>>Version -05 of draft-saintandre-tls-server-id-check has some warning >>>text about Domain Components (DCs). However, the more I delve the matter >>>the less I think that we need to warn people away from using DCs from a >>>security perspective. The problem with them would arise from confusion >>>about the order of DCs based on the string representation, however that >>>kind of confusion is possible for any RDNs and is not limited to DCs (so >>>follow the DER order, not the string order). There might be other >>>reasons to discourage DCs, but so far I have not heard them, so I'm >>>inclined to remove the warnings from -06. >>> >>>Do speak up if you're concerned about this proposal. >>> >>> >>Finally decloaking after being off this topic for a while. >> >>I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. >> >>For example, think about a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains. >> >> >I personally I don't care if DCs are allowed or not by this document. But if DCs are to be prohibited in this document, I want to make sure that the document gives the right reason for that. > >The order of RDNs in a DN is fixed. So you are saying that there are buggy implementations (and maybe most of them are buggy) which don't read RDNs in the correct order, that is why we need to prohibit use of DCs in subjectName? No, I'm saying that the order in which you are supposed to take the DCs has historically been unclear. "Most significant" means different things to different people. From paul.hoffman@vpnc.org Sat Jun 19 07:04:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F7E3A6831 for ; Sat, 19 Jun 2010 07:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.658 X-Spam-Level: X-Spam-Status: No, score=0.658 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjPijhMWTtvR for ; Sat, 19 Jun 2010 07:04:43 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DFAB23A69F2 for ; Sat, 19 Jun 2010 07:04:42 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5JE4lRP072574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jun 2010 07:04:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1CABA1.2050205@isode.com> References: <4C1CABA1.2050205@isode.com> Date: Sat, 19 Jun 2010 07:04:45 -0700 To: Alexey Melnikov From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:04:43 -0000 At 12:36 PM +0100 6/19/10, Alexey Melnikov wrote: >Hi Paul, > >Paul Hoffman wrote: > >> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >> identifier of type dNSName). >> >> 2. If the service using the certificate deploys a technology in >> which a server is discovered by means of DNS SRV records >> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate >> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form >> of otherName from the GeneralName structure in the subjectAltName >> as specified in [SRVNAME]). >> >>If 2 is true, what is the value of the required DNS-ID? >> >One or more hostname for machines that would provide the specified service. I.e. most likely some/all hostnames from the output of DNS SRV lookup, but I can think of some examples where other hostnames can be used in addition to or instead of these. E.g. a machine on internal network, hostname of a NAT box, etc. So a cert says "the hostname of this server is www.example.com, and you can look up the hostname for the server using SRV"? What does that mean in a security context? If I get back one name of yyy.example.com, does that mean that the host has both names, or that there was a lookup error? --Paul Hoffman, Director --VPN Consortium From peter.sylvester@edelweb.fr Sat Jun 19 07:11:32 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CB833A6A0F for ; Sat, 19 Jun 2010 07:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.061 X-Spam-Level: X-Spam-Status: No, score=-0.061 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZsBJxHQp6c3 for ; Sat, 19 Jun 2010 07:11:31 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 281523A63CA for ; Sat, 19 Jun 2010 07:11:31 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id EECCDD4 for ; Sat, 19 Jun 2010 13:06:28 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 078561713C for ; Sat, 19 Jun 2010 13:06:29 +0200 (CEST) Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id D3B0977D8 for ; Sat, 19 Jun 2010 13:06:28 +0200 (CEST) Message-ID: <4C1CA4B4.7090304@edelweb.fr> Date: Sat, 19 Jun 2010 13:06:28 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> In-Reply-To: <4C1CA2B8.9080103@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:11:32 -0000 >> > I personally I don't care if DCs are allowed or not by this document. > But if DCs are to be prohibited in this document, I want to make sure > that the document gives the right reason for that. > > The order of RDNs in a DN is fixed. So you are saying that there are > buggy implementations (and maybe most of them are buggy) which don't > read RDNs in the correct order, that is why we need to prohibit use of > DCs in subjectName? > In addition, RFC 5280 says: In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in [RFC4519]. The Domain Name System (DNS) provides a hierarchical resource labeling system. This attribute provides a convenient mechanism for organizations that wish to use DNs that parallel their DNS names. This is not a replacement for the dNSName component of the alternative name extensions. Implementations are not required to convert such names into DNS names. The syntax and associated OID for this attribute type are provided in the ASN.1 modules in Appendix A. Rules for encoding internationalized domain names for use with the domainComponent attribute type are specified in Section 7.3. From alexey.melnikov@isode.com Sat Jun 19 07:24:37 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80793A6A17 for ; Sat, 19 Jun 2010 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[AWL=1.197, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdcYCx3UYYHI for ; Sat, 19 Jun 2010 07:24:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 7ADC23A6A16 for ; Sat, 19 Jun 2010 07:24:36 -0700 (PDT) Received: from [92.40.172.205] (92.40.172.205.sub.mbb.three.co.uk [92.40.172.205]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 19 Jun 2010 15:24:41 +0100 Message-ID: <4C1CD30B.4090200@isode.com> Date: Sat, 19 Jun 2010 15:24:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:24:37 -0000 Paul Hoffman wrote: >At 11:58 AM +0100 6/19/10, Alexey Melnikov wrote: > > >>Hi Paul, >> >>Paul Hoffman wrote: >> >> >>>At 2:54 PM -0600 6/11/10, Peter Saint-Andre wrote: >>> >>> >>>>Version -05 of draft-saintandre-tls-server-id-check has some warning >>>>text about Domain Components (DCs). However, the more I delve the matter >>>>the less I think that we need to warn people away from using DCs from a >>>>security perspective. The problem with them would arise from confusion >>>>about the order of DCs based on the string representation, however that >>>>kind of confusion is possible for any RDNs and is not limited to DCs (so >>>>follow the DER order, not the string order). There might be other >>>>reasons to discourage DCs, but so far I have not heard them, so I'm >>>>inclined to remove the warnings from -06. >>>> >>>>Do speak up if you're concerned about this proposal. >>>> >>>> >>>Finally decloaking after being off this topic for a while. >>> >>>I am *quite* concerned about this. The DC ordering problem is not "based on the string representation": it is because the set of DCs can be read *by the program* in two directions. >>> >>>For example, think about a cert with "dc=com dc=net". Both net.com and com.net exist today. For different applications, that one cert could apply to two completely different domains. >>> >>> >>I personally I don't care if DCs are allowed or not by this document. But if DCs are to be prohibited in this document, I want to make sure that the document gives the right reason for that. >> >>The order of RDNs in a DN is fixed. So you are saying that there are buggy implementations (and maybe most of them are buggy) which don't read RDNs in the correct order, that is why we need to prohibit use of DCs in subjectName? >> >> >No, I'm saying that the order in which you are supposed to take the DCs has historically been unclear. "Most significant" means different things to different people. > I probably sound like a broken record, but the order is very clear for LDAP. I don't see why is this going to be different for X.509 certificates. From michael@stroeder.com Sat Jun 19 07:42:08 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3907F3A6A16 for ; Sat, 19 Jun 2010 07:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.163 X-Spam-Level: X-Spam-Status: No, score=-0.163 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dq2NLEqMCwNT for ; Sat, 19 Jun 2010 07:42:07 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 451003A6875 for ; Sat, 19 Jun 2010 07:42:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 544F54E087; Sat, 19 Jun 2010 16:42:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-xKmJ3MNV31; Sat, 19 Jun 2010 16:42:06 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 9AB2E4E04C; Sat, 19 Jun 2010 16:42:04 +0200 (CEST) Message-ID: <4C1CD73B.6000602@stroeder.com> Date: Sat, 19 Jun 2010 16:42:03 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 To: Alexey Melnikov References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> In-Reply-To: <4C1CD30B.4090200@isode.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:42:08 -0000 Alexey Melnikov wrote: > Paul Hoffman wrote: >> No, I'm saying that the order in which you are supposed to take the >> DCs has historically been unclear. "Most significant" means different >> things to different people. >> > I probably sound like a broken record, but the order is very clear for > LDAP. I don't see why is this going to be different for X.509 certificates. Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500 names as well. Ciao, Michael. From phoffman@imc.org Sat Jun 19 07:42:24 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892283A6A26 for ; Sat, 19 Jun 2010 07:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lcsy0o5Ai5UH for ; Sat, 19 Jun 2010 07:42:23 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 4FDFD3A6891 for ; Sat, 19 Jun 2010 07:42:23 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5JEgROh075390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jun 2010 07:42:28 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1CD30B.4090200@isode.com> References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> Date: Sat, 19 Jun 2010 07:42:25 -0700 To: Alexey Melnikov From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:42:24 -0000 At 3:24 PM +0100 6/19/10, Alexey Melnikov wrote: >I probably sound like a broken record, but the order is very clear for LDAP. I don't see why is this going to be different for X.509 certificates. If you feel that way, fine. We have historically seen deployed PKIX implementations that got the order wrong because they had no certs to test with. I do not hold it against someone to get the order wrong, particularly because all of the text examples in RFC 5280 say "dc=example,dc=com". From phoffman@imc.org Sat Jun 19 07:56:04 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6893A67F8 for ; Sat, 19 Jun 2010 07:56:04 -0700 (PDT) X-Quarantine-ID: <0OnujBqir1tG> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F6 hex): To: Michael Str\366der ; Sat, 19 Jun 2010 07:56:03 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 7D20B3A6875 for ; Sat, 19 Jun 2010 07:56:03 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5JEu7XW076132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jun 2010 07:56:09 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1CD73B.6000602@stroeder.com> References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> Date: Sat, 19 Jun 2010 07:56:06 -0700 To: Michael Ströder , Alexey Melnikov From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 14:56:04 -0000 At 4:42 PM +0200 6/19/10, Michael Ströder wrote: >Alexey Melnikov wrote: >> Paul Hoffman wrote: >>> No, I'm saying that the order in which you are supposed to take the >>> DCs has historically been unclear. "Most significant" means different >>> things to different people. >>> >> I probably sound like a broken record, but the order is very clear for >> LDAP. I don't see why is this going to be different for X.509 certificates. > >Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500 >names as well. ...and you think that all (or even typical) PKIX implementers read either of those documents? From peter.sylvester@edelweb.fr Sat Jun 19 11:35:01 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089473A68EA for ; Sat, 19 Jun 2010 11:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.045 X-Spam-Level: X-Spam-Status: No, score=-0.045 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqaPzv6k4cKJ for ; Sat, 19 Jun 2010 11:34:55 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id CC86B3A687C for ; Sat, 19 Jun 2010 11:34:54 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 42492D4 for ; Sat, 19 Jun 2010 20:35:00 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 219EF17139 for ; Sat, 19 Jun 2010 20:35:00 +0200 (CEST) Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 1882E77D8 for ; Sat, 19 Jun 2010 20:35:00 +0200 (CEST) Message-ID: <4C1D0DD3.2020907@edelweb.fr> Date: Sat, 19 Jun 2010 20:34:59 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2010 18:35:01 -0000 On 06/19/2010 04:56 PM, Paul Hoffman wrote: > At 4:42 PM +0200 6/19/10, Michael Str=F6der wrote: > =20 >> Alexey Melnikov wrote: >> =20 >>> Paul Hoffman wrote: >>> =20 >>>> No, I'm saying that the order in which you are supposed to take the >>>> DCs has historically been unclear. "Most significant" means differen= t >>>> things to different people. >>>> >>>> =20 >>> I probably sound like a broken record, but the order is very clear fo= r >>> LDAP. I don't see why is this going to be different for X.509 certifi= cates. >>> =20 >> Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X= =2E500 >> names as well. >> =20 > ...and you think that all (or even typical) PKIX implementers read eith= er of those documents? > =20 And there might be a chance that this gets worse with RFCs full of unclear justifications. The order in domain components is as unclear as the order in DNs, i.e. the same confusion can occur IMO due to the two different string representions. (openssl vs ldap) There are two ways, I have seen a real CA having it DN starting wit CN and ending with C, the whole in a certificate issued from a Research Network PKI. Was rather simple to explain and corrected. Examples in various RFCs mentionned also contain CN. If (and that might not be clear) CN is regarded as more significant, then the order of DCs is sufficiently clear IMO. I also wonder if someone who understands the hierarchy of RDNs would consider that the hierarchy in the DC sequence is the other way around. It is more likely that one doesn't think about any order at all in name components (and implement names with hash tables) which may be a reasonable concept with named components. With the text concerning DCs in RFC 5280 that a CA cannot assume that a relying party is able to reconstruct a DNS name from DC components, but the text does not exclude this, thus one can assume that it is constructed correctly if present. having said this, I agree with Alexey when he says (in particular I like the many reasons for the first sentence). > I personally I don't care if DCs are allowed or not by this document. = But if DCs are to be prohibited in this document, I want to make sure=20 that the document gives the right reason for that. Peter From michael@stroeder.com Mon Jun 21 01:27:33 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4713A6859 for ; Mon, 21 Jun 2010 01:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.301 X-Spam-Level: X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiA340rD25F2 for ; Mon, 21 Jun 2010 01:27:32 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 641AF3A69C9 for ; Mon, 21 Jun 2010 01:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 55B7E4E073; Mon, 21 Jun 2010 10:27:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGb4Pon4zSJR; Mon, 21 Jun 2010 10:27:29 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 0C5744E072; Mon, 21 Jun 2010 10:27:28 +0200 (CEST) Message-ID: <4C1F226F.1010408@stroeder.com> Date: Mon, 21 Jun 2010 10:27:27 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 08:27:33 -0000 Paul Hoffman wrote: > particularly because all of the text examples in RFC 5280 say > "dc=example,dc=com". And what's wrong with that example? RFC 5280 lists RFC 4514 as informative reference which I read as DNs are in examples are . Ciao, Michael. From peter.sylvester@edelweb.fr Mon Jun 21 01:56:37 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88DAC3A6A42 for ; Mon, 21 Jun 2010 01:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_50=0.001, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGIbS2pMKaSB for ; Mon, 21 Jun 2010 01:56:36 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 96FE63A685F for ; Mon, 21 Jun 2010 01:56:36 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 7AFC1DA for ; Mon, 21 Jun 2010 10:56:42 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 4ECB317180 for ; Mon, 21 Jun 2010 10:56:42 +0200 (CEST) Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 0A81D77D8 for ; Mon, 21 Jun 2010 10:56:41 +0200 (CEST) Message-ID: <4C1F2947.9080001@edelweb.fr> Date: Mon, 21 Jun 2010 10:56:39 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1F226F.1010408@stroeder.com> In-Reply-To: <4C1F226F.1010408@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 08:56:37 -0000 On 06/21/2010 10:27 AM, Michael Str=F6der wrote: > Paul Hoffman wrote: > =20 >> particularly because all of the text examples in RFC 5280 say >> "dc=3Dexample,dc=3Dcom". >> =20 > And what's wrong with that example? > RFC 5280 lists RFC 4514 as informative reference which I read as DNs ar= e in > examples are . > =20 The citation is taken out of context, all examples also include cn like i= n: Appendix C.1 contains an annotated hex dump of a "self-signed" certificate issued by a CA whose distinguished name is cn=3DExample CA,dc=3Dexample,dc=3Dcom and they reference ldap in all parts except appendix C.1 In C.1 one can read the encoding of that textual representation. 31 67: SEQUENCE { 33 19: SET { 35 17: SEQUENCE { 37 10: OBJECT IDENTIFIER : domainComponent (0 9 2342 19200300 100 1 25) 49 3: IA5String 'com' : } : } 54 23: SET { 56 21: SEQUENCE { 58 10: OBJECT IDENTIFIER : domainComponent (0 9 2342 19200300 100 1 25) 70 7: IA5String 'example' : } : } 79 19: SET { 81 17: SEQUENCE { 83 3: OBJECT IDENTIFIER commonName (2 5 4 3) 88 10: PrintableString 'Example CA' : } : } : } /PS From peter.sylvester@edelweb.fr Mon Jun 21 02:39:35 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CCB3A685A for ; Mon, 21 Jun 2010 02:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.02 X-Spam-Level: X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9TJbkKg6+XW for ; Mon, 21 Jun 2010 02:39:31 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 9C1293A6A4F for ; Mon, 21 Jun 2010 02:39:29 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id A59787F for ; Mon, 21 Jun 2010 11:39:34 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id A6EA817184 for ; Mon, 21 Jun 2010 11:39:34 +0200 (CEST) Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 65E6A77D8 for ; Mon, 21 Jun 2010 11:39:34 +0200 (CEST) Message-ID: <4C1F3352.6080602@edelweb.fr> Date: Mon, 21 Jun 2010 11:39:30 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1F226F.1010408@stroeder.com> <4C1F2947.9080001@edelweb.fr> In-Reply-To: <4C1F2947.9080001@edelweb.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [certid] CN-ID in version 6 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 09:39:35 -0000 2.2 says 5. The certificate SHOULD NOT represent the server's fully-qualified DNS domain name in a Relative Distinguished Name (RDN) of type Common Name (CN) (see [LDAP-SCHEMA]), even though we recognize that many deployed clients still check for this legacy identifier configuration within certificate subjectName. However, if this legacy identifer configuration is employed, then the server's fully-qualified DNS domain name MUST be placed in the last (most specific) RDN within the RDN sequence making up the certificate's subjectName, as the order of RDNs is determined by the DER- encoded Name within the server's PKIX certificate. Furthermore, the certificate's subject Distinguished Name SHOULD NOT contain more than one Common Name attribute, and MUST NOT contain RDNs which consist of multiple Common Name attributes. The second half is aprt of a redefintion of CN-ID * CN-ID = a Relative Distinguished Name (RDN) in the certificate subject that contains one and only one attribute value assertion (AVA) whose attribute type is Common Name (CN) I think one should say exactly the opposite: 5. The certificate SHOULD represent the server's fully-qualified DNS domain name in exactly one CN-ID as the last RDN in the subject DN. The subject DN SHOULD NOT have more than one CN ava. And in the following 6. The certificate SHOULD NOT represent the server's fully-qualified DNS domain name by means of a DC-ID, i.e., a series of Domain Component (DC) attributes in the certificate subject, with one RDN per domain label and one DC in each RDN. Although (for example) could be used to represent the DNS domain name "www.example.com", given the fact that the DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED. There is no reason to reference DNS-ID here. 6. If present in a DN, a sequence of DCs SHOULD be a DC-ID. Peter From paul.hoffman@vpnc.org Mon Jun 21 08:15:37 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382273A68B3 for ; Mon, 21 Jun 2010 08:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.952 X-Spam-Level: X-Spam-Status: No, score=0.952 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcOi3EgeMTt1 for ; Mon, 21 Jun 2010 08:15:26 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 90A7E3A692D for ; Mon, 21 Jun 2010 08:15:05 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5LFF6GY014518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 08:15:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1F2947.9080001@edelweb.fr> References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1F226F.1010408@stroeder.com> <4C1F2947.9080001@edelweb.fr> Date: Mon, 21 Jun 2010 08:15:04 -0700 To: Peter Sylvester , certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 15:15:37 -0000 At 10:56 AM +0200 6/21/10, Peter Sylvester wrote: >On 06/21/2010 10:27 AM, Michael Ströder wrote: >>Paul Hoffman wrote: >> >>>particularly because all of the text examples in RFC 5280 say >>>"dc=example,dc=com". >>> >>And what's wrong with that example? >>RFC 5280 lists RFC 4514 as informative reference which I read as DNs are in >>examples are . >> >The citation is taken out of context, all examples also include cn like in: > >Appendix C.1 contains an annotated hex dump of a "self-signed" > certificate issued by a CA whose distinguished name is > cn=Example CA,dc=example,dc=com > >and they reference ldap in all parts except appendix C.1 >In C.1 one can read the encoding of that textual representation. > > 31 67: SEQUENCE { > 33 19: SET { > 35 17: SEQUENCE { > 37 10: OBJECT IDENTIFIER > : domainComponent (0 9 2342 19200300 100 1 25) > 49 3: IA5String 'com' > : } > : } > 54 23: SET { > 56 21: SEQUENCE { > 58 10: OBJECT IDENTIFIER > : domainComponent (0 9 2342 19200300 100 1 25) > 70 7: IA5String 'example' > : } > : } > 79 19: SET { > 81 17: SEQUENCE { > 83 3: OBJECT IDENTIFIER commonName (2 5 4 3) > 88 10: PrintableString 'Example CA' > : } > : } > : } Exactly. Someone reading the *text* of RFC 5280 would see the components in left-to-right order; only those who read the non-normative dumps would see that they actually appear in the certificate in the correct right-to-left order. No one would ever make the mistake of only reading the normative text, of course... --Paul Hoffman, Director --VPN Consortium From peter.sylvester@edelweb.fr Mon Jun 21 10:12:51 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE01828C0FF for ; Mon, 21 Jun 2010 10:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_20=-0.74, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39BVmoIJW75M for ; Mon, 21 Jun 2010 10:12:50 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id C79B73A6AA6 for ; Mon, 21 Jun 2010 10:12:49 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 3A15197; Mon, 21 Jun 2010 19:12:53 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 34B0517048; Mon, 21 Jun 2010 19:12:53 +0200 (CEST) Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 0AB1877D8; Mon, 21 Jun 2010 19:12:53 +0200 (CEST) Message-ID: <4C1F9D94.8000304@edelweb.fr> Date: Mon, 21 Jun 2010 19:12:52 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1F226F.1010408@stroeder.com> <4C1F2947.9080001@edelweb.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 17:12:51 -0000 > Exactly. Someone reading the *text* of RFC 5280 would see the components in left-to-right order; only those who read the non-normative dumps would see that they actually appear in the certificate in the correct right-to-left order. > Yes. > No one would ever make the mistake of only reading the normative text, of course... > Or write RFCs with ambiguous normative part which cannot be understood with the non-normative part. :-) > --Paul Hoffman, Director > --VPN Consortium > As I said in a previous message, the pb also occurs in a string form like cn=Paul, O=VPN Consortium I think one might want enhance the normative part of RFC 5280: The Name describes a hierarchical name composed of attributes, such as country name, and corresponding values, such as US. The type of the component AttributeValue is determined by the AttributeType; in general it will be a DirectoryString. without other texts of X5xx this is also ambiguous. It doesn't say how the hierarchy is encoded, etc for name constraints, what is a subtree (prefix or suffix)? I may have overlooked something? have fun From paul.hoffman@vpnc.org Mon Jun 21 10:25:15 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8AB3A68C1 for ; Mon, 21 Jun 2010 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.258 X-Spam-Level: * X-Spam-Status: No, score=1.258 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXIG4JUcsmMk for ; Mon, 21 Jun 2010 10:25:14 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 380D63A6805 for ; Mon, 21 Jun 2010 10:25:14 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5LHPICs022178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 10:25:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1F9D94.8000304@edelweb.fr> References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1F226F.1010408@stroeder.com> <4C1F2947.9080001@edelweb.fr> <4C1F9D94.8000304@edelweb.fr> Date: Mon, 21 Jun 2010 10:25:16 -0700 To: Peter Sylvester From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: certid@ietf.org Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 17:25:15 -0000 At 7:12 PM +0200 6/21/10, Peter Sylvester wrote: >>Exactly. Someone reading the *text* of RFC 5280 would see the components in left-to-right order; only those who read the non-normative dumps would see that they actually appear in the certificate in the correct right-to-left order. >> >Yes. >>No one would ever make the mistake of only reading the normative text, of course... >> >Or write RFCs with ambiguous normative part which cannot be understood >with the non-normative part. :-) >>--Paul Hoffman, Director >>--VPN Consortium >> >As I said in a previous message, the pb also occurs in a string form >like cn=Paul, O=VPN Consortium Quite true. >I think one might want enhance the normative part of RFC 5280: > > The Name describes a hierarchical name composed of attributes, such > as country name, and corresponding values, such as US. The type of > the component AttributeValue is determined by the AttributeType; in > general it will be a DirectoryString. > >without other texts of X5xx this is also ambiguous. It doesn't say >how the hierarchy is encoded, etc for name constraints, what >is a subtree (prefix or suffix)? I may have overlooked something? You have overlooked the fact that this effort is to create a new document, not to update RFC 5280, which the PKIX group insists is readable enough. I am well-known for disagreeing, and that is why I think that this new document allowing constructs that are known security problems is a bad idea. --Paul Hoffman, Director --VPN Consortium From michael@stroeder.com Mon Jun 21 10:52:52 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7CF83A6AAA for ; Mon, 21 Jun 2010 10:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcZYlpV45g3m for ; Mon, 21 Jun 2010 10:52:52 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id DEAB13A6805 for ; Mon, 21 Jun 2010 10:52:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id A387A4E104; Mon, 21 Jun 2010 19:52:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unUh6uBcMyAh; Mon, 21 Jun 2010 19:52:51 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 6095B4E103; Mon, 21 Jun 2010 19:52:49 +0200 (CEST) Message-ID: <4C1FA6F0.1040001@stroeder.com> Date: Mon, 21 Jun 2010 19:52:48 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 17:52:52 -0000 Paul Hoffman wrote: > At 4:42 PM +0200 6/19/10, Michael Ströder wrote: >> Alexey Melnikov wrote: >>> Paul Hoffman wrote: >>>> No, I'm saying that the order in which you are supposed to take the >>>> DCs has historically been unclear. "Most significant" means different >>>> things to different people. >>>> >>> I probably sound like a broken record, but the order is very clear for >>> LDAP. I don't see why is this going to be different for X.509 certificates. >> >> Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500 >> names as well. > > ...and you think that all (or even typical) PKIX implementers read either > of those documents? Some of them do. If you dig in mailing list archives you will find that I know enough about deficiencies of real-world software. And I tracked down quite a few bugs in software of "major" PKI vendors some of them related to DN (string) handling. But what does that tell us? To give up writing or referencing RFCs? Ciao, Michael. From phoffman@imc.org Mon Jun 21 11:10:52 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1425A28C129 for ; Mon, 21 Jun 2010 11:10:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F6 hex): To: Michael Str\366der ; Mon, 21 Jun 2010 11:10:51 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 01D4628C134 for ; Mon, 21 Jun 2010 11:10:46 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5LIAnNT024716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 11:10:52 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C1FA6F0.1040001@stroeder.com> References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> <4C1FA6F0.1040001@stroeder.com> Date: Mon, 21 Jun 2010 11:10:47 -0700 To: Michael Ströder From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 18:10:52 -0000 At 7:52 PM +0200 6/21/10, Michael Ströder wrote: >Paul Hoffman wrote: >> At 4:42 PM +0200 6/19/10, Michael Ströder wrote: >>> Alexey Melnikov wrote: >>>> Paul Hoffman wrote: >>>>> No, I'm saying that the order in which you are supposed to take the >>>>> DCs has historically been unclear. "Most significant" means different >>>>> things to different people. >>>>> >>>> I probably sound like a broken record, but the order is very clear for >>>> LDAP. I don't see why is this going to be different for X.509 certificates. >>> >>> Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500 >>> names as well. >> >> ...and you think that all (or even typical) PKIX implementers read either >> of those documents? > >Some of them do. > >If you dig in mailing list archives you will find that I know enough about >deficiencies of real-world software. And I tracked down quite a few bugs in >software of "major" PKI vendors some of them related to DN (string) handling. > >But what does that tell us? To give up writing or referencing RFCs? It tells us that, when there are multiple ways to do things, and some of those ways are known to be insecure due to repeated poor implementations, we can say "don't do that" for the bad ways. From peter.sylvester@edelweb.fr Mon Jun 21 11:16:03 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201EC3A6AB7 for ; Mon, 21 Jun 2010 11:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.644 X-Spam-Level: X-Spam-Status: No, score=0.644 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJGej7BiQ0kH for ; Mon, 21 Jun 2010 11:15:36 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 766283A6A8D for ; Mon, 21 Jun 2010 11:15:30 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id A872997; Mon, 21 Jun 2010 20:15:36 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 967A317061; Mon, 21 Jun 2010 20:15:36 +0200 (CEST) Received: from [192.168.0.21] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 17AD677D8; Mon, 21 Jun 2010 20:15:34 +0200 (CEST) Message-ID: <4C1FAC2D.5000609@edelweb.fr> Date: Mon, 21 Jun 2010 20:15:09 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1F226F.1010408@stroeder.com> <4C1F2947.9080001@edelweb.fr> <4C1F9D94.8000304@edelweb.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 18:16:05 -0000 >> As I said in a previous message, the pb also occurs in a string form >> like cn=Paul, O=VPN Consortium >> > Quite true. > > >> I think one might want enhance the normative part of RFC 5280: >> >> The Name describes a hierarchical name composed of attributes, such >> as country name, and corresponding values, such as US. The type of >> the component AttributeValue is determined by the AttributeType; in >> general it will be a DirectoryString. >> >> without other texts of X5xx this is also ambiguous. It doesn't say >> how the hierarchy is encoded, etc for name constraints, what >> is a subtree (prefix or suffix)? I may have overlooked something? >> > You have overlooked the fact that this effort is to create a new document, not to update RFC 5280, which the PKIX group insists is readable enough. I am well-known for disagreeing, and that is why I think that this new document allowing constructs that are known security problems is a bad idea. > I didn't not overlook that this effort is to create a new doc. With what authority do you say that what the PKIX group "insists"? Indeed, it might be that you have a server "net.com" and another "com.net" ah well, the real problem is between Serbia and the UK computer science departments. Fortunately we have no top level domain www. I am not saying at all that one should allow an http client to accept DCs if neither DNS-ID is not present (and no CN-ID). Rather the contrary. The new document is destined to CAs that fill DNs, and for RPs that think about it. If both are reminded about the order defined by the X.500 base standards, this is an enhancement. Talking about DCs does not allow anything new that isn't allowed today. If this text "prohibits" the use of DCs in DNs, then RFC 5280 becomes somewhat funny because it uses them as examples. Would an answer to Alexey be: DCs MUST not be used since RFC 5280 does not define the order of the encoding of the hierarchy in the normative part of the text. ??? BTW: Should one speak about jurisdiction and country of jurisdiction attributes? From michael@stroeder.com Mon Jun 21 14:02:06 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6ECF3A6863 for ; Mon, 21 Jun 2010 14:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.278 X-Spam-Level: X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-beEXNSsgWE for ; Mon, 21 Jun 2010 14:02:06 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id E50803A684E for ; Mon, 21 Jun 2010 14:02:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id D02DF4E078; Mon, 21 Jun 2010 23:02:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udWNygZsQoqO; Mon, 21 Jun 2010 23:02:09 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 461F14E072; Mon, 21 Jun 2010 23:02:08 +0200 (CEST) Message-ID: <4C1FD34F.90004@stroeder.com> Date: Mon, 21 Jun 2010 23:02:07 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 To: Paul Hoffman References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> <4C1FA6F0.1040001@stroeder.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 21:02:06 -0000 Paul Hoffman wrote: > It tells us that, when there are multiple ways to do things, and some of > those ways are known to be insecure due to repeated poor implementations, > we can say "don't do that" for the bad ways. That's fine for me too. Ciao, Michael. From michael@stroeder.com Mon Jun 21 14:04:12 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F923A67A7 for ; Mon, 21 Jun 2010 14:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[AWL=-0.794, BAYES_40=-0.185, MIME_8BIT_HEADER=0.3, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tM0wFAv+fMf for ; Mon, 21 Jun 2010 14:04:10 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by core3.amsl.com (Postfix) with ESMTP id 382A93A684E for ; Mon, 21 Jun 2010 14:04:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 575CA4E079; Mon, 21 Jun 2010 23:04:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFvnne9qzEZl; Mon, 21 Jun 2010 23:04:14 +0200 (CEST) Received: from [10.1.0.2] (unknown [10.1.0.2]) by srv1.stroeder.com (Postfix) with ESMTP id 029804E072; Mon, 21 Jun 2010 23:04:13 +0200 (CEST) Message-ID: <4C1FD3CD.8090009@stroeder.com> Date: Mon, 21 Jun 2010 23:04:13 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100504 Lightning/1.0b1 SeaMonkey/2.0.5 MIME-Version: 1.0 References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> <4C1FA6F0.1040001@stroeder.com> <4C1FD34F.90004@stroeder.com> In-Reply-To: <4C1FD34F.90004@stroeder.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Paul Hoffman , IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 21:04:13 -0000 Michael Ströder wrote: > Paul Hoffman wrote: >> It tells us that, when there are multiple ways to do things, and some of >> those ways are known to be insecure due to repeated poor implementations, >> we can say "don't do that" for the bad ways. > > That's fine for me too. But to make that more clear in this context: The draft should not discourage completely using DCs in the subject-DN. It should only recommend not to encode the server's hostname in the DCs. Ciao, Michael. From Bruno.Harbulot@manchester.ac.uk Mon Jun 21 15:19:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA70E3A68B1 for ; Mon, 21 Jun 2010 15:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=2.021, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELYbkRFkQrc0 for ; Mon, 21 Jun 2010 15:19:38 -0700 (PDT) Received: from clarity.mcc.ac.uk (clarity.mcc.ac.uk [130.88.200.144]) by core3.amsl.com (Postfix) with ESMTP id B1D613A67C2 for ; Mon, 21 Jun 2010 15:19:38 -0700 (PDT) Received: from kelvin.its.manchester.ac.uk ([130.88.25.195]) by clarity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OQpLC-0003lF-Uh; Mon, 21 Jun 2010 23:19:43 +0100 Received: from 94-192-243-24.zone6.bethere.co.uk ([94.192.243.24]:52501 helo=mymachine) by kelvin.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OQpLC-0001dA-1b; Mon, 21 Jun 2010 23:19:42 +0100 Message-ID: <4C1FE579.5030403@manchester.ac.uk> Date: Mon, 21 Jun 2010 23:19:37 +0100 From: Bruno Harbulot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Michael_Str=F6der?= References: <4C12A27D.3070308@stpeter.im> <4C1CA2B8.9080103@isode.com> <4C1CD30B.4090200@isode.com> <4C1CD73B.6000602@stroeder.com> <4C1FA6F0.1040001@stroeder.com> <4C1FD34F.90004@stroeder.com> <4C1FD3CD.8090009@stroeder.com> In-Reply-To: <4C1FD3CD.8090009@stroeder.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Authenticated-Sender: Bruno Harbulot from 94-192-243-24.zone6.bethere.co.uk (mymachine) [94.192.243.24]:52501 X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk Cc: Paul Hoffman , IETF cert-based identity Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:19:39 -0000 On 21/06/2010 22:04, Michael Ströder wrote: > Michael Ströder wrote: >> Paul Hoffman wrote: >>> It tells us that, when there are multiple ways to do things, and some of >>> those ways are known to be insecure due to repeated poor implementations, >>> we can say "don't do that" for the bad ways. >> >> That's fine for me too. > > But to make that more clear in this context: The draft should not discourage > completely using DCs in the subject-DN. It should only recommend not to encode > the server's hostname in the DCs. I think the problem with that approach is the same as the use of the word "represent" in a couple of paragraphs (as mentioned earlier on this list): if you get some DCs (or CN for that matter), how do you know whether or not they were meant to "represent" the hostname or something else? If DCs are to be used in some but not all cases to convey the hostname to check against, then there either needs a way to disambiguate which case is which. In my opinion, I would split this in two cases: - If there is a subject alt. name.: the Subject DN can be more or less ignored (it would just be a convenience). - If there isn't: the expectations on the DCs (or CN) in the Subject DN have to be strict (i.e. a MUST). If we get something like "SHOULD NOT encode the server hostname in the DCs", then the door is open to ambiguity, and I think that's where the problems will come for determining whether or not the certificate matches the server. (I think that would also be compatible with the existing implementations of RFC 2818.) Best wishes, Bruno. From stpeter@stpeter.im Mon Jun 21 19:42:58 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8883A67FE for ; Mon, 21 Jun 2010 19:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlYVL-ZwO2YJ for ; Mon, 21 Jun 2010 19:42:57 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 31E793A67FC for ; Mon, 21 Jun 2010 19:42:57 -0700 (PDT) Received: from squire.local (dsl-175-202.dynamic-dsl.frii.net [216.17.175.202]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F7EC40E5E for ; Mon, 21 Jun 2010 20:43:03 -0600 (MDT) Message-ID: <4C202337.8050309@stpeter.im> Date: Mon, 21 Jun 2010 20:43:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060809060702040807020008" Subject: [certid] Fwd: Re: [xmpp] #73: client caching of server certificates X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 02:42:58 -0000 This is a cryptographically signed message in MIME format. --------------ms060809060702040807020008 Content-Type: multipart/mixed; boundary="------------050002040708030500080909" This is a multi-part message in MIME format. --------------050002040708030500080909 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FYI from relevant WGLC discussion of draft-ietf-xmpp-3920bis... -------- Original Message -------- Subject: Re: [xmpp] #73: client caching of server certificates Date: Mon, 21 Jun 2010 20:41:16 -0600 From: Peter Saint-Andre To: xmpp@ietf.org On 6/21/10 8:37 PM, xmpp issue tracker wrote: > #73: client caching of server certificates > --------------------------------+--------------------------------------= ----- > Reporter: stpeter@=E2=80=A6 | Owner: stpeter@=E2=80=A6= =20 > Type: defect | Status: new =20 > Priority: minor | Milestone: =20 > Component: 3920bis | Version: =20 > Severity: In WG Last Call | Keywords: =20 > --------------------------------+--------------------------------------= ----- > Section 13.7.2.1.1 states in part: >=20 > > ... if a user permanently accepts a certificate in this > > way, the client MUST cache the certificate (or some > > non-forgeable representation such as a hash value) and > > in future connection attempts behave as in Sub-Case #3. >=20 > Ben Campbell commented: "Should we require a mechanism to allow users = to > revoke trust for such caches certs?" Probably, although I think that's more properly a matter to be addressed in draft-saintandre-tls-server-id-check. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------050002040708030500080909 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG1wcCBt YWlsaW5nIGxpc3QKeG1wcEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3htcHAKCg== --------------050002040708030500080909-- --------------ms060809060702040807020008 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyMjAyNDMwM1owIwYJKoZIhvcNAQkEMRYEFPHRZzax7fZ3oTS/IkcT htqalOqIMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhG5V0E0eEukwzp245b6Eiqzw3JsJYzxhkO/5AUN7 r5+XkSk1CWg8qtTKtZwL+/9tRFE0CrSUNl4TO7QrSWtVflMckR+Dx2x/PbyzqxxbrCsxz0+J NO2V3YiitecKW7CiENQF2BCABG9TRr9e7GimaF0EPtYSpbe+QAHwI8ECqjWmvOH4dlbbxS2T Po1pjUTyYAor7outsQPF8nLDGYl/zECoFn7liaSq1rO9xGZHfOe34in7lHnRxt/7PXNUNPCb 6weubwFkj17LU4l2gPAhW0yXSLs/lyXAmgBwRAr71i4xaT+2irI3CxSPdo1Y7Q1pRjvyDliU JUxeDS/yvJV1PwAAAAAAAA== --------------ms060809060702040807020008-- From stpeter@stpeter.im Mon Jun 21 19:43:22 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DC33A6846 for ; Mon, 21 Jun 2010 19:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMLLAgl7AVjv for ; Mon, 21 Jun 2010 19:43:21 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0D8AE3A67D0 for ; Mon, 21 Jun 2010 19:43:21 -0700 (PDT) Received: from squire.local (dsl-175-202.dynamic-dsl.frii.net [216.17.175.202]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D138040E5E for ; Mon, 21 Jun 2010 20:43:27 -0600 (MDT) Message-ID: <4C20234F.2070201@stpeter.im> Date: Mon, 21 Jun 2010 20:43:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010300060508010706090402" Subject: [certid] Fwd: Re: [xmpp] #74: user acceptance of non-matching presented identities X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 02:43:22 -0000 This is a cryptographically signed message in MIME format. --------------ms010300060508010706090402 Content-Type: multipart/mixed; boundary="------------020807040505080806050205" This is a multi-part message in MIME format. --------------020807040505080806050205 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Another forward from ongoing XMPP discussion... /psa -------- Original Message -------- Subject: Re: [xmpp] #74: user acceptance of non-matching presented identities Date: Mon, 21 Jun 2010 20:42:07 -0600 From: Peter Saint-Andre To: xmpp@ietf.org On 6/21/10 8:40 PM, xmpp issue tracker wrote: > #74: user acceptance of non-matching presented identities > --------------------------------+--------------------------------------= ----- > Reporter: stpeter@=E2=80=A6 | Owner: stpeter@=E2=80=A6= =20 > Type: defect | Status: new =20 > Priority: minor | Milestone: =20 > Component: 3920bis | Version: =20 > Severity: In WG Last Call | Keywords: =20 > --------------------------------+--------------------------------------= ----- > Section 13.7.2.1.1 states in part: >=20 > > Sub-Case #3: The server's certificate includes no presented > > identity that matches the reference identity to which the > > entity attempted to connect but a human user has permanently > > accepted the certificate during a previous connection attempt; >=20 > Ben Campbell commented: "This needs to be associated with the identity= the > use was trying to reach when she accepted the cert in the first place,= > right? That is, if some other server offers the same cert, it's not > automatically accepted, right?" Correct. This should be covered in draft-saintandre-tls-server-id-check (but I don't think it is currently, so I'll forward this message to the certid@ietf.org list). Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------020807040505080806050205 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KeG1wcCBt YWlsaW5nIGxpc3QKeG1wcEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3htcHAKCg== --------------020807040505080806050205-- --------------ms010300060508010706090402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyMjAyNDMyN1owIwYJKoZIhvcNAQkEMRYEFL7SVtH7VBN4ItdjWLin g51pTFVYMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAcHSFNrJdu6J+agNnxtzBxDXvemD0GiKT87edrDKU 37+PW66eerj9t1cZD9DvMAhxCMQnyFIMQqVJZn+NSwkN9ODaawRHcyCDf2Bwp6Ozd5xfWga9 dc8nZW8p99sMRxXI0lFAsVivmRwSqgyhq0yN2cEJIXGBXHAyHIqrh+9mKCRXfcFaiucEwlTd wK6l91dFvoMcroqooRW+cldqPXLvQ5Z3WbwXs9M0QnNluQZZRj6E3DZ7YvQON52gQm6yqVay 2dIrY0NNSu5nzv37NjdRDmw0jbWnndNHkRmitWajGM5nRAolYvB6N78wegNF+m4po9Ue6luK PuC7t7WOdXKh5QAAAAAAAA== --------------ms010300060508010706090402-- From mrex@sap.com Tue Jun 22 14:31:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 520DF28C108 for ; Tue, 22 Jun 2010 14:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_40=-0.185, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gieqzCsognCa for ; Tue, 22 Jun 2010 14:31:33 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 7CD3F28C10D for ; Tue, 22 Jun 2010 14:31:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5MLVaEY017357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Jun 2010 23:31:36 +0200 (MEST) From: Martin Rex Message-Id: <201006222131.o5MLVZk9026823@fs4113.wdf.sap.corp> To: michael@stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Tue, 22 Jun 2010 23:31:35 +0200 (MEST) In-Reply-To: <4C1FA6F0.1040001@stroeder.com> from "=?ISO-8859-1?Q?Michael_Str=F6der?=" at Jun 21, 10 07:52:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: phoffman@imc.org, certid@ietf.org Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:31:39 -0000 =?ISO-8859-1?Q?Michael_Str=F6der?= wrote: > > Paul Hoffman wrote: > > At 4:42 PM +0200 6/19/10, Michael Ströder wrote: > >> Alexey Melnikov wrote: > >>> Paul Hoffman wrote: > >>>> No, I'm saying that the order in which you are supposed to take the > >>>> DCs has historically been unclear. "Most significant" means different > >>>> things to different people. > >>>> > >>> I probably sound like a broken record, but the order is very clear for > >>> LDAP. I don't see why is this going to be different for X.509 certificates. > >> > >> Yes, I concur RFC 2247 is pretty clear and is meant to be applied to X.500 > >> names as well. > > > > ...and you think that all (or even typical) PKIX implementers read either > > of those documents? > > Some of them do. > > If you dig in mailing list archives you will find that I know enough about > deficiencies of real-world software. And I tracked down quite a few bugs in > software of "major" PKI vendors some of them related to DN (string) handling. > > But what does that tell us? To give up writing or referencing RFCs? Since the document under discussion is supposed to become a "Best current practice" document, I'm really wondering which of the existing implementations actually implement server endpoint matching based on DC components of a certificate subject name? I would assume that matching to more than one CN= might be more common than DC matching. -Martin From mrex@sap.com Tue Jun 22 18:02:45 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6385B3A680F for ; Tue, 22 Jun 2010 18:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.902 X-Spam-Level: X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWGsAO2rM+EY for ; Tue, 22 Jun 2010 18:02:44 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 866673A67EA for ; Tue, 22 Jun 2010 18:02:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5N12jcE013881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jun 2010 03:02:45 +0200 (MEST) From: Martin Rex Message-Id: <201006230102.o5N12hwP011034@fs4113.wdf.sap.corp> To: michael@stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Wed, 23 Jun 2010 03:02:43 +0200 (MEST) In-Reply-To: <4C1FD3CD.8090009@stroeder.com> from "=?ISO-8859-1?Q?Michael_Str=F6der?=" at Jun 21, 10 11:04:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: phoffman@imc.org, certid@ietf.org Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 01:02:45 -0000 =?ISO-8859-1?Q?Michael_Str=F6der?= wrote: > > Michael Ströder wrote: > > Paul Hoffman wrote: > >> It tells us that, when there are multiple ways to do things, and some of > >> those ways are known to be insecure due to repeated poor implementations, > >> we can say "don't do that" for the bad ways. > > > > That's fine for me too. > > But to make that more clear in this context: The draft should not discourage > completely using DCs in the subject-DN. It should only recommend not to encode > the server's hostname in the DCs. Nope. It is important to strongly recommend to clients to _NOT_ check the server endpoint identity based on DC components, that is the important issue. There is no known sensible, consistent and reasonably safe interpretation of DC name components as the hostname for a server endpoint. No implementation that doesn't have such code should add it, and existing implementations with such code should think about removing it or disabling it by default. -Martin From peter.sylvester@edelweb.fr Tue Jun 22 21:52:46 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B87C3A6A3B for ; Tue, 22 Jun 2010 21:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdSxIJ7gm4gN for ; Tue, 22 Jun 2010 21:52:45 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 392B43A6A3A for ; Tue, 22 Jun 2010 21:52:45 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 5E711106 for ; Wed, 23 Jun 2010 06:52:52 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 2DEEC17048 for ; Wed, 23 Jun 2010 06:52:52 +0200 (CEST) Received: from [192.168.0.20] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 2F3AD782B for ; Wed, 23 Jun 2010 06:52:45 +0200 (CEST) Message-ID: <4C219303.8000307@edelweb.fr> Date: Wed, 23 Jun 2010 06:52:19 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <201006230102.o5N12hwP011034@fs4113.wdf.sap.corp> In-Reply-To: <201006230102.o5N12hwP011034@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 04:52:46 -0000 On 06/23/2010 03:02 AM, Martin Rex wrote: > =3D?ISO-8859-1?Q?Michael_Str=3DF6der?=3D wrote: > =20 >> Michael Str=F6der wrote: >> =20 >>> Paul Hoffman wrote: >>> =20 >>>> It tells us that, when there are multiple ways to do things, and som= e of >>>> those ways are known to be insecure due to repeated poor implementat= ions, >>>> we can say "don't do that" for the bad ways. >>>> =20 >>> That's fine for me too. >>> =20 >> But to make that more clear in this context: The draft should not disc= ourage >> completely using DCs in the subject-DN. It should only recommend not t= o encode >> the server's hostname in the DCs. >> =20 > Nope. It is important to strongly recommend to clients to _NOT_ > check the server endpoint identity based on DC components, that is > the important issue. There is no known sensible, consistent > and reasonably safe interpretation of DC name components > as the hostname for a server endpoint. > =20 encoding and checking are two different things. There are two subchapters. It is not incoherent IMO to recommend encode a domain if and only if DCs are used at all, and "discourage" checking in all cases. > No implementation that doesn't have such code should add it, > =20 At least 'No one is required neither must be forced to add.' is there any application that requires checking? > and existing implementations with such code should think about > removing it or disabling it by default. > =20 Implementations don't think, well, hm, for implementors the situation might be less clear. Implementation details are out of scope anyway From alexey.melnikov@isode.com Wed Jun 23 12:02:42 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078EA3A6908 for ; Wed, 23 Jun 2010 12:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ8bgzG7deZp for ; Wed, 23 Jun 2010 12:02:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id D0FEE3A6AF7 for ; Wed, 23 Jun 2010 12:02:34 -0700 (PDT) Received: from [172.16.2.161] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 23 Jun 2010 20:02:41 +0100 Message-ID: <4C225A1B.4070806@isode.com> Date: Wed, 23 Jun 2010 20:01:47 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: <4C1CABA1.2050205@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:02:42 -0000 Hi Paul, Paul Hoffman wrote: >At 12:36 PM +0100 6/19/10, Alexey Melnikov wrote: > > >>Hi Paul, >> >>Paul Hoffman wrote: >> >> >>> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >>> identifier of type dNSName). >>> >>> 2. If the service using the certificate deploys a technology in >>> which a server is discovered by means of DNS SRV records >>> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate >>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form >>> of otherName from the GeneralName structure in the subjectAltName >>> as specified in [SRVNAME]). >>> >>>If 2 is true, what is the value of the required DNS-ID? >>> >>One or more hostname for machines that would provide the specified service. I.e. most likely some/all hostnames from the output of DNS SRV lookup, but I can think of some examples where other hostnames can be used in addition to or instead of these. E.g. a machine on internal network, hostname of a NAT box, etc. >> >So a cert says "the hostname of this server is www.example.com, and you can look up the hostname for the server using SRV"? What does that mean in a security context? > This is a good question and it took me some time to gather thoughts on how to reply to it. >If I get back one name of yyy.example.com, does that mean that the host has both names, or that there was a lookup error? > > In general it can be either, or neither. I don't think one can draw any conclusion. Let me try to do a more detailed explanation on how this is supposed to work (at least with the current version of the document): Let's say we have a certificate with (I might be getting the syntax wrong, but you should get the idea of what I mean) dNSName: imap.example.com sRVName: _imap._tcp.example.com I've change www.example.com to imap.isode.com, as there is now a specification about how to use DNS SRV for locating IMAP servers. But the idea applies to other services. So the document says that a client using DNS SRV must check sRVName first. Only if sRVName is not found, then it can check the dNSName. So a client doing DNS SRV lookup for service "imap" for domain "example.com" wouldn't care if the returned hostname is imap.example.com or yyy.example.com. Another client which is explicitly configured with hostname will only check the dNSName value and will not check any sRVName values. There might be several reasons why DNS SRV might return something different from "imap.example.com": different hostnames used on internal and external networks (due to NATs), clustering, etc. So clients shouldn't automatically check if sRVName resolves to one or more of dNSName values specified in the same certificate. From mrex@sap.com Thu Jun 24 14:03:21 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16513A689E for ; Thu, 24 Jun 2010 14:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.915 X-Spam-Level: X-Spam-Status: No, score=-7.915 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFmgrzFOb+FU for ; Thu, 24 Jun 2010 14:03:21 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D80243A6836 for ; Thu, 24 Jun 2010 14:03:20 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5OL3QDc000753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jun 2010 23:03:26 +0200 (MEST) From: Martin Rex Message-Id: <201006242103.o5OL3PO6019652@fs4113.wdf.sap.corp> To: phoffman@imc.org (Paul Hoffman) Date: Thu, 24 Jun 2010 23:03:25 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Jun 19, 10 07:42:25 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Domain Components X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 21:03:21 -0000 Paul Hoffman wrote: > > If you feel that way, fine. We have historically seen deployed PKIX > implementations that got the order wrong because they had no certs > to test with. I do not hold it against someone to get the order wrong, > particularly because all of the text examples in RFC 5280 say > "dc=example,dc=com". You're right on the spot -- all of the DC= examples in rfc-5280 are purely about >>domain name<<. There is also a server mentioned "ldap.example.com", but there is not a single example in rfc-5280 that puts a >>hostname<< into a DC component. So why does draft-saintandre-tls-server-id-check-06 come up with the idea of performing a server endpoint identification against a DC that includes a hostname? Rfc-2818 never suggested this! -Martin From stpeter@stpeter.im Tue Jun 29 13:34:30 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284663A6930 for ; Tue, 29 Jun 2010 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZvYlsTH8ZbZ for ; Tue, 29 Jun 2010 13:34:26 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5B4733A6873 for ; Tue, 29 Jun 2010 13:34:26 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 51FE240E4D for ; Tue, 29 Jun 2010 14:34:36 -0600 (MDT) Message-ID: <4C2A58D8.50700@stpeter.im> Date: Tue, 29 Jun 2010 14:34:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C112371.3000104@bolyard.me> <201006101745.o5AHjn7N022071@fs4113.wdf.sap.corp> <025901cb08c6$248bf550$6da3dff0$@osu.edu> In-Reply-To: <025901cb08c6$248bf550$6da3dff0$@osu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040308040202010407060405" Subject: Re: [certid] Please explicitly disallow unvetted info in subject X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 20:34:30 -0000 This is a cryptographically signed message in MIME format. --------------ms040308040202010407060405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My apologies for the delay, I'm just catching up on list traffic here. On 6/10/10 11:55 AM, Scott Cantor wrote: > These are all good arguments (which I subscribe to) for why treating > commercial X.509 as a "successful" trust infrastructure that other iden= tity > standards should be leveraging in place of new approaches is a really, > really stupid idea. >=20 > But I don't think they're relevant to a document describing how one sho= uld > verify server identity against X.509 certificate content, particularly = with > respect to anything that isn't a CN RDN or a sAN. >=20 > By all means rail against the idiocy of this stuff, and I'll join in si= nce > there are still people pushing it constantly and belittling those who > disagree, but I don't think it needs to be part of this draft. Agreed. Once again, this draft is not the sole repository for all wisdom regarding certificates, TLS, Internet identifiers, and security protocols in general. I'd love to see more general specifications regarding those topics, but in this draft we're trying to boil just a small harbor, not the entire ocean. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040308040202010407060405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyOTIwMzQzMlowIwYJKoZIhvcNAQkEMRYEFEOUu12IuX69KzHMAuoU u9HRxiRPMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAL4y01SGTxNEbBoiFRw5cdREpw1Mq/a75HRdfLgEe tc0fDc8GRN/RuVJL9B+lGvaQbflAjP3uCdxFB8vkVCKjqhyzHLQ9W5dy5Q/z5hN+Tddnyp60 BTPAlkz9x5GTAjx3DTnLYXbLVk83U7nGx78Fhk/PULrZS5GKTT+tdDH+5aXvhBHCfTa1mlpM gM/XOIK23HopdSJ8sSGFzGKCl2z2iWMfrR3Lkz+hiWd0qB/yd1ebE5JyUIrz/dcwu5CkkF6V nKv37AUM4lWveLQoSMauaan9CdGaIVkJsLRAFsfEUdN6JdFwFVugBtNBEJtwfV96Zaekwjrc 23aWIPEEOYQC4wAAAAAAAA== --------------ms040308040202010407060405-- From stpeter@stpeter.im Tue Jun 29 14:29:17 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68B3F3A69E5 for ; Tue, 29 Jun 2010 14:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zakmQW4riVf1 for ; Tue, 29 Jun 2010 14:29:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3D7663A67F3 for ; Tue, 29 Jun 2010 14:29:16 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9495A40E4D for ; Tue, 29 Jun 2010 15:29:26 -0600 (MDT) Message-ID: <4C2A65B5.4080209@stpeter.im> Date: Tue, 29 Jun 2010 15:29:25 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <20100612013249.GA4782@isc.upenn.edu> In-Reply-To: <20100612013249.GA4782@isc.upenn.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002010403050803000801" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 21:29:17 -0000 This is a cryptographically signed message in MIME format. --------------ms030002010403050803000801 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/11/10 7:32 PM, Shumon Huque wrote: > On Fri, Jun 11, 2010 at 05:07:50PM -0700, Paul Hoffman wrote: >> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName= >> identifier of type dNSName). >> >> 2. If the service using the certificate deploys a technology in >> which a server is discovered by means of DNS SRV records >> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate >> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName fo= rm >> of otherName from the GeneralName structure in the subjectAltNa= me >> as specified in [SRVNAME]). >> >> If 2 is true, what is the value of the required DNS-ID? >=20 > I don't think (1) is correct. If someone intends to deploy a=20 > certificate with an application specific name form such as SRV-ID=20 > or URI-ID, then they typically would not want to have a dNSName=20 > in the certificate, to make sure that the cert can't be (mis)used=20 > for unrelated application services at that domain name.=20 >=20 > Of course one might decide to include dNSName too for transition > or backwards compatibility reasons. But I don't think that saying=20 > the certificate MUST include a dNSName is correct. Shumon, I think you are correct here, and that DNS-ID needs to be "SHOULD" instead of "MUST". Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030002010403050803000801 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyOTIxMjkyNVowIwYJKoZIhvcNAQkEMRYEFGsSDRR+4BHO97WA6Y/z x2ykANAUMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAVURLPlDrA0tARtfOKcGShM7M4DNbV38pOJMcYeLM 8WDjib1Xlo0Xq1f2Unf+jWjRRjMTvN5M6psUBRjjDVvhkFNjd56vW/bVSeMr0i/jhXQ5zKPN Uk6KC5aAFHgiNDs8Cf05rTdtdCjFl54TRo96B+Uk9Mrrb5QPvC1RQ6UaOYT2FTcOGCYztSzs k6i8fOi0gKrT0LWfNsxdJ2rzpsaMRiYGy66PnubyPM0owzc63NwR9q+4wScwgRhMTSLpg49K hZxuV2k6ghVSkCymKY98lWOCYOJIpHlArD4MJ68yCFdzwNKSDKfMa5y5OBi9Zrh2eaF17cTA GGGelDFMbZdt5AAAAAAAAA== --------------ms030002010403050803000801-- From stpeter@stpeter.im Tue Jun 29 14:49:31 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922B23A6C21 for ; Tue, 29 Jun 2010 14:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkZRriMSMU1g for ; Tue, 29 Jun 2010 14:49:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3801028C0D8 for ; Tue, 29 Jun 2010 14:49:30 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 942EF40E4D for ; Tue, 29 Jun 2010 15:49:40 -0600 (MDT) Message-ID: <4C2A6A72.5000109@stpeter.im> Date: Tue, 29 Jun 2010 15:49:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C1CABA1.2050205@isode.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010407070703070605090109" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 21:49:31 -0000 This is a cryptographically signed message in MIME format. --------------ms010407070703070605090109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/19/10 8:04 AM, Paul Hoffman wrote: > At 12:36 PM +0100 6/19/10, Alexey Melnikov wrote: >> Hi Paul, >>=20 >> Paul Hoffman wrote: >>=20 >>> 1. The certificate MUST include a "DNS-ID" (i.e., a >>> subjectAltName identifier of type dNSName). >>>=20 >>> 2. If the service using the certificate deploys a technology in=20 >>> which a server is discovered by means of DNS SRV records=20 >>> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate=20 >>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName >>> form of otherName from the GeneralName structure in the >>> subjectAltName as specified in [SRVNAME]). >>>=20 >>> If 2 is true, what is the value of the required DNS-ID? >>>=20 >> One or more hostname for machines that would provide the specified >> service. I.e. most likely some/all hostnames from the output of DNS >> SRV lookup, but I can think of some examples where other hostnames >> can be used in addition to or instead of these. E.g. a machine on >> internal network, hostname of a NAT box, etc. >=20 > So a cert says "the hostname of this server is www.example.com, and > you can look up the hostname for the server using SRV"? What does > that mean in a security context? If I get back one name of > yyy.example.com, does that mean that the host has both names, or that > there was a lookup error? My understanding of the SRVName extension is that it is primarily intended to restrict the use of a certificate to a particular application type (e.g., IMAP or XMPP). This is what Shumon meant when he said: If someone intends to deploy a certificate with an application specific name form such as SRV-ID or URI-ID, then they typically would not want to have a dNSName in the certificate, to make sure that the cert can't be (mis)used for unrelated application services at that domain name. However, DNS SRV records have the property of enabling you to redirect the source domain (e.g., example.com) to a target domain (e.g., apps.example.net) that is outside of the trust boundary of the source domain. Thus draft-daboo-srv-email says: A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially cause MUAs to connect to any IMAP, POP3 or submission server chosen by the attacker. In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host. During recent discussions within the XMPP WG, we decided that we didn't need text along those lines because a malicious attacker with access to the DNS server data could simply return an evil IP address in a DNS result, so why bother the user with scary warnings about a DNS SRV mismat= ch? It's unfortunate that RFC 4985 glosses over the difference between (1) the use of SRVName extensions to restrict deployment to a particular application type and (2) the use of DNS SRV records to redirect a source domain to a target domain that might be outside the trust boundary of the source domain. It might be appropriate for draft-saintandre-tls-server-id-check to have some text about this, and I'll try to write that soon. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010407070703070605090109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyOTIxNDkzOFowIwYJKoZIhvcNAQkEMRYEFJu7hBZgQFYUQV6UoeK0 eKC66fW2MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAVZH2DMMgOtcJdrHV+WrOCd+FbJ04bQq7/9MbwyUG lQf4PdIIZdH+lZU2mKTDSYS/SX2CQ7oAgkAAi2FjeE9mjWqXpFrfqKvTXZa7bKA4y7BHrbNs nQUqlV/t3dFtGYa2Re7C3ROZkzBf3qC0VdmyLLUxvYreTtM3XmH9VT5nnyTRw0NaPSAebgg/ xEIQsJmDjX+YcyRKJq6QNN/VKUNIPwrzpSwQsoFpkB2XfF1i7kpnewIl38pXC0kTVrmdkhI1 1rY1CRKMkW6CyQhcmWUNBtCtC5pmvvG96Aw0uZ2nLSUfLv0cR8rHVIxQMuA76+Jx/8p2rsFx JrMhTPKYdy/PygAAAAAAAA== --------------ms010407070703070605090109-- From stpeter@stpeter.im Tue Jun 29 15:07:01 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD093A67EA for ; Tue, 29 Jun 2010 15:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKY0b7zolexE for ; Tue, 29 Jun 2010 15:06:59 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E0F3F3A659B for ; Tue, 29 Jun 2010 15:06:58 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5701E40E4D for ; Tue, 29 Jun 2010 16:07:08 -0600 (MDT) Message-ID: <4C2A6E8B.7060005@stpeter.im> Date: Tue, 29 Jun 2010 16:07:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040704010700070409060407" Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:07:01 -0000 This is a cryptographically signed message in MIME format. --------------ms040704010700070409060407 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/11/10 6:10 PM, Paul Hoffman wrote: >> However, if this legacy identifer configuration is employed, then >> the server's fully-qualified DNS domain name MUST be placed in the >> last (most specific) RDN within the RDN sequence making up the >> certificate's subjectName, as the order of RDNs is determined by >> the DER- encoded Name within the server's PKIX certificate. >=20 > I always get this wrong, so I assume people less familiar with PKIX > do as well. Before you say "(most specific)" as if it was a toss-off, > you should define "most specific RDN" as "the last RDN within a > sequence", probably in section 1.3. Two questions: 1. Some people use "most significant" and "most specific" interchangeably. Which is correct? 2. More substantially, we currently have this text: The subject field of a PKIX certificate is defined as an X.501 type Name and known as a Distinguished Name (DN) -- see [X.501] and [PKIX]. A DN is an ordered sequence of Relative Distinguished Names (RDNs), where each RDN is a set (i.e., an unordered group) of type- and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], each of which asserts some attribute about the subject of the certificate. In the DER encoding of a DN, the RDNs are always in order from most significant to least significant (i.e., the first RDN is most significant and the last RDN is least significant); however, in the string representation of a DN as used in various protocols and data formats, the RDNs might be ordered from most significant to least significant (e.g., this is true of LDAP) or from least significant to most significant. Is the first RDN most specific, or is the last RDN most specific? I realize that the first one now will later be last [1] depending on the string representation, but my understanding is that in the DER encoding it's the first RDN that is most specific. Corrections are welcome. /psa [1] http://www.bobdylan.com/#/songs/the-times-they-are-a-changin --------------ms040704010700070409060407 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyOTIyMDcwN1owIwYJKoZIhvcNAQkEMRYEFK5UitCBc7sh1S2E5CcQ XVU5mswoMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAb6ecOMtXldBhIgf03vbnTEa08k32/ayvLdgeIjSo V4aPqJ3+u61WQqr4A6Rw2peLMsHQwZ2dVxZKlFsNnlBs9IJXsW0FY8W8l/Sk41sNSqaw9bNy YME05sMjzlkUwxsi4/h14x8hF/eBBS2gk2ZCiljQKrxBpKq3f/qQfyGcDQG1ND9VwTlFzSg+ s7UPUze5cjF+yCdxcPLW3MBtqZjotgHSYjJHu2MOwW89hoSENpHyB6S2URAWY/+TNGV2sHne HgpA0soD7faHMIluVs7yogxGr2n6Owp4Bi6anDaj1miQIPz0CmZ3R9RMqMfXeX+KhzwOjkf6 +H2wv4DBx/FFpwAAAAAAAA== --------------ms040704010700070409060407-- From stpeter@stpeter.im Tue Jun 29 15:14:51 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48D263A6859 for ; Tue, 29 Jun 2010 15:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.525 X-Spam-Level: X-Spam-Status: No, score=-1.525 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gczYTCmrav-B for ; Tue, 29 Jun 2010 15:14:49 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A151C3A67EC for ; Tue, 29 Jun 2010 15:14:49 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3B5AA40E4D for ; Tue, 29 Jun 2010 16:15:00 -0600 (MDT) Message-ID: <4C2A7062.2070207@stpeter.im> Date: Tue, 29 Jun 2010 16:14:58 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030504040704080807040704" Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:14:51 -0000 This is a cryptographically signed message in MIME format. --------------ms030504040704080807040704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/11/10 6:12 PM, Paul Hoffman wrote: >> 6. The certificate SHOULD NOT represent the server's >> fully-qualified DNS domain name by means of a DC-ID, i.e., a series >> of Domain Component (DC) attributes in the certificate subject, >> with one RDN per domain label and one DC in each RDN. Although >> (for example) could be used to >> represent the DNS domain name "www.example.com", given the fact >> that the DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED. >=20 > This should be a MUST NOT. And the reason for the prohibition is not > "DNS-ID can be used instead", but rather "this is insecure because > you can interpret the series of RDNs incorrectly". In version -05 we had the following text: Domain Components (DCs) are unordered. Therefore the following two sets of DCs would be equivalent: dc=3Dcom, dc=3Dexample, dc=3Dcn dc=3Dcn, dc=3Dexample, dc=3Dcom Because com.example.cn is presumably different from cn.example.com, representing or verifying an application server's DNS domain name based on domain components would open a serious security hole. As a result, certificate issuers and application clients MUST NOT use DCs. Someone objected that in fact domain components are not unordered, only that they can be misinterpreted (as everything else can, see ongoing discussion of RDNs and AVAs). Therefore we pulled out the quoted text. Corrections are welcome. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms030504040704080807040704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyOTIyMTQ1OFowIwYJKoZIhvcNAQkEMRYEFHVDlONHHXDLdAXGOW8u WjG7eAJ9MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAMx1HURJWmmnS6bXUGB63MHwuY0s0j/t5cyc5IEGP vembvBrgwTe7kj4DcZhO+tiRGgiygyFPKnUuqZSKVVpNEneKBqnzGAAUMP82bkkzaB+I1VWp AsAMnkujtqox3SqsdhADT6YFO8sKbeEdf3FdA9C5uVSgbiBaWujlOkzjPAGsprbP0zx+xaBX 6YDUYA6KkaSV5FLJOK8Qz14YywWZiOXWSMGz/U8ypswLFFb8IpKI9EHmTMRRCdl5J2bmRhi1 DWgLkfSrytRu9DSf4z9OzkGogah0QYN5NBtopoulnNu6AaxXHXGPJjduH6ouDFECHukSjgr4 2wTy0N0rNrobCAAAAAAAAA== --------------ms030504040704080807040704-- From stpeter@stpeter.im Tue Jun 29 15:16:40 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5851428C0E3 for ; Tue, 29 Jun 2010 15:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUzKjWdbdHoN for ; Tue, 29 Jun 2010 15:16:39 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B94EB28B23E for ; Tue, 29 Jun 2010 15:16:38 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 55F1940E4D for ; Tue, 29 Jun 2010 16:16:49 -0600 (MDT) Message-ID: <4C2A70D0.4080807@stpeter.im> Date: Tue, 29 Jun 2010 16:16:48 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <201006141412.o5EECbvx026607@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080006000508030409060703" Subject: Re: [certid] False choice for CN X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:16:40 -0000 This is a cryptographically signed message in MIME format. --------------ms080006000508030409060703 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/14/10 8:55 PM, Paul Hoffman wrote: > At 4:12 PM +0200 6/14/10, Martin Rex wrote: >> Paul Hoffman wrote: >>>=20 >>>> 1. The certificate MUST include a "DNS-ID" (i.e., a >>>> subjectAltName identifier of type dNSName). >>>=20 >>> . . . >>>=20 >>>> Therefore, if and only if the identity set does not include=20 >>>> subjectAltName extensions of type dNSName, SRVName, or=20 >>>> uniformResourceIdentifier (or any application-specific >>>> subjectAltName extensions supported by the client), the client >>>> MAY as a fallback check for a fully-qualified DNS domain name >>>> in the last Common Name RDN in the sequence of RDNs making up >>>> the Distinguished Name within the certificate's subjectName >>>> (where the term "last" refers to the DER order, which is often >>>> not the string order presented to a user; the order that is >>>> applied here MUST be the DER order). >>>=20 >>> Bzzzzzt! All of 3.4.4 is bogus, given that DNS-ID is required. >>> Please remove it. >>=20 >> I think this needs to stay. >>=20 >> The document under discussion is supposed to be a BCP (Best current >> practice) document, and it will have to describe how clients should >> deal with server certificates that do no have subjectAltNames. It >> does so by describing the common practice that has been in use for >> certs that do not have subjectAltNames. >=20 > That goes counter to the MUST-level statements in the document. You > either need to downgrade the MUST-level requirements, or get rid of > the sections that say, in essence, "if this MUST-level requirement is > not met, then do this". I think this list is leaning toward saying that DNS-ID is a SHOULD, not a MUST, so the quoted text would be appropriate. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080006000508030409060703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYyOTIyMTY0OFowIwYJKoZIhvcNAQkEMRYEFB2xZiDxB2F6tgaYOlbg jZeFwICRMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAma4/fGOF38ljVoWsudxfFjJ+VdftgjRzkpaPphIj 1VKL6sFa7BT7xMu5KONkc/uEW92Lu+sc9PVpKT3SKn3oF4d9ERppE81CYVJAwqNcHYie2jOV ICVyNTSvqCgEu/B9LQ3H6+IHaK0E2+TlAMjcQsTuWbhR4aGeZl1reOXIUMmLt1j/Mdzjsysm xJIALbIZ9SitytUPTGs0gjGsAOfJUzwwr+gzy/Nuljj0b+ubz2y2RgkKy5vWRkJgK/torNiD gbkneKjzoIzwHTIP7HMl9HPMWys+X0W+sz3w5sbjlSOyTZtjkWnJaxQycT3uaHCtfhc6zSqJ 26ps8QckAq7m2gAAAAAAAA== --------------ms080006000508030409060703-- From Bruno.Harbulot@manchester.ac.uk Tue Jun 29 15:31:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A8AB28C0EB for ; Tue, 29 Jun 2010 15:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMQuQ6tWGlLU for ; Tue, 29 Jun 2010 15:31:24 -0700 (PDT) Received: from probity.mcc.ac.uk (probity.mcc.ac.uk [130.88.200.94]) by core3.amsl.com (Postfix) with ESMTP id 58AFD28C0DD for ; Tue, 29 Jun 2010 15:31:02 -0700 (PDT) Received: from rankine.its.manchester.ac.uk ([130.88.25.196]) by probity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1OTjKi-0004kY-1e; Tue, 29 Jun 2010 23:31:12 +0100 Received: from 94-192-243-24.zone6.bethere.co.uk ([94.192.243.24]:54906 helo=mymachine) by rankine.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OTjKh-0004E9-QI; Tue, 29 Jun 2010 23:31:11 +0100 Message-ID: <4C2A7428.3060801@manchester.ac.uk> Date: Tue, 29 Jun 2010 23:31:04 +0100 From: Bruno Harbulot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Peter Saint-Andre References: <4C2A6E8B.7060005@stpeter.im> In-Reply-To: <4C2A6E8B.7060005@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: Bruno Harbulot from 94-192-243-24.zone6.bethere.co.uk (mymachine) [94.192.243.24]:54906 X-Authenticated-From: Bruno.Harbulot@manchester.ac.uk Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 22:31:26 -0000 On 29/06/2010 23:07, Peter Saint-Andre wrote: > On 6/11/10 6:10 PM, Paul Hoffman wrote: >>> However, if this legacy identifer configuration is employed, then >>> the server's fully-qualified DNS domain name MUST be placed in the >>> last (most specific) RDN within the RDN sequence making up the >>> certificate's subjectName, as the order of RDNs is determined by >>> the DER- encoded Name within the server's PKIX certificate. >> >> I always get this wrong, so I assume people less familiar with PKIX >> do as well. Before you say "(most specific)" as if it was a toss-off, >> you should define "most specific RDN" as "the last RDN within a >> sequence", probably in section 1.3. > > Two questions: > > 1. Some people use "most significant" and "most specific" > interchangeably. Which is correct? > > 2. More substantially, we currently have this text: > > The subject field of a PKIX certificate is defined as an X.501 type > Name and known as a Distinguished Name (DN) -- see [X.501] and > [PKIX]. A DN is an ordered sequence of Relative Distinguished Names > (RDNs), where each RDN is a set (i.e., an unordered group) of type- > and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], > each of which asserts some attribute about the subject of the > certificate. In the DER encoding of a DN, the RDNs are always in > order from most significant to least significant (i.e., the first RDN > is most significant and the last RDN is least significant); however, > in the string representation of a DN as used in various protocols and > data formats, the RDNs might be ordered from most significant to > least significant (e.g., this is true of LDAP) or from least > significant to most significant. > > Is the first RDN most specific, or is the last RDN most specific? I > realize that the first one now will later be last [1] depending on the > string representation, but my understanding is that in the DER encoding > it's the first RDN that is most specific. Corrections are welcome. I've always understood (perhaps by mistake) that the most specific was the last in the sequence. This also seems to reflect going "deeper" in the LDAP tree. For example, (from www.google.com:443), the Subject DN is: 156 104: SEQUENCE { 158 11: SET { 160 9: SEQUENCE { 162 3: OBJECT IDENTIFIER countryName (2 5 4 6) 167 2: PrintableString 'US' : } : } 171 19: SET { 173 17: SEQUENCE { 175 3: OBJECT IDENTIFIER stateOrProvinceName (2 5 4 8) 180 10: PrintableString 'California' : } : } 192 22: SET { 194 20: SEQUENCE { 196 3: OBJECT IDENTIFIER localityName (2 5 4 7) 201 13: TeletexString 'Mountain View' : } : } 216 19: SET { 218 17: SEQUENCE { 220 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 225 10: TeletexString 'Google Inc' : } : } 237 23: SET { 239 21: SEQUENCE { 241 3: OBJECT IDENTIFIER commonName (2 5 4 3) 246 14: TeletexString 'www.google.com' : } : } : } I think most I've seen follow this naming structure: country first and CN last. Intuitively, this seems to suggest that the first in the sequence is the least specific and that the last in the sequence is the most specific, if we use this terminology. (Is this correct?) Best wishes, Bruno. From paul.hoffman@vpnc.org Tue Jun 29 17:27:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18EA13A68C7 for ; Tue, 29 Jun 2010 17:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.661 X-Spam-Level: X-Spam-Status: No, score=0.661 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du6nSMwFYhsr for ; Tue, 29 Jun 2010 17:27:18 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 824B33A68A2 for ; Tue, 29 Jun 2010 17:27:18 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5U0RSWR013019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2010 17:27:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C2A65B5.4080209@stpeter.im> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> Date: Tue, 29 Jun 2010 17:18:47 -0700 To: Peter Saint-Andre , certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 00:27:20 -0000 At 3:29 PM -0600 6/29/10, Peter Saint-Andre wrote: >Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002010403050803000801" > >On 6/11/10 7:32 PM, Shumon Huque wrote: >> On Fri, Jun 11, 2010 at 05:07:50PM -0700, Paul Hoffman wrote: >>> 1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName >>> identifier of type dNSName). >>> >>> 2. If the service using the certificate deploys a technology in >>> which a server is discovered by means of DNS SRV records >>> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate >>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form >>> of otherName from the GeneralName structure in the subjectAltName >>> as specified in [SRVNAME]). >>> >>> If 2 is true, what is the value of the required DNS-ID? >> >> I don't think (1) is correct. If someone intends to deploy a >> certificate with an application specific name form such as SRV-ID >> or URI-ID, then they typically would not want to have a dNSName >> in the certificate, to make sure that the cert can't be (mis)used >> for unrelated application services at that domain name. >> >> Of course one might decide to include dNSName too for transition >> or backwards compatibility reasons. But I don't think that saying >> the certificate MUST include a dNSName is correct. > >Shumon, I think you are correct here, and that DNS-ID needs to be >"SHOULD" instead of "MUST". This is a very significant change to the document. Please give us all a chance to see all the edits in the next round before you consider the doc read for Last Call. Personally, no MUST but a pile of orthogonal SHOULDs seems like a bad idea if you are wanting this doc to cause more interoperability. At 4:16 PM -0600 6/29/10, Peter Saint-Andre wrote: >I think this list is leaning toward saying that DNS-ID is a SHOULD, not >a MUST, so the quoted text would be appropriate. Only "appropriate" if you want no MUSTs. Some us would prefer MUSTs to mush. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Jun 29 17:31:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4AD93A68D3 for ; Tue, 29 Jun 2010 17:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.659 X-Spam-Level: X-Spam-Status: No, score=0.659 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ3RIaTVrvEK for ; Tue, 29 Jun 2010 17:31:20 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 31E873A68C7 for ; Tue, 29 Jun 2010 17:31:20 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5U0RSWT013019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2010 17:27:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C2A6E8B.7060005@stpeter.im> References: <4C2A6E8B.7060005@stpeter.im> Date: Tue, 29 Jun 2010 17:17:28 -0700 To: Peter Saint-Andre , certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 00:31:20 -0000 At 4:07 PM -0600 6/29/10, Peter Saint-Andre wrote: >Is the first RDN most specific, or is the last RDN most specific? I >realize that the first one now will later be last [1] depending on the >string representation, but my understanding is that in the DER encoding >it's the first RDN that is most specific. Corrections are welcome. This paragraph shows why it is crazy to assume that developers understand this. First: if the RDN is a sequence, then whether it is encoded in DER or BER is irrelevant. The difference in the two encodings is only relevant for SETs. According to RFC 5280: RDNSequence ::= SEQUENCE OF RelativeDistinguishedName RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue However, RFC 5280 does not say which of the sequence is "most specific". --Paul Hoffman, Director --VPN Consortium From shuque@isc.upenn.edu Tue Jun 29 21:09:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466543A688A for ; Tue, 29 Jun 2010 21:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvYftxd0iWpK for ; Tue, 29 Jun 2010 21:09:26 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id E493A3A69FD for ; Tue, 29 Jun 2010 21:09:25 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 013AE303F; Wed, 30 Jun 2010 00:09:35 -0400 (EDT) Date: Wed, 30 Jun 2010 00:09:35 -0400 From: Shumon Huque To: Peter Saint-Andre Message-ID: <20100630040935.GA26880@isc.upenn.edu> References: <4C1CABA1.2050205@isode.com> <4C2A6A72.5000109@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2A6A72.5000109@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 04:09:27 -0000 On Tue, Jun 29, 2010 at 03:49:38PM -0600, Peter Saint-Andre wrote: > On 6/19/10 8:04 AM, Paul Hoffman wrote: > > At 12:36 PM +0100 6/19/10, Alexey Melnikov wrote: > >> Hi Paul, > >> > >> Paul Hoffman wrote: > >> > >>> 1. The certificate MUST include a "DNS-ID" (i.e., a > >>> subjectAltName identifier of type dNSName). > >>> > >>> 2. If the service using the certificate deploys a technology in > >>> which a server is discovered by means of DNS SRV records > >>> [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate > >>> SHOULD include an "SRV-ID" (i.e., an instance of the SRVName > >>> form of otherName from the GeneralName structure in the > >>> subjectAltName as specified in [SRVNAME]). > >>> > >>> If 2 is true, what is the value of the required DNS-ID? > >>> > >> One or more hostname for machines that would provide the specified > >> service. I.e. most likely some/all hostnames from the output of DNS > >> SRV lookup, but I can think of some examples where other hostnames > >> can be used in addition to or instead of these. E.g. a machine on > >> internal network, hostname of a NAT box, etc. > > > > So a cert says "the hostname of this server is www.example.com, and > > you can look up the hostname for the server using SRV"? What does > > that mean in a security context? If I get back one name of > > yyy.example.com, does that mean that the host has both names, or that > > there was a lookup error? > > My understanding of the SRVName extension is that it is primarily > intended to restrict the use of a certificate to a particular > application type (e.g., IMAP or XMPP). This is what Shumon meant when he > said: > > If someone intends to deploy a certificate with an > application specific name form such as SRV-ID or URI-ID, > then they typically would not want to have a dNSName in > the certificate, to make sure that the cert can't be > (mis)used for unrelated application services at that > domain name. Yup, that's what I meant .. > However, DNS SRV records have the property of enabling you to redirect > the source domain (e.g., example.com) to a target domain (e.g., > apps.example.net) that is outside of the trust boundary of the source > domain. Thus draft-daboo-srv-email says: > > A malicious attacker with access to the DNS server data, or able to > get spoofed answers cached in a recursive resolver, can potentially > cause MUAs to connect to any IMAP, POP3 or submission server chosen > by the attacker. In the absence of a secure DNS option, MUAs SHOULD > check that the target FQDN returned in the SRV record matches the > original service domain that was queried. If the target FQDN is not > in the queried domain, MUAs SHOULD verify with the user that the SRV > target FQDN is suitable for use before executing any connections to > the host. > > During recent discussions within the XMPP WG, we decided that we didn't > need text along those lines because a malicious attacker with access to > the DNS server data could simply return an evil IP address in a DNS > result, so why bother the user with scary warnings about a DNS SRV mismatch? Yeah, I think I agree with that. > It's unfortunate that RFC 4985 glosses over the difference between (1) > the use of SRVName extensions to restrict deployment to a particular > application type and (2) the use of DNS SRV records to redirect a source > domain to a target domain that might be outside the trust boundary of > the source domain. I'm not sure I see a problem here. So what if the domain name of the SRV owner (LHS) is in a different administrative domain than the domain name in the rdata of the SRV record (RHS)? The TLS certificate matching function should only be considering the first one. It can't trust the resolved name unless the lookup was authenticated anyway (with DNSSEC), or the resolved name was explicitly trusted by static local configuration. I assume the use case is hosting providers, eg. _imap._tcp.example.com IN SRV 10 10 143 mail.hostingprovider.com All the client needs to do is authenticate the certificate associated with the identity on the left side (eg. SRVName of _imap.example.com or dNSName of example.com etc). mail.hostingprovider would have to be configured with that certificate (with the co-operation of example.com). If the client gets redirected to connect to mail.evil.com by a DNS attack, the client will fail to authenticate the name on the left side (unless the attacker has also stolen the cert and key). --Shumon. From shuque@isc.upenn.edu Tue Jun 29 21:31:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45D9F28C0E4 for ; Tue, 29 Jun 2010 21:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkEC-qziswjr for ; Tue, 29 Jun 2010 21:31:47 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 92BB23A67FB for ; Tue, 29 Jun 2010 21:31:47 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 389BB3041; Wed, 30 Jun 2010 00:31:58 -0400 (EDT) Date: Wed, 30 Jun 2010 00:31:58 -0400 From: Shumon Huque To: Paul Hoffman Message-ID: <20100630043158.GB26880@isc.upenn.edu> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 04:31:49 -0000 On Tue, Jun 29, 2010 at 05:18:47PM -0700, Paul Hoffman wrote: > At 3:29 PM -0600 6/29/10, Peter Saint-Andre wrote: > >Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002010403050803000801" > > > >On 6/11/10 7:32 PM, Shumon Huque wrote: > >> > >> I don't think (1) is correct. If someone intends to deploy a > >> certificate with an application specific name form such as SRV-ID > >> or URI-ID, then they typically would not want to have a dNSName > >> in the certificate, to make sure that the cert can't be (mis)used > >> for unrelated application services at that domain name. > >> > >> Of course one might decide to include dNSName too for transition > >> or backwards compatibility reasons. But I don't think that saying > >> the certificate MUST include a dNSName is correct. > > > >Shumon, I think you are correct here, and that DNS-ID needs to be > >"SHOULD" instead of "MUST". > > This is a very significant change to the document. Please give us all a chance to see all the edits in the next round before you consider the doc read for Last Call. > > Personally, no MUST but a pile of orthogonal SHOULDs seems like a bad idea if you are wanting this doc to cause more interoperability. > > At 4:16 PM -0600 6/29/10, Peter Saint-Andre wrote: > >I think this list is leaning toward saying that DNS-ID is a SHOULD, not > >a MUST, so the quoted text would be appropriate. > > Only "appropriate" if you want no MUSTs. Some us would prefer MUSTs to mush. > > --Paul Hoffman, Director > --VPN Consortium Let's concentrate on the MUST/SHOULD applicability for the four identity types discussed in this document: * CN-ID = a Relative Distinguished Name (RDN) of type Common Name (CN) * DNS-ID = a subjectAltName identifier of type dNSName * SRV-ID = the SRVName form of otherName from the GeneralName structure in SubjectAltName * URI-ID = a subjectAltName identifier of type uniformResourceName I don't think any of them are a MUST. It depends upon the details of the application service. If a service deployer is using SRV-ID or URI-ID, then presumably they want to restrict the use of the certificate to a specific application at a domain name. In that case SHOULD is not appropriate for DNS-ID or CN-ID. In fact, you can argue that they SHOULD NOT use either of those more generic forms (unless it is for backwards compatibility). For folks who are using straight domain names rather than the application specific forms (probably the vast majority, at least initially), and we want to deprecate CN-ID and steer them towards DNS-ID, then I agree that DNS-ID can be a SHOULD. I don't think it can be a MUST today -- there are probably many certificate issuers that can't deal with anything other than CN. So, if we want to attach a SHOULD to DNS-ID, it should be a conditional one (the condition being that application specific name forms like SRV and URI aren't being used). -- Shumon Huque University of Pennsylvania. From peter.sylvester@edelweb.fr Tue Jun 29 22:06:54 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5773A6C21 for ; Tue, 29 Jun 2010 22:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5DS88mASRD1 for ; Tue, 29 Jun 2010 22:06:52 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 6097C3A6C1F for ; Tue, 29 Jun 2010 22:06:52 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 8AE12E6 for ; Wed, 30 Jun 2010 07:07:02 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 69CE617048 for ; Wed, 30 Jun 2010 07:07:02 +0200 (CEST) Received: from [192.168.0.10] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 6478B782B for ; Wed, 30 Jun 2010 07:07:02 +0200 (CEST) Message-ID: <4C2AD0F5.5030705@edelweb.fr> Date: Wed, 30 Jun 2010 07:07:01 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C2A6E8B.7060005@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 05:06:54 -0000 On 06/30/2010 02:17 AM, Paul Hoffman wrote: > At 4:07 PM -0600 6/29/10, Peter Saint-Andre wrote: > >> Is the first RDN most specific, or is the last RDN most specific? I >> realize that the first one now will later be last [1] depending on the >> string representation, but my understanding is that in the DER encoding >> it's the first RDN that is most specific. Corrections are welcome. >> > This paragraph shows why it is crazy to assume that developers understand this. > To me it only shows missing understanding of one person. 'this' refers to what? The the in this draft or rfc 5280? > First: if the RDN is a sequence, then whether it is encoded in DER or BER is irrelevant. The difference in the two encodings is only relevant for SETs. > > According to RFC 5280: > RDNSequence ::= SEQUENCE OF RelativeDistinguishedName > > RelativeDistinguishedName ::= > SET SIZE (1..MAX) OF AttributeTypeAndValue > > However, RFC 5280 does not say which of the sequence is "most specific". > IMO it is not exactly best place but at the end of paragraph 7.1 there is: "A distinguished name DN1 is within the subtree defined by the distinguished name DN2 if DN1 contains at least as many RDNs as DN2, and DN1 and DN2 are a match when trailing RDNs in DN1 are ignored." Given a natural interpretation of tree and subtree, one can deduce that the "highest" RDN is the first, or the most specific is the last. But since this is so nicely hidden, a reminder seems useful. From ietf-certid@velox.ch Tue Jun 29 23:12:37 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695753A6C23 for ; Tue, 29 Jun 2010 23:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bDCfVLgx2YB for ; Tue, 29 Jun 2010 23:12:35 -0700 (PDT) Received: from appendix.velox.ch (appendix.velox.ch [62.75.148.60]) by core3.amsl.com (Postfix) with ESMTP id A019D3A689C for ; Tue, 29 Jun 2010 23:12:35 -0700 (PDT) Received: from cortex.velox.ch (84-75-163-235.dclient.hispeed.ch [84.75.163.235]) (authenticated bits=0) by appendix.velox.ch (8.14.4/8.14.4/2.0) with ESMTP id o5U6Ci6S004091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 30 Jun 2010 08:12:45 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=appendix-177f; t=1277878365; bh=o8yWVQAcxzVRhfcKFa0ePJvYAzIGPtcPzYPcOsCpwSw=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=o8miLq/RdwFJMvq4bZf8uT8v1PlwYzb5mTGcnuyim2qWuWQDw+2U4S53jQ7I8yOBQ YbcJhvW/b/5mjsZ9/qx+9jQFhlfXKT6xa0Kn9XXhIkpzzhJ0qakYZS0o3akv6t7D6N i6gZACoalfK578lTcQf3stAAsag4jcB30gkNRyDr6mz/WjONAIyMWjOxfguUz9ANqB pUmqTgFNEwfPX6yzZuSenqH8v16vPgqPQqAQkIuzo3FWmJl0gAoRQuTEYsZOj3VvnU N21NPiAGNb+4DHFQOvDb8+mLrFbvL+ZB9bEyrxeNaYP9QWCUhdMWTi//ofyzFfMZPS rCo+2K1t5l1aw== Message-ID: <4C2AE05A.4010205@velox.ch> DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=velox.ch; s=cortex-8a58; t=1277878364; bh=o8yWVQAcxzVRhfcKFa0ePJvYAzIGPtcPzYPcOsCpwSw=; h=Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding; b=U/D+5q0d+R0gSTDORmOd6zszXmTJOHNxO7S/bEYR0HM72q9GopQXzK6oaKMbt82y7 oPhHnxx2sT6vPqSclj8PTuZBSuaYTuF//K6kzUZgGNAqxc/y7/kUKK5o1S3YY2r06z Hl+liYbA09oRHSyIuIVdbqdBqrk6fqcBI2TV8ZQ/Uc52BlBmcgBRqrhhWj+pnlrJHb 3FZgZLg0XR3zay6rxC03ZD6dEAertEwG8L6TQFLkm7umaszy3rz/dJw1gwHXQiRK2m 41X8aLRMDFac8pPn7IHfOYupwp9lX0jwdN5VUBmmvo/ESJ3DQll9sgboC1L+fJKexL pQvFUu+OXiYrg== Date: Wed, 30 Jun 2010 08:12:42 +0200 From: Kaspar Brand User-Agent: Thunderbird/3.0 MIME-Version: 1.0 To: certid@ietf.org References: <4C2A6E8B.7060005@stpeter.im> In-Reply-To: <4C2A6E8B.7060005@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 06:12:37 -0000 On 30.06.2010 00:07, Peter Saint-Andre wrote: > Two questions: > > 1. Some people use "most significant" and "most specific" > interchangeably. Which is correct? "most specific", I would say. And "correct" in the sense that it's the wording used in RFC 2818 (you won't find this term in X.501 in the section about names, e.g.). > 2. More substantially, we currently have this text: > > The subject field of a PKIX certificate is defined as an X.501 type > Name and known as a Distinguished Name (DN) -- see [X.501] and > [PKIX]. A DN is an ordered sequence of Relative Distinguished Names > (RDNs), where each RDN is a set (i.e., an unordered group) of type- > and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], > each of which asserts some attribute about the subject of the > certificate. In the DER encoding of a DN, the RDNs are always in > order from most significant to least significant (i.e., the first RDN > is most significant and the last RDN is least significant); however, > in the string representation of a DN as used in various protocols and > data formats, the RDNs might be ordered from most significant to > least significant (e.g., this is true of LDAP) or from least > significant to most significant. > > Is the first RDN most specific, or is the last RDN most specific? The last (as stated by others already). If we want to be really picky with definitions, then > where each RDN is a set (i.e., an unordered group) of type-and-value > pairs or "attribute value assertions" (AVAs) isn't entirely correct. RFC 5280 actually defines RelativeDistinguishedName as a SET OF AttributeTypeAndValue (not a SET OF AttributeValueAssertion, these have a different syntax, cf. X.501). I.e., drop "or 'attribute value assertions' (AVAs)" from the above definition, and change the definition of CN-ID to * CN-ID = a Relative Distinguished Name (RDN) in the certificate subject that contains one and only one type-and-value pair of type Common Name (CN) (On a somewhat related matter: when referring to subjectAltName entries - e.g. in Paul's message on "Empty subjects" - using the term AVA should be avoided, too. Simply use "a subjectAltName entry of type X".) Kaspar From mrex@sap.com Wed Jun 30 06:19:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 911813A6A24 for ; Wed, 30 Jun 2010 06:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.914 X-Spam-Level: X-Spam-Status: No, score=-6.914 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edYBkZ7j5ELI for ; Wed, 30 Jun 2010 06:19:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 433C23A6830 for ; Wed, 30 Jun 2010 06:19:26 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5UDJaFS004726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jun 2010 15:19:36 +0200 (MEST) From: Martin Rex Message-Id: <201006301319.o5UDJZQj029339@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Wed, 30 Jun 2010 15:19:35 +0200 (MEST) In-Reply-To: <4C2A7062.2070207@stpeter.im> from "Peter Saint-Andre" at Jun 29, 10 04:14:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:19:27 -0000 Peter Saint-Andre wrote: > > In version -05 we had the following text: > > Domain Components (DCs) are unordered. Therefore the following two > sets of DCs would be equivalent: > > dc=com, dc=example, dc=cn > > dc=cn, dc=example, dc=com > > Because com.example.cn is presumably different from cn.example.com, > representing or verifying an application server's DNS domain name > based on domain components would open a serious security hole. As a > result, certificate issuers and application clients MUST NOT use DCs. > > Someone objected that in fact domain components are not unordered, only > that they can be misinterpreted (as everything else can, see ongoing > discussion of RDNs and AVAs). Therefore we pulled out the quoted text. I'm sorry, but this example is completely bogus. * If you look at the examples of DC= usage in rfc-5280, they contain only >>domain<< names. There is never a mentioning of a hostname, and therefore the server endpoint identification does not apply. * Some of the examples in rfc-5280 clearly combine DC= componentes with a CN= of a regular user ! It would be a terribly bad idea to newly introduce a concept of matching server endpoint identities that were supposed to be used for informational purposes in regular user certificates. I would really appreciate a "MUST not use DC-ID for server endpoint identification", which also happens to be the current practice and what had previously been specified. rfc-2818 doesn't mention DC= at all. -Martin From Kurt.Zeilenga@Isode.com Wed Jun 30 06:47:57 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BED63A6989 for ; Wed, 30 Jun 2010 06:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_17=0.6, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDPYvOeIr4MX for ; Wed, 30 Jun 2010 06:47:54 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3F0E33A6A40 for ; Wed, 30 Jun 2010 06:47:53 -0700 (PDT) Received: from [192.168.1.101] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 30 Jun 2010 14:48:02 +0100 X-SMTP-Protocol-Errors: NORDNS From: Kurt Zeilenga In-Reply-To: <4C2A6E8B.7060005@stpeter.im> Date: Wed, 30 Jun 2010 06:48:00 -0700 Message-Id: <7918CC38-B49D-4604-BAFE-622E0E1D14B9@Isode.com> References: <4C2A6E8B.7060005@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1081) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 13:47:59 -0000 On Jun 29, 2010, at 3:07 PM, Peter Saint-Andre wrote: > 1. Some people use "most significant" and "most specific" > interchangeably. Which is correct? This is bad. Most significant and most specific are not interchangeable = terms. Most significant refers to the RDN with the greatest value. = That is, the RDN which is nearest the root of the naming tree. The most = specific RDN refers to the RDN which is deepest in the tree, the RDN = that is composed of AVAs which distinguish the relative name within a = subtree. In the DN (using RFC 4513 = notation), o=3DExample is the most significant (e.g, RDN with the = greatest value), and cn=3DKurt Zeilenga is the most specific (RDN which = is most specific in describing the named object). > 2. More substantially, we currently have this text: >=20 > The subject field of a PKIX certificate is defined as an X.501 type > Name and known as a Distinguished Name (DN) -- see [X.501] and > [PKIX]. A DN is an ordered sequence of Relative Distinguished Names > (RDNs), where each RDN is a set (i.e., an unordered group) of type- > and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], > each of which asserts some attribute about the subject of the > certificate. In the DER encoding of a DN, the RDNs are always in > order from most significant to least significant (i.e., the first = RDN > is most significant and the last RDN is least significant); however, > in the string representation of a DN as used in various protocols = and > data formats, the RDNs might be ordered from most significant to > least significant (e.g., this is true of LDAP) or from least > significant to most significant. One could replace 'least/most significant' here with 'most/least = specific'. Regards, Kurt= From cantor.2@osu.edu Wed Jun 30 07:31:05 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1906528C0F6 for ; Wed, 30 Jun 2010 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsoJ59s+jcBY for ; Wed, 30 Jun 2010 07:30:50 -0700 (PDT) Received: from defang2.it.ohio-state.edu (defang2.it.ohio-state.edu [128.146.216.82]) by core3.amsl.com (Postfix) with ESMTP id 47DA13A6A65 for ; Wed, 30 Jun 2010 07:30:47 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang2.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o5UEUbhI004830; Wed, 30 Jun 2010 10:30:37 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.161.86]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o5UEUan0025381; Wed, 30 Jun 2010 10:30:36 -0400 From: "Scott Cantor" To: , "'Peter Saint-Andre'" References: <4C2A7062.2070207@stpeter.im> <201006301319.o5UDJZQj029339@fs4113.wdf.sap.corp> In-Reply-To: <201006301319.o5UDJZQj029339@fs4113.wdf.sap.corp> Date: Wed, 30 Jun 2010 10:30:42 -0400 Organization: The Ohio State University Message-ID: <02f001cb1860$d1b4b880$751e2980$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQHw/oZDN8Cbi9rMHuAHJj2p5ekf8ZJOxFrg Content-language: en-us X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.82 Cc: certid@ietf.org Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 14:31:05 -0000 > I would really appreciate a "MUST not use DC-ID for server endpoint > identification", which also happens to be the current practice and > what had previously been specified. rfc-2818 doesn't mention DC= at all. +1 The last thing we need is *another* way to do what existing methods already address. -- Scott From stpeter@stpeter.im Wed Jun 30 07:53:28 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394993A685C for ; Wed, 30 Jun 2010 07:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG+vJTldzPFd for ; Wed, 30 Jun 2010 07:53:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 539783A65A5 for ; Wed, 30 Jun 2010 07:53:27 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 31D0540E57; Wed, 30 Jun 2010 08:53:37 -0600 (MDT) Message-ID: <4C2B5A6F.6000107@stpeter.im> Date: Wed, 30 Jun 2010 08:53:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Scott Cantor References: <4C2A7062.2070207@stpeter.im> <201006301319.o5UDJZQj029339@fs4113.wdf.sap.corp> <02f001cb1860$d1b4b880$751e2980$@osu.edu> In-Reply-To: <02f001cb1860$d1b4b880$751e2980$@osu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020600070206010307070907" Cc: certid@ietf.org Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 14:53:28 -0000 This is a cryptographically signed message in MIME format. --------------ms020600070206010307070907 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 8:30 AM, Scott Cantor wrote: >> I would really appreciate a "MUST not use DC-ID for server endpoint >> identification", which also happens to be the current practice and >> what had previously been specified. rfc-2818 doesn't mention DC=3D at= all. >=20 > +1 >=20 > The last thing we need is *another* way to do what existing methods alr= eady > address. That seems to be the consensus here, and I concur. IMHO we don't even necessarily need to say anything about why we're prohibiting DC=3D, given= that we're working to document best current practices and there's not even a current practice (let alone a best one) to use DC=3D. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020600070206010307070907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDE0NTMzNVowIwYJKoZIhvcNAQkEMRYEFEe3ZYdg59ZX83kZfd53 cWZMnH+SMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAGCFxSOURYLosVyO01/nccSer60l9oHAURQ+ot/ox nn5eM2/7xR/G3FGlhLLYV+kATU0rfmNKk4uQdG+2LWQQ6/fz1t6e2lN3Pdswtgf1bmdiF7Z+ vb1rWDGpqeyH7TDk0r1UsryFSyg8dpjSE3TUc60XPs0xMvcgQMJpwL7N72wjPomlpq7YV+7K tHhGF4o6SoJWgL8CQ4C6Vd8/Lm35qOjO71XD2nAY+r3s56yZdaIKlT6hWnUxG9rypjYlm1Zd nvJulLD2HvQ0HHbrZGdRvt/PRugja/nmcqSwT+nRFcNCJYJY275pxZ70Vns+dLB22w21B1rk 9aVzp1r1FcBOzAAAAAAAAA== --------------ms020600070206010307070907-- From paul.hoffman@vpnc.org Wed Jun 30 08:13:45 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918F13A69B0 for ; Wed, 30 Jun 2010 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFz2EfAQunID for ; Wed, 30 Jun 2010 08:13:44 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9FC1E3A6850 for ; Wed, 30 Jun 2010 08:13:44 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5UFDrKe069304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 08:13:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100630043158.GB26880@isc.upenn.edu> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> Date: Wed, 30 Jun 2010 08:13:53 -0700 To: Shumon Huque From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:13:45 -0000 At 12:31 AM -0400 6/30/10, Shumon Huque wrote: >Let's concentrate on the MUST/SHOULD applicability for the four >identity types discussed in this document: > > * CN-ID = a Relative Distinguished Name (RDN) of type Common Name > (CN) > > * DNS-ID = a subjectAltName identifier of type dNSName > > * SRV-ID = the SRVName form of otherName from the GeneralName > structure in SubjectAltName > > * URI-ID = a subjectAltName identifier of type > uniformResourceName > Agree. >I don't think any of them are a MUST. It depends upon the details >of the application service. > >If a service deployer is using SRV-ID or URI-ID, then presumably >they want to restrict the use of the certificate to a specific >application at a domain name. In that case SHOULD is not appropriate >for DNS-ID or CN-ID. In fact, you can argue that they SHOULD NOT >use either of those more generic forms (unless it is for backwards >compatibility). > >For folks who are using straight domain names rather than the >application specific forms (probably the vast majority, at least >initially), and we want to deprecate CN-ID and steer them towards >DNS-ID, then I agree that DNS-ID can be a SHOULD. I don't think >it can be a MUST today -- there are probably many certificate >issuers that can't deal with anything other than CN. > >So, if we want to attach a SHOULD to DNS-ID, it should be a >conditional one (the condition being that application specific >name forms like SRV and URI aren't being used). I agree that we have to look at the details of the service. To me, there are two types of names: - direct (CN-ID, DNS-ID, and URI-ID) - indirect (SRV-ID) If they are all SHOULD, and we don't say when one should not mix and match, we haven't helped interoperability. I think instead, we need something like "MUST have either one or more of (CN-ID, DNS-ID, and URI-ID), or SRV-ID". This would be followed by "if the cert has an SRV-ID, it SHOULD NOT have any of (CN-ID, DNS-ID, and URI-ID) because the meaning of combination of what is received from the SRV lookup and the given DNS names is undefined." Does that sound reasonable? --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Wed Jun 30 08:16:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87C863A6A3B for ; Wed, 30 Jun 2010 08:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.655 X-Spam-Level: X-Spam-Status: No, score=0.655 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ+-Myr9Nj4t for ; Wed, 30 Jun 2010 08:16:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DC84D3A6AD6 for ; Wed, 30 Jun 2010 08:16:23 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5UF85wn068888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 08:08:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <02f001cb1860$d1b4b880$751e2980$@osu.edu> References: <4C2A7062.2070207@stpeter.im> <201006301319.o5UDJZQj029339@fs4113.wdf.sap.corp> <02f001cb1860$d1b4b880$751e2980$@osu.edu> Date: Wed, 30 Jun 2010 08:08:05 -0700 To: "Scott Cantor" , , "'Peter Saint-Andre'" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: certid@ietf.org Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:16:26 -0000 At 10:30 AM -0400 6/30/10, Scott Cantor wrote: > > I would really appreciate a "MUST not use DC-ID for server endpoint >> identification", which also happens to be the current practice and >> what had previously been specified. rfc-2818 doesn't mention DC= at all. > >+1 > >The last thing we need is *another* way to do what existing methods already >address. Another +1 --Paul Hoffman, Director --VPN Consortium From mrex@sap.com Wed Jun 30 08:21:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AE93A6A15 for ; Wed, 30 Jun 2010 08:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.193 X-Spam-Level: X-Spam-Status: No, score=-8.193 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvpmgVgE-RIe for ; Wed, 30 Jun 2010 08:21:00 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B0C763A6834 for ; Wed, 30 Jun 2010 08:20:59 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o5UFL9Il010186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jun 2010 17:21:09 +0200 (MEST) From: Martin Rex Message-Id: <201006301521.o5UFL8q8006323@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Wed, 30 Jun 2010 17:21:08 +0200 (MEST) In-Reply-To: <4C2A7062.2070207@stpeter.im> from "Peter Saint-Andre" at Jun 29, 10 04:14:58 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:21:02 -0000 Peter Saint-Andre wrote: > > In version -05 we had the following text: > > Domain Components (DCs) are unordered. Therefore the following two > sets of DCs would be equivalent: > > dc=com, dc=example, dc=cn > > dc=cn, dc=example, dc=com > > Because com.example.cn is presumably different from cn.example.com, > representing or verifying an application server's DNS domain name > based on domain components would open a serious security hole. As a > result, certificate issuers and application clients MUST NOT use DCs. Slightly OT: adding DC= AVAs to a DName would be fairly unreasonable if they did _not_ have a defined order. I assume that the order is as much defined as it is for the regular "hierarchical directory tree". Although my PKIX & LDAP exposure is at the homeopathic level, I assume the idea of the DC= components could be to establish something like a hierarchical LDAP directory model based on DNS rather than assuming a single global X.500 directory hierarchy and full-fledged DAP. -Martin From mrex@sap.com Wed Jun 30 08:51:53 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1AB3A6877 for ; Wed, 30 Jun 2010 08:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.355 X-Spam-Level: X-Spam-Status: No, score=-8.355 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paSPYwkamnNg for ; Wed, 30 Jun 2010 08:51:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 248603A67D4 for ; Wed, 30 Jun 2010 08:51:49 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5UFpxUB004724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jun 2010 17:51:59 +0200 (MEST) From: Martin Rex Message-Id: <201006301551.o5UFpwjh008254@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Wed, 30 Jun 2010 17:51:58 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Jun 30, 10 08:13:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:51:53 -0000 Paul Hoffman wrote: > > At 12:31 AM -0400 6/30/10, Shumon Huque wrote: > >Let's concentrate on the MUST/SHOULD applicability for the four > >identity types discussed in this document: > > > > * CN-ID = a Relative Distinguished Name (RDN) of type Common Name > > (CN) > > > > * DNS-ID = a subjectAltName identifier of type dNSName > > > > * SRV-ID = the SRVName form of otherName from the GeneralName > > structure in SubjectAltName > > > > * URI-ID = a subjectAltName identifier of type > > uniformResourceName > > > > Agree. Me2. > > I agree that we have to look at the details of the service. To me, > there are two types of names: > - direct (CN-ID, DNS-ID, and URI-ID) > - indirect (SRV-ID) > If they are all SHOULD, and we don't say when one should not mix and > match, we haven't helped interoperability. I think instead, we need > something like "MUST have either one or more of (CN-ID, DNS-ID, > and URI-ID), or SRV-ID". This would be followed by "if the cert has an > SRV-ID, it SHOULD NOT have any of (CN-ID, DNS-ID, and URI-ID) because > the meaning of combination of what is received from the SRV lookup > and the given DNS names is undefined." > > Does that sound reasonable? I think this covers only part of the picture. Describing what certs should have and should not have may be interesting to CA-operators and admins, but seems to apply to new designs only, and not allow for migration. I would appreciate guidance for the implementors. And at that point we will have to get rid of that "is undefined" entirely -- i.e. we will have to specify exactly what is supposed to happen if more than one identifier is present. While CN-ID and DNS-ID have exactly the same scope (hostname) SRV-ID and URI-ID have a more restrictive scope. Does a combination make sense? Or do we expect that to happen only during migration from a currently used CN-ID or DNS-ID to a SRV-ID or URI-ID? Keep in mind that "flag days" where the _entire_ installed base is taken down, changed/updated and put back up, are difficult and rare in practice. Should CN-ID or DNS-ID be entirely ignored when SRV-ID or URI-ID is found and understood/used by a client for server endpoint identification? in the sense that SRV-ID and URI-ID supersede CN-ID or DNS-ID for the clients which understand them? The migration scenario that worries me slightly is that were the CA supports adding features that the installed base doesn't support yet. It could happen that incorrect "new" stuff is added, and as long as noone checks the new stuff, this problem is not noticed. But as soon as the first component is updated to understand this cert attribute, the fact that its incorrect is likely to result in an interop problem if the updated component is "strict" in checking of the new feature. When adding new features with a patch to the installed base, I therefore tend to be tolerant. -Martin From peter.sylvester@edelweb.fr Wed Jun 30 08:58:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CD33A6A15 for ; Wed, 30 Jun 2010 08:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=1.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7rA3Dutjg5j for ; Wed, 30 Jun 2010 08:58:19 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 418513A699F for ; Wed, 30 Jun 2010 08:58:19 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id 8BFF4138 for ; Wed, 30 Jun 2010 17:58:29 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 8127817048 for ; Wed, 30 Jun 2010 17:58:29 +0200 (CEST) Received: from [192.168.0.10] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 61B7E782B for ; Wed, 30 Jun 2010 17:58:29 +0200 (CEST) Message-ID: <4C2B69A1.5040505@edelweb.fr> Date: Wed, 30 Jun 2010 17:58:25 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C2A7062.2070207@stpeter.im> <201006301319.o5UDJZQj029339@fs4113.wdf.sap.corp> <02f001cb1860$d1b4b880$751e2980$@osu.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] DC should be MUST NOT X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 15:58:20 -0000 On 06/30/2010 05:08 PM, Paul Hoffman wrote: > At 10:30 AM -0400 6/30/10, Scott Cantor wrote: > >>> I would really appreciate a "MUST not use DC-ID for server endpoint >>> identification", which also happens to be the current practice and >>> what had previously been specified. rfc-2818 doesn't mention DC= at all. >>> >> +1 >> >> The last thing we need is *another* way to do what existing methods already >> address. >> > Another +1 > +1, RFC 5280 already "warns" about that. In addition, implementations of this specification MUST be prepared to receive the domainComponent attribute, as defined in [RFC4519]. The Domain Name System (DNS) provides a hierarchical resource labeling system. This attribute provides a convenient mechanism for organizations that wish to use DNs that parallel their DNS names. This is not a replacement for the dNSName component of the alternative name extensions. Implementations are not required to convert such names into DNS names. From peter.sylvester@edelweb.fr Wed Jun 30 09:23:44 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7AD3A68F5 for ; Wed, 30 Jun 2010 09:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.355 X-Spam-Level: X-Spam-Status: No, score=-0.355 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71-uxDI9xiiP for ; Wed, 30 Jun 2010 09:23:36 -0700 (PDT) Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id EDA183A6824 for ; Wed, 30 Jun 2010 09:23:35 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id AD0DAA5 for ; Wed, 30 Jun 2010 18:23:46 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 8713517048 for ; Wed, 30 Jun 2010 18:23:46 +0200 (CEST) Received: from [192.168.0.10] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 6B9A2782B for ; Wed, 30 Jun 2010 18:23:46 +0200 (CEST) Message-ID: <4C2B6F91.2030807@edelweb.fr> Date: Wed, 30 Jun 2010 18:23:45 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C2A6E8B.7060005@stpeter.im> <7918CC38-B49D-4604-BAFE-622E0E1D14B9@Isode.com> In-Reply-To: <7918CC38-B49D-4604-BAFE-622E0E1D14B9@Isode.com> Content-Type: multipart/alternative; boundary="------------010106020407040705000905" Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 16:23:44 -0000 This is a multi-part message in MIME format. --------------010106020407040705000905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> 2. More substantially, we currently have this text: >> >> The subject field of a PKIX certificate is defined as an X.501 type >> Name and known as a Distinguished Name (DN) -- see [X.501] and >> [PKIX]. A DN is an ordered sequence of Relative Distinguished Names >> (RDNs), where each RDN is a set (i.e., an unordered group) of type- >> and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], >> each of which asserts some attribute about the subject of the >> certificate. In the DER encoding of a DN, the RDNs are always in >> order from most significant to least significant (i.e., the first RDN >> is most significant and the last RDN is least significant); however, >> in the string representation of a DN as used in various protocols and >> data formats, the RDNs might be ordered from most significant to >> least significant (e.g., this is true of LDAP) or from least >> significant to most significant. >> > > One could replace 'least/most significant' here with 'most/least specific'. > +1 significant is a bad term in this context IMO according to W&M: *1* *:* having meaning; /especially/ *:* suggestive *2 a* *:* having or likely to have influence or effect *:* important ; /also/ *:* of a noticeably or measurably large amount *b* *:* probably caused by something other than mere chance --------------010106020407040705000905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
2. More substantially, we currently have this text:

  The subject field of a PKIX certificate is defined as an X.501 type
  Name and known as a Distinguished Name (DN) -- see [X.501] and
  [PKIX].  A DN is an ordered sequence of Relative Distinguished Names
  (RDNs), where each RDN is a set (i.e., an unordered group) of type-
  and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN],
  each of which asserts some attribute about the subject of the
  certificate.  In the DER encoding of a DN, the RDNs are always in
  order from most significant to least significant (i.e., the first RDN
  is most significant and the last RDN is least significant); however,
  in the string representation of a DN as used in various protocols and
  data formats, the RDNs might be ordered from most significant to
  least significant (e.g., this is true of LDAP) or from least
  significant to most significant.
    

One could replace 'least/most significant' here with 'most/least specific'.
+1  significant is a bad term in this context IMO according to W&M:

1 : having meaning; especially : suggestive <a significant glance>
2 a : having or likely to have influence or effect : important <a significant piece of legislation>; also : of a noticeably or measurably large amount <a significant number of layoffs> <producing significant profits> b : probably caused by something other than mere chance <statistically significant correlation between vitamin deficiency and disease>



--------------010106020407040705000905-- From lha@apple.com Wed Jun 30 09:25:47 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C1C43A6827 for ; Wed, 30 Jun 2010 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.903 X-Spam-Level: X-Spam-Status: No, score=-104.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjgRAKZOT10h for ; Wed, 30 Jun 2010 09:25:46 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 9524D3A6824 for ; Wed, 30 Jun 2010 09:25:46 -0700 (PDT) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 0423D9ACDD30 for ; Wed, 30 Jun 2010 09:25:58 -0700 (PDT) X-AuditID: 11807134-b7b53ae000005755-d7-4c2b70155f83 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id C6.9B.22357.5107B2C4; Wed, 30 Jun 2010 09:25:57 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [10.55.233.40] (166-205-138-167.mobile.mymmode.com [166.205.138.167]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L4U00FYE5N41M20@et.apple.com> for certid@ietf.org; Wed, 30 Jun 2010 09:25:57 -0700 (PDT) References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> In-reply-to: Message-id: <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> Content-transfer-encoding: quoted-printable X-Mailer: iPhone Mail (8A293) From: =?utf-8?Q?Love_H=C3=B6rnquist_=C3=85strand?= Date: Wed, 30 Jun 2010 09:27:06 -0700 To: Paul Hoffman X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "certid@ietf.org" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 16:25:47 -0000 Paul, all 30 jun 2010 kl. 08:13 skrev Paul Hoffman : > At 12:31 AM -0400 6/30/10, Shumon Huque wrote: >> Let's concentrate on the MUST/SHOULD applicability for the four >> identity types discussed in this document: >>=20 >> * CN-ID =3D a Relative Distinguished Name (RDN) of type Common Name >> (CN) >>=20 >> * DNS-ID =3D a subjectAltName identifier of type dNSName >>=20 >> * SRV-ID =3D the SRVName form of otherName from the GeneralName >> structure in SubjectAltName >>=20 >> * URI-ID =3D a subjectAltName identifier of type >> uniformResourceName >>=20 >=20 > Agree. >=20 >> I don't think any of them are a MUST. It depends upon the details >> of the application service. >>=20 >> If a service deployer is using SRV-ID or URI-ID, then presumably >> they want to restrict the use of the certificate to a specific >> application at a domain name. In that case SHOULD is not appropriate >> for DNS-ID or CN-ID. In fact, you can argue that they SHOULD NOT >> use either of those more generic forms (unless it is for backwards >> compatibility). >>=20 >> For folks who are using straight domain names rather than the >> application specific forms (probably the vast majority, at least >> initially), and we want to deprecate CN-ID and steer them towards >> DNS-ID, then I agree that DNS-ID can be a SHOULD. I don't think >> it can be a MUST today -- there are probably many certificate >> issuers that can't deal with anything other than CN. >>=20 >> So, if we want to attach a SHOULD to DNS-ID, it should be a >> conditional one (the condition being that application specific >> name forms like SRV and URI aren't being used). >=20 > I agree that we have to look at the details of the service. To me, there a= re two types of names: > - direct (CN-ID, DNS-ID, and URI-ID) > - indirect (SRV-ID) > If they are all SHOULD, and we don't say when one should not mix and match= , we haven't helped interoperability. I think instead, we need something lik= e "MUST have either one or more of (CN-ID, DNS-ID, and URI-ID), or SRV-ID". T= his would be followed by "if the cert has an SRV-ID, it SHOULD NOT have any o= f (CN-ID, DNS-ID, and URI-ID) because the meaning of combination of what is r= eceived from the SRV lookup and the given DNS names is undefined." >=20 > Does that sound reasonable? I think that both "direct" and "indirect" SHOULD be allowed at the same time= . The reason is that if you have a client that supports SRV lookups, in for ex= ample jabber, then you want to have the SRV name in there so the client can m= atch the server cert with what the user typed. Of course there are jabber clients out there that don't support SRV lookup a= nd want to to the normal direct mappings rules. Since the server doesn't really know what client they talk to it need to han= d out a cert that matches both rules -> must hAve both for interop reasons. So the direct names are not used for intermediate values, they are only used= with names what comes/is derived user input. Love Skickat fr=C3=A5n min iPhone= From stpeter@stpeter.im Wed Jun 30 10:41:19 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C063A6A18 for ; Wed, 30 Jun 2010 10:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+P9mKEBQPSl for ; Wed, 30 Jun 2010 10:41:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E1E653A68CD for ; Wed, 30 Jun 2010 10:41:16 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BAF1340E4D for ; Wed, 30 Jun 2010 11:41:26 -0600 (MDT) Message-ID: <4C2B81C3.1040402@stpeter.im> Date: Wed, 30 Jun 2010 11:41:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <4C2A6E8B.7060005@stpeter.im> <4C2AE05A.4010205@velox.ch> In-Reply-To: <4C2AE05A.4010205@velox.ch> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090105090905000501080003" Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:41:19 -0000 This is a cryptographically signed message in MIME format. --------------ms090105090905000501080003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 12:12 AM, Kaspar Brand wrote: > On 30.06.2010 00:07, Peter Saint-Andre wrote: >> Two questions: >> >> 1. Some people use "most significant" and "most specific" >> interchangeably. Which is correct? >=20 > "most specific", I would say. And "correct" in the sense that it's the > wording used in RFC 2818 (you won't find this term in X.501 in the > section about names, e.g.). >=20 >> 2. More substantially, we currently have this text: >> >> The subject field of a PKIX certificate is defined as an X.501 type= >> Name and known as a Distinguished Name (DN) -- see [X.501] and >> [PKIX]. A DN is an ordered sequence of Relative Distinguished Name= s >> (RDNs), where each RDN is a set (i.e., an unordered group) of type-= >> and-value pairs or "attribute value assertions" (AVAs) [LDAP-DN], >> each of which asserts some attribute about the subject of the >> certificate. In the DER encoding of a DN, the RDNs are always in >> order from most significant to least significant (i.e., the first R= DN >> is most significant and the last RDN is least significant); however= , >> in the string representation of a DN as used in various protocols a= nd >> data formats, the RDNs might be ordered from most significant to >> least significant (e.g., this is true of LDAP) or from least >> significant to most significant. >> >> Is the first RDN most specific, or is the last RDN most specific? >=20 > The last (as stated by others already). If we want to be really picky > with definitions, then >=20 >> where each RDN is a set (i.e., an unordered group) of type-and-value >> pairs or "attribute value assertions" (AVAs) >=20 > isn't entirely correct. RFC 5280 actually defines > RelativeDistinguishedName as a SET OF AttributeTypeAndValue (not a SET > OF AttributeValueAssertion, these have a different syntax, cf. X.501). >=20 > I.e., drop "or 'attribute value assertions' (AVAs)" from the above > definition,=20 Based on feedback from you and from Kurt, I have changed the foregoing paragraph to: Certificates are binary objects -- they are encoded using distinguished encoding rules (DER). Thus, the generation of displayable (a.k.a. printable) renderings of certificate subject and issuer names means that the DER-encoded sequences are decoded and converted into a "string representation" before being rendered. Because a DN is an ordered sequence, order is preserved in the string representation of a DN. However, because an RDN is an unordered group of attribute-type-and-value pairs, the string representation of an RDN can differ from the canonical DER encoding; in the canonical encoding, the RDN that is nearest to the root of the naming tree is called the "most significant" RDN and the RDN that is deepest in the tree (and that therefore distinguishes the relative name) is called the "most specific" RDN. See [LDAP-DN] for details. > and change the definition of CN-ID to >=20 > * CN-ID =3D a Relative Distinguished Name (RDN) in the certifica= te > subject that contains one and only one type-and-value pair > of type Common Name (CN) Done, thanks. > (On a somewhat related matter: when referring to subjectAltName entries= > - e.g. in Paul's message on "Empty subjects" - using the term AVA shoul= d > be avoided, too. Simply use "a subjectAltName entry of type X".) So: It is perfectly acceptable for a PKIX certificate to have an empty subject field as long as there is at least one subjectAltName entry. Is that better? Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090105090905000501080003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDE3NDEyM1owIwYJKoZIhvcNAQkEMRYEFEhI11l5aNf6RBziq5Pm v2EOu772MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAQni0n7Pu8IU3gqEozQunVRZVQAEzV4qyQYkO9kVZ t3aOha6I5Q6nghVlfUil4FH+1cQKRk7WIEIdo5WcqO6EiQmI9ToEkawX2272n3tWBgYDXLae XNfR/JSJN/cerVFPcQDnFnukQ112CO2WNVkbSanuBYEASqO8Oi+7zmwsHEFwMaFLHI5WoNj2 5SLMpA1YXAI3w+eafFrtu6A4OKXSfWpkxvloedv0y/6JroUrqoEQ6frUbGvEJg+WYbzaBGru sl4WYFkkAnms1b2ZPO+lTHoPgx6Q+v4/AmDyoptUXetCObRW63ey79JBRkG5C80B44lSY6c9 2z/mPL+RWY3e0wAAAAAAAA== --------------ms090105090905000501080003-- From mrex@sap.com Wed Jun 30 10:46:10 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B593A68CD for ; Wed, 30 Jun 2010 10:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.205 X-Spam-Level: X-Spam-Status: No, score=-8.205 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YP+YtWdZob7 for ; Wed, 30 Jun 2010 10:46:10 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B00873A6880 for ; Wed, 30 Jun 2010 10:46:09 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5UHkJeQ028408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jun 2010 19:46:19 +0200 (MEST) From: Martin Rex Message-Id: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Wed, 30 Jun 2010 19:46:18 +0200 (MEST) In-Reply-To: <4C2B81C3.1040402@stpeter.im> from "Peter Saint-Andre" at Jun 30, 10 11:41:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:46:10 -0000 Peter Saint-Andre wrote: > > Based on feedback from you and from Kurt, I have changed the foregoing > paragraph to: > > Certificates are binary objects -- they are encoded using > distinguished encoding rules (DER). Thus, the generation of > displayable (a.k.a. printable) renderings of certificate subject and > issuer names means that the DER-encoded sequences are decoded and > converted into a "string representation" before being rendered. > Because a DN is an ordered sequence, order is preserved in the string > representation of a DN. However, because an RDN is an unordered > group of attribute-type-and-value pairs, the string representation of > an RDN can differ from the canonical DER encoding; in the canonical > encoding, the RDN that is nearest to the root of the naming tree is > called the "most significant" RDN and the RDN that is deepest in the > tree (and that therefore distinguishes the relative name) is called > the "most specific" RDN. See [LDAP-DN] for details. I'm actually confused by refering to one end with "most significant" and the other with "most specific". Couldn't we just drop the "most significant" entirely and use "least specific" / "most specific" for the two ends? -Martin From stpeter@stpeter.im Wed Jun 30 10:51:47 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41F33A6A6E for ; Wed, 30 Jun 2010 10:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYp+dKkxWBnk for ; Wed, 30 Jun 2010 10:51:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9BB6B3A68CD for ; Wed, 30 Jun 2010 10:51:46 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF8E640E4D; Wed, 30 Jun 2010 11:51:56 -0600 (MDT) Message-ID: <4C2B843A.5010206@stpeter.im> Date: Wed, 30 Jun 2010 11:51:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: mrex@sap.com References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> In-Reply-To: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090809060806050008070403" Cc: certid@ietf.org Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 17:51:47 -0000 This is a cryptographically signed message in MIME format. --------------ms090809060806050008070403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 11:46 AM, Martin Rex wrote: > Peter Saint-Andre wrote: >> >> Based on feedback from you and from Kurt, I have changed the foregoing= >> paragraph to: >> >> Certificates are binary objects -- they are encoded using >> distinguished encoding rules (DER). Thus, the generation of >> displayable (a.k.a. printable) renderings of certificate subject an= d >> issuer names means that the DER-encoded sequences are decoded and >> converted into a "string representation" before being rendered. >> Because a DN is an ordered sequence, order is preserved in the stri= ng >> representation of a DN. However, because an RDN is an unordered >> group of attribute-type-and-value pairs, the string representation = of >> an RDN can differ from the canonical DER encoding; in the canonical= >> encoding, the RDN that is nearest to the root of the naming tree is= >> called the "most significant" RDN and the RDN that is deepest in th= e >> tree (and that therefore distinguishes the relative name) is called= >> the "most specific" RDN. See [LDAP-DN] for details. >=20 > I'm actually confused by refering to one end with "most significant" an= d > the other with "most specific". Couldn't we just drop the "most signif= icant" > entirely and use "least specific" / "most specific" for the two ends? Given that we never use the term "most significant" in this I-D, I'd say we can remove any mention of it. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090809060806050008070403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDE3NTE1NFowIwYJKoZIhvcNAQkEMRYEFMO5+9QH943BN1nFpLHc wXn5PgRQMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAbvs50ALQ6yEaCfbx6mdzDmO1fYKBarpqLXKV3oqk qGOgN/FSVF7EOXDznqOsXFZRkvztYaI3hn4/YN/u6BTFoqqa/6UW4HuY2/2HjUlmK/bpua0z A1CX6SudITJqT6pZn1bGTyiGMfAYGHfIXbcgo0N0iocmEJlYFzBc2rRZXRf3kNlal2wWbamr BFk2BUYaObxlecEdHm/P65/qU9hX8Zrc25hKLzKeXrDw2a/D1S+cFsQ7sdyCKYk3XKRnsiOP y/5yrNWZgXcDUHQJe26+lGmtBV/qg70o8YMbYzoHarF+ffvU0D9pWP+zmpHD8fIwHqc42U/B W5dmacX9E9HiaAAAAAAAAA== --------------ms090809060806050008070403-- From paul.hoffman@vpnc.org Wed Jun 30 11:18:06 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316173A6ADE for ; Wed, 30 Jun 2010 11:18:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char F6 hex): To: Love H\366rnquist \305strand[...] X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN90wr6QLr87 for ; Wed, 30 Jun 2010 11:18:04 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B3AD23A6ADD for ; Wed, 30 Jun 2010 11:18:03 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5UIIBTB082669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 11:18:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> Date: Wed, 30 Jun 2010 11:18:10 -0700 To: Love Hörnquist Åstrand From: Paul Hoffman Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 18:18:06 -0000 At 9:27 AM -0700 6/30/10, Love Hörnquist Åstrand wrote: >I think that both "direct" and "indirect" SHOULD be allowed at the same time. > >The reason is that if you have a client that supports SRV lookups, in for example jabber, then you want to have the SRV name in there so the client can match the server cert with what the user typed. > >Of course there are jabber clients out there that don't support SRV lookup and want to to the normal direct mappings rules. > >Since the server doesn't really know what client they talk to it need to hand out a cert that matches both rules -> must hAve both for interop reasons. > >So the direct names are not used for intermediate values, they are only used with names what comes/is derived user input. Unfortunately, I agree with this logic. I say "unfortunately" because it means that we then don't have a MUST, and therefore lose interoperability. For sanity, the document needs to say why it is OK to have both direct and indirect and what to do when they are both there, but I agree that we can't say MUST have only one. --Paul Hoffman, Director --VPN Consortium From alexey.melnikov@isode.com Wed Jun 30 11:35:04 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6383A68F6 for ; Wed, 30 Jun 2010 11:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+creNzdiduA for ; Wed, 30 Jun 2010 11:35:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id C819F3A67ED for ; Wed, 30 Jun 2010 11:35:02 -0700 (PDT) Received: from [172.16.2.136] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 30 Jun 2010 19:35:12 +0100 Message-ID: <4C2B8E43.7070806@isode.com> Date: Wed, 30 Jun 2010 19:34:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Paul Hoffman References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 18:35:04 -0000 Paul Hoffman wrote: >At 9:27 AM -0700 6/30/10, Love H=F6rnquist =C5strand wrote: > =20 > >>I think that both "direct" and "indirect" SHOULD be allowed at the same ti= me. >> >>The reason is that if you have a client that supports SRV lookups, in for = example jabber, then you want to have the SRV name in there so the client ca= n match the server cert with what the user typed. >> >>Of course there are jabber clients out there that don't support SRV lookup= and want to to the normal direct mappings rules. >> >>Since the server doesn't really know what client they talk to it need to h= and out a cert that matches both rules -> must hAve both for interop reasons= . >> >>So the direct names are not used for intermediate values, they are only us= ed with names what comes/is derived user input. >> =20 >> >Unfortunately, I agree with this logic. > I agree with this logic too (without "unfortunately" ;-)). >I say "unfortunately" because it means that we then don't have a MUST, and = therefore lose interoperability. For sanity, the document needs to say why i= t is OK to have both direct and indirect and what to do when they are both t= here, but I agree that we can't say MUST have only one. > =20 > I think a document specifying how to perform TLS server identity=20 verification for a particular protocol can specify if only one of them=20 can be allowed (and which one), or if both can be allowed. This=20 addresses interoperability for a particular protocol. From stpeter@stpeter.im Wed Jun 30 11:43:25 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB1403A68A4 for ; Wed, 30 Jun 2010 11:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7Z7B0qCWGE4 for ; Wed, 30 Jun 2010 11:43:24 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 98B963A67F5 for ; Wed, 30 Jun 2010 11:43:24 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8470C40E4D; Wed, 30 Jun 2010 12:43:34 -0600 (MDT) Message-ID: <4C2B9054.40703@stpeter.im> Date: Wed, 30 Jun 2010 12:43:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Shumon Huque References: <4C1CABA1.2050205@isode.com> <4C2A6A72.5000109@stpeter.im> <20100630040935.GA26880@isc.upenn.edu> In-Reply-To: <20100630040935.GA26880@isc.upenn.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000004030804090403050904" Cc: Richard Barnes , certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 18:43:25 -0000 This is a cryptographically signed message in MIME format. --------------ms000004030804090403050904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Warning: tangent. On 6/29/10 10:09 PM, Shumon Huque wrote: > On Tue, Jun 29, 2010 at 03:49:38PM -0600, Peter Saint-Andre wrote: > >> It's unfortunate that RFC 4985 glosses over the difference between (1)= >> the use of SRVName extensions to restrict deployment to a particular >> application type and (2) the use of DNS SRV records to redirect a sour= ce >> domain to a target domain that might be outside the trust boundary of >> the source domain. >=20 > I'm not sure I see a problem here. So what if the domain name of=20 > the SRV owner (LHS) is in a different administrative domain than=20 > the domain name in the rdata of the SRV record (RHS)? The TLS certifica= te > matching function should only be considering the first one. It > can't trust the resolved name unless the lookup was authenticated > anyway (with DNSSEC), or the resolved name was explicitly trusted by > static local configuration. I assume the use case is hosting > providers, eg. >=20 > _imap._tcp.example.com IN SRV 10 10 143 mail.hostingprovider.com >=20 > All the client needs to do is authenticate the certificate associated=20 > with the identity on the left side (eg. SRVName of _imap.example.com=20 > or dNSName of example.com etc). mail.hostingprovider would have to be=20 > configured with that certificate (with the co-operation of example.com)= =2E=20 > If the client gets redirected to connect to mail.evil.com by a DNS atta= ck,=20 > the client will fail to authenticate the name on the left side (unless = > the attacker has also stolen the cert and key). Correct. Here's the rub: mail.hostingprovider would have to be configured with that certificate (with the co-operation of example.com). In most cases, the admins of example.com don't want to trust hostingprovider.com with their private keys, and the admins of hostingprovider.com don't want the legal liability of holding private keys for example.com either. In the XMPP community we have been working on a solution to this problem (see draft-ietf-xmpp-dna), but the problem applies more generally (IMAP, etc.) and is becoming more urgent with the spread of hosted applications. Richard Barnes has coined the term "High Assurance Re-Direction" ("HARD") for this problem. He and I have been planning to write an I-D that describes this "HARD problem", but it's becoming increasingly unlikely that we'll meet the I-D cutoff before Maastricht. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000004030804090403050904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDE4NDMzMlowIwYJKoZIhvcNAQkEMRYEFHGLYG+xBVtlACUNt4hJ PNi/vYp0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAWfWILdI5viX/CYlRnDZGJADBS6ulCV+cKzDmyaHq oxmyh7pDldwP5LKtD2IUk8prrbVjD3aF1p5TnTOyEv1+5M7IV3zQ1rEkN5VwGhmq8jB+gbX9 70PEaN8bHZYsJnbbH/ZWcm2ocGn43waE8P1gghvkYLfRo7Yu4ZNkXumw7z/9OJsXU0X64xYW T1FpnT4plBHS097OJHQaLw/VnDeklIqxU5RgtlS4XpXVOuiQAEKa2zdtFUgbmhiZTr2JIxHn huJWWQ8Y0hCDaVkH82ytqDp4QliuifUuPOxGEEDQTuocyEeSwJkifffkUB9U6t5jqn9g6vB/ mY1LdePpCsDfkgAAAAAAAA== --------------ms000004030804090403050904-- From stpeter@stpeter.im Wed Jun 30 11:54:18 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A3D3A69BC for ; Wed, 30 Jun 2010 11:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKK2nToth2+a for ; Wed, 30 Jun 2010 11:54:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0D53A3A6911 for ; Wed, 30 Jun 2010 11:54:17 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7B0D840E4D for ; Wed, 30 Jun 2010 12:54:27 -0600 (MDT) Message-ID: <4C2B92E2.50401@stpeter.im> Date: Wed, 30 Jun 2010 12:54:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> <4C2B8E43.7070806@isode.com> In-Reply-To: <4C2B8E43.7070806@isode.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020604060705020301040109" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 18:54:18 -0000 This is a cryptographically signed message in MIME format. --------------ms020604060705020301040109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 12:34 PM, Alexey Melnikov wrote: > Paul Hoffman wrote: >=20 >> At 9:27 AM -0700 6/30/10, Love H=C3=B6rnquist =C3=85strand wrote: >> =20 >> >>> I think that both "direct" and "indirect" SHOULD be allowed at the >>> same time. >>> >>> The reason is that if you have a client that supports SRV lookups, in= >>> for example jabber, then you want to have the SRV name in there so >>> the client can match the server cert with what the user typed. >>> >>> Of course there are jabber clients out there that don't support SRV >>> lookup and want to to the normal direct mappings rules. >>> >>> Since the server doesn't really know what client they talk to it need= >>> to hand out a cert that matches both rules -> must hAve both for >>> interop reasons. >>> >>> So the direct names are not used for intermediate values, they are >>> only used with names what comes/is derived user input. >>> =20 >> Unfortunately, I agree with this logic. >> > I agree with this logic too (without "unfortunately" ;-)). >=20 >> I say "unfortunately" because it means that we then don't have a MUST,= >> and therefore lose interoperability. For sanity, the document needs to= >> say why it is OK to have both direct and indirect and what to do when >> they are both there, but I agree that we can't say MUST have only one.= >> =20 >> > I think a document specifying how to perform TLS server identity > verification for a particular protocol can specify if only one of them > can be allowed (and which one), or if both can be allowed. This > addresses interoperability for a particular protocol. I would dearly like to say "MUST use DNS-ID" so that we have a baseline for interoperability across all application protocols. However, it seems that the best we can do is interoperability for a given application protocol (HTTP, IMAP, SIP, XMPP, etc.). That saves the kind of interoperability people really care about, but it does make life a bit more complicated for certification authorities and makes this BCP less clean. Unfortunately, reality is messy... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020604060705020301040109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDE4NTQyNlowIwYJKoZIhvcNAQkEMRYEFM0+sh4zamgZmuSZEQwQ 3xUDLQxHMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAGK8VSjbQ9qthnQEhrvINUfTi+sq/y3RltUfkMQrn 3oMPKronZz8He60j8dy40vIykLpefRZe1q6i0y9upj4ro+UG+YKkIdKEzFVgR00/JNYZ+LhZ +DM0oNxrtARn+dpOEeSH7f2DQZ35udNyuwud7xqn3xJWFMyuVktgbcl5r1Ooy1sHIzZNy6Zk t0VJBzAeVMZjzIApAZyicpZBfATBN49fSSwt9MtAC5PH+9zLBg3PI8jpHul5PvcsenmmIaiK E3wMuaFuWEJCdORTIByd2O97xkHWnsOp5ukKYuAQ1/8Xyg6mgk+Y9+IkA+IwWnaMr3s4rSGR h48wA8kJStcOrAAAAAAAAA== --------------ms020604060705020301040109-- From stpeter@stpeter.im Wed Jun 30 12:52:56 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74E303A6891 for ; Wed, 30 Jun 2010 12:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZYEfDBVoacj for ; Wed, 30 Jun 2010 12:52:55 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 20C4B3A6823 for ; Wed, 30 Jun 2010 12:52:55 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 45AA340E4D for ; Wed, 30 Jun 2010 13:53:05 -0600 (MDT) Message-ID: <4C2BA09F.8020908@stpeter.im> Date: Wed, 30 Jun 2010 13:53:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060400040200090108010601" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 19:52:56 -0000 This is a cryptographically signed message in MIME format. --------------ms060400040200090108010601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 12:18 PM, Paul Hoffman wrote: > At 9:27 AM -0700 6/30/10, Love H=C3=B6rnquist =C3=85strand wrote: >> I think that both "direct" and "indirect" SHOULD be allowed at the >> same time. >>=20 >> The reason is that if you have a client that supports SRV lookups, >> in for example jabber, then you want to have the SRV name in there >> so the client can match the server cert with what the user typed. >>=20 >> Of course there are jabber clients out there that don't support SRV >> lookup and want to to the normal direct mappings rules. >>=20 >> Since the server doesn't really know what client they talk to it >> need to hand out a cert that matches both rules -> must hAve both >> for interop reasons. >>=20 >> So the direct names are not used for intermediate values, they are >> only used with names what comes/is derived user input. >=20 > Unfortunately, I agree with this logic. I say "unfortunately" because > it means that we then don't have a MUST, and therefore lose > interoperability. For sanity, the document needs to say why it is OK > to have both direct and indirect and what to do when they are both > there, but I agree that we can't say MUST have only one. Upon further reflection, I think there are two dimensions here: 1. From the client's perspective, some names are direct (provided by the user =3D DNS-ID, CN-ID, URI-ID) and some names are indirect (resolved by the client based on the input provided by the user =3D SRV-ID). This dimension matters for verification. 2. From the service provider's persective, some names are unrestricted (can be used in any application =3D DNS-ID and CN-ID) and some names are unrestricted (can be used in only one kind of application =3D SRV-ID and URI-ID). This dimension matters for issuance. I'll work to formulate this distinction more carefully in text that can be included in the spec. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms060400040200090108010601 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDE5NTMwM1owIwYJKoZIhvcNAQkEMRYEFAOzCTjZAWOGGZ9OxVMw fnyCX66zMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAI1VL2bLf5A7oUYI8TSFe8Y7SXTJrczy+EWPYGjzL ZfJNzZDl00S/QxWCQumx1wi8at754otcEW+OiYlk3T9tu0T4K1Fz4aqzFYDAwe9/Kk0V0m2f eF/aC359czd1V/PkOUh782HTX9LcPwij4I8WrlpKx+3bD7bNJEXYy3r09i8LFj9auJGewz8f IagiLkhFiQ0uAkvQQfXkqGreOVH4myqqbL0vLNE0bPpcvinj2wqCnDoYY/32vAuP5tKBZm3F sefyrhdU68qeSWLjzWJHeOa1T5u8lg94r3BAjg1pESVJEATMtJZla9Tn/4aPY9ocBlUB5eK7 IYDwhU3uhQaX8gAAAAAAAA== --------------ms060400040200090108010601-- From paul.hoffman@vpnc.org Wed Jun 30 13:00:25 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4014C3A6924 for ; Wed, 30 Jun 2010 13:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7PvFrAruH8c for ; Wed, 30 Jun 2010 13:00:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 85DFE3A6809 for ; Wed, 30 Jun 2010 13:00:24 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5UK0YW2089471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 13:00:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C2BA09F.8020908@stpeter.im> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> <4C2BA09F.8020908@stpeter.im> Date: Wed, 30 Jun 2010 13:00:32 -0700 To: Peter Saint-Andre , certid@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 20:00:25 -0000 At 1:53 PM -0600 6/30/10, Peter Saint-Andre wrote: >Upon further reflection, I think there are two dimensions here: > >1. From the client's perspective, some names are direct (provided by the >user = DNS-ID, CN-ID, URI-ID) and some names are indirect (resolved by >the client based on the input provided by the user = SRV-ID). This >dimension matters for verification. > >2. From the service provider's persective, some names are unrestricted >(can be used in any application = DNS-ID and CN-ID) and some names are >unrestricted (can be used in only one kind of application = SRV-ID and >URI-ID). This dimension matters for issuance. That should be "...and some names are restricted (can be used in only...". But, yes, this is a good distinction. >I'll work to formulate this distinction more carefully in text that can >be included in the spec. That would help implementers (and hopefully CAs) a lot. --Paul Hoffman, Director --VPN Consortium From lha@apple.com Wed Jun 30 13:50:55 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC96E3A6B20 for ; Wed, 30 Jun 2010 13:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.601 X-Spam-Level: X-Spam-Status: No, score=-105.601 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7tdxwqdTdql for ; Wed, 30 Jun 2010 13:50:47 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id B9CC53A696B for ; Wed, 30 Jun 2010 13:50:46 -0700 (PDT) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id F03CE9AD97C3 for ; Wed, 30 Jun 2010 13:50:49 -0700 (PDT) X-AuditID: 11807136-b7c9dae000000fcd-63-4c2bae29b98a Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay15.apple.com (Apple SCV relay) with SMTP id 2F.51.04045.92EAB2C4; Wed, 30 Jun 2010 13:50:49 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [10.82.192.45] (166-205-136-152.mobile.mymmode.com [166.205.136.152]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L4U00FWVHWL32A0@gertie.apple.com> for certid@ietf.org; Wed, 30 Jun 2010 13:50:49 -0700 (PDT) References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> In-reply-to: <4C2B843A.5010206@stpeter.im> Message-id: <5571525D-A0FF-4A9B-A040-1F2DFDEFE491@apple.com> X-Mailer: iPhone Mail (8A293) From: =?utf-8?Q?Love_H=C3=B6rnquist_=C3=85strand?= Date: Wed, 30 Jun 2010 13:51:59 -0700 To: Peter Saint-Andre X-Brightmail-Tracker: AAAAAQAAAZE= Cc: "certid@ietf.org" Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 20:50:56 -0000 30 jun 2010 kl. 10:51 skrev Peter Saint-Andre : > On 6/30/10 11:46 AM, Martin Rex wrote: >> Peter Saint-Andre wrote: >>> >>> Based on feedback from you and from Kurt, I have changed the foregoing >>> paragraph to: >>> >>> Certificates are binary objects -- they are encoded using >>> distinguished encoding rules (DER). Thus, the generation of >>> displayable (a.k.a. printable) renderings of certificate subject and >>> issuer names means that the DER-encoded sequences are decoded and >>> converted into a "string representation" before being rendered. >>> Because a DN is an ordered sequence, order is preserved in the string >>> representation of a DN. However, because an RDN is an unordered >>> group of attribute-type-and-value pairs, the string representation of >>> an RDN can differ from the canonical DER encoding; in the canonical >>> encoding, the RDN that is nearest to the root of the naming tree is >>> called the "most significant" RDN and the RDN that is deepest in the >>> tree (and that therefore distinguishes the relative name) is called >>> the "most specific" RDN. See [LDAP-DN] for details. >> >> I'm actually confused by refering to one end with "most significant" and >> the other with "most specific". Couldn't we just drop the "most significant" >> entirely and use "least specific" / "most specific" for the two ends? > > Given that we never use the term "most significant" in this I-D, I'd say > we can remove any mention of it. Peter, Can you please add a DER encoded Name, the asn1parse/dump version of the name, and the LDAP version of string and annotation what the different parts are called, this confuses me every time I try to in parse the rfc's and drafts. Thanks Love > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > > _________ From stpeter@stpeter.im Wed Jun 30 14:56:23 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDCF3A695F for ; Wed, 30 Jun 2010 14:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1m6oEVAm9ua9 for ; Wed, 30 Jun 2010 14:56:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E9BD33A69CE for ; Wed, 30 Jun 2010 14:56:21 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 125DF40E4D for ; Wed, 30 Jun 2010 15:56:31 -0600 (MDT) Message-ID: <4C2BBD8D.5080300@stpeter.im> Date: Wed, 30 Jun 2010 15:56:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "certid@ietf.org" References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <5571525D-A0FF-4A9B-A040-1F2DFDEFE491@apple.com> In-Reply-To: <5571525D-A0FF-4A9B-A040-1F2DFDEFE491@apple.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020900050407060601090600" Subject: Re: [certid] Need to define "most specific RDN" X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 21:56:23 -0000 This is a cryptographically signed message in MIME format. --------------ms020900050407060601090600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 2:51 PM, Love H=C3=B6rnquist =C3=85strand wrote: >=20 > 30 jun 2010 kl. 10:51 skrev Peter Saint-Andre : >=20 >> On 6/30/10 11:46 AM, Martin Rex wrote: >>> Peter Saint-Andre wrote: >>>>=20 >>>> Based on feedback from you and from Kurt, I have changed the >>>> foregoing paragraph to: >>>>=20 >>>> Certificates are binary objects -- they are encoded using=20 >>>> distinguished encoding rules (DER). Thus, the generation of=20 >>>> displayable (a.k.a. printable) renderings of certificate >>>> subject and issuer names means that the DER-encoded sequences >>>> are decoded and converted into a "string representation" before >>>> being rendered. Because a DN is an ordered sequence, order is >>>> preserved in the string representation of a DN. However, >>>> because an RDN is an unordered group of >>>> attribute-type-and-value pairs, the string representation of an >>>> RDN can differ from the canonical DER encoding; in the >>>> canonical encoding, the RDN that is nearest to the root of the >>>> naming tree is called the "most significant" RDN and the RDN >>>> that is deepest in the tree (and that therefore distinguishes >>>> the relative name) is called the "most specific" RDN. See >>>> [LDAP-DN] for details. >>>=20 >>> I'm actually confused by refering to one end with "most >>> significant" and the other with "most specific". Couldn't we >>> just drop the "most significant" entirely and use "least >>> specific" / "most specific" for the two ends? >>=20 >> Given that we never use the term "most significant" in this I-D, >> I'd say we can remove any mention of it. >=20 > Peter, >=20 > Can you please add a DER encoded Name, the asn1parse/dump version of > the name, and the LDAP version of string and annotation what the > different parts are called, this confuses me every time I try to in > parse the rfc's and drafts. I'm still just learning about all of these different terms, formats, versions, and representations. And yes it is quite confusing. Perhaps I'll ask one of the co-editors or contributors to come up with a good example as you have requested... Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms020900050407060601090600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDIxNTYyOVowIwYJKoZIhvcNAQkEMRYEFO1o+0/tyu611Yx1NZIU OiuhbBQuMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAKQc9yT4JqPjiAuXu9BdIJf1LmfkrQbX/fr4Eju8u FV4BvSzGYfcxIouGZsSsE27UpNpgDxljcK6bwf6h+4csUHZp5qtgF+8CILWyW6iGe9wpgLPx UM3kt+s+ZZSDqr9cqfI0AuhI6BM27dJrJnp+RNcEEfRzyNqa/lUjzCDdg7rx1/KrHq+j7mkD j0y0pWvE0ljFvDPj5GpmTSf080A3Osx4K+2Qq+lr/kUiRlfhe716y5FyKfTDUGuw1bKiP+q6 cTvy6G/JrVybtegaarsccyjYtys3rSqw5k1BTw1UURhXMzfGz5tovRGSE7Pns0TByMTf6oXz TucfVw6WLBfEQwAAAAAAAA== --------------ms020900050407060601090600-- From stpeter@stpeter.im Wed Jun 30 15:01:18 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806673A6928 for ; Wed, 30 Jun 2010 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok-2qVMiPQBh for ; Wed, 30 Jun 2010 15:01:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 719BA3A659C for ; Wed, 30 Jun 2010 15:01:17 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3764E40E4D for ; Wed, 30 Jun 2010 16:01:07 -0600 (MDT) Message-ID: <4C2BBEA1.1090506@stpeter.im> Date: Wed, 30 Jun 2010 16:01:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: certid@ietf.org References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> <4C2BA09F.8020908@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060708080004060107000505" Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 22:01:18 -0000 This is a cryptographically signed message in MIME format. --------------ms060708080004060107000505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 6/30/10 2:00 PM, Paul Hoffman wrote: > At 1:53 PM -0600 6/30/10, Peter Saint-Andre wrote: >> Upon further reflection, I think there are two dimensions here: >>=20 >> 1. From the client's perspective, some names are direct (provided >> by the user =3D DNS-ID, CN-ID, URI-ID) and some names are indirect >> (resolved by the client based on the input provided by the user =3D >> SRV-ID). This dimension matters for verification. >>=20 >> 2. From the service provider's persective, some names are >> unrestricted (can be used in any application =3D DNS-ID and CN-ID) >> and some names are unrestricted (can be used in only one kind of >> application =3D SRV-ID and URI-ID). This dimension matters for >> issuance. >=20 > That should be "...and some names are restricted (can be used in > only...".=20 Typing too fast here. :) > But, yes, this is a good distinction. >=20 >> I'll work to formulate this distinction more carefully in text that >> can be included in the spec. >=20 > That would help implementers (and hopefully CAs) a lot. Here is a first draft... ### 2.1. Naming Applications This specification assumes that an Internet application is named based on a DNS domain name (e.g., "example.com") -- supplemented in some circumstances by an application type (e.g., "the IMAP server at example.com"). From the perspective of the application client or user, some names are direct because they are provided directly by the user (e.g., via runtime input or prior configuration) whereas other names are indirect because they are resolved by the client based on input provided by the user (e.g., a target name resolved from a source name using DNS SRV records). This dimension matters for certificate verification. From the perspective of the application server or service provider, some names are unrestricted because they can be used in any kind of application (e.g., a certificate might be re-used for both the HTTP service and the IMAP service at example.com) whereas other names are restricted because they can be used in only one kind of application (e.g., a special-purpose certificate that can be used only for an IMAP service). This dimension matters for certificate issuance. Therefore: o A CN-ID identifier is direct (provided by a user) and unrestricted (can be used for any application). o A DNS-ID identifier is direct (provided by a user) and unrestricted (can be used for any application). o An SRV-ID identifier is indirect (resolved by a client) and restricted (can be used for only a single application). o A URI-ID identifier is direct (provided by a user) and restricted (can be used for only a single application). We summarize this taxonomy in the following table. +-----------+-----------+---------------+ | | Direct | Restricted | +-----------+-----------+---------------+ | CN-ID | Yes | No | +-----------+-----------+---------------+ | DNS-ID | Yes | No | +-----------+-----------+---------------+ | SRV-ID | No | Yes | +-----------+-----------+---------------+ | URI-ID | Yes | Yes | +-----------+-----------+---------------+ When implementing software, deploying services, and issuing certificates for secure PKIX-based authentication, it is important to keep these distinctions in mind. In particular, best practices differ somewhat for application server implementations, application client implementations, service providers, and certification authorities. Protocol specifications that reference this document MUST specify which identifiers are mandatory-to-implement by servers and clients, which identifiers are to be preferred by service providers, and which identifiers ought to be supported by certificate issuers. Because these requirements differ across applications, it is impossible to categorically stipulate universal rules (e.g., that all software implementations, service providers, and certification authorities for all application protocols need to use or support DNS- IDs as a baseline for the purpose of interoperability); however, it is preferable that each application protocol will at least define a baseline that applies to the community of software developers, service providers, and CAs actively using or supporting that technology. ### --------------ms060708080004060107000505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDYzMDIyMDEwNVowIwYJKoZIhvcNAQkEMRYEFCB7SHgFZf3uH4gm+GpJ 9hAL2Kw+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAQk+kZiQdN4UiAT4iMIn796UxaJdkg/E5CKkc83wk 45/H5e0g2KFT3U5AgXn8z3gWx7y2waeNAWMDDzM6e9nzHoDmPRKS0oB/QMbhH6o6ekgIJT/y ssF0ENbWqmwfUsg1Jn7n0OhBaHYbzYvCMLaHy9ejoKwzDAmmI5VTeXmvQ12teedqcTqnv7Iq 9IsrQf/JCVhPifY3f1WbYJWEK1j+jq8vsiv8wLW79mxtbAUI8L2HDF6NALf+hh5hKoNQF7+f vSj2lxvSDaXSX0riZ82ZrGJk2PNlaCWcVgjufZ3fFeY4Ce/y6ZYLohrvkAI1gF8W4SSWt3/1 FST2Vuwq3yEoFAAAAAAAAA== --------------ms060708080004060107000505-- From mrex@sap.com Wed Jun 30 16:29:25 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2483A693E for ; Wed, 30 Jun 2010 16:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.617 X-Spam-Level: X-Spam-Status: No, score=-8.617 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UGpCvY7lZZO for ; Wed, 30 Jun 2010 16:29:24 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 05B423A67CC for ; Wed, 30 Jun 2010 16:29:23 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o5UNTXSi001328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Jul 2010 01:29:34 +0200 (MEST) From: Martin Rex Message-Id: <201006302329.o5UNTXLF012594@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 1 Jul 2010 01:29:33 +2600 (MEST) In-Reply-To: <4C2BBEA1.1090506@stpeter.im> from "Peter Saint-Andre" at Jun 30, 10 04:01:05 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jun 2010 23:29:25 -0000 Actually, _some_ of the PKIX-heavy APPS might want to restrict usability of server certificates by "extendedKeyUsage" in addition to what we define as server endpoint identification here. The wording in rfc-5280 section 4.2.1.12 appears a self-contradictory to me, because it conditionalizes "MUST only" with "applications MAY do whatever they see fit", and application negligence is likely to be the norm. And btw. how "applications MAY" is used it refers to individual implementations and such an interpretation aligns well with the more easily understandable text in rfc-2459. If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application. -Martin Peter Saint-Andre wrote: > > Therefore: > > o A CN-ID identifier is direct (provided by a user) and unrestricted > (can be used for any application). > o A DNS-ID identifier is direct (provided by a user) and > unrestricted (can be used for any application). > o An SRV-ID identifier is indirect (resolved by a client) and > restricted (can be used for only a single application). > o A URI-ID identifier is direct (provided by a user) and restricted > (can be used for only a single application). > > We summarize this taxonomy in the following table. > > +-----------+-----------+---------------+ > | | Direct | Restricted | > +-----------+-----------+---------------+ > | CN-ID | Yes | No | > +-----------+-----------+---------------+ > | DNS-ID | Yes | No | > +-----------+-----------+---------------+ > | SRV-ID | No | Yes | > +-----------+-----------+---------------+ > | URI-ID | Yes | Yes | > +-----------+-----------+---------------+ > > When implementing software, deploying services, and issuing > certificates for secure PKIX-based authentication, it is important to > keep these distinctions in mind. In particular, best practices > differ somewhat for application server implementations, application > client implementations, service providers, and certification > authorities. Protocol specifications that reference this document > MUST specify which identifiers are mandatory-to-implement by servers > and clients, which identifiers are to be preferred by service > providers, and which identifiers ought to be supported by certificate > issuers. Because these requirements differ across applications, it > is impossible to categorically stipulate universal rules (e.g., that > all software implementations, service providers, and certification > authorities for all application protocols need to use or support DNS- > IDs as a baseline for the purpose of interoperability); however, it > is preferable that each application protocol will at least define a > baseline that applies to the community of software developers, > service providers, and CAs actively using or supporting that > technology. From xmlscott@gmail.com Wed Jun 30 18:01:59 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA793A68D8 for ; Wed, 30 Jun 2010 18:01:59 -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=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CqRJA7uth-I for ; Wed, 30 Jun 2010 18:01:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id ADE013A68C7 for ; Wed, 30 Jun 2010 18:01:58 -0700 (PDT) Received: by vws14 with SMTP id 14so47400vws.31 for ; Wed, 30 Jun 2010 18:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ce0UvBV2wsvsEFD7C3ShNCs65ZBaEPgaY2PrVgxTxYI=; b=wTLBWn04r5NeQ/XEW18srHq19di0CA5cqVCmXHkCmDFcjDr2JttT3QseeoyPM5xL7L u22M0PQ1COdXNROqwAU0aJYvJ3n0a8uWNCiDveX70qQlx0tFWGsPKGcfvK+odiQyLPRH zjHBb0+sf6FqkpeLp8rbOWt6LEHogFdCyaqKY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=q5CWlqJ9uyFAdwUvOXm94dUwzg4yF24qEbiuv/aweKG4k9vaJDPJ/Tumj8ZdYFxWo4 5S8GItQaj3rbeIGxHAGoG7xMutQ7Knj+l19kw2pwc468bBFUG8bHgKRyxRRdgt7kpIT9 0e2cvO72g5v4gCLQ0KaM/2jSkfYgkUIJftEbA= Received: by 10.220.128.203 with SMTP id l11mr5210513vcs.265.1277946126777; Wed, 30 Jun 2010 18:02:06 -0700 (PDT) Received: from ybr.home.skrb.org (c-98-229-134-198.hsd1.ma.comcast.net [98.229.134.198]) by mx.google.com with ESMTPS id k8sm5232879vcr.30.2010.06.30.18.02.05 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Jun 2010 18:02:06 -0700 (PDT) Message-ID: <4C2BE90A.90800@gmail.com> Date: Wed, 30 Jun 2010 21:02:02 -0400 From: Scott Lawrence User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: certid@ietf.org References: <4C1CABA1.2050205@isode.com> <4C2A6A72.5000109@stpeter.im> <20100630040935.GA26880@isc.upenn.edu> <4C2B9054.40703@stpeter.im> In-Reply-To: <4C2B9054.40703@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 01:02:00 -0000 On 2010-06-30 14:43, Peter Saint-Andre wrote: > Correct. Here's the rub: > > mail.hostingprovider would have to be configured with that > certificate (with the co-operation of example.com). > > In most cases, the admins of example.com don't want to trust > hostingprovider.com with their private keys, and the admins of > hostingprovider.com don't want the legal liability of holding private > keys for example.com either. But mail.hostingprovider never needs the private keys for example.com - all they need is a cert signed by example.com. The TLS client can tell hostingprovider which cert to present, so they can have different ones for each client (of course, mine doesn't do that, but they could). From stpeter@stpeter.im Wed Jun 30 20:35:18 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF093A67D3 for ; Wed, 30 Jun 2010 20:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pl8wZH+oXFiO for ; Wed, 30 Jun 2010 20:35:15 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A1EED3A657C for ; Wed, 30 Jun 2010 20:35:09 -0700 (PDT) Received: from squire.local (dsl-179-197.dynamic-dsl.frii.net [216.17.179.197]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2117740E4D for ; Wed, 30 Jun 2010 21:35:20 -0600 (MDT) Message-ID: <4C2C0CF6.10608@stpeter.im> Date: Wed, 30 Jun 2010 21:35:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010700070307070908080007" Subject: [certid] version -07 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 03:35:18 -0000 This is a cryptographically signed message in MIME format. --------------ms010700070307070908080007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Based on all the list feedback provided so far, I've pushed out a new version (-07) for your review: http://www.ietf.org/id/draft-saintandre-tls-server-id-check-07.txt I'll post diffs as soon as they are available. Please note that I have not coordinated all of the modifications with my co-editor, so Jeff might poke me tomorrow to complain. :) Both draft-daboo-srv-email and draft-ietf-xmpp-3920bis depend on this I-D, so we're hoping to gather any further feedback soon and finish it off in the near future. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010700070307070908080007 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDcwMTAzMzUxOFowIwYJKoZIhvcNAQkEMRYEFOiigdCXgyEltyrUc5Kl a0MLfN5CMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAe4SjIygvVpTML1SqPVCILiaBw+jdt2IaiLxHMNz/ W685C4rJAny88sCC92dqaHnh8zY23nWPUgfXCjBOiolNsecvGipPOqlAHoHn9GgljUsCmZAW Z7+gu5Mmo0skeC/6UEbia6to8sEWg5no+bpjzEqTw5hvtawjXDZc1jgHzH8oBF/mHVagWP6C kvOdON7xcL1ZyFaFb0rKDNCedo0zvuvOBYlc7bjpL0qFrBT4IyJ2Try3ICRTX7CgwcYqZt7w 0BnGB3kbg9TnDCCMz7qsx4zV/7BN0Z+2/fXcdWwTwZz28uAPyXjVm6YQelMBnbSDP/UECrsk L6+CxM3S85rm3gAAAAAAAA== --------------ms010700070307070908080007-- From shuque@isc.upenn.edu Wed Jun 30 21:55:47 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4953F3A67FA for ; Wed, 30 Jun 2010 21:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfbLSs6eHhbK for ; Wed, 30 Jun 2010 21:55:46 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 7362B3A67CF for ; Wed, 30 Jun 2010 21:55:46 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 732973057; Thu, 1 Jul 2010 00:55:57 -0400 (EDT) Date: Thu, 1 Jul 2010 00:55:57 -0400 From: Shumon Huque To: Peter Saint-Andre Message-ID: <20100701045557.GA3758@isc.upenn.edu> References: <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <20100630043158.GB26880@isc.upenn.edu> <07D9A6FC-C154-4125-AC33-45F2CE0C0374@apple.com> <4C2BA09F.8020908@stpeter.im> <4C2BBEA1.1090506@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C2BBEA1.1090506@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 04:55:47 -0000 On 6/30/10 2:00 PM, Paul Hoffman wrote: [...] > I agree that we have to look at the details of the service. To me, > there are two types of names: > - direct (CN-ID, DNS-ID, and URI-ID) > - indirect (SRV-ID) On Wed, Jun 30, 2010 at 04:01:05PM -0600, Peter Saint-Andre wrote: [...] > Therefore: > > o A CN-ID identifier is direct (provided by a user) and unrestricted > (can be used for any application). > o A DNS-ID identifier is direct (provided by a user) and > unrestricted (can be used for any application). > o An SRV-ID identifier is indirect (resolved by a client) and > restricted (can be used for only a single application). > o A URI-ID identifier is direct (provided by a user) and restricted > (can be used for only a single application). I'm not sure I buy this classification. I was trying to figure out what Paul meant by "direct" and "indirect" - it looks like direct means "provided by client" and indirect means "DNS resolution was involved". In that sense I don't see any distinct category for SRV-ID. The information in the SRV-ID *is* provided by the client. If the client is attempting to connect to the IMAP service at example.com, it already has all the information to construct the SRV identity (_imap.example.com) - no DNS resolution was involved. DNS resolution is involved in all 4 of these identity types in order to get the network layer address of the server for connection establishment purposes. This should be differentiated from the identity of the server used for TLS/PKIX authentication. CN-ID, DNS-ID, URI-ID will involve A, AAAA DNS resolutions. And don't forget that they might also involve aliases (CNAMEs). The more meaningful classification to me involves the difference between generic domain name identities (CN-ID, DNS-ID) and application specific identities (SRV-ID, URI-ID). (Actually URI-ID can be even more granular, by also specifying a particular resource/path within an application, but I don't think we want to deal with that in this draft -- to manage the scope of this draft, maybe we need to constrain the format of URIs that we are addressing). --Shumon. From shuque@isc.upenn.edu Wed Jun 30 22:05:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535A63A68D9 for ; Wed, 30 Jun 2010 22:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z23UsazIaNiy for ; Wed, 30 Jun 2010 22:05:48 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 78EB53A6855 for ; Wed, 30 Jun 2010 22:05:48 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 8DF923057; Thu, 1 Jul 2010 01:05:59 -0400 (EDT) Date: Thu, 1 Jul 2010 01:05:59 -0400 From: Shumon Huque To: Martin Rex Message-ID: <20100701050559.GB3758@isc.upenn.edu> References: <201006301551.o5UFpwjh008254@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006301551.o5UFpwjh008254@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 05:05:49 -0000 On Wed, Jun 30, 2010 at 05:51:58PM +0200, Martin Rex wrote: > > While CN-ID and DNS-ID have exactly the same scope (hostname) > SRV-ID and URI-ID have a more restrictive scope. Does a combination > make sense? Or do we expect that to happen only during migration > from a currently used CN-ID or DNS-ID to a SRV-ID or URI-ID? > Keep in mind that "flag days" where the _entire_ installed base is taken down, > changed/updated and put back up, are difficult and rare in practice. My take is the combination makes sense primarily for migration periods (which might be long in some cases). > Should CN-ID or DNS-ID be entirely ignored when SRV-ID or URI-ID is > found and understood/used by a client for server endpoint identification? > in the sense that SRV-ID and URI-ID supersede CN-ID or DNS-ID for the > clients which understand them? Yes, I think so. I think the draft already specifies a preference order putting SRV-ID and URI-ID ahead of the DNS-ID/CN-ID. --Shumon. From shuque@isc.upenn.edu Wed Jun 30 22:24:16 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF52B3A67FA for ; Wed, 30 Jun 2010 22:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYlj1bixat7P for ; Wed, 30 Jun 2010 22:24:11 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 4A6223A67CF for ; Wed, 30 Jun 2010 22:24:09 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 0E25A3058; Thu, 1 Jul 2010 01:24:21 -0400 (EDT) Date: Thu, 1 Jul 2010 01:24:20 -0400 From: Shumon Huque To: Martin Rex Message-ID: <20100701052420.GA4920@isc.upenn.edu> References: <4C2BBEA1.1090506@stpeter.im> <201006302329.o5UNTXLF012594@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006302329.o5UNTXLF012594@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: certid@ietf.org Subject: Re: [certid] What DNS-ID if also using a DNS-SRV? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 05:24:16 -0000 On Thu, Jul 01, 2010 at 01:29:33AM +2600, Martin Rex wrote: > Actually, _some_ of the PKIX-heavy APPS might want to restrict > usability of server certificates by "extendedKeyUsage" in addition > to what we define as server endpoint identification here. > > The wording in rfc-5280 section 4.2.1.12 appears a self-contradictory > to me, because it conditionalizes "MUST only" with "applications MAY do > whatever they see fit", and application negligence is likely to be > the norm. And btw. how "applications MAY" is used it refers to > individual implementations and such an interpretation aligns well > with the more easily understandable text in rfc-2459. > > > If the extension is present, then the certificate MUST only be used > for one of the purposes indicated. If multiple purposes are > indicated the application need not recognize all purposes indicated, > as long as the intended purpose is present. Certificate using > applications MAY require that the extended key usage extension be > present and that a particular purpose be indicated in order for the > certificate to be acceptable to that application. > > > -Martin Yeah, I was actually waiting to see who brings this up first! :-) A smaller group of us had discussions about this (via private e-mail prior to the certid list being set up). I'm sure the others will chime in with their thoughts. But our general impression is that KU/EKU are very poorly understood. Some of my principal concerns with using them for application restriction are that the current ones aren't defined precisely enough. Ideally you need a new EKU for every new application protocol for proper security compartmentalization. Also they depend on a more complicated set of things happening correctly on both the server and client side. The client has to perform an additional step in addition to matching the subject identity. And actually to ensure that the use of the cert is being constrained, the EKU extension has to be marked critical (which I think breaks some modes of migration) - assuming of course that client software rejects the cert if they don't understand the EKU extension, which may not be a true assumption for the deployed base of software. --Shumon.