Dear all:
Two observations on the IPR analysis found below inline. Some text is
highlighted to support my observations.
Eric Rescorla wrote:
SUMMARY
I do not believe this document should be advanced to Proposed Standard
at this time. First, it is not clear that there is really sufficient
interest in this document to justify it being at the PS level. Second,
despite several revisions to the RedPhone IPR disclosure, the IPR
status of this document remains unclear. Finally, there are technical
issues that should be fixed before the document advances at all.
BACKGROUND
This document was originally brought to the TLS WG, which expressed
little interest in it. It was subsequently sponsored as an individual
submission by then SEC AD Sam Hartman and approved by the IESG.
Subsequent to IESG approval, one of the authors (Brown) filed an IPR
statement
(https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=765)
that claims to cover the technology. The listed terms were RAND but not
necessarily royalty-free. The IESG rescinded the approval of this
document and sent it back to last call. In the interim, two other IPR
statements have been filed, one by Stephen Farrell on work that he did
and a third party disclosure one by Eric Rescorla on some IBM
work. In the subsequent last call, there was not wide support
for the document and it was not approved. Recently, Brown revised
his IPR statement to assert that at least some usages of this
draft are not covered by the relevant patent application
(https://datatracker.ietf.org/ipr/1026/) and that encumbered
usages would be subject to RAND licensing, leading to this fourth
last call.
IPR ISSUES
IMHO the IPR situation is substantially less clear than it has
been made out to be. First, there is is not one but three
IPR disclosures, with the other two relating to Siemens and IBM. As
I stated in my previous review, I'm not too worried about the
IBM IPR, but the Siemens one is less available and it's harder
to evaluate, though the inventor, Steve Farrell says he thinks
it may not apply.
That still leaves the RedPhone IPR. As I indicated above,
the current IPR statement asserts that only some uses of this
document, not the document itself, are covered by the
relevant patent application:
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). This statement
applies only to the IETF Document draft-housley-tls-authz-extns-07.txt
(hereafter the "Protocol Document").
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.
I have two concerns here. First, it is not clear to me that the
four listed ways don't actually implicate a significant fraction
^^^^^^^^^^^^^^^^
of the space. In particular, one very natural use of authorization
data is in coordination with legal agreements. However, this is
specifically two of the four listed covered uses:
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.
So, in practice, many useful applications of this document are in
fact encumbered.
You seem to assume that patent rights are created by the IPR disclosure,
while they are created by the *patent* (in this case still at the
application stage) that you didn't study.
More troubling, however, is potential encumbrances outside of these
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
four uses. The assertion by RedPhone is just that, an assertion. It
is not a license grant. If I implement the protocol described in this
document, I would still be vulnerable to an infringement suit by
RedPhone even if I did not use it in any of the four listed
ways. RedPhone would simply have to assert that upon reexamining the
patent it had concluded that the scope was more general than they had
previously sought. All RedPhone's assertion buys me is a defense
against willful infringement. To sharpen this point, consider the case
where RedPhone sold the patent to some other entity which then decided
to file suit. This is not a purely theoretical worry. While I have
not studied the patent, a number of the claims seem rather broader
than what is described above and quite possibly cover all uses of the
protocol described in this document.
This would apply to any IETF IPR disclosure, and it essentially says
that no matter what the inventor-entrepreneur discloses, hypothetical
developments from loosely related precedents, or even mere imagination,
will ever put the IPR submitter in the devil's role. OK, you seem to
have better faith in big corporations - I don't know why.
Basically, you state that an IETF IPR disclosure can hardly be
deterministic enough for those ideologically opposed to patents. This
statement detracts the whole IETF process.
Aren't you committed to the advance of the IETF? If so, the IPR
disclosure mechanism is a bait-and-trap mechanism: an
inventor-entrepreneur is told "Please disclose in good faith," and then
he is forever presumed to act in bad faith.
TECHNICAL ISSUES
S 3.3.
As Simon Josefsson notes, the length of the SAMLAssertion
should allow up to 2^24 or 2^32 bytes. As far as I know,
the only objection to this is backward compatibility.
S 3.3.1
I'm quite concerned about the use of entityName field to bind an AC to
a certificate. In the absence of Internet-wide name subordination,
there may be many certificates with the same DN issued by different
CAs. As the issuer of an AC, I generally want to authorize specific
entities, not "anyone who has a DN that chains to one of the 150
roots in your browser". I would remove this option entirely.
S 3.3.
This URLandHash production has a nasty futureproofing bug, because the
length isn't self-contained. If the server uses a hash the consumer
doesn't recognize, the consumer can't even parse the rest of the
extension, even if it contains other AuthorizationDataEntry objects
which the client could otherwise parse and which would in and
of themselves be sufficient. The URLandHash production should
either have a length or have the hash be a variable length value,
e.g., opaque hash<0..255>. This would allow parsing even if you
don't know the hash.
S 3.3.3
This circular reference issue seems bogus to me. There are
lots of places where it's not going to be relevant, and
SHOULD is overstrong.
S 4.
This document should use the RFC 5246 hash registry (and its
contents), not define its own. Note that the values in that
registry differ from those in this draft.
EDITORIAL ISSUES
S 2.
The beginning of this section needs to be clearly marked as
non-normative, since it's just a recap of 4366.
S 3.
"can be exchanges" -> "can be exchanged"
-Ekr
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada H2M 2A1
Tel.: (514)385-5691
Fax: (514)385-5900
web site: http://www.connotech.com
e-mail: thierry.moreau@xxxxxxxxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf