Subject: draft-housley-tls-authz-extns-07.txt to Proposed Standard

From: Ralf Weber <[email-masked]>
Date: Wed, 11 Feb 2009 09:17:03 +0100

Moin!

I haven't been aware of this draft before the FSF encouraged some  
people to send there opinion into the IETF mailing list. This isn't my  
first post to an IETF mailinglist and I am subscribed to this and  
other lists on the IETF, so I do think I qualify as IETF participant.  
I did spend some time reading the draft, the IPR disclosure and before  
stating an opinion it would be nice if the people that have dealt with  
it longer could tell me if what I got out of it is correct so far.

1. RedPhone Security applied for some patents that we are talking  
about here in 2005
2. RedPhone Security then authored/co-authored a draft in 2006
3. This could no be successfully processed within the TLS WG
4. The draft was then submitted as individual submission
5. The IESG did not approve the document because of an IPR disclosure  
that has been removed as of now
6. After two years the authors try to again standardize the same draft  
that was declined two years ago with a new IPR disclosure
7. While the IPR may not be relevant to the draft (IANAL) I do not see  
how an useful implementation could work around it:
	- The draft is about extending TLS to authorize before the secure  
connection is established
	- Authorizations are usually done by exchanging and comparing secrets/ 
certificates
	- This is exactly what points 3 and 4 of the IPR disclosure describe

If all of the above is mostly correct I would say that the fact that  
there is no royalty free license available for implementors and there  
are a lot of TLS implementations available under FOSS licenses, which  
could not implement this without violating RedPhone's IPR would lead  
me to the conclusion that I have to oppose this draft.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/
Data | Voice | Managed Services

Schütze Deine Umwelt | Erst denken, dann drucken

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland  
* Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *

Geschäftsführer: Dr. Jürgen Hernichel (Vors.), Rita Thies *  
Amtsgericht Frankfurt/Main HRB 46123 * USt.-IdNr. DE 197 498 400

---

From: Ralf Weber <[email-masked]>
Date: Wed, 11 Feb 2009 16:14:16 +0100

Moin!

On 11.02.2009, at 14:16, Theodore Tso wrote:
> No, actually.  Point 3 is very tightly constrained to certain types of
> Agreements, where Agreements is defined in point 2.  Point 4 is about
> countersigning authorizations, presumably with the intention of
> forwawrding them to a 3rd party.  There is plenty of prior art for
> point 4 all by itself (Kerberos V5, for one, and it was certainly not
> the first system to do that).
So your statement is that the patent claim is invalid, because of  
prior art? If so we are not 100% sure unless someone questions the  
patent claim in court - Volunteers ;-).

> There are plenty of ways in which authorization data could be passed
> via TLS that would clearly not violate RedPhone Security's claimed
> patent claims.  There is over 30 years of prior art involving
> cryptographically sealed authorization data that could be passed via
> this protocol extension.
I think the difference is that the authorization is exchanged as part  
of the setup rather then over the established channel, but as Sam  
Hartmann pointed out there may be other use cases for these protocol  
extensions so I think the best way to advance with the document would  
be to run it again in the TLS working group.

So long
-Ralf
---
Ralf Weber

---

From: [email-masked]
Date: Wed, 11 Feb 2009 11:09:30 -0800 (PST)

> ...

> 	- This is exactly what points 3 and 4 of the IPR disclosure describe

I completely disagree with this assessment. The points you mention are quite
specifically talking about Agreements, not certificates. Agreements are defined
in point 2:

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

Let me be the first to state that placing a definition of a key term in the
middle of an item list and then referencing in subsequent items, as opposed to
usual approach of having a separate section defining terms, is a pretty poor
way to write this up, but even so I think the meaning is quite clear. What's
being reserved here is a fairly specific set of use cases where this mechanism
is used to muck around with a stored set of agreements (per the above
definition).

The real question is whether or not having to pay to use this technology in
this particular set of use cases is too onerous or not. I can envision several
uses for this extension, mostly revolving around the server sending back
information about what the client is or isn't authorized to do and the client
adjusting the options it makes available accordingly, and none of them involve
operations of any sort on stored agreements. But others with other intended
uses for this stuff may see it differently, (And of course anyone who actually
uses this extension for something would be wise to consult with an actual
lawyer. That's also a nonnegligable burden that needs to be taken into
account.)

(I guess this means I agree with Brian's assessment of this and disagree with
Eric and Simon.)

I will also point out that patents on specific use cases of various IETF
protocols are quite common. At a minimum I am aware of similar patents on use
cases in SMTP, IMAP, HTTP, and LDAP. (I recently did an expert witness gig in a
case involving patent claims on both SMTP and HTTP, as a matter of fact.) If we
decide the existance of such patents preclude standardization we're going to
find ourselves with nothing to do in fairly short order.

