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

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.

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.

>
> ...Mark​
>
>