Re: [certid] Comments on draft-saintandre-tls-server-id-check-04

Nelson B Bolyard <nelson@bolyard.me> Mon, 07 June 2010 18:23 UTC

Return-Path: <nelson@bolyard.me>
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 201CC3A6784 for <certid@core3.amsl.com>; Mon, 7 Jun 2010 11:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599]
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 tNWuXH2laOf5 for <certid@core3.amsl.com>; Mon, 7 Jun 2010 11:23:37 -0700 (PDT)
Received: from smtpauth22.prod.mesa1.secureserver.net (smtpauth22.prod.mesa1.secureserver.net [64.202.165.44]) by core3.amsl.com (Postfix) with SMTP id 84D883A67BD for <certid@ietf.org>; Mon, 7 Jun 2010 11:23:37 -0700 (PDT)
Received: (qmail 23229 invoked from network); 7 Jun 2010 18:23:37 -0000
Received: from unknown (24.5.142.42) by smtpauth22.prod.mesa1.secureserver.net (64.202.165.44) with ESMTP; 07 Jun 2010 18:23:36 -0000
Message-ID: <4C0D3922.9070104@bolyard.me>
Date: Mon, 07 Jun 2010 11:23:30 -0700
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: certid@ietf.org
References: <201006041637.o54GbgVh024358@fs4113.wdf.sap.corp>
In-Reply-To: <201006041637.o54GbgVh024358@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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: Mon, 07 Jun 2010 18:23:39 -0000

(Resending: first copy seems to have bounced off the server.)
On 2010-06-04 09:37 PDT, Martin Rex wrote:

> I am perfectly well aware of the wording in rfc-2818.
> 
> But security-wise an X.509 Cert containing
> 
> CN=host1.example.com, CN=host2.example.com, CN=host3.example.com
> 
> is significantly less dangerous that an X.509 Cert containing
> 
> CN=*.example.com
> 
> and therefore this wording in rfc-2818 is unreasonable in several aspects
> and I chose to completely and deliberately ignore it in my 
> implementation.

I'm not surprised that you say that.  It's not the first time you've
told us that you've deliberately ignored something in an RFC that you
considered unreasonable.

But consider that, because of the wording that you ignore, some (many) CAs
will only check the DNS name in ONE of the CNs in the cert subject name.
Other CNs may contain strings whose contents are unchecked.
If you rely on their contents, you're relying on unchecked DNS names.
I wouldn't call that "significantly less dangerous" than a wildcard cert
whose domain (not host) name part has been checked.

Now, as an aside, I think the practice of CAs to put unchecked and
unvetted data ("certified nonsense") into the subject names of their
certs is reprehensible, and IMO, the RFCs should all explicitly
disallow it.  Maybe this draft is the place to start.  But until then,
sadly, it will remain the case that some CAs check only certain specific
attributes (and then only the last one) in the names of the certs they
issue, and software that chooses to honor other fields will be vulnerable.

> Btw. I did not understand the meaning of "most specific" anyway, so I
> considered it unlikely that this could be interoperably implement by only
> matching a single CN= entry.  While the initial definition of
> distinguished names might have had a hierarchical directory structure in
> mind,

The initial, *AND CURRENT*, definitions of DNs still have a hierarchical
organization.  X.501 is worth a read.

> one does find distinguished names in "unusal" ordering out there, as well
> as distinguished names entirely without country AVA, even ones with only
> CN=

True.  There's no requirement that any particular attribute types appear
in any hierarchy.  X.501 talks about this at length.