Re: crypto-ISSUE-13: Relationship between the W3C Web Cryptography work product and the IETF JOSE WG [Web Cryptography API]

On Tue, Aug 7, 2012 at 8:56 PM, Harry Halpin <hhalpin@w3.org> wrote:
> On 08/06/2012 04:56 AM, Ryan Sleevi wrote:
>>
>> On Sun, Aug 5, 2012 at 7:24 PM, Web Cryptography Working Group Issue
>> Tracker <sysbot+tracker@w3.org> wrote:
>>>
>>> crypto-ISSUE-13: Relationship between the W3C Web Cryptography work
>>> product and the IETF JOSE WG [Web Cryptography API]
>>>
>>> http://www.w3.org/2012/webcrypto/track/issues/13
>>>
>>> Raised by: Ryan Sleevi
>>> On product: Web Cryptography API
>>>
>>> During IETF 84, a frequent question asked was about the relationship
>>> between the W3C Web Cryptography API work product and the IETF JOSE WG work
>>> product.
>>>
>>> As currently spec'd in 1.10, an AlgorithmIdentifier is an (Algorithm or
>>> DOMString). This was added in response to ACTION-7, which was to permit
>>> string identifiers as names for algorithms.
>>>
>>> Two issues arise from this:
>>> 1) Is the additional complexity for handling EITHER an Algorithm OR a
>>> DOMString worthwhile to the API? The result of ACTION-7 was the introduction
>>> of the Algorithm Normalizing Rules, which adds additional complexity for
>>> mapping between DOMStrings to Algorithms.
>>> 2) Should the specification directly refer to the JOSE Algorithms (JWA)?
>>>
>>>
>>>
>> I'd like to propose that the current low-level API specifically
>> clarify that there is *no* specific or priviledged relationship to the
>> IETF JOSE work.
>
> Note that as part of the chartering process, in response to member concerns
> we did commit to actively liason with JOSE WG and given how closely related
> these subjects are, I think that's a good thing, and both processes are in
> motion, although JOSE much more stable. In particular, from the charter: "In
> particular, the IETF JavaScript Object Signing and Encryption (JOSE) Working
> Group is producing formats relevant to the Web Cryptography Working Group,
> and therefore an official liaison is necessary in particular with the JOSE
> WG."
>
> However, I would note that the exact parameters of what is done to ensure
> compatibility between the two WGs is up to the two WGs.

My read of this was in the context of the high-level API, which I
understand to be David's view as well (though I don't presume to speak
for him). That's why I wanted to make sure to bring it to the WG to
see where consensus is.

>
>
>>
>> Specifically:
>> 1) Algorithm/AlgorithmParams does *not* need to be on-the-wire
>> equivalent to JWA parameters
>> 2) It is *not* required that algorithm short-names match their JWA
>> counterparts.
>
>
> I think your earlier arguments that the JOSE WG shortnames don't give enough
> low-level flexibility is convincing for key import\export in primary
> features. However, if we do go down the path of a higher-level API, then I
> think in order to not confuse developers it would be good to reuse when
> possible JOSE and allow key import/export in a JOSE format as a secondary,
> time-permitting feature. I know most JS developers could not get their heads
> around ASN.1.

Absolutely. I think JOSE makes a great deal of sense for a high-level
API - especially as JOSE has already dealt with many of the security
and format ratholes.

>
> Also, while I support ASN.1 as our default key format, there have been
> security concerns re ASN.1 parsing [1]. Thus, it seems having an alternative
> would be good, but then again right now I think browser vendors don't have
> JOSE format support baked in. Thus, a shim library may be the way to go for
> a higher-level API, depending on various vendors. Perhaps a volunteer to
> start thinking about the higher-level API would be useful?

The security issues from ASN.1 have, in many cases, been a result of
the language(s) used for ASN.1 parsing and the security guarantees of
the underlying language, rather than with ASN.1 itself. For example,
buffer over/underflows or template confusion. Given JS as a language,
this is less of a concern.

While not wanting to endorse any particular tool or library, an
example of ASN.1 parsing in JS can be found at http://lapo.it/asn1js/
, to show that this is not a major challenge.

>>
>> My opinion is that this represents a generic API for use in the
>> client. One possible consumer, of many, may include the work-products
>> of the JOSE working group. However, I believe that they do not
>> represent the only consumer of this API, therefore I do not believe it
>> makes sense to primarily design or tightly-couple this work to the
>> JOSE WG.
>>
>> Our current use-cases document, as captured during chartering and
>> through further feedback, shows a number of use cases that are not
>> tied to the JOSE WG. The so-called Netflix Use Case does not make
>> mention of JOSE, the OTR messaging (ala CryptoCat) does not use JOSE,
>> and neither XML encryption and S/MIME e-mail do not use JOSE.
>>
>> Unless we consider all of these to be first-class, which might include
>> the special handling of XML-DSig parameters (
>> http://www.w3.org/TR/xmldsig-core/ ) or ASN.1/DER/OID naming of
>> algorithms, then I think the special treatment of JOSE is an
>> over-specification of this API that may complicate matters
>> unnecessarily.
>>
>> I believe that the mapping of JOSE->Web Crypto API can be easily
>> accommodated by way of an application-dependent API call. For example,
>>
>> /**
>>   * @param {String} algorithmName The name of the JOSE algorithm to
>> look up parameters for
>>   * @type Algorithm The W3C Web Cryptography Algorithm parameters
>>   */
>> function lookupJOSEAlgorithm(algorithmName) {
>>    if (algorithmName == "HS256") {
>>      return { 'name': 'hmac', 'params': { 'hash': { 'name': 'sha-256' } }
>> };
>>    } else if (algorithmName == "HS384") {
>>      return { 'name': 'hmac', 'params': { 'hash': { 'name': 'sha-384' } }
>> };
>>    } else if (algorithmName == "RS384") {
>>      return { 'name': 'rsa-pkcs1-v1_5', 'params': { 'hash': { 'name':
>> 'sha-384' } } };
>>    } else if (...) {
>>      ...
>>    }
>> }
>>
>> Likewise, if an application was implementing an S/MIME client, it
>> might do something like:
>>
>> function lookupSMimeAlgorithm(algorithmIdentifier) {
>>    var pkcs1Oid = "1.2.840.113549.1.1";
>>    if (algorithmIdentifier.oid.substr(0, pkcs1Oid.length) == pkcs1Oid) {
>>      var oidLeaf = algorithmIdentifier.oid.substr(pkcs1Oid.length);
>>      var hashName = '';
>>      if (oidLeaf == "5") {
>>        hashName = "sha-1";
>>      } else if (oidLeaf == "11") {
>>        hashName = "sha-256";
>>      } else if (oidLeaf == "12") {
>>        hashName = "sha-384";
>>      } else if (...) {
>>         ...
>>      }
>>      return { 'name': 'rsa-pkcs1-v1_5', 'params': { 'hash': { 'name':
>> hashName } } };
>>    }
>> }
>>
>> While admittedly, not pretty, I think it has the benefit of avoiding
>> the "everything and the kitchen sink" approach in the draft of this
>> API, and further avoids tightly-coupling any JOSE-specific knowledge
>> in to user agents. Since JOSE-specific handling has been modestly
>> punted to the high-level API, it seems appropriate to not carry
>> JOSE-specific portions into the low-level API.
>>
>> For those who feel strongly about keeping JOSE string identifiers, can
>> you please explain why we wouldn't want to use:
>> - Java Cryptography Architecture names -
>>
>> http://download.java.net/jdk8/docs/technotes/guides/security/StandardNames.html
>> - XML DSig algorithm identifiers -
>> http://www.w3.org/TR/xmldsig-core/#sec-AlgID
>> - Algorithm OIDs used with (CMS, PKIX, TLS, etc) - eg, PKCS#1/RFC 3447
>> - http://tools.ietf.org/html/rfc3447
>
>
>  The aforementioned efforts are not JS-based, unlike JOSE.

I don't think that matters though. The above use cases are all listed
in our use cases, and all things that can be implemented via these
APIs. Which was sort of my point - that the format of the (keys,
messages) is somewhat orthogonal to the language bindings of the API.

With this API, you could build a full featured PKIX cert validator
(with nothing else beyond what we've discussed). You could built a
full S/MIME client. You could build a full XML-DSig parser (at least,
as far as I'm familiar with XML-Dsig).

The JCA comment was because WebIDL and friends have bindings in
languages more than just JavaScript, even if I think we as a WG are
biased towards. Example - http://www.w3.org/TR/WebIDL-Java/

That was the context for pointing out these different examples.

>
>
>>
>> I'm not trying to be facetious with the above question. It's very
>> likely that this API will be exposed to Java clients (eg:
>> http://dev.w3.org/2006/webapi/WebIDL/java.html ), be used to implement
>> XML DSig signatures/verification, or be used to process PKIX
>> certificates (listed under secondary features) or S/MIME messages
>> (listed under secondary use cases)
>
>
> [1] http://www.cosic.esat.kuleuven.be/publications/article-1432.pdf
>>
>>
>
>

Received on Wednesday, 8 August 2012 17:17:02 UTC