Re: [certid] It is not always a good idea to enforce CN check as leaf RDN only

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 05 April 2010 21:34 UTC

Return-Path: <alexey.melnikov@isode.com>
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 957483A6A8C for <certid@core3.amsl.com>; Mon, 5 Apr 2010 14:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Level:
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_05=-1.11, J_CHICKENPOX_12=0.6]
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 UpgE5tI5taNw for <certid@core3.amsl.com>; Mon, 5 Apr 2010 14:34:29 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B4BA13A6A8B for <certid@ietf.org>; Mon, 5 Apr 2010 14:34:29 -0700 (PDT)
Received: from [192.168.20.2] ((unknown) [212.183.140.53]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <S7pXYgBHTlJD@rufus.isode.com>; Mon, 5 Apr 2010 22:34:27 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4BBA575C.9040902@isode.com>
Date: Mon, 05 Apr 2010 22:34:20 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <20100317134327.GA14163@eltex.net> <4BA1A532.9090107@stpeter.im> <20100318045825.GA14076@eltex.net> <4BB3C447.7000505@stpeter.im>
In-Reply-To: <4BB3C447.7000505@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: certid@ietf.org
Subject: Re: [certid] It is not always a good idea to enforce CN check as leaf RDN only
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, 05 Apr 2010 21:34:31 -0000

Peter Saint-Andre wrote:

>On 3/17/10 10:58 PM, ArkanoiD wrote:
>  
>
>>Well, when it comes to implementation we get *two* matching algorithms then,
>>which is definitely no good ;-). 
>>    
>>
>Given that a self-signed certificate can say *anything*, I don't know
>that it's helpful to enforce any rules about issuance and checking of
>self-signed certs. It's not as if any "certification" has taken place in
>this situation.
>  
>
+1.

>>What is the rationale of enforcing CN to
>>be leaf RDN?
>>    
>>
>As I recall, Alexey Melnikov brought that up so I'll ping him about it.
>
The short answer is that only the leaf RDN corresponds to the entity to 
which the certificate belongs. Other RDNs can correspond to entities 
that signed the certificate. E.g. if subject name is:

 cn=example.com, o=Certificated, cn=verisign.com, c=US

then it doesn't mean that verisign.com is the entity described by the 
certificate.