> -----Original Message----- > From: Carl Wallace [mailto:[email protected]] > 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" <[email protected]> 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> _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
