Re: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific RDN")

Peter Saint-Andre <stpeter@stpeter.im> Wed, 06 October 2010 16:33 UTC

Message-ID: <4CACA52A.6030905@stpeter.im>
Date: Wed, 06 Oct 2010 10:34:50 -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.2.9) Gecko/20100915 Thunderbird/3.1.4
MIME-Version: 1.0
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <4CA9238F.1070709@KingsMountain.com>
In-Reply-To: <4CA9238F.1070709@KingsMountain.com>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IETF cert-based identity <certid@ietf.org>
Subject: Re: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific RDN")
Precedence: list

On 10/3/10 6:45 PM, =JeffH wrote:
> [ forwarding with permission of the author (I didn't write the below) in
> order that we have this info publicly available in the archives ]
> 
> Subject: Fwd: [certid] Need to define "most specific RDN"
> From: Paul Tiemann <paul.tiemann.usenet@gmail.com>
> Date: Fri, 16 Jul 2010 11:56:11 -0600 (10:56 PDT)
> To: Jeff Hodges <Jeff.Hodges@KingsMountain.com>om>, Kaspar Brand
> <ietf-certid@velox.ch>

<snip/>

Jeff, what is your take? Here's what I see...

> My opinion on steps for improvement from where we are now:
> 
> 1) Clarify CN usage by strongly recommending only 1 CN in a subject.

I think we already do that, because in our working copy Section 3,
bullet 6 states:

       The certificate MAY contain more than one DNS-ID, but SHOULD NOT
       contain more than one CN-ID.

> 2) Encourage ubiquitous usage of the SAN extension, so that almost all CA
> issued certificates include the SAN extension, only deviating from that for
> reasons of compatibility with legacy servers or clients which choke on the
> SAN.

Again I think we already do that, because in our working copy Section 3,
bullets 1 through 3 state:

   1.  The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName
       entry of type dNSName) if possible as a baseline for
       interoperability.

   2.  If the service using the certificate deploys a technology in
       which a server is discovered by means of DNS SRV records
       [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate
       SHOULD include an "SRV-ID" (i.e., a subjectAltName entry of type
       otherName whose name form is SRVName as specified in [SRVNAME]);
       furthermore, multiple instances of the "SRV-ID" identifier type
       are allowed.

   3.  If the service using the certificate deploys a technology in
       which a server is typically associated with a URI (e.g., this is
       true of [SIP]), then the certificate SHOULD include a URI-ID
       (i.e., a subjectAltName entry of type uniformResourceIdentifier);
       the scheme SHALL be that of the protocol associated with the
       service type and the authority component SHALL be the fully-
       qualified DNS domain name of the service; furthermore, multiple
       instances of the "URI-ID" identifier type are allowed.

> 3) Make strong recommendations to stop using CN-IDs in subject

Done via bullet 5 in Section 3 of our working copy:

   5.  Even though many deployed clients still check for the CN-ID
       within the certificate subject name, the certificate SHOULD NOT
       represent the server's fully-qualified DNS domain name in a
       CN-ID.

> 4) Stop using server-IDs in common names experimentally

That's an implementation and deployment issue, not a spec issue,
although we would hope that folks do some experiments and report on the
results.

Peter

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

[certid] fyi: assessment of present compatibility… =JeffH
Re: [certid] fyi: assessment of present compatibi… Matt McCutchen
Re: [certid] fyi: assessment of present compatibi… Peter Saint-Andre