On Jan 18, 2012, at 3:38 PM, Alexey Melnikov wrote: > On 17/01/2012 10:16, Brian Trammell wrote: >> 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... > Saying it is an opaque string is Ok, but you don't even specify which > characters are allowed in it. >> Will add. > Thanks.
Hm. Good point; also didn't mention a maximum length. Fixed in -07, defined as 1*255(VCHAR). >>> 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. > How about something like this: > > OLD: > RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual > authentication for transport confidentiality, identification, and > authentication, as in [RFC2818]. > > NEW: > RID systems MUST use HTTP over TLS as specified in [RFC2818], with the > exception > of server TLS identity verification which is detailed below. Ah. Okay, now I understand the issue... > RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual > X.509 authentication. TLS provides for transport confidentiality, > identification, and authentication. The language has changed in -07 to the following; would this be acceptable? RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual authentication for confidentiality, identification, and authentication, as in [RFC2818], when transporting RID messages over HTTPS. RID systems MUST use mutual authentication; that is, both RID systems acting as HTTPS clients and RID systems acting as HTTPS servers MUST be identified by an X.509 certificate [RFC5280]. Mutual authentication requires full path validation on each certificate, as defined in [RFC5280]. >>> 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. > SRV-ID are really only applicable to protocols which are using DNS SRV. So I > would have prohibited them... But if you want to keep using them, you need to > specify what is the service name you would expect in them. Indeed. We don't, so, removed. Thanks for the clarification. Actually, since the binding between RID and a PKI is better defined in rfc6045-bis, 6046-bis now refers to it, as follows: Each RID system SHOULD authenticate its peers via a PKI as detailed in Section 9.3 of [I-D.ietf-mile-rfc6045-bis]. Would this address the concern? Many thanks, best regards, Brian >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/gen-art
