Hi Eric, My take fwiw: I personally don't believe that the slightly-inventive bit of the stuff I sent to the patent lawyer should cover this I-D - at the time, (and I've no records to help, sorry), we weren't blessed with open source browsers and so we had to use proxies to insert our authorization logic - so there were no ACs/PACs or any other authorization tokens in the TLS handshake at all (I think we basically did a MITM on the browser). In my mind the nub of the issue is that the proxy had to pre-empt the normal https flow in order to do authorization (and, more tellingly at the time, strong crypto which is actually what we were interested in providing). But IANAL and all that of course. More to the point, I really have no clue whether or not the German language claims might or might not cover the I-D in question. To the extent I can help, I'd be happy to work with someone who can parse German legalise to try get a better handle on that. I do recall being careful that draft-ietf-tls-attr-cert didn't impinge on what I thought at the time might be encumbered. But I've nothing good to cite to back that up I'm afraid and the subsidiary that I worked for then no longer exists. Sorry again, but it was a decade ago. I think your conclusion about processing this in the TLS WG is the right one, and I'm happy to do whatever I can to help there or wherever. Regards, Stephen. Eric Rescorla wrote:
$Id: draft-housley-tls-authz-extns-07-rev.txt,v 1.1 2007/03/09 18:52:17 ekr Exp $ BACKGROUND This document specifies a generic mechanism for including additional non-TLS authentication data (e.g., attribute certificates). This data isn't necessary to complete the handshake cryptographically but might be of use to some higher-level application. This document was not a product of the TLS WG but was reviewed by at least some members of the WG. This document was 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 are 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. All disclosures can be found at: https://datatracker.ietf.org/public/ipr_search.cgi?option=document_search&document_search=draft-housley-tls-authz-extns DISCUSSION I have reviewed the Brown and IBM patent applications. It is not clear to me that the Brown application covers this draft. I have trouble seeing how the seeing how the claims are on-point at all. In my non-lawyer opinion the IBM application clearly covers this draft, but every important claim is preceded by the prior art of draft-ietf-tls-attr-cert (http://tools.ietf.org/html/draft-ietf-tls-attr-cert-01). So, I'm not over-worried about this IPR either. I have not yet reviewed the IPR cited by Mr. Farrell, and his comments suggest that this may be fruitless: I was an inventor. The Siemens subsidiary involved no longer exists. I don't know where the ownership ended up. The filing is extremely unclear, even for a patent - the reason is that the lawyer translated my input to German, filed that and later translated back to English, all without checking back with any of the inventors. The German version may be more easily understood, I don't know. The original filing was to protect a product that sent SESAME PACs (inside GSS tokens) to & fro in order to do access control for web clients & servers. The I-D isn't doing that, but the claims might be written broadly enough to be a concern. However, since Mr. Farrell was also the author of draft-ietf-tls-attr-cert it's not at all implausible that it would be covered by this work. I'm fairly conflicted here. On the one hand, I believe there is some interest in being able to carry SAML assertions and X.509 attr certs in TLS handshakes. While it appears that Mr. Brown failed to disclose his relevant IPR, it's not clear to me that this has any practical effect since I don't see how this IPR affects one's ability to implement this standard. On the gripping hand, I *am* worried about the IPR cited by Mr. Farrell and I have not yet had a chance to analyze it. My TLS co-chair suggests that this document should go forward as Experimental. I see two problems with that. First: it assigns code points out of a space which is reserved for Standards Action. Second, the only reason for this document to proceed at all at this point (given the IPR issue) is the claim that there are applications which actually would make use of this extension. Given all this, plus the fact that this is squarely a TLS-relevant document, and the IETF norm that it is best when WGs assess the level of IPR involvement and balance that against the important of the work, I think it would be best if this work were brought to the TLS WG, which could decide whether to make it a WG item, in which case the decisions about IPR could be made in the WG. If it clears that bar, then we can have some level of confidence that the IPR issues were judged. If it can't meet that bar, then it probably should not be published at all. -Ekr _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf