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

Why access to raw keying material is valuable

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 10 May 2012 08:34:18 -0700
Message-ID: <CABcZeBO8W4pyWnyKER2uODsWGjhTvQOHjkk6SGOYhX_=2GEBSA@mail.gmail.com>
To: public-webcrypto@w3.org
While I generally agree that it's useful for applications not to have much
contact with the keying material, experience has shown that designing
APIs which are intended to rigidly limit that access can make it very
hard to use them for new applications. The example I usually give is
tokens designed for S/MIME which were unusable for TLS because
TLS required much more direct access to the result of the RSA operations.
However, conveniently we have a good example now being provided
by JOSE.

For reasons that are well-known, it's dangerous to use encryption
without integrity. Accordingly, JOSE is planning to require that any
encryption come with some integrity function. In the current design,
this is done by using public key cryptography to exchange a master
key (CMK) and then running it through a key derivation function
to derive separate integrity and confidentiality keys:

http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-01#section-7

The problem here is that implementing this kind of design (which I
hasten to add is very reasonable) in an environment which is also
designed to deny access to any keying material requires that the
KDF process be built into the crypto API from the start. If it's not
(which it doesn't appear to be in the current editor's draft), you're
simply hosed.

More generally, it's a mistake to think that the primitives you need to
implement protocols are well enough specified that you won't need
new ones for new protocols. But precisely the primitives you need
to implement new protocols tend to be the ones you need for users
of those primitives to exfiltrate data about the keying material.

-Ekr
Received on Thursday, 10 May 2012 15:35:32 UTC

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