> If all of the above is mostly correct

IMO it is not. In particular, I think you have confused "agreement" with
"certificate" and that they are not at all the same thing.

> I would say that the fact that

This also appears to be incorrect - even to others who opposed approval of this
document. Even given the broadest possible interpretation of the terms of this
agreement, it's still about use, not implementation of the basic mechanism. The
statement of this could not be clearer:

    No License Required for Implementers.

Of course if your implementation is targetted at the use cases RedPhone is
pursuing and you proceed to distribute it for that purpose, you're likely to
get into trouble.

				Ned

P.S. I've read the IPR dlsclosure and the patents claims, but what would
be useful to see is the document shepard writeup. Are those available somewhere
online?  If they are I don't know where to find them and I was unable
to coerce The Google into dilvulging their location.

---

From: Aaron Williamson <[email-masked]>
Date: Wed, 11 Feb 2009 15:43:47 -0500

[email-masked] wrote:
> specifically talking about Agreements, not certificates.

Yes, this is obviously right, "Agreements" are not certificates.  But I don't
think it's clear that storing Agreements covers only "a fairly specific set of
use cases."  Since Agreements include contracts and negotiable instruments, it
seems that it could encompass most uses in e-commerce: for example an online
store that requires buyers to use authorizations when making a purchase, and
then stores the transaction details along with the authorization data.

Sales transactions are a central use case for TLS, are they not?  If online
sales using the authz extensions are not within the scope of term 3, I don't
think it is at all clear from the IPR Statement, and the onus should be on
RedPhone to clarify this.  If they are, I think RedPhone's restrictions can
hardly be said to apply only to corner cases.

Aaron

---

From: [email-masked]
Date: Wed, 11 Feb 2009 13:20:45 -0800 (PST)

> use cases."

Well, perhaps "specific set of use cases" was a bit strong, but OTOH I think
there are quite a few legitimate use cases that are pretty clearly allowed
under this license, such as the one Russ provided involving military
clearances.

The question is whether or not the allowed use cases are sufficient to warrant
standardization. This is why I thought it would be interesting to see the
writeup - it might include statements of planned implementations and uses.

> Since Agreements include contracts and negotiable instruments, it

> Sales transactions are a central use case for TLS, are they not?

For basic TLS, sure, it's a major use, if not the major use. For exchanging
additional authorization information, it's a lot less obvious. Again, the
applications I can envision wanting this extension for have nothing to do with
such agreements and nothing to do with e-commerce.

That said, I will also point point that from my perspective at least the real
issue I have with using this extension has more to do with how TLS is
implemented in real world applcations. This extension has to be implemented in
existing TLS libraries in order to be usable - if that's not going to happen
then the extension is useless to me. (Another reason the writeup might be
interesting to see.)

And even if this does get implemented there are still issues. I have a lot more
experience with nss than openssl, so maybe this doesn't apply to openssl, but
in complex server-side environemnts gettting at and using extension stuff in
nss is not exactly trivial. So given a choice between doing this exchange as
part of the application versus using this extension, the extension needs to
present some pretty compelling added value to be the preferred choice.

> If online

I was quite careful not to make any such claim.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Feb 2009 10:50:13 +1300

On 2009-02-12 08:09, [email-masked] wrote:
...
> to coerce The Google into dilvulging their location.

For current drafts you should be able to find them via the I-D tracker
history. As far as I can see, this is not the case for this draft. It
was first reviewed by the IESG in May/June 2006, and I think that we
weren't yet putting shepherd writeups in the tracker then. In fact,
there probably wasn't a formal shepherd at that time, for any individual
submission. RFC4858 was not yet out. And of course all that was before
the first IPR disclosure.

    Brian

P.S. It's quite amusing that the tracker (in its public version)
still shows the IESG ballot as it stood in June 2006.

---

From: David Morris <[email-masked]>
Date: Wed, 11 Feb 2009 15:14:40 -0800 (PST)

> think it's clear that storing Agreements covers only "a fairly specific set of

Hmmmm, my interpretation would be that a certificate is in fact 
documentation of an agreement between the CA and the owner/user of the 
cert. I see no distinction between 'agreements' and 'certificates' in this 
context.

David Morris

---

From: [email-masked]
Date: Wed, 11 Feb 2009 15:18:55 -0800 (PST)

> cert. I see no distinction between 'agreements' and 'certificates' in this

Again, the term "agreement" in this context has a specific meaning given in
item 2. IMO certs do not fit this definition. They're not even close.

				Ned