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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf