On 9/1/15 14:49 , Watson Ladd wrote:
I do not know. It is not my field of expertise, and I'm not employed by a commercial vendor to really care.On Tue, Sep 1, 2015 at 2:02 PM, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:On 9/1/15, 13:54 , "TLS on behalf of Dave Garrett" <tls-boun...@ietf.org on behalf of davemgarr...@gmail.com> wrote:On Tuesday, September 01, 2015 01:24:05 pm Jeffrey Walton wrote:They, however, obviously do have the choice of switching from DSA to ECDSA, so that argument doesn't make much sense here.I suppose that depends on how threatened you feel by Certicom’s claimed patents on EC.If the US Federal government actually got sued over ECC patents, I would hope they'd just abolish them and move on.I don’t think it’s as simple as that. US government licensed some of the ECC technology from Certicom. But I’ve heard Certicom claim that the licensing terms are so narrow that only direct national security applications qualify for that license.Did Certicom ever have patents applying to the use of ECDHE in TLS? It's not clear that they did: certainly RFC 6090 goes so far as to claim that there are patent-free implementation methods based on pre-1985 sources.
So I have neither skills nor incentives (nor time!) to research patents issued for ECC to figure how they could impact my work, because in general they cannot.
But I'm conscious of other people for who it could be important.
This isn’t something where vendors (and their lawyers) can rely on “would hope”.This is all a side-discussion, here, though. The US government's requirements are not our concern here. Dropping DSA in TLS leaves two perfectly fine options available to them, RSA & ECDSA, plus a new one yet to be added by the CFRG. They have to eventually keep up with things just like everyone else. If they want to be sloppy and keep DSA around, it's not like they couldn't just ignore that part of the eventual TLS 1.3 RFC within their own ecosystem. Everyone else, however, will be fine with the rest.The problem is that standardization of an algorithm or a technology by IETF or IRTF is completely unrelated to the patent/licensing status of that algorithm or technology. So unless Certicom comes forward and explicitly releases its IPR, most of the vendors would consider the patended and therefore toxic. I know I would. And forcing those vendors to spend money on licensing isn’t going to work (recall RSA). This would be a strong reason to hold on to DSA until the ECC patents expire. (Like it happened with RSA.)And what patents are you concerned about, and when were they issued?
See above.I am not tracking patents - have neither time, nor interest in doing that. But I'm not releasing commercial software. I think somebody made a list of the patents owned by Certicom, but I can't recall the details. That would be the first thing to look at, IMHO.
Since (AFAIK) nobody here is a patent lawyer (and even if there were :), any recommendation or opinion regarding those patents posted here isn't worth much. E.g. if you implement and sell ECDSA or EdDSA, and are sued by e.g. Certicom for not licensing it from them - who's going to pay your legal fees? Probably not the participants of this forum. :)
It boils down to Certicom (and other companies???) holding some IPR on (some?) ECC technology that commercial vendors must license from them, or risk lawsuits. The famed NSA deal doesn't seem to be wide enough to cover the industry because of that "national security applications" clause that is a subject to interpretation. And those companies (intentionally?) keep the scope of their patents vague...
At least this is how I understand the state of the field.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
