A more complete statement might have been nicer, but I will assume that anybody implementing this knows about S/MIME capabilities.
What is there is adequate to address my comment. Jim > -----Original Message----- > From: Paul Hoffman [mailto:[email protected]] > Sent: Sunday, July 31, 2016 6:08 PM > To: Jim Schaad <[email protected]> > Cc: dane WG list <[email protected]> > Subject: Re: [dane] Working group Last call: draft-ietf-dane-smime-11.txt > > On 25 Jul 2016, at 7:02, Jim Schaad wrote: > > >>> I also wanted to make sure people (including the authors) had seen: > >>> https://www.ietf.org/mail-archive/web/dane/current/msg08382.html > >> > >> This has come up in the past when discussing SMIME. One suggestion > >> was to use a different prefix (like _encrypt. and _sign). When this > >> was brought up, the patent status of this was not entirely clear, and > >> there were privacy discussions raised on exposing queries to the > >> purpose of the query. Perhaps the document can state that if the > >> certificate is obtained via SMIMEA, it should be checked whether it > >> is suitable for the task to perform. And that publishers are > >> encouraged to publish SMIMEA records for certificates that allow both > >> signing and encryption. > >> But this latter approach did not have a clear consensus. > > > > This is not the issue that my message was designed to highlight. In > > S/MIME it is possible to say which of the message formats and which > > content encryption algorithms are supported by a client. This is not > > the same as designating if a certificate is being used for encryption > > or signing. > > We will add a mention of RFC 4262 to the draft. > > --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
