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

[<[e-mail]>]

Simon Josefsson wrote:

> > My reading of RedPhone's IPR disclosure 1026 is that they claim to
> > have a patent application about a larger system that includes
> > tls-authz as one part, and uses it in particular way. If you want to
> > build a system matching the numbered list 1..4 in the disclosure
> > (RedPhone's description of what they claim is covered), then you
> > would have to consider this IPR disclosure.
>
> A license is required for each of the cases 1, 2, 3, and 4
> individually.

Well -- if the patent is granted, a license may be required if you
do any of the things listed in the granted patent's claims.  The items
1..4 may or may not be an accurate summary of the claims in the
application, and what's granted may be different from the application.

> As far as I read item 3, it seems to cover many kind of realistic
> use of this protocol.  As soon as you have some authorization data,
> you would typically compare the sender of the authorization to some
> set of valid issuers.
>
> > However, I think there are many more good uses for tls-authz that
> > do *not* match items 1..4.
>
> That would change things.  Can you describe a practical way to use
> tls-authz that wouldn't be covered by, for example, item 3?  I tried
> to understand one unencumbered use-case of tls-authz earlier:
> <http://thread.gmane.org/gmane.ietf.general/33561>.  To my reading,
> the example seems encumbered.  If you can explain an unencumbered
> use-case that would help.

I have not read the actual patent application (and I'm not planning
to), and as I noted above, I do not know how accurate the four-item
summary is.  Without reading the application itself, saying "here's a
use case that is not covered by the claims" would be rather unwise.

However, draft-ietf-tls-attr-cert-01 (from 1998, predating this
application by many years) describes a use case where the client
presents an AC containing a role or security clearance to the server,
and the server uses this to determine whether the client is allowed to
access the requested resource.

It's of course possible that the patent applications's claims cover
this use case, too -- but personally, I would not be extremely worried
about getting sued by RedPhone if this was the use case I'd be doing.

(Note that draft-ietf-tls-attr-cert-01 also has lot of other stuff
that is not in tls-authz; e.g. about acquiring/issuing ACs, and hints
about what ACs the client should consider presenting. But there's some
overlap as well.)

> > Just because someone has filed a patent application on some rather
> > obscure combination of B+C+D should not prevent others from using
> > the protocol for things not covered by that application. Thus, I
> > support publishing this as an RFC (either Informational or
> > Standards Track).
>
> Obviously part of our disagreement seems to be what is "obscure".
>
> Would you still support publication if the patent application covers
> broader ways to use the protocol?

I agree that this is a relevant question; if the application would
claim to cover most of the interesting use cases (and only some
obscure cases would be unencumbered), that could change my opinion.

Best regards,
Pasi