On 17/11/10 4:50 AM, Paul Hoffman wrote: > Marsh: could you be more specific on which patents you think apply > to normal use of ECDSA and ECDH? Or were you just saying "because > some company says they have patents, I believe them"? For extra > credit, please read draft-mcgrew-fundamental-ecc-03.txt and suggest > where it might be wrong.
When searching for the above .txt with filetype:pdf the first hit in Google: http://www.ietf.org/ietf-ftp/IPR/certicom-ipr-draft-mcgrew-fundamental-ecc-03.pdf Wherein: I. Patent Holder/Applicant (“Patent Holder”): Certicom Corp. ... IV. IETF Document or Other Contribution to Which this IPR Disclosure Relates: draft‐mcgrew‐fundamental‐ecc‐03 V. Disclosure of Patent Information (i.e., patents or patent applications required to be disclosed by section 6 of RFC3979) A. US6704870, granted on March 9, 2004 (Yes, published) B. US7215773, granted on May 8, 2007 (Yes, published) VI. Licensing Declaration: Patent Holder is currently aware of the information disclosed in V., supra, which may relate to one or more implementations of IV., supra, which may become incorporated in an IETF RFC. To the extent that Patent Holder’s existing intellectual property rights under V., supra, may cover an implementation of a product compliant with the reference in IV., supra, Patent Holder informs that it and its Affiliates will make a license available on fair, reasonable and non‐discriminatory ("FRAND") terms and conditions based on reciprocity to all persons desiring to implement the aforesaid IETF RFC under such patent rights (e.g., make, use, sell, import, distribute, copy, etc.) the Patent Holder owns, solely to the extent such technology is essential to comply with the IETF RFC. ... -- The point being that Certicom is asserting they have two patents that read on the draft "which may relate to one or more implementations of IV., supra, which may become incorporated in an IETF RFC". The first patent is for digital signatures on a smart card. The second is for a key validation scheme. FRAND is incompatible with a good portion of open source licenses, all of them as a principle by the Open Source Initiative: http://www.opensource.org/osr-rationale Open Standards Requirements for Software - Rationale, Draft 5; 2006-09-19 The Purpose of Open Standards The purpose of an open standard is to increase the market for a technology by enabling potential consumers or suppliers of that technology to invest in it without having to either pay monopoly rent or fear litigation on trade secret, copyright, patent, or trademark causes of action. No standard can properly be described as "open" except to the extent it achieves these goals. You cannot for instance distribute software under the GPL that requires payment or rent by a downstream recipient. The GPL doesn't support the restriction of field of use by the recipient which lets out "terms and conditions based on reciprocity to all persons desiring to implement the aforesaid IETF RFC under such patent rights" as a restriction were someone to pony up blanket license fees. One would think it possible to avoid the patents. You could contemplate needing a lawyer to implement an 'open standard'. (This is the "or fear litigation" on "patent" "causes of action"). One way out or the morass would be to have a reference implementation known not to infringe. An explanation of the bounds of the patents against the implementation would be helpful for those seeking to modify performance or deny say power analysis attacks (should such be possible). _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
