Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <FE426405-9658-41BD-BD3B-68D358CC3CEB@verisign.com>
Date: Mon, 20 Oct 2014 08:54:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <63BF3336-C9B8-4D16-BEB7-D42EFBB7A113@vpnc.org>
References: <273F9612-13AF-4CB8-B15C-912AAD04C738@verisign.com>
 <CF875C06-E4DA-4DCA-A722-5FDEE04B3069@vpnc.org>
 <67BDE5B6-58C7-4E0B-8CB4-045E51027D85@ieca.com>
 <3473729E-BC37-48DB-9ACD-FB872CB666DE@vpnc.org>
 <FE426405-9658-41BD-BD3B-68D358CC3CEB@verisign.com>
To: Eric Osterweil <eosterweil@verisign.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/jJpmN7rX8nwaNFGmQYO-HdiLv4g
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] draft-ietf-dane-smime
Precedence: list

On Oct 20, 2014, at 8:23 AM, Osterweil, Eric <eosterweil@verisign.com> =
wrote:

> TLS and S/MIME use pretty different security models (session vs. =
object security)

Sure, but how is that difference relevant here? DANE is about =
distributing certificates and keying information through DNS: it is =
agnostic to the security model.

> , so necessarily coupling the RRs doesn=92t seem to make sense. =20

It has so far in the WG. The WG asked us early on to make as few changes =
as possible to the TLSA definition.

> In addition, to echo what others have already said on the list, I =
really don=92t think it is reasonable to gate updates to the SMIMEA =
proposal on updating TLSA.

Fully agree, and that's not what I was proposing. The two changes that =
you have proposed (revocation indication and alternate sources for =
getting the information) can be done as new values to the existing RR =
subfields. Doing so would make what you want usable for both SMIMEA and =
TLSA. Proposals to make those changes can trivially be done as =
stand-alone Internet Drafts.

>> A better process would be for the proponents to offer a standalone =
draft for the idea that will be an extension that would be usable to =
both TLSA and SMIMEA and any other documents that come later.
>=20
> Just by looking at the list, it seems like there are a number of =
voices that disagree with you on this. =20

Where "a number" means "two", and even they didn't actually disagree =
about creating standalone drafts, simply that the assumption that the =
use cases might be different.

> Also, isn=92t the SMIMEA work still an evolving draft? =20

Yes, of course.

> What else does one need besides: articulated rationale, proposed =
requirements, operational data, suggested text, and running code from =
multiple people in order to support suggested revisions? =20

Consensus in the WG. That may seem anathema to you, but it's the way =
that the IETF works.

--Paul Hoffman=