> -----Original Message----- > From: dane [mailto:[email protected]] On Behalf Of Paul Wouters > Sent: Monday, July 25, 2016 6:33 AM > To: Warren Kumari <[email protected]> > Cc: dane WG list <[email protected]> > Subject: Re: [dane] Working group Last call: draft-ietf-dane-smime-11.txt > > On Sun, 24 Jul 2016, Warren Kumari wrote: > > > A reminder that this WGLC closes tomorrow -- so far we have not really > > seen sufficient feedback on this document. PLEASE review this document > > and provide comment. > > I have reviewed the document. I think it is ready for IETF LC but it could > see a > few small changes: > > It should probably update its reference in the introduction to list soon to > be RFC- > 7929 (openpgpkey) and wait on that doc (in AUTH48 now) to go out first. > > The SMIMEA resource record has no special TTL requirements. > > During openpgpkey discussion, it was decided it was better to remove this > line. I > would think the same applies to smime. > > During openpgpkey discussion, people insisted on specifying the "experimental > goal" of the Experimental RFC. That section is missing in this document. > > Section 3's title is a bit long. In openpgpkey we used a shorter title. I > suggest > "Location of the SMIMEA record". > > The openpgpkey had updated the "tcp only" phrasing to make it more layer > agnostic and mentions DNS-COOKIES as a defense and method to allow UDP. > You might want to consider using the same approach instead of banning UDP > altogether. > > > 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. Jim > > Paul > > > W > > > > On Sat, Jul 9, 2016 at 12:53 PM, Olafur Gudmundsson <[email protected]> > wrote: > >> > >> Dear Colleagues > >> > >> The editors of > >> https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ have > >> requested a WGLC, the chairs are satisfied that the document is in > >> good shape. This message starts a three week WG LC, that concludes on > >> Monday July 25 23:59 UTC (we have extended the usual 2 weeks because > >> of the upcoming meeting, travel, etc). > >> > >> This document is on the Experimental track, it is a close relative of > >> a prior document from our group > >> https://datatracker.ietf.org/doc/draft-ietf-dane-openpgpkey/ which > >> is in > >> AUTH-48 at this point. > >> Any discussions on “local part” other than to point out a difference > >> between the OPENPGP document and this one are out of scope. > >> > >> Any other issues should be brought forward > >> > >> thanks > >> Olafur & Warren > >> > >> _______________________________________________ > >> dane mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/dane > >> > > > > > > > > -- > > I don't think the execution is relevant when it was obviously a bad > > idea in the first place. > > This is like putting rabid weasels in your pants, and later expressing > > regret at having chosen those particular rabid weasels and that pair > > of pants. > > ---maf > > > > _______________________________________________ > > dane mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dane > > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
