Re: [TLS] Review of draft-saintandre-tls-server-id-check
Peter Saint-Andre <stpeter@stpeter.im> Tue, 31 August 2010 18:21 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732503A6A6D; Tue, 31 Aug 2010 11:21:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level:
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 fjzot4M1XG85; Tue, 31 Aug 2010 11:21:42 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6B34F3A69E9; Tue, 31 Aug 2010 11:21:42 -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 7053F400EE; Tue, 31 Aug 2010 12:25:07 -0600 (MDT)
Message-ID: <4C7D4853.8020507@stpeter.im>
Date: Tue, 31 Aug 2010 12:22:11 -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.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <BLU137-W32189ED2D1B0FDFCBF639F93840@phx.gbl> <4C7C3442.9020403@stpeter.im> <BLU137-DS3BE7BD3D47980030F667A93890@phx.gbl>
In-Reply-To: <BLU137-DS3BE7BD3D47980030F667A93890@phx.gbl>
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: ietf@ietf.org, XMPP <xmpp@ietf.org>, 'Cyrus Daboo' <cyrus@daboo.name>, tls@ietf.org, '=JeffH' <Jeff.Hodges@kingsmountain.com>, rbarnes@bbn.com, pkix@ietf.org
Subject: Re: [TLS] Review of draft-saintandre-tls-server-id-check
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Aug 2010 18:21:44 -0000
On 8/30/10 5:10 PM, Bernard Aboba wrote: > Peter St. Andre said: > > "an SRV record can be used for two quite different purposes: > > 1. To point from an application service name to a particular > host/domain name in the same administrative domain (e.g., > _imap._example.com points to mailhost.example.com for its IMAP > service). > > 2. To delegate an application service name to a hosting provider > outside in the administrative domain of the application service > (e.g., example.com delegates its IMAP service to > apps.example.net)..... > > As I see it, RFC 4985 glosses over the foregoing distinction." > > [BA] It took some adjustment for me, but as I understand it, the > underlying assumption of RFC 4985 is that if the certificate is > considered valid by RFC 5280 path validation (e.g. chains to a valid > trust anchor, etc.) then delegations both within and outside the > source administrative domain can be validated. This logic, if > pursued, could apply beyond SRV RR validation, to things like NAPTR > validation via a URI/IRI in the certificate. If that's the logic, I'd at the least like to see a "4985bis" spec make that clear, because IMHO it's not spelled out now. > Scoping (EKUs, name constraints, etc.) is a different question. Agreed. > Peter also said: > > "However, the question arises: what is the client supposed to check > if an SRV lookup for _imap._example.com yields apps.example.net? My > reading of RFC 4985 leads me to think that the certificate presented > by apps.example.net is supposed to contain an SRV-ID of > _imap.example.com, which means roughly "this certificate indicates > that this provider is authorized to provide IMAP service for the > example.com domain". (How the certification authority determines that > the delegation is indeed authorized is outside the scope of this > I-D.) > > [BA] That's also my reading of RFC 4985, but I'll let others more > knowledgeable (like the author) weigh in. That would indeed be helpful. Peter -- Peter Saint-Andre https://stpeter.im/
- Re: [TLS] Review of draft-saintandre-tls-server-i… Peter Saint-Andre
- Re: [TLS] Review of draft-saintandre-tls-server-i… Peter Saint-Andre
- Re: [TLS] Review of draft-saintandre-tls-server-i… Bernard Aboba
- Re: [TLS] Review of draft-saintandre-tls-server-i… =JeffH
- Re: [TLS] [xmpp] Review of draft-saintandre-tls-s… Bernard Aboba
- Re: [TLS] Review of draft-saintandre-tls-server-i… James Schaad
- Re: [TLS] [xmpp] Review of draft-saintandre-tls-s… Bernard Aboba
- Re: [TLS] Review of draft-saintandre-tls-server-i… Peter Saint-Andre
- Re: [TLS] Review of draft-saintandre-tls-server-i… James Schaad
- Re: [TLS] Review of draft-saintandre-tls-server-i… Peter Saint-Andre
- Re: [TLS] Review of draft-saintandre-tls-server-i… Peter Saint-Andre
- [TLS] Why require EKU for certid? Paul Hoffman
- Re: [TLS] Why require EKU for certid? Peter Saint-Andre
- Re: [TLS] Why require EKU for certid? Jim Schaad
- Re: [TLS] [certid] Why require EKU for certid? Martin Rex
- Re: [TLS] [certid] Why require EKU for certid? Henry B. Hotz