Re: Review of draft-saintandre-tls-server-id-check
Peter Saint-Andre <stpeter@stpeter.im> Mon, 13 September 2010 19:16 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EE23A6A97; Mon, 13 Sep 2010 12:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level:
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, 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 GAYuM0Q0z7EW; Mon, 13 Sep 2010 12:16:33 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E844B3A6A70; Mon, 13 Sep 2010 12:16:32 -0700 (PDT)
Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BEAE400EE; Mon, 13 Sep 2010 13:21:04 -0600 (MDT)
Message-ID: <4C8E78A9.7040608@stpeter.im>
Date: Mon, 13 Sep 2010 13:16:57 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
Subject: Re: Review of draft-saintandre-tls-server-id-check
References: <C8B43C8F.EE18%stefan@aaa-sec.com>
In-Reply-To: <C8B43C8F.EE18%stefan@aaa-sec.com>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, IETF cert-based identity <certid@ietf.org>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Sep 2010 19:16:38 -0000
On 9/13/10 12:39 PM, Stefan Santesson wrote: > Peter, > > On 10-09-13 6:08 PM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote: >> >> Hi Shumon, >> >> As I see it, this I-D is attempting to capture best current practices >> regarding the issuance and checking of certificates containing >> application server identities. Do we have evidence that any existing >> certification authorities issue certificates containing both an SRVname >> for the source domain (e.g., example.com) and dNSName for the target >> domain (e.g., apphosting.example.net)? Do we have evidence that any >> existing application clients perform such checks? If not, I would >> consider such complications to be out of scope for this I-D. >> >> That said, we need to be aware that if such usage arises in the future, >> someone might write a document that updates or obsoletes this I-D; in >> fact the present authors very much expect that such documents will >> emerge after the Internet community (specifically certification >> authorities, application service providers, and application client >> developers) have gained more experience with PKIX certificates in the >> context of various application technologies. >> >> Peter > > I would like to turn the question around and ask why this specification need > to have an opinion on whether a relying party feels he have to check both > host name and service? Stop right there. :) I sense a possible source of confusion. What do you mean by "host name" and what do you mean by "service"? In this I-D, we talk about "DNS domain name" and "service type", which map quite well to _Service.Name from RFC 4985: the DNS domain name is the "source domain" provided by the user or configured into the client (e.g., "example.com") and the "service type" is a given application protocol that could be serviced by the source domain (e.g., "IMAP"). This I-D is attempting to gently nudge people in the direction of checking both the DNS domain name and the service type. IMHO this is consistent with considering the SRVName and uniformResourceIdentifier subjectAltName entries as more tightly scoped than dNSName or CN, and therefore as potentially more "secure" in some sense (the subject might want to limit use of a particular certificate to only the service type identified in the SRVName or uniformResourceIdentifier). If by "host name" you mean "target domain" as defined in the I-D (and mapping to "Target" from RFC 2782) then we have more to discuss. > I'm not against describing the typical case, as long as this specification > does not imply that a relying party that has a reason to check two name > types is doing something wrong. That is not the intent of this I-D, however that would be functionality over and above what this I-D defines. > I have no extremely good examples of practical implementation here but > checking both host name and service seems like both extremely easy and good > practice. With respect to revisions to this I-D, the lack of good examples troubles me because we have been trying to abstract from common usage, not to define guidelines for use cases that have not yet been defined, implemented, and deployed. Given that you would prefer to leave the door open to more advanced checking rules, I think you would object to this text in Section 4.3: Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. It does so by seeking a match and stopping the search if any presented identifier matches one of its reference identifiers. The search fails if the client exhausts its list of reference identifiers without finding a match. You are saying that it is not necessarily appropriate to stop the search once a single match is found, because the client might be configured to look for multiple matches (e.g., a match against both the source domain and the target domain). Would you like to suggest text that covers such a case? Here is a possible rewrite of Section 4.3 that might address your concern. ### 4.3. Seeking a Match Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. The search fails if the client exhausts its list of reference identifiers without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search. Implementation Note: A client might be configured to perform multiple searches, i.e., to match more than one reference identifier; although such behavior is not forbidden by this document, rules for matching multiple reference identifiers are a matter for implementation or future specification. Security 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 entry types supported by the client. Detailed comparison rules for finding a match are provided in the following sections. ### Peter -- Peter Saint-Andre https://stpeter.im/
- Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check =JeffH
- Re: Review of draft-saintandre-tls-server-id-check t.petch
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: [xmpp] Review of draft-saintandre-tls-server-… Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check t.petch
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Shumon Huque
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- RE: Review of draft-saintandre-tls-server-id-check Bernard Aboba
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: Review of draft-saintandre-tls-server-id-check Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Martin Rex
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Paul Hoffman
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Richard L. Barnes
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Peter Saint-Andre
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Stefan Santesson
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Dave Cridland
- Re: [certid] Review of draft-saintandre-tls-serve… Shumon Huque
- Re: [certid] Review of draft-saintandre-tls-serve… Dave Cridland
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check t.petch
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Re: Review of draft-saintandre-tls-server-id-check Peter Saint-Andre
- Why require EKU for certid? Paul Hoffman
- Re: Why require EKU for certid? Peter Saint-Andre
- Re: [certid] Why require EKU for certid? Martin Rex
- RE: [TLS] Why require EKU for certid? Jim Schaad
- Re: [certid] Why require EKU for certid? Henry B. Hotz