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 ).

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                       
Development Mailing List             
Automated List Manager                 

Reply via email to