Re: [certid] What security does SRV-ID add when DNS-ID will always match?

Peter Saint-Andre <stpeter@stpeter.im> Wed, 30 March 2011 22:34 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2488C3A6BE4 for <certid@core3.amsl.com>; Wed, 30 Mar 2011 15:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.734
X-Spam-Level:
X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.135, 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 DIQCszFUWDwH for <certid@core3.amsl.com>; Wed, 30 Mar 2011 15:34:28 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C6CB73A67EE for <certid@ietf.org>; Wed, 30 Mar 2011 15:34:27 -0700 (PDT)
Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4F6F440022; Wed, 30 Mar 2011 16:37:54 -0600 (MDT)
Message-ID: <4D93B054.6060508@stpeter.im>
Date: Thu, 31 Mar 2011 00:36:04 +0200
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.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Matt McCutchen <matt@mattmccutchen.net>
References: <4D35EFE7.4060209@KingsMountain.com> <1300568731.1916.34.camel@localhost> <4D9334DB.3040909@stpeter.im> <1301516234.1917.27.camel@localhost> <4D9399D9.2020302@stpeter.im> <1301521507.1917.56.camel@localhost> <4D93A5D5.1020601@stpeter.im> <1301522412.1917.61.camel@localhost>
In-Reply-To: <1301522412.1917.61.camel@localhost>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020300050409020204000606"
Cc: IETF cert-based identity <certid@ietf.org>, =JeffH <Jeff.Hodges@KingsMountain.com>
Subject: Re: [certid] What security does SRV-ID add when DNS-ID will always match?
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 22:34:29 -0000

On 3/31/11 12:00 AM, Matt McCutchen wrote:
> On Wed, 2011-03-30 at 23:51 +0200, Peter Saint-Andre wrote:
>> On 3/30/11 11:45 PM, Matt McCutchen wrote:
>>> On Wed, 2011-03-30 at 23:00 +0200, Peter Saint-Andre wrote:
>>>> I think that this is a matter of local policy -- a client could prefer
>>>> SRV-IDs yet still accept DNS-IDs, and as far as I can see that behavior
>>>> is not expressly forbidden by the spec.
>>>
>>> "Prefer" is vague.  Specifically, I would like the client to accept a
>>> DNS-ID if and only if the certificate contains no SRV-IDs.  How is this
>>> accommodated within the framework of the spec?  Clearly the reference
>>> identifier must contain a DNS-ID. 
>>
>> Ah, I see the confusion. MUST has been changed to SHOULD in order to be
>> consistent with what I have called the inclusion approach.
> 
> I'm not referring to the change in the document.  I meant that the goal
> of accepting a DNS-ID in the case that the certificate contains no
> SRV-IDs is impossible to achieve unless the (fixed) list of reference
> identifiers contains a DNS-ID.

You are right that, on the inclusion approach, including a DNS-ID in the
list of reference identifiers is the only way to achieve the behavior
you desire. However, in order for the client to vary its behavior based
on the identifiers presented by the server, we would have needed to
modify the spec to use the conditional approach. I'm sure you can
understand that it was simply way too late to perform such major
surgery, two months after IESG approval.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/