Re: [keyassure] CN/SAN matching (was: End entity certificate

Martin Rex <mrex@sap.com> Thu, 31 March 2011 01:03 UTC

Return-Path: <mrex@sap.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5083A6AAE for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 18:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.22
X-Spam-Level:
X-Spam-Status: No, score=-10.22 tagged_above=-999 required=5 tests=[AWL=0.029, 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 U-25gi2gUAvn for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 18:03:43 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 6E6433A692C for <keyassure@ietf.org>; Wed, 30 Mar 2011 18:03:43 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2V15KhN000391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 31 Mar 2011 03:05:21 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103310105.p2V15KtX009924@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Thu, 31 Mar 2011 03:05:20 +0200 (MEST)
In-Reply-To: <AANLkTinsivAM6W2DrpHb+a8T_CRN5=gBjBQD76=Ysbqu@mail.gmail.com> from "Eric Rescorla" at Mar 30, 11 10:20:21 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: peter@palfrader.org, keyassure@ietf.org, paul.hoffman@vpnc.org
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2011 01:03:45 -0000

Eric Rescorla wrote:
> 
> Jay Daley <jay@nzrs.net.nz> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Nope, it's up to applications.  If you want SN/CAN *not* to be
> > > checked for HTTPS, then you need to go revise RFC 2818; for SMTP,
> > > RFC 3207; for IMAP/POP3, RFC 2595.
> >
> > Indeed.
> >
> > I assumed we were updating RFC 2818.
> 
> In that case, this document will need to be dual last called in the
> TLS WG, since 2818 was a TLS product.

While it doesn't call itself an update to rfc2818 by its document header,
I always assumed it wanted to be this update.

  http://tools.ietf.org/html/rfc6125


The question is more about "if the creator of the certificate placed
attributes in that certificates that are traditionally considered
"constraints" or "usage restrictions", should these be still be honoured,
even if there is no PKIX cert path validation performed on the certificate.

This is why personally, I have a preference to use X.509v1 certs as
self-signed TLS server certs -- there are significantly less attributes
to get wrong by accident.


But the real issue is more about determining intent.
Maybe the DANE TLSA record should also carry a hint whether or not
the cert attributes (anything besides the public key) should
be ignored (= not checked, not seen as usage limitations).

There may be clients in the installed base that have certain
checks or assumptions about presence of specific attributes in
a certificate hardcoded, and the TLS server admin may want to
provide the attributes only/specifically for those old clients
in the installed base -- not for DANE-aware new clients.


-Martin