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

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.

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

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?

>
> 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'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 03:56:32 UTC