Re: Last Call Comments on draft-housley-tls-authz-07

[Stephen Farrell <[e-mail]>]

Hi Eric,

My take fwiw:

I personally don't believe that the slightly-inventive bit of
the stuff I sent to the patent lawyer should cover this I-D - at
the time, (and I've no records to help, sorry), we weren't blessed
with open source browsers and so we had to use proxies to insert
our authorization logic - so there were no ACs/PACs or any other
authorization tokens in the TLS handshake at all (I think we
basically did a MITM on the browser).

In my mind the nub of the issue is that the proxy had to pre-empt
the normal https flow in order to do authorization (and, more
tellingly at the time, strong crypto which is actually what we
were interested in providing). But IANAL and all that of course.

More to the point, I really have no clue whether or not the
German language claims might or might not cover the I-D in
question. To the extent I can help, I'd be happy to work
with someone who can parse German legalise to try get a
better handle on that.

I do recall being careful that draft-ietf-tls-attr-cert
didn't impinge on what I thought at the time might be
encumbered. But I've nothing good to cite to back that up
I'm afraid and the subsidiary that I worked for then no
longer exists. Sorry again, but it was a decade ago.

I think your conclusion about processing this in the TLS WG
is the right one, and I'm happy to do whatever I can to help
there or wherever.

Regards,
Stephen.


Eric Rescorla wrote:
> $Id: draft-housley-tls-authz-extns-07-rev.txt,v 1.1 2007/03/09 18:52:17 ekr Exp $
> 
> BACKGROUND
> This document specifies a generic mechanism for including additional
> non-TLS authentication data (e.g., attribute certificates). This
> data isn't necessary to complete the handshake cryptographically
> but might be of use to some higher-level application. This document
> was not a product of the TLS WG but was reviewed by at least some
> members of the WG. This document was 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 are 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. All disclosures can be found at:
> 
> https://datatracker.ietf.org/public/ipr_search.cgi?option=document_search&document_search=draft-housley-tls-authz-extns
> 
> 
> DISCUSSION
> I have reviewed the Brown and IBM patent applications. It is not clear
> to me that the Brown application covers this draft.  I have trouble
> seeing how the seeing how the claims are on-point at all. In my non-lawyer
> opinion the IBM application clearly covers this draft, but every
> important claim is preceded by the prior art of draft-ietf-tls-attr-cert
> (http://tools.ietf.org/html/draft-ietf-tls-attr-cert-01). So, I'm not
> over-worried about this IPR either.
> 
> I have not yet reviewed the IPR cited by Mr. Farrell, and
> his comments suggest that this may be fruitless:
> 
>    I was an inventor. The Siemens subsidiary involved no longer
>    exists. I don't know where the ownership ended up. The filing is
>    extremely unclear, even for a patent - the reason is that the
>    lawyer translated my input to German, filed that and later
>    translated back to English, all without checking back with any of
>    the inventors. The German version may be more easily understood, I
>    don't know. The original filing was to protect a product that sent
>    SESAME PACs (inside GSS tokens) to & fro in order to do access
>    control for web clients & servers. The I-D isn't doing that, but
>    the claims might be written broadly enough to be a concern.
> 
> However, since Mr. Farrell was also the author of draft-ietf-tls-attr-cert
> it's not at all implausible that it would be covered by this work.
> 
> I'm fairly conflicted here. On the one hand, I believe there is some
> interest in being able to carry SAML assertions and X.509 attr certs
> in TLS handshakes. While it appears that Mr. Brown failed to disclose
> his relevant IPR, it's not clear to me that this has any practical
> effect since I don't see how this IPR affects one's ability to
> implement this standard.  On the gripping hand, I *am* worried about
> the IPR cited by Mr. Farrell and I have not yet had a chance to
> analyze it.
> 
> My TLS co-chair suggests that this document should go forward as
> Experimental. I see two problems with that. First: it assigns code
> points out of a space which is reserved for Standards Action. Second,
> the only reason for this document to proceed at all at this point
> (given the IPR issue) is the claim that there are applications which
> actually would make use of this extension.
> 
> Given all this, plus the fact that this is squarely a TLS-relevant
> document, and the IETF norm that it is best when WGs assess the level
> of IPR involvement and balance that against the important of the work,
> I think it would be best if this work were brought to the TLS WG,
> which could decide whether to make it a WG item, in which case the
> decisions about IPR could be made in the WG.  If it clears that bar,
> then we can have some level of confidence that the IPR issues were
> judged. If it can't meet that bar, then it probably should not be
> published at all.
> 
> 
> -Ekr
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf