> The IESG is considering publication of this document as a Proposed
> Standard. The IESG has requested that the TLS WG provide input
> (positive or negative) on this proposal. Please post comments to the
> list before Monday June 11.
I implemented tls-authz in gnutls some time ago and sent two technical
comments in <http://thread.gmane.org/gmane.ietf.tls/2365>. I believe
one of them is still relevant:
- The size of authorization data, i.e., X.509 attribute certs and SAML
assertions, are limited to 64kb. Is it certain that we won't need
more?
Further, as many of you are certainly aware, there are patent claims on
the technology, see the IPR disclosure page at:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833
The disclosure mentions a patent license. I see two problems with the
license:
1) You need to explicitly request license from RPS. This approach has
worked poorly in the past. Some companies goes away and never
replies to such requests, leaving implementers in a legally unclear
situation. There are even examples of big companies not responding
to license requests (ObExample: IBM's Unicode BOCU patent license).
I believe this is sufficient to defer significant wide use of the
protocol.
This problem could be addressed by granting the rights in the license
directly to everyone, without a need to request the license.
2) The license you get restrict use of the protocol to SAML attributes
and X.509 attribute certificates that do not refer to legal
contracts. This is what I have understood 'PAS functions' in the
license to refer to. Whether the references must be explicit in the
authorization data is probably not easy to decide.
I believe there is a considerable amount of prior art for having
implicit references to legal contracts in authorization data. For
example, a Kerberos ticket with a principal that refer to an
employee's account can be seen as an implicit reference to the
employee's contract with the company, which may include a security
policy that needs to be followed. Still, existence of prior art
doesn't mean implementers can ignore a patent.
For one project I'm involved in which is considering to use
TLS-AUTHZ, we've informally realized that this situation is a
non-starter, and that if we have to, we'll look into other technical
solutions to achieve the same goal as tls-authz.
While I am quite aware of efforts to improve the patent situation -- I
have talked to Mark about the license -- I believe that until there is
consensus in the IETF community that the (possibly revised) license
terms are acceptable for wide deployment on the Internet, this document
should not be published as a Proposed Standard.
