Re: [W3C Web Crypto WG] about extensions to Web Crypto specification

On Thu, Aug 28, 2014 at 11:19 AM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

>  You wrote “Perhaps this is the solution: pull out *all the algorithms*
> into, say, five extension specifications:
>
> - RSA
>
> - AES
>
> - EC
>
> - Hash algorithms
>
> - Key Derivation
>
> ”
>
>
>
> That would just make things needlessly harder on developers.  As a working
> group, we owe it to developers to make the core spec as easy to use as
> possible, while still enabling extension in a timely manner.  Yes,
> obtaining consensus in the working group may be painful, but that’s not an
> excuse for us to inflict enduring pain on developers using our specs as a
> result.
>
>
>
> I strongly oppose removing any of the existing algorithms from the core
> spec.
>

​So, then, the question is what is your proposal for moving forward
regarding extensibility ? Specifically, for new values of the *parameters*
to the algorithms, which seems to be the one open issue (AFAICT).​

​We're not going to get anywhere with everyone stating what they *don't*
like and no new ideas.

...Mark​



>
>
>                                                                 -- Mike
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Thursday, August 28, 2014 11:12 AM
> *To:* Ryan Sleevi
> *Cc:* GALINDO Virginie; public-webcrypto@w3.org
>
> *Subject:* Re: [W3C Web Crypto WG] about extensions to Web Crypto
> specification
>
>
>
>
>
>
>
> On Thu, Aug 28, 2014 at 11:00 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
>
>
>
> On Thu, Aug 28, 2014 at 10:12 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
>
>
>
> On Thu, Aug 28, 2014 at 9:53 AM, Ryan Sleevi <sleevi@google.com> wrote:
>
>
> On Aug 28, 2014 9:43 AM, "Mark Watson" <watsonm@netflix.com> wrote:
> >
> >
> >
> >
> > On Wed, Aug 27, 2014 at 8:04 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >>
> >>
> >>
> >> On Tue, Aug 26, 2014 at 7:51 AM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Aug 25, 2014 at 6:01 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Aug 25, 2014 at 5:49 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Aug 25, 2014 at 5:31 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> >>>>>>
> >>>>>>
> >>>>>> On Mon, Aug 25, 2014 at 5:25 PM, Mark Watson <watsonm@netflix.com>
> wrote:
> >>>>>>>
> >>>>>>> All,
> >>>>>>>
> >>>>>>> Based on the lack of response to my questions below, I propose we
> close this issue as a "non-issue". As far as I can tell the specification
> contains all the extensibility that we need in the form of the ability to
> add additional algorithms.
> >>>>>>
> >>>>>>
> >>>>>> And what of SHA-3?
> >>>>>
> >>>>>
> >>>>> ​The various SHA flavors in the specification are already distinct
> algorithms. I don't see any problem adding more with the algorithm
> extensibility mechanism.​
> >>>>
> >>>>
> >>>> Apologies for not being clearer.
> >>>>
> >>>> How does SHA-3 work with RSA? With ECDSA? With HKDF? With Concat?
> With PBDKF2?
> >>>>
> >>>> I realize that your answer may very well be "I don't know", because
> no such thing exists as SHA-3 yet (beyond Keccak with some undefined set of
> parameters and uses).
> >>>>
> >>>> The point being that we don't know HOW interoperability will work in
> this case.
> >>>
> >>>
> >>> ​Hmm, the specification looks quite clear to me on this. For example,
> the RSA-SSA procedures say things like "Perform the signature generation
> operation defined in Section 8.2 of [RFC3447] with the key represented by
> the [[handle]] internal slot of key as the signer's private key and the
> contents of message as M and using the hash function specified in the hash
> attribute of the [[algorithm]] internal slot of key as the Hash option for
> the EMSA-PKCS1-v1_5 encoding method."
> >>> ​
> >>> ​So, supposing we had a WebCrypto algorithm specification for SHA-3,
> the phrase "​hash function specified in the hash attribute of the
> [[algorithm]] internal slot of key" would be well-defined and the question
> becomes one of whether RFC3447, Section 8.2, is clear on how this hash
> function should be used within the EMSA-PKCS1-v1_5 encoding method.
> Answering this question is clearly out of scope of WebCrypto. RSA-OAEP,
> RSA-PSS, HMAC, CONCAT, HKDF and PBKDF2 are similar.
> >>
> >>
> >> Apologies for not being clearer, as I hoped the issue would have been
> apparent.
> >>
> >> Consider both the importKey and exportKey methods of RSA-SSA -
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/ee10c81e1141/spec/Overview.html#rsassa-pkcs1-operations
> >>
> >> These are certainly IN SCOPE of WebCrypto
> >>
> >> Or consider that these hash algorithms may not be valid with Concat,
> HKDF, or PBKDF2, whereas the current spec implies they are.
> >>
> >
> >
> > ​Thanks for clarifying. That your point was specific to import / export
> was not at all apparent from your original statements.
> >
> > For spki and pkcs8 the solution seems straightforward in that we should
> have the OIDs for the hash algorithms defined by the WebCrypto
> specification of the hash algorithm and then refer out to that from our
> algorithms. For example, RSA-OAEP would say
>
> I'll stop you here: That doesn't work. Or more aptly, it does not work to
> decouple the two aspects, nor does it logically fit a model of dependencies
> where the hash is an aspect of the algorithm, because you are instead
> treating the algorithm as an aspect of the hash.
>
> ​Do you mean that the OID to use for a given hash algorithm might be
> specific to the main algorithm ?
>
>
>
> Indeed it is, as you can see from reading RFC 3447.
>
>
>
>
>
> So, then you need a specific notion of "Registered hash algorithms for
> RSA-OAEP"​, where one has to explicitly register a new hash algorithm with
> RSA-OAEP and in that process define the OID to be used in that context ?
>
>
>
> That is what RFC 3447 has done, and gets to the more deeper point about
> how we holistically deal with these issues.
>
>
>
>
>
> Does that work ? It's a lot of complexity for an extension that is
> probably some way away. I could argue that we should leave RSA-OAEP as is
> and if, in future, someone wants to define RSA-OAEP-2 which includes more
> hash algorithms, they can do so. That has the advantage that you know, when
> you see that RSA-OAEP is supported, exactly which hash algorithms are
> supported.
>
>
>
> This is EXACTLY what I'm trying to avoid. I find the notion of
> "RSA-OAEP-2" to arguably be a failure on our part for defining a clean and
> consistent API.
>
>
>
> ​Well, it depends how you look at it. Is the outcome is that RSA-OAEP
> supports only, exactly and always a specific set of hash algorithms and
> RSA-OAEP-2 supports ​only, exactly and always a specific, larger, set of
> hash algorithms, that looks pretty straightforward and simple.
>
>
>
> On the other hand, if you don't know, without trying, which hash
> algorithms RSA-OAEP supports on a given browser, that adds some complexity.
>
>
>
>
>
>
>
> It's why I didn't propose it to begin with.
>
> >
> > for exportKey:
> > "Set the algorithm object identifier to the OID
> > ​ ​
> > defined by the specification of the hash algorithm identified by the
> name attribute of the hash attribute of the [[algorithm]] internal slot of
> key".
> >
> > for importKey: "If the algorithm object identifier field of hashAlg is
> equivalent to an OID specified by a registered algorithm that supports the
> digest operation, Set hash to the name of that registered algorithm
> > ​.​
> > "
> >
> > ​For JWK, I see it is more difficult, because JWK combines the hash
> identifier into the algorithm name, e.g. "RSA-OAEP-256"​. If you remember I
> had advocated using lookup tables for this problem, in which case extension
> is simply a matter of saying that other specifications may extend the
> table. We could still do that or something similar, such as a notion of
> "registered JWK algorithms" with a requirement that each registered JWK
> algorithm consists of a tuple ( alg, name, params ), alg being the JWK alg
> string, name is the WebCrypto algorithm name and params is an object which,
> for the RSA-OAEP case, contains a single member, "hash", identifying the
> WebCrypto hash algorithm. Then, for RSA-OAEP:
> >
> > for exportKey: "If the name attribute of the hash attribute of the
> [[algorithm]] internal slot of key matches the hash attribute of the params
> attribute of a registered JWK algorithm with name
> > ​ attribute​
> > "RSA-OAEP",
> > ​s​
> > et the alg attribute of jwk to the alg attribute of that registered JWK
> algorithm."
> >
> > for importKey:
> > "If the alg field of jwk is equal to the alg attribute of a registered
> JWK algorithm, let hash be the hash attribute of the params attribute of
> that registered JWK algorithm."
> >
> > ​I'm happy to draft a detailed implementation of this if you like.
>
> I already explored your solution in the past, and believe its both
> inconsistent and illogical when carried out, which is why I didn't propose
> it, and why I still see the issue as existing.
>
>  ​So, what's your alternative ?
>
>
>
> Again, as above, we can have algorithms that are static and well-defined
> in this respect and create new algorithms when we want to add more options.
> This does not seem so bad since it keeps the discovery of what is supported
> clean and ​simple, introduces new functionality in considered steps instead
> of piecemeal and avoids an explosion on the permutations and combinations
> of supported algorithms and parameters.
>
>
>
> Well, the ugly reality is we ALREADY have a vast explosion of permutations
> and combinations of supported algorithms and parameters, as inherent and
> intrinsic in an API that serves multiple software implementations, or
> worse, as shown by the September meeting, has desire to serve hardware
> implementations as well.
>
>
>
> There's already issues as to which RSA modulus sizes are supported - do
> they support odd bits? Even bits multiples of 8? Multiples of 256? Powers
> of 2?
>
>
>
> Do they support RSA-SSA with SHA-1 but RSA-OAEP with SHA-256, etc?
>
>
>
> I don't mean to suggest this is necessarily a good thing, merely that it
> is how the current spec behaves.
>
>
>
>
>
> ​This is in effect the status quo. In the absence of alternative
> proposals, I suggest that's what we get.​
>
>
>
> And the status quo is highly undesirable. I agree, proposals are lacking,
> but I think it highlights a fundamental design issue, and we at least need
> to know how things will progress - whether it is, as you suggest, a
> proliferation of algorithm names (RSA-SSA-WITH-X, RSA-OAEP-v3) or some
> other aspect.
>
>
>
> Of course, if every algorithm was itself an extension spec, as has been
> suggested, then when SHA-3 comes along, the RSA-OAEP spec could be revised
> to introduce support, maintaining the same name, and adding new parameters
> or describing how the state machine would handle it.
>
>
>
> Perhaps this is the solution: pull out *all the algorithms* into, say,
> five extension specifications:
>
> - RSA
>
> - AES
>
> - EC
>
> - Hash algorithms
>
> - Key Derivation
>
>
>
>
>
> The upside is this keeps internal consistency in developer's real world
> code.
>
> The downside is what we have struggled with since the very first day,
> which is capability discovery - whether we suggest something is
> normative/MTI (but not yet implemented by a UA) or not.
>
>
>
> This is not something unique to our WG - WebApps and CSS regularly
> encounter this. But it's a fundamental issue we have to solve as part of
> the design of our API, which is that we know not just how things look
> today, but are able to provide meaningfully consistent guidance on how
> things could look tomorrow, and that we're happy with how they end up.
>
>
>
> ​I understand and agree, however to simultaneously say "the current spec
> is broken", "I've no idea how to fix it" and "everyone else's ideas are
> broken"​ is a recipe for indefinite delay.
>
>
>
> ...Mark
>
>
>
>
>
>
>
>
>
> ​...Mark​
>
>
>
>
>
>
>
> >
> > ...Mark​
> >
> >
>
>
>
>
>
>
>