Pete, thanks for your review. Tim, thanks for your responses. I entered a No Objection ballot. I think the general approach of limiting the changes to the HTTPS-related ones seems right, and I agree with your argument below about TLS validation.
Alissa > On Apr 8, 2019, at 11:52 AM, Tim Bruijnzeels <[email protected]> wrote: > > Dear Pete, > > Thank you for the review and my apologies for the late reply (I have been > moving house). > > Replies in-line. > >> On 22 Mar 2019, at 19:37, Pete Resnick via Datatracker <[email protected]> >> wrote: >> >> Reviewer: Pete Resnick >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. >> >> Document: draft-ietf-sidrops-https-tal-07 >> Reviewer: Pete Resnick >> Review Date: 2019-03-22 >> IETF LC End Date: 2019-03-18 >> IESG Telechat date: 2019-04-11 >> >> Summary: >> >> I MUST say that this document is quite MUSTy. I only noted those that caused >> me >> confusion or seemed useless. All of these are either minor issues or nits. >> Either way, the document is generally ready. >> >> Major issues: >> >> None. >> >> Minor issues (or might be nits): >> >> In 2.3: >> >> The validity interval of this trust anchor SHOULD reflect the >> anticipated period of stability... >> >> Are there cases where it wouldn't reflect the period of stability? If so, it >> would be good to give an example. If not, then s/SHOULD reflect/reflects. > > This is not modified from RFC 7730 - to which I was not an author. I have > limited my changes to adding HTTPS support. > > That said, I don't think this should be a SHOULD. In practice Relying Parties > will retrieve TA certificates on every validation run, and changes happen at > unpredictable intervals. > > I would prefer a text that said: > > The validity interval of this trust anchor is chosen such that the > "notBefore" time predates the moment that this certificate is published, and > the "notAfter" time is after the planned time of re-issuance of this > certificate. > >> >> Similarly for: >> >> Thus, the entity that issues the trust anchor SHOULD issue a >> subordinate CA certificate that contains... >> >> In this case, that SHOULD might even be a MUST. > > Also unchanged since 7730. > > In my opinion this whole section makes recommendations and assumptions about > operations of a Trust Anchor. But it's not complete, and it does not reflect > the operational realities, and there may be other choices that are valid here > too. > > It may be worthwhile discussing these things in sidrops, but for now I would > propose to make this section a bit less formal. > > So I would suggest: > > CURRENT: > Because the public key in the TAL and the trust anchor MUST be stable, this > motivates operation of that CA in an offline mode. Thus, the entity that > issues the trust anchor SHOULD issue a subordinate CA certificate that > contains the same INRs (via the use of the "inherit" option in the INR > extensions of the subordinate certificate). > > NEW: > Because the public key in the TAL and the trust anchor MUST be stable, this > motivates operation of that CA in an offline mode. In that case a subordinate > CA certificate containing the same INRs, or in theory any sub-set of INRs, > can be issued for online operations. > > I suspect though that some of the RFC7730 authors may object to this change. > >> In section 4, in the last full paragraph and the bullets, I'm not at all >> clear >> why these are RECOMMENDEDs and SHOULD [NOT]s. If they're not MUSTs, it seems >> like you should explain circumstances (at least in general terms) where an >> implementation would choose to do deviate from these. >> > > Personally I would prefer that this document does not try to prescribe how > TLS Verification is done. I don't think this is the right place. The current > text is based on similar text in section 4.3 of RFC8182, which I co-authored. > I don't consider myself an expert on TLS verification - that section is > largely based on IESG feedback at the time. > > I kind of understand where the IESG came from at the time. It's a reference > to RFC7525 which is a BCP for this kind of thing, but in my opinion it > requires too much in the way of specifying local behaviour (to this RFC). I > am not confident that this is the best way - it may not get sufficient > review, it may get outdated, and it may be un-implementable. > > In practice Relying Party implementers will use whatever TLS verification is > done by the HTTPS client libraries that they use. They will have little > control over the exact behaviour. And implementing their own from scratch > will most likely make things more brittle and less secure. > > I am open to suggestions :D > > >> Nits/editorial comments: >> >> In the introduction, the "SHOULD" seems superfluous; it doesn't indicate some >> important implementation advice that someone wouldn't otherwise notice in the >> protocol. But it's a nit if ever there was one. > > ack > > > > Thanks > Tim > > >> >> >> _______________________________________________ >> Sidrops mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidrops > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
