Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt

Scott Rose <> Tue, 14 January 2014 13:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5DE4B1ADF76 for <>; Tue, 14 Jan 2014 05:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 05EZaG6ReCAp for <>; Tue, 14 Jan 2014 05:56:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A45121ADFF8 for <>; Tue, 14 Jan 2014 05:56:48 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 14 Jan 2014 08:56:00 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 14 Jan 2014 08:56:36 -0500
Received: from ( []) by (8.13.8/8.13.1) with ESMTP id s0EDuXlR008893 for <>; Tue, 14 Jan 2014 08:56:33 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Scott Rose <>
In-Reply-To: <>
Date: Tue, 14 Jan 2014 08:56:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <>
To: " list" <>
X-Mailer: Apple Mail (2.1827)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Jan 2014 13:56:50 -0000

On Jan 8, 2014, at 10:54 AM, Paul Hoffman <> wrote:

> Thanks for the review, Scott. I didn't see it until I has pulled the lever on -04 to deal with a few of Mark's comments.
I'd rather hear negative reviews of bad ideas than no reviews of good ones. 

> On Jan 8, 2014, at 6:58 AM, Scott Rose <> wrote:
>> 1. naming convention to help distinguish between signing and encryption key certs (for enterprises that use separate certs for encrypting and signing).  It helps reduce the size of the SMIMEA RRset a bit, but admittedly minor compared to the size of an X.509 cert.
> The slight saving of space also introduces a new, significant failure mode, namely that if the person listing the cert in the DNS gets the type wrong then the receiver can't use it. I'd say "no" on this one.

Admittedly it doesn't save much.  

>> 2. a new CU value for "revoked" to indicate that this user's certificates have been revoked.  
> We considered things like this for TLSA, and the WG seemed very hesitant to have the DNS be used as a second, unofficial revocation mechanism. For instance, what would it mean for the DNS to say that an S/MIME cert is revoked, but when the user pulls a fresh CRL, the cert isn't there? The best we might do is to have a signal for "go refresh your revocation view" in the DNS, but that seems like very marginal value.

Our thinking was with local trust anchors where places may not keep their CRL's up to date or even make it available.  I hope it's not optimistic in thinking that new DANE uses will encourage people to keep CRL's current.

>> There are some signed/encrypted email projects rolling out now that are using CERT RR's or combinations of SRV RR's and LDAP servers.  Having something like SMIME would be an improvement, but the spec needs to be finalized.  
> And Jakob and I apologize for the long lag since the earlier draft. We too would like to see this finished.

Count me as a reviewer.


> --Paul Hoffman