Jean-Marc Desperrier wrote:
Tom Wu via RT wrote:
This patch adds full RFC 5054 support in OpenSSL 1.0.1 and 1.1.0,
and has been updated to apply cleanly to the 20101229 dev snapshot.
This version of the patch supercedes the earlier patches submitted
under this ticket. Please let me know what the next steps are for
the integration of this patch into OpenSSL 1.0.1 and 1.1.0.
Tom, where is there a reference clearly explaining *why* they are no
more patent concern on SRP ? (for example the Phoenix Technologies Ltd.
one https://datatracker.ietf.org/ipr/63 ).
After some researches :
Stanford U. owns US patent 6,539,479 on SRP and makes it available free
of any fee and of any restriction on usage.
Patent 6,539,479 references patent US 5241599 and US 5440635, held by
Lucent [EKE patents]. However the text, including the prior art
description, doesn't clearly describe what the relation with those two
EKE patents is, and so in my opinion doesn't clearly state if
implementing it requires to use elements of US 5241599 and US 5440635
(and so require a licence on those two patents) or not.
I'm tempted to think that if US 5241599 and US 5440635 were actually
required for an implementation it would be described, but without
further info, the situation still sounds somewhat uncertain to me.
Patent 6,539,479 does not seem to reference the claims of patent
6,226,383 by Phoenix [SPEKE patent] that was not yet delivered when the
patent application for patent 6,539 was submitted.
In my understanding, this should mean an implementation of patent
6,539,479 doesn't infringe on patent 6,226,383, because :
- two patents can't be delivered on the same thing (except when the
patent office makes a big mistake), it's the duty of the patent office
to check concurrent applications to avoid that
- so the existing art research done by the examiner should have digged
up this existing application, even if still under examination. If it
were truly relevant I'd really expect it to be at least be referenced by
the patent.
But my researches also show that concerns about the IPR status are
indeed the origin of RFC 5054 (TLS/SRP) being informational instead of
standard track. I didn't search every message on the TLS group, so I'm
unable to say if those concerns were later recused but that for some
reason the TLS group was still unwilling to go with standard track.
Trivia :
- On Dec. 16, 1996, Tom Wu posted a message to the sci.crypt newsgroup
named "Remote Authentication Protocol With Diffie-Hellman"
- On March 25, 1997 Jablon, David P. filed a patent application, leading
to the delivery of patent 6,226,383 (SPEKE/Phoenix patent) that includes
a reference to this newsgroup message (so acknowledges it as prior art)
- On July 15, 1997, Tom Wu filed a provisional patent application,
leading to the delivery of patent 6,539,479 "System and method for
securely logging onto a remotely located computer"
This helps explain that patents 6,539,479 and 6,226,383 can be very
close to each other, without 6,226,383 being relevant for 6,539,479
because the shared elements were already public at the time the
application for 6,226,383 was made.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
