- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 9 May 2012 11:38:22 -0700
- To: David Dahl <ddahl@mozilla.com>
- Cc: public-webcrypto@w3.org
- Message-ID: <CACvaWvYb4877EKvOmbBJ2tcSxok7bceWW=Z_z7g5d0390gTxLA@mail.gmail.com>
On Wed, May 9, 2012 at 8:45 AM, David Dahl <ddahl@mozilla.com> wrote:
> I spent some time on the phone with Wan-Teh and Ryan Sleevi yesterday to
> discuss the editor's draft.Some questions and issues we came up with about
> the preliminary work on the spec are:
>
> 1. Feature (algorithm and capability) detection. We should provide a
> method by which the API can be queried for features/algorithms/cipher
> suites/etc that allows a script to bail out early before attempting an
> operation that will fail. e.g.: we need a version attribute as well,
> "window.crypto.pk.version" to start
>
> 2. Specifying algorithms for crypto operations other than RSA might become
> more complicated than the preliminary spec proposes
>
> There was a discussion about perhaps changing the API to look more like:
>
> window.crypto.rsa.generateKeys() encryptAndSign() verifyAndDecrypt()
>
> I think we can design this in a more 'general purpose' way (similar to the
> current ED) using an options parameter that specifies the algorithm,
> padding, hash/mac,or cipher suite, etc.
>
> 3. Potential need for a parallel set of low-level interfaces. I still
> think we should avoid this as a potential sinkhole. My initial desire to
> provide an "easy-and-safe-to-use" interface is I think the point of this
> API. A parallel, low-level interface is also desired.
>
> 4. The interest in secondary features seemed high in the public call. We
> need to prioritize. (I think this all falls on use-cases to sort out)
>
> 5. I need to run the current spec through where it is using ECC in place
> of RSA to see how it looks/feels - regardless of whether or not browser
> vendors can implement. This also brings up the issue of not stating
> algorithms as MUST IMPLEMENT
>
> 6. We should adopt JOSE specs for all input and output. This gives more
> credence to a very high-level API using cipher suites, which will remove
> most of the ambiguity of a 'generic API'. Of course, using cipher suites is
> not a silver bullet, as Ryan said, SSL has 117+ cipher suites maintained by
> IETF.
>
> 7. For the symmetric API, we need to examine the use cases (notably, the
> Netflix use-case) and figure out what the starting point looks like. Mark
> Watson and Mitch Zollinger of Netflix are interested in another F2F meeting
> to discuss this.
>
> We want to avoid creating the "Netflix API"and I think there are use cases
> in common with what they have proposed.
>
> Wan-Teh, Ryan: is there anything else I forgot to mention?
>
>
> Regards,
>
> David
(Resending to the list from the correct address)
Given that points 1, 2, 5 and 6 were all related, but in ways that are not
immediate obvious, in part due to their ordering, I've made an effort to
formalize some of the things we discussed.
The decision very much hinges upon anticipated Use Cases and Requirements,
so having submissions of possible use cases will be very important to the
group having a positive effect.
1. Core Question: What level of 'crypto' does the API expose.
- High Level API - An API for "box" or "unbox" (eg: similar to
http://nacl.cr.yp.to/ )
- Medium Level API - An API designed around
constructions/ciphersuites, rather than individual algorithms or schemes.
- Low Level API - An API that exposes algorithms (RSA, ECDSA, ECDH,
DH, DSA, AES, 3DES, SHA-1, SHA-2). Additionally exposes schemes (PKCS#1
v1.5/2.0, OAEP, PSS for the RSA case).
- The distinction between the Low Level & Medium Level API is
whether or not the script/caller/application can "mix and
match" (RSA (2048
bit) + OAEP + SHA-2 (256 bit)) versus having all possible permutations
defined in some way ("RSA-OAEP-SHA2-256")
2. If exposing a High Level API
1. The caller should/would have limited ability to influence the
parameters, algorithms, and schemes involved. These would be
decided by the
UA.
2. As such, the UA needs to be able to signal to the caller (and
other consumers of the data) what these parameters were. The use of
JOSE-defined encodings such as JWE/JWA/JWS as an output result of the API
thus makes the most sense in terms of providing a consistent interface.
3. Wan-Teh was concerned that the possible need for versioning (on
top of the JOSE-defined JSON encoding), in the event the
encodings further
change.
3. If exposing a Medium Level API
1. There is a need to specify combinations of algorithms and schemes
combined for purposes of signatures (for example: RSA-PSS) or encryption
(RSA-OAEP, AES-128-CBC) or MACing (HMAC-SHA-1, AES-CMAC).
2. If going with a string-based algorithm specifier:
1. Well-known strings may need be provided as part of the draft,
otherwise UAs may adopt different names for the same
algorithm and force
scripts into UA-sniffing. "AES" vs "AdvancedEncryptionStandard"
2. If well-known strings are specified, how is this maintained as
new algorithms and schemes are introduced. Is it possible to specify
extensions to the draft without requiring a fully new specification?
3. Unless UAs are required to MUST IMPLEMENT all defined algorithms,
a means for feature detection should be provided by the API prior to any
work done. If intending to do an RSA-OAEP signature, for example, one
should first check that RSA-OAEP is supported before doing the more
expensive RSA key generation.
1. This also to support various regulatory or legal frameworks
that may mandate or prohibit the use of certain
algorithms/schemes/ciphers,
as well as to potentially not preclude the use of 'national'
cryptography
such as GOST or SEED without requiring it be implemented by UAs.
4. Even at the medium level, there is still potentially a need to
take parameters. For example, with ECC key generation, the
parameters such
as the curve/point name - are they flexible or is it hardcoded into the
algorithm name ("ECC-secp256r1")
4. If exposing a Low Level API
1. Feature detection of supported algorithms, schemes, etc are still
needed.
2. Should this API provide a single, overloaded entry point, or
provide multiple entry points?
1. Single/Overloaded: "window.crypto.sign()", which takes an
options object that specifies the signature mechanism. The selected
signature mechanism then determines what the other (expected/required)
parameters should be
2. Multiple entry points: "window.crypto.rsa.sign(signature
algorithm, padding scheme, ...)" vs "window.crypto.aes.encrypt(...)"
I think the approach of the WG will be dependent on the Use Cases that
emerge. I believe I enumerated them in what I believe will be the most
controversial for consensus and implementations (high level) to least
controversial for consensus an implementations. This is because designing
whether to either "only" support say, RSA-PSS-SHA2 (High Level) or
"require" support (Medium Level), it becomes a matter of opinion and
potentially crypto-policy. Further, when we talk about things like "safe to
use" or "easy", they're very hard to quantify, and reflect matters of
opinion and not fact. As such, reaching consensus may be difficult.
Additionally, given that a High Level API necessarily precludes the ability
to do anything at the Medium or Low levels, and likewise a Medium
effectively prohibits operations that would be permitted at the Low level,
I (as an individual) believe that for the general utility of the Web
Community, we'd best be served by providing the Low Level API for
applications to build on. I believe the decision about the best API for
such Medium and High level APIs will be best decided by the web community
at large, and will be a constantly evolving and adapting based on feedback,
with perhaps multiple frameworks providing different alternatives.
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.
Received on Thursday, 10 May 2012 15:48:18 UTC