Re: [Gen-art] [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11
Ben Campbell <ben@nostrum.com> Wed, 08 December 2010 05:42 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFAB3A68D3; Tue, 7 Dec 2010 21:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.976
X-Spam-Level:
X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001, 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 1PG3PVvHO08k; Tue, 7 Dec 2010 21:42:43 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 57F2E3A68C5; Tue, 7 Dec 2010 21:42:42 -0800 (PST)
Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oB85i7Xh096798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 Dec 2010 23:44:07 -0600 (CST) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <4CFF114B.5010204@stpeter.im>
Date: Tue, 07 Dec 2010 23:44:07 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <19F8341D-9815-4BB7-8837-83850FAC4F9E@nostrum.com>
References: <p06240832c922cb7e04d9@[10.20.30.151]> <4CFEB1C5.4010103@stpeter.im> <E7A814CA-E758-460A-A340-6444CA82B267@nostrum.com> <4CFF114B.5010204@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1082)
Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism)
Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, certid@ietf.org
Subject: Re: [Gen-art] [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 05:42:46 -0000
On Dec 7, 2010, at 11:02 PM, Peter Saint-Andre wrote: > Thanks, Ben. > > In general, I think this document is describing the tools available to > protocol designers, not telling protocol designers which tools to use. Okay, then :-) On re-reading the thread, I realize I did a lot of dead-horse beating. Further comments below, with the areas I think we are in agreement elided. > > More comments inline. > > On 12/7/10 5:10 PM, Ben Campbell wrote: >> I'm jumping in a bit late with some review followup. It's not >> entirely clear to me where in the thread I should re-insert myself, >> so I apologize if I bring up stuff that would have been resolved or >> otherwise obvious at other points in the thread--I'll dig back >> through and respond further as appropriate. >> >> (And I realize I'm doing lots of arm-waving around >> whats-really-going-on with URI-IDs and SIP. If we need a higher >> bandwidth communication, I can be available.) >> >> Comments inline: >> >> On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote: >> [...] >> >> Understood. It may be that the answer is that the use of URI-ID is >> not sufficiently understood to offer general guidance. OTOH, in the >> case of SIP, the URI-ID appears to be solely for the purpose of >> binding a domain name to the service. Otherwise, the use as defined >> in RFC5922 would be substantially identical to using a DNS-ID. More >> to the point, RFC5922 does not use URI-ID to specify a user identity, >> only a host identity. Would you recommend designers of a new protocol >> to follow that pattern? > > Well, this document is about host ("application service") identity, so > user identity is conveniently out of scope. > Okay >> I note that (unless I missed it) the 5922 >> doesn't seem to allow for falling back to a dNSName. Is that a >> reasonable choice for a new protocol to make? > > I think not. IMHO the fallback is a good idea. But, from previous comments, such guidance does not belong in this draft, right? [...] >> Given the previous conversation about how SIP seems to be the only >> protocol with the equivalent scheme issue that actually uses URI-IDs, >> and that it doesn't seem to need to worry about which scheme its >> using at the moment, I no longer think this draft needs to worry >> about it. If it were to say anything at all along those lines, it >> would probably need to be along the lines of KISS. For example, I >> don't think you want designers trying to assert security properties >> by which scheme they include in a cert (i.e. "foo" vs "foos") > > Well, I do think a using protocol does need to specify which URI scheme > names are acceptable for the application protocol. You wouldn't want a > client to think that fubar://example.com identifies a SIP service. The > tel: URI scheme is an interesting counter-example in some ways. > Not to mention "im:" and "pres:" :-) Am I correct in assuming you mean that in the context of what schemes they will put in a certificate, or match to a certificate, right? As opposed to what schemes are legal in the application protocol as a whole--since these are probably somewhat separate dimensions of extensibility. (If the second, then I'm in over my depth in meta-protocol design, and would certainly defer to an apps area expert if one were handy ;-) ) [...] >>>> -- 4.2.2: >>>> >>>> Can we have a URI-ID example? >>> >>> How's this? >>> >>> A voice-over-IP (VoIP) user agent that is connecting via SIP to >>> the voice service at "voice.example.edu" might have only one >>> reference identifier: a URI-ID of "sip:voice.example.edu" (see >>> [SIP-CERTS]). >>> >> >> Would it make sense to say something to indicate this is true, even >> though the connection may have been opened based on a URI of >> "sip:user@voice.example.edu"? (I'm trying to figure out the best way >> to word that without trying to invoke SIP request-URI vs route set >> complexities, but my brain is tired. I will think further about it.) > > What do you mean by "the connection was opened based on a URI of > sip:user@voice.example.edu"? Yes, the client might know that it is > configured for an account with that URI, but in order to communicate > with the application service it will need to resolve the DNS domain name > (and application type) to an IP address. So that's the reference > identifier. The presented identifier in the certificate will also be of > the form sip:domain, not sip:user@domain. > Sure, and I guess what I am talking about is how one derives a reference identifier of sip:voice.example.edu from an address of record (AoR) of sip:user@voice.example.edu. For example, I click on the AoR on a web page, or I type it from Mr. User's business card. I guess my point is it would be useful for the example to show that, given the URI of a _resource_, you derive (extract?) a URI of a _service_ to be the reference entry. You've mentioned that in text, but it would be useful for the example to show it as well. [...] > >>> I suggest the following tweaks: >>> >>> 3. If the service using the certificate deploys a technology in >>> which a server is programatically associated with a URI for >>> security purposes (e.g., this is true of [SIP] as specified by >>> [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not >>> describe usage of a URI-ID for HTTP services), then the certificate >>> SHOULD include a URI-ID; the scheme SHALL be that of the protocol >>> associated with the service type and the "authority" component >>> SHALL be the fully-qualified DNS domain name of the service. A >>> specification that re-uses this one MUST specify whether particular >>> URI schemes are to be considered equivalent (e.g., http and https, >>> or sip and sips as described in [SIP-SIPS]). >> >> I think this is pretty close, modulo previous comments above. I >> wonder if the fact that SIP appears to abstract the scheme rather >> than use the scheme of any particular URI is relevant here, or just >> adds too much complexity to the language. > > My first thought it that it adds too much complexity, but I'll consider > it further tomorrow. > Okay. I can't off-hand think of a simple way to put it, so you are probably right. [...]
- [Gen-art] Gen-ART LC Review of draft-saintandre-t… Ben Campbell
- Re: [Gen-art] Gen-ART LC Review of draft-saintand… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Paul Hoffman
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH