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

On Thu, Aug 28, 2014 at 11:12 AM, Mark Watson <watsonm@netflix.com> wrote:

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

Seems like a reasonable balance between a preponderance of small
specifications and one monolithic.


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

Even if they can all be true statements.

My goal is to make sure we're not letting inertia carry us forward into a
BAD spec. I'm fully aware that we run the risk of inertia failing to carry
us forward, but my continued hope is other members of the WG will actually
get involved and examine and consider these issues, beyond just you (and,
to be clear, I do greatly appreciate you taking the time to understand and
consider the issues and suggest solutions), so that we can see whether or
not this is something that's

- Unworkable, and should be iced
- Workable, but with "I can live with it" ugliness
- Solvable elegantly and cleanly with a little creativity and elbow grease

What I don't want to do is assume that "no one commented, therefore it's
the right solution"


>
> ...Mark
>
>
>
>>
>>
>>>
>>> ​...Mark​
>>>
>>>
>>>
>>>>
>>>> >
>>>> > ...Mark​
>>>> >
>>>> >
>>>>
>>>
>>>
>>
>