On 14/02/17 01:29, Paul Hoffman wrote: > On 7 Feb 2017, at 8:12, Stephen Farrell wrote: > >> I've done my AD review of this draft. My own comments >> on the content are below (the one I'd most like to >> see fixed is the "escrow" stuff) and are ok to be >> handled along with other IETF LC comments. > > We decided to take these on now, before the IETF LC.
And for the record, I'm fine with those changes. (Though a grammar fix may be needed, that can be done later.) Thanks, S. > >> However, before I start IETF LC I would like to be >> sure that the WG are ok with the IPR declaration [1] >> filed in 2014 that said "Licensing Declaration to >> be Provided Later." I think 2017 is "later" enough >> to ask whether that the WG (via the chairs) explicitly >> declare that they are ok that this has yet to be >> clarified. > > Warren has stated the question explicitly, and we await the response. > > --Paul and Jakob > > ====================================================================== > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DNS-based Authentication of Named > Entities of the IETF. > > Title : Using Secure DNS to Associate Certificates > with Domain Names For S/MIME > Authors : Paul Hoffman > Jakob Schlyter > Filename : draft-ietf-dane-smime-15.txt > Pages : 11 > Date : 2017-02-13 > > Abstract: > This document describes how to use secure DNS to associate an S/MIME > user's certificate with the intended domain name, similar to the way > that DNS-Based Authentication of Named Entities (DANE), RFC 6698, > does for TLS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-dane-smime-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-15 > > > ====================================================================== > >> - abstract: Someone will want DANE expanded. Better to avoid >> the acronym maybe. > > Done. > >> - intro: "Some people want..." is odd - that is not a >> technical justification and the entire paragraph is not that >> convincing. I'd say deleting that para would be better. Or >> add a real justification for the experiment which I think >> relates more to attempting to mitigate the difficulty of >> finding certs from outside the enterprise than anything else. > > Many people here liked the justification, but we agree that your > justification is a good one as well. Added. > >> - intro: I'd suggest adding a sentence about how this is >> similar to RFC7929. As a reader, I'd find it odd to only find >> that out later. > > Done. > >> - section 3: This is the same idea as in RFC 7929 right? >> (Other than _smimecert I mean,) If so then saying so is right >> as it'll help with IETF LC and IESG review and for >> developers. If those differ, then saying how and why I think >> would be needed. > > Done. > >> - section 4: Please check whether this is all fine when also >> considering draft-ietf-lamps-eai-addresses (also in IETF LC). >> That check may need to wait a little bit until we're done >> with the LC comment handling for the LAMPS deraft. > > The current text is "all fine" with the LAMPS draft. > >> - Section 9: the discussion of an MTA doing the outbound >> encryption seems a bit theoretical - I don't recall that >> being dnoe in reality except maybe in very special cases like >> nested smime, or military messaging. Am I wrong about that? > > Yes, you are. There have been products doing this for many years > (possibly more than a decade). Having said that... > >> - section 9: I think the text about escrow would be better >> after the current last para (where you call out the danger of >> bad public keys being put in the DNS), and this (escrow) >> ought be described as a special case of that attack, where >> the attacker is the organisation itself. (While there are >> cases where the organisation doing this is not intended as an >> attack, were it done for most DNS names, it would mostly be >> an attack, and is not distinguishable from an attack for the >> sender, so therefore it ought IMO be considered an attack.) > > Yes, good call. Done. > >> - section 9: s/MUST not/MUST NOT/ or I-D nits complains > > And we must keep the tool happy, mustn't we? Done. > >> - section 11: I-D nits complains, maybe calling this >> "normative references" would help, but in any case, please >> consider/fix this. > > The tool is wrong, but we can fix it easily anyhow. Done. > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
