Skip to content, sitemap or skip to search.

Personal tools
Join now
You are here: Home Blogs Community IETF: Please reject the "Transport Layer Security (TLS) Authorization Extensions" proposed standard

IETF: Please reject the "Transport Layer Security (TLS) Authorization Extensions" proposed standard

by John Sullivan Contributions Published on Feb 11, 2009 12:02 PM

The Free Software Foundation and the GNU Project oppose publication of "Transport Layer Security (TLS) Authorization Extensions" (draft-housley-tls-authz-extns) as a proposed standard. We do not think that RedPhone Security's 1026 disclosure filing provides sufficient assurance to free software users that they will not be considered in violation of RedPhone's patent.

In response to a previous RedPhone patent disclosure, GnuTLS removed its support for these authorization extensions. The updated Licensing Declaration does not provide assurance sufficient for GnuTLS to restore this support, and the same unfortunately holds true for any other software maintained by the GNU Project.

The Licensing Declaration starts out right:

RedPhone Security hereby asserts 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 (IPR).

However, it is then followed by an important caveat:

The values provided in, and the processing required by the authorizations ("authz_data" in the Protocol Document) sent or received using the techniques defined in TLS Authorizations Extensions are not specified in the Protocol Document. When an implementation generates the authorizations or processes these authorizations in any of the four ways described below, then this practice may be covered by RedPhone Security's patent claims.

It appears that RedPhone's disclaimer covers software developers who implement the standard in a vague sense, but not the people who then actually use that software. A patent disclaimer must clearly cover both developers and users to be acceptable. Furthermore, the caveat is not written exclusively, leaving the door open for further claims. It does not say that the four ways described are the only practices that may be covered.

RedPhone's assurance that it will "grant licenses for such uses in a fair and nondiscriminatory manner" does not address the problems raised by their assertion, because software users cannot be expected to place trust in a company's judgment of what constitutes fair or nondiscriminatory. No company should be vested with the power to make case-by-case licensing decisions about who can and who cannot use or implement a standard, and users regardless should not have to pay for permission to use Internet standards.

We know that the IETF and IESG largely share our view that patent-encumbered standards are unacceptable. We believe that the process has twice now reached the proper conclusion -- the draft has been rejected as a standard. Please do not allow this decision to be negated. If RedPhone is serious about providing a patent assurance sufficient to cover both writing and using software that implements these authorization extensions, the FSF would be happy to work with them on drafting text that makes this intent clear.

On a broader note, we'd like to suggest that the IETF consider the impact of of patents and copyrights on proposed standards specifically and separately, instead of under the umbrella of IPR or "intellectual property." The term lumps together disparate areas of law and inaccurately frames questions then discussed as analogous to questions about property rights over physical objects -- a framing that suits companies who wish to extend the influence of their copyrights and patents. It also has the effect of including other laws in the discussion which don't actually pertain to the question of who can use the standard. The term has unfortunately become widespread, but a community as concerned and responsible with language as the IETF should take leadership in this area and reject its use.

Thank you for the opportunity to comment on these issues. We recognize that the volume of mail generated by our announcement about this issue to the free software community may be causing inconvenience, but causing inconvenience was not the point of that call. In our reading of the comments that have been sent so far from the free software community, the majority of them are from people who work in related areas and have taken time to think through and express their concerns. We hope the IETF will consider each comment on its individual merit, and if the volume of mail is interfering with that process, consider providing in the future a separate address for comment that is not the general mailing list. Our goal and our encouragement to the public is to participate in the process according to the directions provided, not to spoil it.

Document Actions

The FSF is a charity with a worldwide mission to advance software freedom — learn about our history and work. is powered by:


Send your feedback on our translations and new translations of pages to