...
I did spend some time reading the draft, the IPR disclosure and before stating an opinion it would be nice if the people that have dealt with it longer could tell me if what I got out of it is correct so far.
1. RedPhone Security applied for some patents that we are talking about here in 2005 2. RedPhone Security then authored/co-authored a draft in 2006 3. This could no be successfully processed within the TLS WG 4. The draft was then submitted as individual submission 5. The IESG did not approve the document because of an IPR disclosure that has been removed as of now 6. After two years the authors try to again standardize the same draft that was declined two years ago with a new IPR disclosure 7. While the IPR may not be relevant to the draft (IANAL) I do not see how an useful implementation could work around it: - The draft is about extending TLS to authorize before the secure connection is established - Authorizations are usually done by exchanging and comparing secrets/ certificates - This is exactly what points 3 and 4 of the IPR disclosure describe
I completely disagree with this assessment. The points you mention are quite specifically talking about Agreements, not certificates. Agreements are defined in point 2: 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). Let me be the first to state that placing a definition of a key term in the middle of an item list and then referencing in subsequent items, as opposed to usual approach of having a separate section defining terms, is a pretty poor way to write this up, but even so I think the meaning is quite clear. What's being reserved here is a fairly specific set of use cases where this mechanism is used to muck around with a stored set of agreements (per the above definition). The real question is whether or not having to pay to use this technology in this particular set of use cases is too onerous or not. I can envision several uses for this extension, mostly revolving around the server sending back information about what the client is or isn't authorized to do and the client adjusting the options it makes available accordingly, and none of them involve operations of any sort on stored agreements. But others with other intended uses for this stuff may see it differently, (And of course anyone who actually uses this extension for something would be wise to consult with an actual lawyer. That's also a nonnegligable burden that needs to be taken into account.) (I guess this means I agree with Brian's assessment of this and disagree with Eric and Simon.) I will also point out that patents on specific use cases of various IETF protocols are quite common. At a minimum I am aware of similar patents on use cases in SMTP, IMAP, HTTP, and LDAP. (I recently did an expert witness gig in a case involving patent claims on both SMTP and HTTP, as a matter of fact.) If we decide the existance of such patents preclude standardization we're going to find ourselves with nothing to do in fairly short order.
If all of the above is mostly correct
IMO it is not. In particular, I think you have confused "agreement" with "certificate" and that they are not at all the same thing.
I would say that the fact that there is no royalty free license available for implementors and there are a lot of TLS implementations available under FOSS licenses, which could not implement this without violating RedPhone's IPR would lead me to the conclusion that I have to oppose this draft.
This also appears to be incorrect - even to others who opposed approval of this document. Even given the broadest possible interpretation of the terms of this agreement, it's still about use, not implementation of the basic mechanism. The statement of this could not be clearer: No License Required for Implementers. Of course if your implementation is targetted at the use cases RedPhone is pursuing and you proceed to distribute it for that purpose, you're likely to get into trouble. Ned P.S. I've read the IPR dlsclosure and the patents claims, but what would be useful to see is the document shepard writeup. Are those available somewhere online? If they are I don't know where to find them and I was unable to coerce The Google into dilvulging their location. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf