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@xxxxxxxx > 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@xxxxxxxxxxxxx My Phone: 214-244-4827 _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf