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​
>>> >
>>> >
>>>
>>
>>
>