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

["Osterweil, Eric" <[e-mail]>]

On Feb 6, 2014, at 11:01 PM, Jim Schaad <[e-mail]> 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/

+1

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

Eric