Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with

["tom.petch" <cfinss@xxxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Martin Rex" <Martin.Rex@xxxxxxx>
To: "Dean Anderson" <dean@xxxxxxx>
Cc: <tls@xxxxxxxx>; <rms@xxxxxxx>; <iesg@xxxxxxxx>
Sent: Monday, June 30, 2008 7:01 PM
Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with


> Dean,
> 
> I really do not understand why you're making such a big fuzz.
> 
> Discussing IPR issues burns a whole lot of resources in a useless fashion.

Martin

I am thinking that perhaps you have grasped why Dean is making such a big fuzz.

Tom Petch

> The last time we debated IPR issues on this list was about TLS-SRP,
> and while discussing it, we did _ALSO_ talk about the certicom
> patent claims for ECC and their effect on the ECC ciphersuites.
> 
> For TLS, the standards-track ciphersuites are not affected by 
> Certicoms ECC patent claims.  So there is simply no necessity to
> _discuss_ alternatives in the informational RFC on the ECC ciphersuites.
> 
> The existence of these claims could have been indicated
> more prominently.  Maybe we're just to accustomed to patent claims
> (like the expired DH and RSA patents) for TLS that we only worry
> and focus on IPR issues for the standards track.  A lot of people
> are sick of beating the dead horse -- there are parties interested
> in implementing the technology, and we let them publish a spec
> as informational, on which they can base their interoperable
> implementations.
> 
> 
> See e.g. Peter Gutmann's message:
> 
> : From: pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)
> : To: pgut001@xxxxxxxxxxxxxxxxx, ynir@xxxxxxxxxxxxxx
> : Subject: Re: [TLS] Straw poll on TLS SRP status
> : In-Reply-To: <991F5FF9-FB79-4627-9DBD-7C3D1168F083@xxxxxxxxxxxxxx>
> : Message-Id: <E1HvUhu-0001XL-00@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> : Date: Tue, 05 Jun 2007 20:48:02 +1200
> :
> : [...]
> :
> : It's irrelevant what the software has built in, if no-one's using it
> : then it may as well not be there (that's just a paraphrasing of the
> : prime directive of security UI, "If the user doesn't understand your
> : feature, it doesn't exist").  Certicom issued their "royalty-free
> : license" for ECC in TLS last year some time, and I still haven't seen
> : any use of it by anyone outside the USG and its dependents as part of
> : the Suite B mandate.  Although I can't speak for vendors like Microsoft,
> : I would imagine their only reason for putting it in IE was for
> : that particular market (I've talked to non-MS developers and they've
> : told me that's the sole reason why they added it to their product).
> :
> : (Again, I don't know about the IKE situation).
> :
> : Anyway, this is all going off on a bit of a tangent...
> 
> 
> The most irritating for me (last time I checked) about the Certicom
> license was that it was NOT royalty-free.  Instead, it used a business
> model that did not charge for the implementation (of the communication
> protocols), but instead it wants a premium for every EC certificate
> issued by a CA.
> 
> What happens if a customer / end user living in a country where the
> Certicom patent is valid purchases certificates from a CA which
> operates in a country where the Certicom patents do not exist
> (or are invalid/inapplicable, e.g. to Software)?
> 
> Who will Certicom sue in such a situation (if any)?  The end user?
> The provider of the protocol implementation?
> 
> Waiting for the patents to expire is IMHO a workable approach for
> the ECC ciphersuites.  Waiting worked for us with the DH and RSA patents,
> when there weren't any alternatives, let alone a working installed base.
> 
> 
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls