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

Martin Rex <> Thu, 31 March 2011 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE5083A6AAE for <>; Wed, 30 Mar 2011 18:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.22
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U-25gi2gUAvn for <>; Wed, 30 Mar 2011 18:03:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6E6433A692C for <>; Wed, 30 Mar 2011 18:03:43 -0700 (PDT)
Received: from by (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 <>
Message-Id: <>
To: (Eric Rescorla)
Date: Thu, 31 Mar 2011 03:05:20 +0200 (MEST)
In-Reply-To: <> 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
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Mar 2011 01:03:45 -0000

Eric Rescorla wrote:
> Jay Daley <> 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.

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.