Nic and all,
What is suggested here is not a reasonable solution or rational
suggestion. I use ECC and was an early supporter of ECC. Our
ECC product exceeds the current IETF standards track. We will
continue to use ECC and improve on our ECC product as we see
fit. The IPR, like FISMA, is misguided as thankfully the recent GAO
report clearly pointed out.
Nicolas Williams wrote:
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
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls
Regards,
Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
Abraham Lincoln
"YES WE CAN!" Barack ( Berry ) Obama
"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt
"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng. INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
jwkckid1(_at_)ix(_dot_)netcom(_dot_)com
My Phone: 214-244-4827
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf