IETF Logo Mail Archive

Re: [certid] Need to define "most specific RDN"

Martin Rex <mrex@sap.com> Wed, 21 July 2010 23:12 UTC

Return-Path: <mrex@sap.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 B9BBE3A6857 for <certid@core3.amsl.com>; Wed, 21 Jul 2010 16:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.469
X-Spam-Level:
X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[AWL=0.780, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 rr4aA8aDawqJ for <certid@core3.amsl.com>; Wed, 21 Jul 2010 16:12:34 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8210F3A6824 for <certid@ietf.org>; Wed, 21 Jul 2010 16:12:34 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o6LNCjn0024645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jul 2010 01:12:45 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201007212312.o6LNCi8Y017372@fs4113.wdf.sap.corp>
To: nelson@bolyard.me (Nelson B Bolyard)
Date: Thu, 22 Jul 2010 01:12:44 +0200 (MEST)
In-Reply-To: <4C3DDC18.4020808@bolyard.me> from "Nelson B Bolyard" at Jul 14, 10 08:47:36 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: certid@ietf.org
Subject: Re: [certid] Need to define "most specific RDN"
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 21 Jul 2010 23:12:37 -0000

Nelson B Bolyard wrote:
> 
> SANs solve this whole problem.  They have a component that may ONLY contain
> DNS names, and therefore is easily constrained.  DNS name constraints would
> be effective if certs ONLY put DNS names into SANs.  But putting DNS names
> into SANs effectively bypasses name constraints (at least, in
> implementations I tested last year).

Look at the server certificate here(*):

   https://edgecastcdn.net/

and SANs in it.  The Server cert is from a 3-level CA hierarchy
(Entrust on top, two intermediate CAs from DigiCert).

How exactly are name constraints going to make issuing such certs
easier or safer, and can you actually come up with a meaningful
name constraints for such a cert?

-Martin


(*) Server cert example found here:
    http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
    recently mentioned on this list.

v2.8.7 | Report a Bug | By Email