Subject: Review of draft-ietf-tls-authz-extns-07

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Feb 2009 21:36:51 -0800

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.

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.

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

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 11 Feb 2009 09:53:42 -0500

Dear all:

Two observations on the IPR analysis found below inline. Some text is 
highlighted to support my observations.

> four listed ways don't actually implicate a significant fraction
   ^^^^^^^^^^^^^^^^
> So, in practice, many useful applications of this document are in

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
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> 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: [email-masked]

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Feb 2009 09:50:10 -0500

Excerpts from Thierry Moreau on Wed, Feb 11, 2009 09:53:42AM -0500:
> 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.

Actually intellectual property rights are never firm until tested in
the courts, and even after that they may change.

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 11 Feb 2009 10:21:56 -0500

> the courts, and even after that they may change.

Obviously. However a big step towards determinism is achieved when 
someone actually reads the patent application versus *not reading*.

My point is that IETF participants doing their assessment of the pros 
and cons should at least be aware that the reference citation in the 
IETF IPR disclosue entry (e.g. US patent application 11/234,404 in the 
present instance) is highly relevant. Protocol engineering is improved 
when relevant facts are taken into consideration.

- Thierry Moreau

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 11 Feb 2009 16:23:13 +0100

Thierry Moreau <[email-masked]> writes:

> disclosure, while they are created by the *patent* (in this case still
> at the application stage) that you didn't study.

I've seen you claim this a few times, and I wish to attempt to refute
the argument.

What we are evaluating here is how the patent status around the
technology affects deployment and smooth operations of the Internet.
While the claims in a patent (application) is relevant, it is not the
only thing that is relevant.

There are many patents out there that, if enforced, would make it
impossible to implement core Internet protocols.  I'm told the TLS
protocol itself is covered by several patents, for example.  We don't
care as much about those patents because nobody appears to enforce them.
That proves that the claims made in patents aren't the only thing we
must look at.

The actions taken by the patent filer, and the licensing conditions
demanded by the patent filer is usually more interesting.

There are organizations that use patents as a threat to sue other
organizations.  In these cases, the patent is not as important as the
legal threat.  It is possible to threaten to sue even if the patent is
irrelevant to the case at hand, for anyone sufficiently familiar with
the technology.  That doesn't change the legal risk.

When evaluating whether to implement a particular technology, you need
to evaluate all the risks.  The text of patent (applications) helps in
the evaluation.  My point is that the actions of patent holders is
significantly more relevant.

/Simon

---

From: Thierry Moreau <[email-masked]>
Date: Wed, 11 Feb 2009 11:06:52 -0500

> significantly more relevant.

Dear Simon:

Interesting, and completely new to me.

Do you have any guidelines / methodology / evaluation criteria / sources 
of precedents or any other "sources of law"? According to those, one 
could turn emprircal-observations-of-patent-holder-actions into a) an 
evaluation whether to implement and/or b) an evaluation whether to adopt 
as an IETF document (standards track / informational / experimental).

Perhaps there is some form of non written IPR etiquette.

Perhaps you have an intuitive talent at this type of analysis and you 
are the Oracle in the present instance, i.e. you made the evaluation and 
then the FSF started its campaign.

May I invite you politely to bring some form of rationality to this. I 
am confident that you have such potential.

In the meantime, I stubbornly stick to my reading of the IPR disclosure 
1026 section 3 along with the US patent application 11/234,404 
independent claims as amended on 2008/01/25. I hereby acknowledge that 
this action may be detrimental to future evaluations of my actions with 
respect to the IPR etiquette as you may have intuitive knowledge.

Regards,

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900

---

From: Aaron Williamson <[email-masked]>
Date: Wed, 11 Feb 2009 12:21:59 -0500

Thierry,

> as an IETF document (standards track / informational / experimental).

If I read you correctly, you deride Simon because he considers this draft to
carry patent risks but does not absolutely quantify those risks.  But Simon is
right that evaluating a patent is not an engineering exercise -- even if you are
an expert in the relevant technology (as he is) and in the relevant law (as you
are not), it is often impossible to determine whether a particular patent will
be granted, and then whether it will be enforced against you by the patent
holder, and then whether it will be upheld by a court.

