SUMMARY I do not believe this document should be advanced to Proposed Standard at this time. First, it is not clear that there is really sufficient interest in this document to justify it being at the PS level. Second, despite several revisions to the RedPhone IPR disclosure, the IPR status of this document remains unclear. Finally, there are technical issues that should be fixed before the document advances at all. BACKGROUND This document was originally brought to the TLS WG, which expressed little interest in it. It was subsequently sponsored as an individual submission by then SEC AD Sam Hartman and approved by the IESG. Subsequent to IESG approval, one of the authors (Brown) filed an IPR statement (https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=765) that claims to cover the technology. The listed terms were RAND but not necessarily royalty-free. The IESG rescinded the approval of this document and sent it back to last call. In the interim, two other IPR statements have been filed, one by Stephen Farrell on work that he did and a third party disclosure one by Eric Rescorla on some IBM work. In the subsequent last call, there was not wide support for the document and it was not approved. Recently, Brown revised his IPR statement to assert that at least some usages of this draft are not covered by the relevant patent application (https://datatracker.ietf.org/ipr/1026/) and that encumbered usages would be subject to RAND licensing, leading to this fourth last call. IPR ISSUES IMHO the IPR situation is substantially less clear than it has been made out to be. First, there is is not one but three IPR disclosures, with the other two relating to Siemens and IBM. As I stated in my previous review, I'm not too worried about the IBM IPR, but the Siemens one is less available and it's harder to evaluate, though the inventor, Steve Farrell says he thinks it may not apply. That still leaves the RedPhone IPR. As I indicated above, the current IPR statement asserts that only some uses of this document, not the document itself, are covered by the relevant patent application: RedPhone Security hereby asserts that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights (IPR). This statement applies only to the IETF Document draft-housley-tls-authz-extns-07.txt (hereafter the "Protocol Document"). The values provided in, and the processing required by the authorizations ("authz_data" in the Protocol Document) sent or received using the techniques defined in TLS Authorizations Extensions are not specified in the Protocol Document. When an implementation generates the authorizations or processes these authorizations in any of the four ways described below, then this practice may be covered by RedPhone Security's patent claims. I have two concerns here. First, it is not clear to me that the four listed ways don't actually implicate a significant fraction of the space. In particular, one very natural use of authorization data is in coordination with legal agreements. However, this is specifically two of the four listed covered uses: 2. To store Agreements and locate Agreements based on authorization data received from a sender, where Agreements are any legally recognizable and documented agreement between two parties, including, without limitation (a) agreements between governing bodies (e.g. treaties, memoranda of understanding), (b) agreements created by governing bodies (e.g. laws, edicts, orders), and (c) other agreements enforceable by governing bodies (e.g. contracts, negotiable instruments). 3. To compare the sender of authorization data to a stored collection of Agreement signers. So, in practice, many useful applications of this document are in fact encumbered. More troubling, however, is potential encumbrances outside of these four uses. The assertion by RedPhone is just that, an assertion. It is not a license grant. If I implement the protocol described in this document, I would still be vulnerable to an infringement suit by RedPhone even if I did not use it in any of the four listed ways. RedPhone would simply have to assert that upon reexamining the patent it had concluded that the scope was more general than they had previously sought. All RedPhone's assertion buys me is a defense against willful infringement. To sharpen this point, consider the case where RedPhone sold the patent to some other entity which then decided to file suit. This is not a purely theoretical worry. While I have not studied the patent, a number of the claims seem rather broader than what is described above and quite possibly cover all uses of the protocol described in this document. TECHNICAL ISSUES S 3.3. As Simon Josefsson notes, the length of the SAMLAssertion should allow up to 2^24 or 2^32 bytes. As far as I know, the only objection to this is backward compatibility. S 3.3.1 I'm quite concerned about the use of entityName field to bind an AC to a certificate. In the absence of Internet-wide name subordination, there may be many certificates with the same DN issued by different CAs. As the issuer of an AC, I generally want to authorize specific entities, not "anyone who has a DN that chains to one of the 150 roots in your browser". I would remove this option entirely. S 3.3. This URLandHash production has a nasty futureproofing bug, because the length isn't self-contained. If the server uses a hash the consumer doesn't recognize, the consumer can't even parse the rest of the extension, even if it contains other AuthorizationDataEntry objects which the client could otherwise parse and which would in and of themselves be sufficient. The URLandHash production should either have a length or have the hash be a variable length value, e.g., opaque hash<0..255>. This would allow parsing even if you don't know the hash. S 3.3.3 This circular reference issue seems bogus to me. There are lots of places where it's not going to be relevant, and SHOULD is overstrong. S 4. This document should use the RFC 5246 hash registry (and its contents), not define its own. Note that the values in that registry differ from those in this draft. EDITORIAL ISSUES S 2. The beginning of this section needs to be clearly marked as non-normative, since it's just a recap of 4366. S 3. "can be exchanges" -> "can be exchanged" -Ekr _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf