Re: [TLS] Comments on draft-housley-tls-authz-extns-07

[Bodo Moeller <bmoeller at acm.org>]

On Wed, May 30, 2007 at 07:25:05PM -0400, Dean Anderson wrote:
> On Tue, 29 May 2007, Mark Brown wrote:

>> 2) If it's been published or in use prior to RPS's patent filing, then *any*
>> such method of verifying authorizations is "prior art", and can be used with
>> tls-authz under the GUL.  There are a lot of prior specs in this area...
>> And of course you're free to invent new verification methods, etc.  Only one
>> method is reserved by RPS under the GUL.

> This is true of any patent, but it is always expensive to litigate.  My
> view (as you already know) is that your patent is entirely covered by
> prior art, is not novel, and therefore should not be issued by the PTO.  
> The PTO issues many such patents, however, despite efforts to identify
> prior art and obvious claims.

Be sure to note the exact wording of what Mark (as a co-inventor) is
saying.

He does not allege that there is a lot of prior art that RedPhone
Security is not seeking patent protection for.  (In fact, the
published patent application does not cite any prior art.)  Rather,
he is saying that RedPhone Security is intending to allow the use of
prior-art methods *with tls-authz* *under the General Use License*.

That is, the implicit claim here is that the combination of these
prior-art methods with tls-authz *is*, or may be, patent-protected.
(From an advocatus diaboli point of view: The prior-art verification
method in itself may be patent-free, but the Internet-Draft has been
designed to meet the requirements of whatever is novel in the patent
claim.)

As of the patent application (20060174323, filed September 23, 2005),
the inventors were claiming

   1. A method comprising: receiving a request to interact with a
      network resource provided by a second entity via a computer
      network; receiving assurances via the network that a first
      entity has authorized an agent to send the request to the second
      entity on behalf of the first entity; and complying with the
      request subject to acceptance of the assurances. 

  25. A computer readable medium comprising computer readable
      instructions that cause a processor to: receive one or more
      agent instructions sent to a second entity from an agent via a
      computer network; receive assurances via the network that a
      first entity has authorized the agent to send the one or more
      agent instructions to the second entity on behalf of the first
      entity; and comply with the one or more agent instructions
      subject to acceptance of the assurances.

  29. A method comprising: sending a request to interact with a
      network resource to a second entity via a network; sending
      assurances to the second entity via the network that a first
      entity has authorized an agent to send the request to the second
      entity on behalf of the first entity; and receiving a response
      complying with the request subject to acceptance of the request
      and the assurances by the second entity.

  45. A computer readable medium comprising computer readable
      instructions that cause a processor to: send one or more agent
      instructions to a second entity from an agent via a network;
      send assurances to the second entity via the network that a
      first entity has authorized the agent to send the one or more
      agent instructions on behalf of the first entity; and receive a
      response complying with the one or more agent instructions
      subject to acceptance of the assurances by the second entity. 

  49. A system comprising: a local directory server that sends request
      from a second entity from an agent via a network and sends
      assurances to the second entity via the network that the first
      entity has authorized the agent to send the request on behalf of
      the first entity; and a remote directory server that receives
      the request and receives the assurances, wherein the remote
      directory server complies with the request subject to acceptance
      of the assurances. 

(These are the independent claims only -- of course there's a number
of more restrictive dependent claims.)

Any of this would be covered by the patent.  Those who agree to the
conditions of the GUL would be able to obtain a royalty-free patent
license from RedPhone Security allowing them to implement everything
except certain Protected Assurance System (PAS) functions (the license
immediately being revoked if they implement and release any of the PAS
functions without having obtained a PAS license).  The conditions
include granting reciprocal licenses, and avoiding any of the
following:

    Protected Assurance System (PAS) Functions

    1. To validate certificates, including, without limitation,
       Certificates or Attribute Certificates containing "critical"
       certificate policies using Object Identifiers within an arc
       registered to RedPhone Security
       (e.g. iso.org.dod.internet.private.enterprise.23106)

    2. To store Agreements and locate Agreements based on assurances
       received from a sender.  (Agreements are defined below in
       Schedule A)

    3. To compare the sender of assurances to a stored collection of
       Agreement signers.

    4. To sign ("countersign") assurances received from a sender via
       the Protocol after verifying that the sender¢s digital
       signature over those assurances is correct.

    https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833

Mark has carefully avoided explicitly discussing whether there is
prior art for claim 1.  Of course, he knows more about the current
fate of the patent application than we do -- and he has *not* implied
that claim 1 has been amended to make it more specific than the known
claim from the published application.  Possibly he has become aware of
prior art since filing the patent application, but it is entirely
possible that the patent will be granted with claim 1 as filed.


I wouldn't want to see such an IPR-laden protocol put on Standards
Track unless there are compelling reasons (and I don't see compelling
reasons to do so in this case).  The IPR holders are *not* saying that
uninfringing use will be possible with the patent that they intend to
obtain -- rather, they expect *anyone* implementing the specification
to obtain a license for it (which may be royalty-free, but imposes a
number of conditions in exchange).



[...]
> Another problem with the GUL is that you must agree to not implement PAS
> functions.  Why is this bad? Why the FUD to scare people into licensing
> quickly?  Here's why:
> 
> Even if you later stop using authz-extns (say because we design a
> non-patented alternative), this agreement may still be valid, and it may
> be difficult to get out of it---And then you won't be able to implement
> PAS functions (well, not without paying RPS or its successors).  So,
> executing the agreement may worse even than the patent.  So, it is
> probably better to stop using the patented protocol immediately, and pay
> cash damages _if_ RPS presses for reparation for the (short) unlicensed
> use.
> 
> What to do?
> 
> It can't be ignored that a patent may issue on the authz-extns draft.  
> Implementers who have already implemented authz-extns should remove the
> implementation from distribution immediately.  They now have notice of
> possible infringement. They should even remove old versions containing
> implmentations, and they should notify their users of the likely
> infringement and inform their users they should stop using the (likely)  
> patented code. You should look closely at the PAS functions and the
> license agreement and think about at least the next 21 years, and
> possibly forever, before you sign the agreement.
> 
> Don't forget to tell the IESG that you don't want this protocol
> standardized.


>> Since nobody knows precisely which RPS patent claims will issue,
>> executing a GUL may help to alleviate concerns right now.  The
>> RedPhone Security GUL amounts to a way to guarantee for yourself that
>> Sending any "prior art" SAML / AC assertions over TLS will be
>> royalty-free.  On the whole it's your choice to use the GUL or not.

> Using prior art to create an alternative to authz-extns ensures that no
> patents will issue that encumber the standard.  I favor a new draft,
> based entirely on prior art.

Agreed.



_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls