[dane] Review draft-hoffman-dane-smime-04.txt

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

1.  Based on the set of email messages I think that the introduction needs
some expansion. My previous question on the scope of the problem had to do
with the first sentence of the introduction as this implies that
certificates coming with messages are the main point of this document.   I
will try and address this in a separate message.

2.  In order to deal with issues that are present for S/MIME and not for
TLS, I believe that a new conjunction items is required to be added to the
Certificate Usage field that says a) this is the EE certificate to be used
and b) this is the trust anchor to be used.

3.  If the certificate lookup problem is to be solved, then it needs to be
made clear that the full certificate selector is going to be the common one
for the EE certificate of an S/MIME recipient for encryption, but it may not
be for an S/MIME sender that is signing.  

4.  I think a new security consideration needs to be placed in for dealing
with certificate revocation.  In the TLS case if a server knows that a
certificate has been revoked, it can just not present it and the only
problem will be that the client cannot validate the certificate until the
TTL has expired.  This is not the case for encryption certificates for
recipients of S/MIME messages.  It is highly probable that the recipient
will still want the sender to do a revocation check as that might be faster
than the TTL expiration.  In this case the sender will be unable to get a
valid certificate and must defer sending.  If this is not the case then a
certificate which has been revoked by the CA might still be used by an RP
because it is valid in the DNS.  At a minimum this is a discussion that is
needed for setting TTL times on these records.

5.  I think a new security consideration needs to be placed in for dealing
with the fact that the DNS authority might not be authorative for any
information in the association.  As presented elsewhere, consider the case
where I put up a CA for my enterprise, but decide to all the use of Gmail
accounts for some employees.  This means that I now need to have Google
publish into its DNS the EE and trust root certificates for my employees
that are using the Gmail accounts.  Google however does not control any of
the security properties of the CA that is being used to issues and maintain
the certificates involved.  This different from the usual TLS case where the
DNS provider and the service provider have a tight association.  Even in the
case where things are outsourced there is a contractual relationship between
the DNS provider and the service provider.  This is not the case for the
email world.

6.  It might be worthwhile to consider allowing for publication of trust
anchor records (only type 2) at the _smimecert level for those cases where a
small number of trust anchors should be used for all of the recipients for a
domain.  This does not solve the EE certificate look up problem, but does
make a simpler way to advertise the TA for a domain without allowing trolls
to find all of the email addresses associated with a domain.

7.  This document does not refer to the registries created in 7.2, 7.3 and
7.4 of the DANE TLSA document.  This means it is not clear that if a
document defines a new TLSA certificate usage, that it would or would not
apply to the SMIMEA record.  A this time I would assume that it would not.

8.  As mentioned elsewhere, the problem of looking up certificates in the
presence of mail servers that are willing to do collapse of local parts
needs to be addressed.  The problem needs to be described, but a solution
does not need to be stated as this is highly dependent on how the collapse
is going to be done.

Jim