[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
- [certid] Domain Components Peter Saint-Andre
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Alexey Melnikov
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Alexey Melnikov
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Peter Sylvester
- [certid] CN-ID in version 6 Peter Sylvester
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Paul Hoffman
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Michael Ströder
- Re: [certid] Domain Components Bruno Harbulot
- Re: [certid] Domain Components Martin Rex
- Re: [certid] Domain Components Martin Rex
- Re: [certid] Domain Components Peter Sylvester
- Re: [certid] Domain Components Martin Rex