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/