Re: [certid] What DNS-ID if also using a DNS-SRV?

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 30 June 2010 15:13 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 918F13A69B0 for <certid@core3.amsl.com>; Wed, 30 Jun 2010 08:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.657
X-Spam-Level:
X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_50=0.001, HELO_MISMATCH_COM=0.553]
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 vFz2EfAQunID for <certid@core3.amsl.com>; Wed, 30 Jun 2010 08:13:44 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9FC1E3A6850 for <certid@ietf.org>; Wed, 30 Jun 2010 08:13:44 -0700 (PDT)
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o5UFDrKe069304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jun 2010 08:13:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624081dc8510ebfea3f@[10.20.30.158]>
In-Reply-To: <20100630043158.GB26880@isc.upenn.edu>
References: <p062408bbc8388055fb6d@[10.20.30.158]> <20100612013249.GA4782@isc.upenn.edu> <4C2A65B5.4080209@stpeter.im> <p06240842c8503b7c94bc@[10.20.30.158]> <20100630043158.GB26880@isc.upenn.edu>
Date: Wed, 30 Jun 2010 08:13:53 -0700
To: Shumon Huque <shuque@isc.upenn.edu>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"
Cc: certid@ietf.org
Subject: Re: [certid] What DNS-ID if also using a DNS-SRV?
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 Jun 2010 15:13:45 -0000

At 12:31 AM -0400 6/30/10, Shumon Huque wrote:
>Let's concentrate on the MUST/SHOULD applicability for the four
>identity types discussed in this document:
>
>      *  CN-ID = a Relative Distinguished Name (RDN) of type Common Name
>         (CN)
>
>      *  DNS-ID = a subjectAltName identifier of type dNSName
>
>      *  SRV-ID = the SRVName form of otherName from the GeneralName
>         structure in SubjectAltName
>
>      *  URI-ID = a subjectAltName identifier of type
>         uniformResourceName
>

Agree.

>I don't think any of them are a MUST. It depends upon the details
>of the application service.
>
>If a service deployer is using SRV-ID or URI-ID, then presumably
>they want to restrict the use of the certificate to a specific
>application at a domain name. In that case SHOULD is not appropriate
>for DNS-ID or CN-ID. In fact, you can argue that they SHOULD NOT
>use either of those more generic forms (unless it is for backwards
>compatibility).
>
>For folks who are using straight domain names rather than the
>application specific forms (probably the vast majority, at least
>initially), and we want to deprecate CN-ID and steer them towards
>DNS-ID, then I agree that DNS-ID can be a SHOULD. I don't think
>it can be a MUST today -- there are probably many certificate
>issuers that can't deal with anything other than CN.
>
>So, if we want to attach a SHOULD to DNS-ID, it should be a
>conditional one (the condition being that application specific
>name forms like SRV and URI aren't being used).

I agree that we have to look at the details of the service. To me, there are two types of names:
- direct (CN-ID, DNS-ID, and URI-ID)
- indirect (SRV-ID)
If they are all SHOULD, and we don't say when one should not mix and match, we haven't helped interoperability. I think instead, we need something like "MUST have either one or more of (CN-ID, DNS-ID, and URI-ID), or SRV-ID". This would be followed by "if the cert has an SRV-ID, it SHOULD NOT have any of (CN-ID, DNS-ID, and URI-ID) because the meaning of combination of what is received from the SRV lookup and the given DNS names is undefined."

Does that sound reasonable?

--Paul Hoffman, Director
--VPN Consortium