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

["Jim Schaad" <[e-mail]>]

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.

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.

A mention, but problem not a solution, to the case folding problem for local
parts in email addresses needs to stated so that people understand it
exists.    A quote from RFC 6530 is

  It has long been the case that the email syntax permits choices about
   mailbox names that are unwise in practice, if one actually intends
   the mailboxes to be accessible to a broad range of senders.  The most
   often cited examples involve the use of case-sensitivity and tricky
   quoting of embedded characters in mailbox local parts.  These
   deliberately unusual constructions are permitted by the protocols,
   and servers are expected to support them.  Although they can provide
   value in special cases, taking advantage of them is almost always bad
   practice unless the intent is to create some form of security by
   obscurity.

Which would seem to me to say, yes this is a legal thing to do.  However if
you do it you should be taken back of the wood shed and whipped.  Thus
although it is legal it is highly unadvisable.  Thus one does case folding
in the look up, one may be get a wrong security answer so one should not do
it even if it is tempting.  I.e. - this at a minimum is a security
consideration because people are going to try and do it if we don't tell
them not to do it and why they should not do it.