Re: [certid] Comments on draft-saintandre-tls-server-id-check-04
Peter Saint-Andre <stpeter@stpeter.im> Thu, 10 June 2010 02:19 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 5931928C128 for <certid@core3.amsl.com>;
Wed, 9 Jun 2010 19:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.155
X-Spam-Level:
X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[AWL=-1.156,
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 614M+N8Qec2h for
<certid@core3.amsl.com>; Wed, 9 Jun 2010 19:18:56 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com
(Postfix) with ESMTP id ABA283A6867 for <certid@ietf.org>;
Wed, 9 Jun 2010 19:18:56 -0700 (PDT)
Received: from squire.local (dsl-228-47.dynamic-dsl.frii.net [216.17.228.47])
(Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id
C419540E3E for <certid@ietf.org>; Wed, 9 Jun 2010 20:18:57 -0600 (MDT)
Message-ID: <4C104B88.1070307@stpeter.im>
Date: Wed, 09 Jun 2010 20:18:48 -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.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: certid@ietf.org
References: <4C0E90E9.4050101@KingsMountain.com> <4C0F3EBC.9000902@velox.ch>
In-Reply-To: <4C0F3EBC.9000902@velox.ch>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary="------------ms060700030309070603060101"
Subject: Re: [certid] Comments on draft-saintandre-tls-server-id-check-04
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: Thu, 10 Jun 2010 02:19:00 -0000
On 6/9/10 1:11 AM, Kaspar Brand wrote:
> On 08.06.2010 20:50, =JeffH wrote:
>> I personally seem to recall observing certs in the wild whose string-formatted
>> DNames included the "+" notation as Martin illustrates above, and which denotes
>> an RDN SET, although I don't recall whether such certs were produced by "real
>> CAs" as Nelson terms a certain subclass of CAs.
>>
>>
>> Kaspar -- would information wrt multi-valued RDNames be embodied in the sample
>> you used to generate the above info you shared with the list? If so, are there
>> any occurances, and if so what's the frequency?
>
> There are 38 occurrences (out of ~90,000), originating from three "real
> CAs". The vast majority (34) are EV SSL certs from a CA which apparently
> likes to stuff the CN (2.5.4.3) and the serialNumber (2.5.4.5)
> attributes into a single RDN. [Not so surprisingly, the remaining 4
> certs were issued by two CAs which apparently run their infrastructure
> with software from that other "real CA" - which is the reason for seeing
> the same peculiar encoding in their certs.]
Thanks for the numbers.
> In the context of this BCP, I consider the discussion about
> "multi-valued RDNs" an academic thing, mostly. I would not mind,
> however, to change the last sentence in section 2.2, item 6 to something
> like "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" (provided that
> this wording pleases the ASN.1 terminology experts in the audience here).
Done in our working copy.
> The definition of "CN-ID" in section 1.3 should probably also be adapted
> (i.e., it should explicitly forbid multi-CN RDNs).
Is this a more accurate definition?
* CN-ID = a subject Distinguished Name (DN) whose constituent
sequence of Relative Distinguished Names (RDNs) contains one
and only one attribute value assertion (AVA) whose attribute
type is Common Name (CN)
Peter
--
Peter Saint-Andre
https://stpeter.im/
- Re: [certid] Comments on draft-saintandre-tls-ser… =JeffH
- Re: [certid] Comments on draft-saintandre-tls-ser… Kaspar Brand
- Re: [certid] Comments on draft-saintandre-tls-ser… Peter Saint-Andre
- Re: [certid] Comments on draft-saintandre-tls-ser… Kaspar Brand
- Re: [certid] Comments on draft-saintandre-tls-ser… Peter Saint-Andre