Sirs;
I am writing to protest moving forward with "Fourth Last Call:
draft-housley-tls-authz-extns" in part because I find the announcement
disingenuous at best. The announcement on the email list quotes IPR 1026:
"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"..g. laws,
edicts, orders), and (c) other agreements enforceable by governing bodies
(e.g. contracts, negotiable instruments)."
However, the Fourth Last Call fails to note that IPR 1026 goes on to say:
====
"The Patent Holder states that its position with respect to licensing any
patent claims contained in the patent(s) or patent application(s)
disclosed above that would necessarily be infringed by implementation of
the technology required by the relevant IETF specification ("Necessary
Patent Claims"), for the purpose of implementing such specification, is as
follows(select one licensing declaration option only):
...
"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.
1. To issue or validate certificates containing "critical" certificate
policies using Object Identifiers within an arc registered to RedPhone
Security (e.g. iso.org.dod.internet.private.enterprise.23106). This
includes, without limitation, Certificates or Attribute Certificates.
2. To store Agreements and locate Agreements based on authorization data
received from a sender, where 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).
3. To compare the sender of authorization data to a stored collection of
Agreement signers.
4. To sign ("countersign") authorization data received from a sender via
the TLS Authorizations Extensions after verifying that the sender's
digital signature over those assurances is correct.
RedPhone Security agrees to grant licenses for such uses in a fair and
nondiscriminatory manner. This statement applies to the Disclosed Patent
Information, including all amendments in all nations as published during
the course of prosecution."
====
Items 2,3, and 4 in RedPhone Security's list are very problematic in my
view. They are a natural extension to anyone skilled in computer science
and therefore should not have been granted a patent in the first place.
That is still somewhat beside the main point, however. The IETF used to
insist upon at least two working, interoperable implementations before any
draft RFC could reach Proposed status. At least one of the two needed to
be public domain or FOSS. This used to be regarded as a minimum
requirement to enforce the ISOC's mission to establish global standards.
That mission still exists. Redphone Security's stance as outlined in IPR
1026 negates the possibility of creating such a global standard because
there is no such thing as "fair and non-discrimnatory" for FOSS unless the
license grant is to all developers and users. Therefore, IPR 1026 forces
the IETF to reject draft-housley-tls-authz-extns until such time as these
issues can be resolved.
Sincerely,
Jim Smilanich
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf