[certid] CN-ID in version 6

Peter Sylvester <peter.sylvester@edelweb.fr> Mon, 21 June 2010 09:39 UTC

Return-Path: <peter.sylvester@edelweb.fr>
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 05CCB3A685A for <certid@core3.amsl.com>; Mon, 21 Jun 2010 02:39:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.02
X-Spam-Level:
X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_50=0.001]
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 L9TJbkKg6+XW for <certid@core3.amsl.com>; Mon, 21 Jun 2010 02:39:31 -0700 (PDT)
Received: from ganymede.on-x.com (ganymede.on-x.com [92.103.215.11]) by core3.amsl.com (Postfix) with ESMTP id 9C1293A6A4F for <certid@ietf.org>; Mon, 21 Jun 2010 02:39:29 -0700 (PDT)
Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by ganymede.on-x.com (Postfix) with ESMTP id A59787F for <certid@ietf.org>; Mon, 21 Jun 2010 11:39:34 +0200 (CEST)
Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id A6EA817184 for <certid@ietf.org>; Mon, 21 Jun 2010 11:39:34 +0200 (CEST)
Received: from [192.168.0.21] (gut75-3-82-227-163-182.fbx.proxad.net [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTP id 65E6A77D8 for <certid@ietf.org>; Mon, 21 Jun 2010 11:39:34 +0200 (CEST)
Message-ID: <4C1F3352.6080602@edelweb.fr>
Date: Mon, 21 Jun 2010 11:39:30 +0200
From: Peter Sylvester <peter.sylvester@edelweb.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4
MIME-Version: 1.0
To: certid@ietf.org
References: <4C12A27D.3070308@stpeter.im> <p0624086ac8386db66483@[10.20.30.158]> <4C1CA2B8.9080103@isode.com> <p0624082ac8427d3d733f@[10.20.30.158]> <4C1CD30B.4090200@isode.com> <p0624082dc84286e8b770@[10.20.30.158]> <4C1F226F.1010408@stroeder.com> <4C1F2947.9080001@edelweb.fr>
In-Reply-To: <4C1F2947.9080001@edelweb.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [certid] CN-ID in version 6
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: Mon, 21 Jun 2010 09:39:35 -0000

2.2 says

   5.  The certificate SHOULD NOT represent the server's fully-qualified
        DNS domain name in a Relative Distinguished Name (RDN) of type
        Common Name (CN) (see [LDAP-SCHEMA]), even though we recognize
        that many deployed clients still check for this legacy identifier
        configuration within certificate subjectName.  However, if this
        legacy identifer configuration is employed, then the server's
        fully-qualified DNS domain name MUST be placed in the last (most
        specific) RDN within the RDN sequence making up the certificate's
        subjectName, as the order of RDNs is determined by the DER-
        encoded Name within the server's PKIX certificate.  Furthermore,
        the certificate's subject Distinguished Name SHOULD NOT contain
        more than one Common Name attribute, and MUST NOT contain RDNs
        which consist of multiple Common Name attributes.

The second half is aprt of a redefintion of CN-ID

       *  CN-ID = a Relative Distinguished Name (RDN) in the certificate
          subject that contains one and only one attribute value
          assertion (AVA) whose attribute type is Common Name (CN)


I think one should say exactly the opposite:

5. The certificate SHOULD represent the server's fully-qualified
     DNS domain name in exactly one CN-ID as the last RDN in the
     subject DN.
     The subject DN SHOULD NOT have more than one CN ava.

And in the following

   6.  The certificate SHOULD NOT represent the server's fully-qualified
        DNS domain name by means of a DC-ID, i.e., a series of Domain
        Component (DC) attributes in the certificate subject, with one
        RDN per domain label and one DC in each RDN.  Although (for
        example)<dc=www,dc=example,dc=com>  could be used to represent
        the DNS domain name "www.example.com", given the fact that the
        DNS-ID can be used instead, the DC-ID is NOT RECOMMENDED.

There is no reason to reference DNS-ID here.

6. If present in a DN, a sequence of DCs SHOULD be a DC-ID.

Peter