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

Paul Hoffman <> Wed, 08 January 2014 15:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37DEA1ADF58 for <>; Wed, 8 Jan 2014 07:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id as2KryNMtX8z for <>; Wed, 8 Jan 2014 07:54:44 -0800 (PST)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 398981AD68A for <>; Wed, 8 Jan 2014 07:54:44 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id s08FYWkR078644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 08:34:34 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Wed, 8 Jan 2014 07:54:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Scott Rose <>
X-Mailer: Apple Mail (2.1827)
Cc: " list" <>
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: Wed, 08 Jan 2014 15:54:45 -0000

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.

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.

> 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.

> 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.

--Paul Hoffman