IETF Logo Mail Archive

[certid] CN-ID and name constraints

Matt McCutchen <matt@mattmccutchen.net> Fri, 24 September 2010 01:09 UTC

Return-Path: <matt@mattmccutchen.net>
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 CB83F3A68F1 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 18:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FTylkXUMu763 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 18:09:55 -0700 (PDT)
Received: from homiemail-a37.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id B14133A6851 for <certid@ietf.org>; Thu, 23 Sep 2010 18:09:55 -0700 (PDT)
Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 45E8C1D0064 for <certid@ietf.org>; Thu, 23 Sep 2010 18:10:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=M9WW9/MjCU9ce70O5mc+AlH12wV2oe48d93feZMsjyX 4wXeU6UeU/GA81NoD6mqJq9j/tizcnUUO9L6Oq7Tq6l//hruvmCARnD0UaCD70I5 +teuU4n1Vm2eEFeCSF20NPYiGOVT5yJwi649SWkOaR5bzuBAGE9NF7m1cnQHfTaA =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=wmNkWeJ7k+ZSFX9ebHiAUpOen7M=; b=Og9ORhUz9O +C0LzMMznbJJ6/uXV76/pkZOWgcHXO0B8+3TNsMcXBi+fsh3mFdHxhI+qCyzSIBZ W9QYdSzvk4c772Psp5dDs0HWq35dUh3HwHF0WKFnqnYZiarcT9IE0LCUqhBHLTaE T8DVdQbjPx2f8Cq4E2pofLH87AHW8nZUU=
Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 06E0A1D0063 for <certid@ietf.org>; Thu, 23 Sep 2010 18:10:23 -0700 (PDT)
From: Matt McCutchen <matt@mattmccutchen.net>
To: certid@ietf.org
In-Reply-To: <201009231613.o8NGDiL2016566@fs4113.wdf.sap.corp>
References: <201009231613.o8NGDiL2016566@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
Date: Thu, 23 Sep 2010 21:10:22 -0400
Message-ID: <1285290623.1939.15.camel@mattlaptop2.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.4
Content-Transfer-Encoding: 7bit
Subject: [certid] CN-ID and name constraints
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: Fri, 24 Sep 2010 01:09:56 -0000

On Thu, 2010-09-23 at 18:13 +0200, Martin Rex wrote:
> Paul Hoffman wrote:
> > 
> >>> There should at least be a rule stating that any client that accepts the CN
> >>> attribute to carry the domain name MUST also perform name constraints on
> >>> this attribute using the domain name logic if name constraints is applied to
> >>> the path. Failing this requirement poses a security threat if the claimed
> >>> domain name in CN-ID violated the name constraints set for domain names.
> > 
> > Fully disagree.
> 
> I do agree with Paul that something is very wrong about this paragraph.
> 
> What it seems to request is that dNSName SAN name constraints ought
> to be performed on CN-ID if server endpoint identification is
> performed with CN-ID.
> 
> Since there is a requirement to use (issue) DNS-IDs in server certs,
> and a requirement to ignore CN-ID when DNS-ID is present, such a
> name constraints processing scheme looks awkward to me.

[...]

> A CA with name constraints for DNSName SANs (required critical according
> to rfc5280, mind you) in its own CA certificate that issues TLS server
> certificates without dNSName SANs yields "fubar" on my scorecard.

But if by doing that they can issue certificates that clients will
accept for server names the superior CA did not intend, that's a big
security problem.

> Those that need the backwards compatibility will _not_ disable
> the matching fallback if DNSName SANs are present,

NSS doesn't:

https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName

The idea is that by including a dNSName SAN, the CA opts out of the
backward compatibility.  I don't think anyone issues certificates with
both dNSName SAN and CN with the intent that the CN be honored as a
server name.

> and they're
> even more unlikely to adopt such a weird name constraints
> processing of a fallback they shouldn't be doing in the 
> first place and keep doing only to not interfere with
> installed base.

Those that need backwards compatibility, name constraints, and security
need to do something about this issue.

Some previous discussion:

http://www.ietf.org/mail-archive/web/pkix/current/msg27619.html

-- 
Matt

v2.23.0 | Report a Bug | By Email