Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

[Erick O <[e-mail]>]

________________________________
From: Nicolas Williams <[e-mail]>
To: Dean Anderson <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Sent: Tuesday, July 21, 2009 12:50:28 PM
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

On Mon, Jul 20, 2009 at 04:54:36PM -0400, Dean Anderson wrote:
> Its possible to use any draft as toilet paper---a use that doesn't 
> infringe---but that doesn't mean the draft is free and unencumbered.

The IPR applies to ECC, so don't use ECC.  I don't see
draft-ietf-tls-extractor as explicitly encumbered, but as encumbered
when used with ECC, and in encumbered ways.  But see below.

> It is not the patents on these other standards that are the problem with
> TLS-extractor.  It is that using the methods described in the extractor
> draft further infringe patents owned by Certicom.  So we should either
> use other methods, or require that Certicom offer a suitable license.

Arguably any IPR claim on draft-ietf-tls-extractor based on ECC IPR is
wrong: if you infringe on the ECC IPR then use of
draft-ietf-tls-extractor does not make this infringement worse.

The interesting question is:

    Suppose you have an implementation of TLS that has a license to
    Certicom's ECC IPR, and suppose that you have an application that
    uses draft-ietf-tls-extractor, and the application does not have its
    own license to Certicom's ECC IPR -- is the application then
    infringing on Certicom's IPR??

IANAL and will not speculate as to what the answer to that is.  Each TLS
implementor should get their own legal advice on this question.

However if the answer is yes, then the TLS implementation must not
export the TLS extractor to applications when doing so would cause the
applications to infringe.  That might make the APIs obnoxious (apps
would have to indicate what IPR they've licensed, if any), but the
result would still be useable and useful.

IMO draft-ietf-tls-extractor should progress.  TLS implementors may want
to get legal advice as to whether draft-ietf-tls-extractor APIs puts
third-party applications at risk, and if so how they should communicate
this risk to third-parties.  Such a note might well belong in the RFC
itself.

Ideally Certicom would say that draft-ietf-tls-extractor does not put
applications at risk of infringment regardless of whether ECC cipher
suites [that could infringe on Certicom IPR] are in use.  But
draft-ietf-tls-extractor should proceed even without such a statement.

Nico
-- 
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls