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 <nore...@ietf.org> > 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 > sidr...@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
