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

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 14 February 2014 19:18 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 CBD6E1A02E9 for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 11:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPspNVp1iTjs for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 11:18:42 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7203A1A0374 for <dane@ietf.org>; Fri, 14 Feb 2014 11:18:36 -0800 (PST)
Received: from [10.20.30.90] (50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s1EJGS8x064953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Feb 2014 12:17:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-67.dsl.dynamic.sonic.net [50.1.98.67] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com>
Date: Fri, 14 Feb 2014 11:17:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <35DEAFB0-54C5-4E36-923D-36644F88CE7D@vpnc.org>
References: <07ba01cf23b9$4b4e0540$e1ea0fc0$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/ksckwwTpC5jat2EujAVeKpT-7Vg
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] Comments on draft-ietf-dane-smime-04
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: Fri, 14 Feb 2014 19:18:44 -0000

On Feb 6, 2014, at 8:01 PM, Jim Schaad <ietf@augustcellars.com> 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/

Done.

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

Nope, that's out of scope (and we have added a sentence to that effect). This document should *not* change, nor even repeat, the identity-binding rules for S/MIME.

> 3.  Section 2, para 1:  First sentence - see the last item.  It may be not
> an EE certificate that is being associated.

It is *always* an EE cert that is being associated. It may not be an EE cert that was gotten through SMIMEA. I have added wording to that effect.

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

Yep.

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

As this is the debate that has happened later in the WG, we have not added that to the new draft, but we expect to have to address this in a later draft. It is a WG-wide issue, not related just to SMIMEA. I have added a placeholder in the introduction for this topic.

I'll post the new draft after PaulW posts his with the new hash-of-LHS text.

--Paul Hoffman