- From: <bugzilla@jessica.w3.org>
- Date: Thu, 05 Jun 2014 07:22:00 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985 --- Comment #10 from Ryan Sleevi <sleevi@google.com> --- (In reply to Boris Zbarsky from comment #8) > > The answers to the above questions are different. > > So let's turn this around. How does one actually make use of this API in > practice? That is, how does one discover the supported key lengths, hash > algorithms, and exponents for RSASSA-PKCS1-v1_5 and RSA-PSS? This is the general algorithm discovery problem, which goes back to ISSUE-3 ( http://www.w3.org/2012/webcrypto/track/issues/3 ) Within the WG, the plan has been that during the CFI phase, each algorithm is independently treated as an interoperable component to be tested, and exit criteria for *each* algorithm having defined points of interoperability. This again relates to the Curve25519 discussion. That said, even UAs may not know what the practical limitations are while implementing! PKCS#11, for example, doesn't have a way to discover the step size for keys, while CNG does ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa375525(v=vs.85).aspx ) If this sounds like a horrible place to be in, from a UA, now you see why this has been such a long effort. This is akin to trying to define a set of 3D APIs, when the underlying implementation may be on OpenGL, DirectX, and Glide, during their heyday. While there is significant conceptual overlap, the translation is... lossy. The current API is a reflection of attempting to find the lowest common denominator of potential implementability (eg: through cross-referencing PKCS#11, CAPI/CNG, CDSA/SecurityTransforms/CommonCrypto, OpenSSL, GnuTLS), while at the same time recognizing there are practical limitations towards the interop. Broadly speaking, many of the interop issues come up with the asymmetric operations, due to their greater variability. Many of the symmetric operations have a very limited number of modes and key sizes. However, there's already been concern about whether or not the 192-bit AES key sizes are worthwhile from an implementation standpoint, or if practically speaking, only 128/256-bit are meaningful. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 5 June 2014 07:22:01 UTC