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: Ryan Sleevi <sleevi@google.com>
Date: Thu, 10 May 2012 17:37:18 -0700
Message-ID: <CACvaWvaTQajHFJ1UX8Kpvq_twasz+o6NZCca442PdkcM2iNo2Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: David Dahl <ddahl@mozilla.com>, public-webcrypto@w3.org
On Thu, May 10, 2012 at 8:53 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> Ryan,
>
> This is really useful. One point I wanted to highlight...
>
> On Wed, May 9, 2012 at 11:38 AM, Ryan Sleevi <sleevi@google.com> wrote:
> > My own belief is that the best/most interesting API will be a low level
> API
> > that provides a single/overloaded method with options objects. In short,
> > something that is akin to PKCS#11 for JavaScript. Given that PKCS#11 is
> able
> > to support SSL/TLS, S/MIME, DTLS, SRTP, PGP, and high value transactions,
> > all through a single interface, I believe it's a reasonably proven
> > approach.
>
> I think it would be really useful to come to consensus on whether TLS
> support
> is required. As I said earlier, TLS requires you do some really funky
> stuff with:
>
> (a) the RSA padding.
> (b) the DH output
>
> If you want to have an API that supports TLS, you either need to have
> explicit support for the TLS operations or raw access to the keying
> material.
>
> -Ekr
>

Agreed.

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.
Received on Friday, 11 May 2012 00:37:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:10 UTC