Hi, Alexey, Thanks for the review; questions and comments thereon inline...
On Jan 14, 2012, at 9:45 PM, Alexey Melnikov wrote: > I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, > please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments you may > receive. > > Document: draft-ietf-mile-rfc6046-bis-05 > Reviewer: Alexey Melnikov > Review Date: 2012–01–14 > IETF LC End Date: 2012-01-17 > IESG Telechat date: 2012-01-19 > > Summary: This draft is almost ready for publication as a Proposed Standard > RFC. > > > Major issues: > > In Section 3: > > The RID callback MUST contain a zero-length entity body > and a 'RID-Callback-Token' entity header > > [Minor issue] "header" --> "header field" (header is the collection of all > header fields). > > , itself containing a unique > token generated by the receiving RID system. > > I am missing ABNF for the new header field. Seems a little superfluous... it's an opaque string, but I suppose we should point out it doesn't contain \r or \n... Will add. > RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual > authentication for transport confidentiality, identification, and > > Do you mean that a RID client must use X.509 certificates? Well, each RID system (HTTP client or server) is identified by an X.509 certificate (hence "mutual"); how can I make this clearer? > authentication, as in [RFC2818]. > > I find the whole sentence to be confusing. Note that the rules of RFC 6125 > for certificate verification are stricter than in RFC 2818 and this sentence > can be read as conflicting with the paragraph below which requires use of RFC > 6125. What are you trying to say here? The intention here is "Use current best practices as would be supported by off-the-shelf HTTP/1.1 and TLS 1.1 implementations to provide mutual authentication." "Current best practices", however, seems to be something of a moving target. I cite 2818 as it is the current binding between HTTP/1.1 and TLS. I cite 6125 solely for certificate verification. > RID systems MUST provide for the verification of the identity of a > RID system peer presenting a valid and trusted certificate, by > verifying the fully-qualified domain name and service name from the > DNS SRV record, if available, against that stored in the certificate, > > I am confused: this is the first time DNS SRV records are mentioned > (BTW, they need a Normative Reference). Earlier text seem to suggest that DNS > SRV are not used to locate protocol endpoints. If RID is using DNS SRV, then > information about how it is used is missing from the document. It doesn't. Was trying to point out here that SRV must be matched if (for deployment-specific reasons) it was present. This is simply a poor attempt at citing 6125. > as in Section 6 of [RFC6125]. > > RFC 6125 allows for various options and this paragraph doesn't seem to cover > all of them. I suggest you check Section 13.7.1.2.1 of RFC 6120 for an > example of what should be specified (ignore XmppAddr identifier type, as it > is very XMPP specific). For X.509 SANs which are disallowed, you should say > so. Will do. (6125 is missing something here, a guide for using it in other specs...) Best regards, Brian _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
