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

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",
> "CKM_TLS_MASTER_KEY_DERIVE_DH", and "CKM_TLS_KEY_AND_MAC_DERIVE" - which
> 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.

Wan-Teh

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