...
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf