[dane] DANE-EE(3) certificate matching rules?
Viktor Dukhovni <firstname.lastname@example.org> Sun, 16 March 2014 20:54 UTC
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7F01A01F9 for <email@example.com>; Sun, 16 Mar 2014 13:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
Received: from mail.ietf.org ([184.108.40.206]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU44-qAJ2GpD for <firstname.lastname@example.org>; Sun, 16 Mar 2014 13:54:37 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [220.127.116.11]) by ietfa.amsl.com (Postfix) with ESMTP id C53911A01E4 for <email@example.com>; Sun, 16 Mar 2014 13:54:36 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 827372AADF5; Sun, 16 Mar 2014 20:54:28 +0000 (UTC)
Date: Sun, 16 Mar 2014 20:54:28 +0000
From: Viktor Dukhovni <firstname.lastname@example.org>
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.5.23 (2014-03-12)
Subject: [dane] DANE-EE(3) certificate matching rules?
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 20:54:40 -0000
We've previously agreed on cu=DANE-EE(3) obviating name checks, since the TLSA base domain with port and protocol prefix is in fact a more specific binding of the service end-point and public key than any name in the certificate, and (perhaps more so) because this dramatically simplifies virtual hosting. In the OPs draft I went further and stated that verification of the DANE-EE(3) end-entity certificate stops at matching it against the TLSA record, and its content MUST otherwise be ignored. This subsumes at least checks of the expiration date and also the EKU, both of which are essentially superseded by the TLSA RR. I may have gone a bit further than necessary. The main goal is to make DANE authentication usable in protocols with no user to "click OK". To this end I want to avoid the most common operational failures with PKIX. Therefore I propose that: - In addition to name checks, expiration checks also be performed via the TLSA RR signature lifetime, rather than the certificate expiration date. The TLSA record is updated frequently as the DNSSEC zone is periodically re-signed. This ensures that there are no surprise expirations. Certificates can be replaced at the operator's convenience. - Though the EKU is technically superseded by the TLSA RR type, which implies a TLSA usage, getting this wrong would be discovered immediately by the server operator, and quickly fixed. There is no need to complicate implementations by special-casing DANE EKU processing. Similarly with the key usage, and other fields. Therefore, the final proposal for DANE-EE(3) is that only name checks and expiration checks are out of scope. This applies whether the selector is Cert(0) or SPKI(1). However, when *all* TLSA records are "IN TLSA DANE-EE(3) SPKI(1) ?", implementations that support the proposed bare public key TLS extension, may signal that extension, in which case if the server cooperates, in effect the rest of the certificate is ignored (in fact never transmitted). Any comments? Can the above be the final consensus on this topic? -- Viktor.
- [dane] DANE-EE(3) certificate matching rules? Viktor Dukhovni
- Re: [dane] DANE-EE(3) certificate matching rules? James Cloos
- Re: [dane] DANE-EE(3) certificate matching rules? Martin Rex
- Re: [dane] DANE-EE(3) certificate matching rules? Viktor Dukhovni
- Re: [dane] DANE-EE(3) certificate matching rules? Paul Wouters