W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

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

From: Ryan Sleevi <sleevi@google.com>
Date: Sun, 5 Aug 2012 19:56:12 -0700
Message-ID: <CACvaWvbaJjoofxm7STiFqKZqRM1-Sbr-uAQvO9rSYvaCW4CW_w@mail.gmail.com>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
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

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.

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

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

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

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)
Received on Monday, 6 August 2012 02:56:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:25 UTC