That Simon's reached one conclusion rather than another in this instance based
in part on guesswork can hardly be blamed on his imprecision.  Whether the
patent eventually issues and includes the claims as stated in the application
depends upon the quality of the examination by the patent office (it is widely
recognized that the PTO is overworked and cannot devote sufficient time to each
application).  Whether the patent-holder will target a particular implementation
depends upon the advice it's received from counsel and its own assessment of the
risks and rewards.  Whether the software developer (or user) can effectively
parry even a very weak claim depends upon the resources of the developer (which
in the case of free and open source software developers are often quite limited,
as you might imagine).  As Simon said, in any one or all three of these steps,
the language of the patent claims themselves might be irrelevant.

You are rightly concerned with how IETF can possibly make a decision one way or
the other on a given disclosure when the question is so slippery.  In short, an
implementor can only have absolute certainty if he has an unequivocal license
from the patent holder for himself and his users to make, use, and practice the
claims.  Any qualification of the license adds uncertainty, and the
qualifications in RedPhone's statement create a good deal of uncertainty indeed.
 For example, it is difficult to imagine (though I am not myself an expert on
TLS authorizations) an implementation of the proposed standard that would not
"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."

I understand that absolute certainty is not the aim of IETF.  But I also believe
that a significant proportion of the IETF constituency is concerned with
enabling the development of free and open source software implementing IETF
standards.  Where, as I believe is the case here, an IPR disclosure from one of
the drafters of the document offers insufficient certainty that such
implementations are possible, the IETF should certainly take notice.

Best regards,

Aaron Williamson
ISOC-NY

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 12 Feb 2009 12:25:03 +0100

Thierry Moreau <[email-masked]> writes:

> Do you have any guidelines / methodology / evaluation criteria /
> sources of precedents or any other "sources of law"? According to
> those, one could turn emprircal-observations-of-patent-holder-actions
> into a) an evaluation whether to implement and/or b) an evaluation
> whether to adopt as an IETF document (standards track / informational
> / experimental).
>

See RFC 3669, it contains good discussion and interesting examples.

The evaluation done in the examples of RFC 3669 does not generally seem
to be of what's in the actual patent text.  Instead people have
evaluated the actions taken (or not taken) by patent holders.  This
re-inforces my point.

> are the Oracle in the present instance, i.e. you made the evaluation
> and then the FSF started its campaign.

Heh.  I have been careful to avoid reading any patent text or make any
judgement of the patent disclaimer and licensing conditions.  That is
not my field of expertise.  I do not have any influence over what the
FSF does or decides here.

One person can't reliable make a decision like this, it needs to be
discussed by the community and people can provide their thoughts on the
topic.  Eventually, after hearing what people have said, everyone can
form their own opinion of the situation.  This is what I've done, and I
have also made my opinion publicly known in this discussion.

That doesn't mean I cannot be convinced otherwise.  There are two things
I believe are critical in this discussion:

  1) how widely the patent filer believes their patent applies, and

  2) the licensing conditions offered by the patent filer.

Item 2) has apparently been evaluated by the FSF and they found that the
conditions doesn't allow wide use of implementations.  Reading the
patent disclaimer myself, I don't see anything that invalidates this
evaluation, and I see things that re-inforce the evaluation.  The FSF
has access to legal aid and has a track record in working in this area.
Some engineers, like Pasi and Sam seems to believe the opposite.
However, the FSF takes the legal risk if I re-add the tls-authz
implementation to GnuTLS.  So to me the FSFs evaluation carry more
weight.

Item 1) is, alas, difficult to judge without the vulcan mind melt, but
it is warranted to be conservative.  The licensing conditions demanded
for certain uses also gives some indication of the scope of the
perceived applicability.

As far as I can tell, the simplest approach to resolve the problem would
be to offer the technology for free use to anyone without limitation.
This solves item 2) and makes the more difficult to judge item 1)
irrelevant.

/Simon

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 12 Feb 2009 08:37:17 -0500

Simon,

Thanks for these clarifications. They explain how you, and how 
"apparently" the FSF came to the conclusion about the current Redphone 
IPR situation.

(No need to repeat my opposite views already on the record.)

- Thierry