Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
"Jim Schaad" <ietf@augustcellars.com> Sat, 31 May 2014 01:37 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB51A06C3 for <dane@ietfa.amsl.com>; Fri, 30 May 2014 18:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyyTeg08BmPb for <dane@ietfa.amsl.com>; Fri, 30 May 2014 18:37:30 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53F71A02BE for <dane@ietf.org>; Fri, 30 May 2014 18:37:29 -0700 (PDT)
Received: from Philemon (unknown [50.38.87.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 48AC538EE8 for <dane@ietf.org>; Fri, 30 May 2014 18:37:25 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: dane@ietf.org
References: <201405290805.s4T85HBT008757@new.toad.com> <20140529141626.GH27883@mournblade.imrryr.org>
In-Reply-To: <20140529141626.GH27883@mournblade.imrryr.org>
Date: Fri, 30 May 2014 18:35:06 -0700
Message-ID: <047901cf7c70$973d92d0$c5b8b870$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHszl+QFE6HMjc8qxJLluNV1wqK1wOYfV3pmwJ/0HA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/kBdMXvu52KU8ws7pF2rpYqZvrpo
Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 01:37:31 -0000
-----Original Message----- From: dane [mailto:dane-bounces@ietf.org] On Behalf Of Viktor Dukhovni Sent: Thursday, May 29, 2014 7:16 AM To: dane@ietf.org Subject: Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys On Thu, May 29, 2014 at 01:05:17AM -0700, John Gilmore wrote: > In reviewing the draft, I noticed that it doesn't ever describe how > you store such a public key in a TLSA record. I think there is an obvious format, that should be spelled out explicitly in some suitable document. Namely the same format as for the SPKI of a leaf certificate with any supported matching type: ; Match SPKI of a certificate or just the bare public key _25._tcp.mx1.example.com IN TLSA DANE-EE(3) SPKI(1) ? {blob} [JLS] That may be one obvious format. I think that an even better format would be to define a new TLSA certificate type so that the client will know that an OOB bare key is what is coming. Thus ; Match SPKI of a certificate or just the bare public key _25._tcp.mx1.example.com IN TLSA DANE-BARE-KEY(4) SPKI(1) ? {blob} This means that there is no overlap between those that are planning to do PKIX and those that are planning to do bare keys both in the filtering of the information and publishing of the data. Both could be offered, and the DANE query would allow a client to know that OOB is going to be acceptable. Jim DANE TLS clients that also support the new TLS oob public key extension can include it in their client HELLO, provided every RR in the TLSA RRset is a "3 1 X" RR (they must perform the DNS lookup before client HELLO). If any of the RRs have a different usage, then a full leaf certificate may be required, and the client MUST NOT signal oob public key support (since the client would potentially be unable to match a subset of the TLSA records, which may the currently active configuration). -- Viktor. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Hoffman
- [dane] Extending TLSA RFC to operate with TLS's n… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Wes Hardaker
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Jim Schaad
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Tom Gindin
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Stephen Farrell
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Olafur Gudmundsson
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… James Cloos
- Re: [dane] Extending TLSA RFC to operate with TLS… Stephen Farrell
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Simon Arlott
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Servers which offer RPK but have no TL… John Gilmore
- Re: [dane] Servers which offer RPK but have no TL… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Servers which offer RPK but have no TL… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… John Gilmore
- Re: [dane] Servers which offer RPK but have no TL… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni
- [dane] Extending TLSA RFC to operate with TLS's n… John Gilmore
- Re: [dane] Extending TLSA RFC to operate with TLS… Paul Wouters
- Re: [dane] Extending TLSA RFC to operate with TLS… Viktor Dukhovni