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

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.

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.

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

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