On 2009-01-14 at 08:18 -0800, The IESG wrote:
Since the third Last Call, RedPhone Security filed IETF IPR disclosure
1026. This disclosure statement asserts in part 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". The
full text of IPR disclosure 1026 is available at:
https://datatracker.ietf.org/ipr/1026/
I've read through that.
So, implementing the part of any useful application which does the
protocol encoding/decoding is not encumbered, but doing anything
practical with it is?
In particular, RedPhone disavow patent encumbrance over
sending/receiving but not upon, eg, constructing the authorizations to
send or interpreting them; then, they explicitly note cases which may be
encumbered, such as looking up the claimed authorizer to ensure that
they are in fact permitted to make such an authorization, or using data
conveyed in the extension after checking the signature.
Either the security policy is statically configured, so a lookup needs
to be performed, or the security policy is carried in the TLS
transaction and the protocol signatures need to be verified so that
arbitrary assertions aren't trusted.
I'm not a stake-holder in this and haven't previously contributed, so
have no reasonable voice in objecting, but I am trying to understand the
situation.
It's of little value to be able to send data across the wire if that
data is not permitted to convey useful information.
For the people who want this draft published (and perhaps have a pending
implementation), would you please humour me by offering some usage
scenarios, other than debugging or toys, which would meet security
review and which are not covered by the four points which the
patent-holder notes as potentially encumbered?
I'm far from a subject matter expert, so there may well be such cases; I
hope that the act of laying out a counter-example or two will make it
clearer for all concerned parties what can and can't be done and
demonstrate practical use to publication.
Thanks,
-Phil
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf