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

Re: [Web Crypto WG] Agenda for next call on 14th of May (15:00 EDT/19:00 UTC)

From: Wan-Teh Chang <wtc@google.com>
Date: Mon, 14 May 2012 10:57:15 -0700
Message-ID: <CALTJjxFXeseWV8z-xJDpCG=WTBYN+pJiY4A0JTdJZgLePdY6Ag@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Eric Rescorla <ekr@rtfm.com>, David Dahl <ddahl@mozilla.com>, public-webcrypto@w3.org
On Thu, May 10, 2012 at 5:37 PM, Ryan Sleevi <sleevi@google.com> wrote:
> In the PKCS#11 model, there is a generic function, C_DeriveKey, which takes
> a mechanism and set of (mechanism dependent) parameters and returns a key
> handle.
> For use with this function, PKCS#11 then (un?)fortunately exposes three
> protocol-specific mechanisms to callers - "CKM_TLS_MASTER_KEY_DERIVE",
> allows TLS 1.0 to be implemented via opaque handles. Equally, mechanisms are
> specified for SSL 3.0 and WTLS.
> If pursuing a low-level model, it's not unreasonable to think such a thing
> could be done. If an API was generic enough to support schemes PSS, OAEP,
> and AEAD, with their various optional parameters, then there may be the
> opportunity to fit in such a mechanism. Whether or not it should be done is
> an excellent question for the WG. I have no strong feelings one way or the
> other, and while interested to see if there was such a use case, I'm perhaps
> more interested in a generic-but-extensible API.

I am also interested in a generic-but-extensible API.

It is unlikely that someone will implement TLS using the
Web Crypto API, so a requirement to support TLS could be
overly restrictive. The TLS-specific PKCS #11 mechanisms
for C_DeriveKey all use a special "mechanism parameter"
structure to essentially add input and output arguments
to the C_Derivekey function.  This is especially true for
the CK_SSL3_KEY_MAT_PARAMS structure.  I am not sure if
the Web Crypto API should allow this level of extensibility.

On the other hand, this kind of "hack" for TLS support
seems to be limited to the C_DeriveKey.  The RSA
padding (which I guess Ekr really referred to the
concatenation of SHA-1 and MD5 hashes without
the use of DigestInfo) can be handled cleanly.

Received on Monday, 14 May 2012 17:57:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:01 UTC