Re: Review of draft-saintandre-tls-server-id-check

Stefan Santesson <stefan@aaa-sec.com> Mon, 13 September 2010 18:40 UTC

Return-Path: <stefan@aaa-sec.com>
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 AC29F3A6A8E for <ietf@core3.amsl.com>; Mon, 13 Sep 2010 11:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.584
X-Spam-Level:
X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 w+Ir-vrNrQGM for <ietf@core3.amsl.com>; Mon, 13 Sep 2010 11:40:36 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 335F53A6AC2 for <ietf@ietf.org>; Mon, 13 Sep 2010 11:39:45 -0700 (PDT)
Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B7C43387385 for <ietf@ietf.org>; Mon, 13 Sep 2010 20:39:54 +0200 (CEST)
Received: (qmail 57043 invoked from network); 13 Sep 2010 18:39:47 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <stpeter@stpeter.im>; 13 Sep 2010 18:39:47 -0000
User-Agent: Microsoft-Entourage/12.26.0.100708
Date: Mon, 13 Sep 2010 20:39:43 +0200
Subject: Re: Review of draft-saintandre-tls-server-id-check
From: Stefan Santesson <stefan@aaa-sec.com>
To: Peter Saint-Andre <stpeter@stpeter.im>, Shumon Huque <shuque@isc.upenn.edu>
Message-ID: <C8B43C8F.EE18%stefan@aaa-sec.com>
Thread-Topic: Review of draft-saintandre-tls-server-id-check
Thread-Index: ActTcwf0udnggguB60aSFg5RUAFEuw==
In-Reply-To: <4C8E4C6B.3040803@stpeter.im>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
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 18:40:39 -0000

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?

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.

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.

/Stefan