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

I don't think this message made it to the mailing list, http://lists.w3.org/Archives/Public/public-webcrypto/2012May/thread.html

Ryan's response generates some definitions that really help set the stage for us all to get on the same page as far as what is meant by "high level", "medium level" and "low level" API designs. I thought DOMCrypt was "high level", but in reality it is not.

In order to be at all interoperable with existing systems, which I think will be a driving force for adoption, we may need to have a lower-level API that allows developers to use the algorithm, padding, hash/mac or signature an existing system uses. This can be achieved through the use of cipher suites or by creating an API that can just talk PKCS#11, etc. directly - of course with a much more "webby" interface. I have changed my opinion on this, mainly because I was unsure just how low-level the DOMCrypt API actually is.

As far as secondary features are concerned, I think we should re-visit each (as well as primary features) with the greater group and ask ourselves how will each feature spur adoption and usage. I think this will be key for the success of this API. (Perhaps key import/export is one of these features).

Again, thank you Ryan for spelling this out so clearly.

David    

----- Original Message -----
> From: "Ryan Sleevi" <sleevi@google.com>
> To: "David Dahl" <ddahl@mozilla.com>
> Cc: public-webcrypto@w3.org
> Sent: Wednesday, May 9, 2012 1:38:22 PM
> Subject: Re: [Web Crypto WG] Agenda for next call on 14th of May (15:00 EDT/19:00 UTC)
> 
> 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 14:54:30 UTC