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

I would agree with Wan-Teh that molding the Crypto API to support intricacies of TLS protocol should be out of scope for this working group. If someone wants to support TLS through JavaScript they can use the core crypto support offered by the API and build TLS logic in their applications. The application can use whatever means it desires to protect the (pre-)master-secret.. Granted it may not be as secure as native TLS support in the API, but the alternative would result in a heavy API with limited set of use cases.

regards,
--- asad

-----Original Message-----
From: Wan-Teh Chang [mailto:wtc@google.com] 
Sent: Monday, May 14, 2012 12:57 PM
To: Ryan Sleevi
Cc: Eric Rescorla; David Dahl; public-webcrypto@w3.org
Subject: 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 22:57:59 UTC