W3C home > Mailing lists > Public > public-webcrypto-comments@w3.org > October 2012

Re: ECDSA support in practice - Rather limited

From: Anders Rundgren <anders.rundgren@telia.com>
Date: Wed, 24 Oct 2012 20:33:29 +0200
Message-ID: <50883479.3000207@telia.com>
To: Ryan Sleevi <sleevi@google.com>
CC: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>
On 2012-10-24 18:52, Ryan Sleevi wrote:
> On Wed, Oct 24, 2012 at 1:58 AM, Anders Rundgren
> <anders.rundgren@telia.com> wrote:
>> NSS: Supports ECDSA but when used in Firefox (the User Agent) it is not except if you add a suitable *external* crypto provider.
>>
>> Windows: .NET 4.5 supports ECDSA but not for usage in TLS (WCF).  Seems to be the case even for W8.
>>
>> Android: KeyChain in JellyBean (4.1) seems to not support ECDSA although it is hard to say since the KeyChain documentation is virtually non-existent (the source code is the documentation?).
>>
>> I guess the RIM patent is still the issue here?
>>
>> Anders
>>
> 
> This has been discussed previously at
> http://lists.w3.org/Archives/Public/public-webcrypto/2012Jul/0131.html

Nice table, all items in a one-dimensional list!

.NET crypto is as dysfunctional as in Android:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.asymmetricalgorithm.aspx

"The DSACryptoServiceProvider class is an implementation of a digital signature algorithm.
 You can also use RSACryptoServiceProvider to create and verify a digital signature.
 The System.Security.Cryptography namespace provides concrete classes for RSA and DSA only."

I had to switch to BouncyCastle for my SKS/KeyGen2 .NET implementation.

Mike's table isn't only unreadable, it is also incorrect.

Anders


> 
> I suggest if you have you contributions to make to the table, Mike
> Jones would be appreciative. As it is, all of the platforms you
> mention are already covered.
> 
> The support in TLS client libraries is orthogonal to the support in
> the low-level cryptographic stack, just like it is orthogonal to the
> support within certificate validation/verification libraries. While
> they share some overlap, statements about an TLS stack cannot be used
> to infer or disprove support within the low-level implementation or
> within an X.509 stack.
> 
Received on Wednesday, 24 October 2012 18:34:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 18:34:03 GMT