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

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

> -----Original Message-----
> From: Carl Wallace [mailto:[e-mail]]
> Sent: Tuesday, September 11, 2012 5:29 PM
> To: Jim Schaad; 'IETF DANE WG list'
> Subject: Re: [dane] Review draft-hoffman-dane-smime-04.txt
> 
> On 9/11/12 8:04 PM, "Jim Schaad" <[e-mail]> wrote:
> ><snip>
> >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.
> 
> Why the trust anchor?  It's far more common (in my experience) to have to
> install a trust anchor to exchange email with someone than to interact
with a
> web server.  It's also common for the trust anchor considered by the
sender
> to vary from the trust anchor used by the verifier.  A CA constraint
should
> work well here.

You are quite right that a CA constraint would also work here as well.
However part of the effort is to reduce the need to install the trust anchor
as is currently required today.  I would agree that that one would be able
to say a) this EE cert and b) through this CA as well.  I would argue that
we want to create the AND statement that I argued for back in the days of
DANE base spec but nobody else thought was needed.


> 
> >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.
> 
> Certificate lookup for encryption seems like something that might be
better
> solved using a certificate transparency log.

It will be interesting to see if this really amounts to anything, but the
authors have said that this is one goal of the current work.

Jim

> 
> <snip>