Re: [dane] Comments on draft-ietf-dane-smime-04

"Osterweil, Eric" <> Thu, 13 February 2014 18:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 606FC1A03B1 for <>; Thu, 13 Feb 2014 10:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g-8_N9M2o6k8 for <>; Thu, 13 Feb 2014 10:19:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A15CD1A03A7 for <>; Thu, 13 Feb 2014 10:19:13 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 13 Feb 2014 10:19:30 PST
Received: from ( []) by (8.13.6/8.13.4) with ESMTP id s1DIJBpe029637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 13:19:11 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.02.0342.003; Thu, 13 Feb 2014 13:19:11 -0500
From: "Osterweil, Eric" <>
To: Jim Schaad <>
Thread-Topic: [dane] Comments on draft-ietf-dane-smime-04
Thread-Index: Ac8jpUDvnDpFqfeXTuqw0g8WYmGXPwFbL7gA
Date: Thu, 13 Feb 2014 18:19:10 +0000
Message-ID: <>
References: <07ba01cf23b9$4b4e0540$e1ea0fc0$>
In-Reply-To: <07ba01cf23b9$4b4e0540$e1ea0fc0$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>, "<>" <>
Subject: Re: [dane] Comments on draft-ietf-dane-smime-04
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: Thu, 13 Feb 2014 18:19:36 -0000

On Feb 6, 2014, at 11:01 PM, Jim Schaad <> wrote:

> 1.  Section 1, para 1: The first two sentences imply that a single
> certificate is going to be present in a message.  While this is true in a
> large number of cases, there are many times in which more than one
> certificate may be present.  These include having different signing an
> encrypting keys or intermediate certificates for chain building.  I would
> request that the first two sentences be modified to make certificate be
> plural.  s/a certificate. This certificate assists/certificates.  These
> certificates assist/


> 2. Section 1, para 1: The last sentence is missing a step in the description
> of the process of validating that  certificate is bound to a purported
> sender.  The current text just looks at the validation process and does not
> talk about what is necessary to check the binding itself.  In most cases,
> but not all, this involves looking for the senders email address in the
> certificate itself.  (In other cases some type of external database would be
> required or one could say that the sender and the signer may not be the same
> person even though the signature itself validates.)
> One thing about this document that I don't remember having seen on the list
> is the question of doing the binding check between the senders address and
> the contents of a certificate.  Is it going to be considered sufficient if
> one does the DNS look up for the certificates?  Is it only a sufficient
> check for some types of SMIMEA records but not for others?  I.e. EE
> certificate vs CA or TA certificate.

I agree that we should discuss this.  With PGP, I can use a key with a diff email than the account from which I send it (for ex, I can use my spam account and rely on my full name and friends who know me to make the logical leap), do we all want DANE to outlaw this for S/MIME?  

> The document needs to distinguish between the steps of validating and
> trusting a certificate and doing the binding between an email address and  a
> certificate.  While it is possible to both in some cases, in others these
> need to be distinct steps.
> 3.  Section 2, para 1:  First sentence - see the last item.  It may be not
> an EE certificate that is being associated.
> 4.  Section 3, step 1:  It would be nice to be explicit that you are doing a
> UTF8 Unicode string to octet string transformation before doing the Base32
> conversion.  The referenced document says that this is the case for SMTP
> submission in one mode, but it is not clear that the SMTP submission format
> is what we are doing here.  Being explicit would be helpful.
> There are two general problems that people are looking to solve with this
> document.
> A) I have an email address and a certificate, I want to validate the
> certificate and check the association between the certificate and the email
> address.
> B) I have an email address, I need to find a certificate.
> At present I believe that this document is addressing problem A and not
> problem B.  It would be good to state that problem B is out of scope in the
> introduction if this is the case.
> If problem B is what the document is trying to solve, then there are a
> number of issues that need to be addressed:
> a) The set of certificate usages needs to be restricted to 1 and 3 so that
> one will get a certificate about the EE
> b) The set of certificates selectors needs to be restricted to 0 so that the
> certificate is always present
> c) The matching type needs to be restricted to 0 so that the certificate is
> always present.

Actually, Scott Rose's suggestions on this draft cover a mechanism to overcome this, by pointing at a place to learn certs.  I think this commentary helps to further underscore the utility of that.