Re: IANA registry for WebCrypto?

On Wed, Jan 23, 2013 at 7:42 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> If there is any security threat, I would think it would be much greater for WebCrypto than for JOSE, since it's WebCrypto that will actually be in the hands of developers doing the crypto bits.  JOSE is just an arrangement of the secured octets; if done properly, it has *no* security implications beyond those of the algorithms employed.
>>
>> That's not at all a fair statement. That's like saying that
>> "encrypt-then-mac", "mac-then-encrypt", and "encrypt-and-mac" are all
>> just arrangements of secured octets, and thus have no security
>> implications.
>
> Indeed, if you look at CMS, which is logically parallel to JOSE, it allows all three of those arrangements.  Then S/MIME, an application of CMS, discusses the implications:
> <http://tools.ietf.org/html/rfc5751#section-3.6>
>
> So no, the format you use to say "These are the signed/encrypted octets and the key/algorithm I used to make them" shouldn't have security implications.  It's a layer below that.
>
>
>
>>> Again: We're just talking about defining identifiers.  That's different from whether identifiers are legal for use in a given protocol or application.  JOSE and WebCrypto could draw on the same registry, but JOSE could forbid the use of non-AEAD algorithms.
>>
>> Richard,
>>
>> As was run into the ground in past discussions, when this WG reached
>> consensus and successfully closed the issue, there is a distinction
>> between what JOSE is attempting to do (effectively, qualify as many
>> parameters as possibel as part of the name) and what WebCrypto is
>> trying to do (provide a cryptographic API in which the parameters are
>> specified).
>
> As I've said before, this is a meaningless distinction.  JOSE parameters ultimately get shoved into some API.  Wouldn't it be nice if an implementation could just copy instead of maintaining YET ANOTHER algorithm name translation table?
>
> The goals of the two efforts are not contradictory; each can benefit from the other approach.  Are you seriously saying you're opposed to allowing a developer to just use a string like "HMAC-SHA-256" instead of the compound structure he has to figure out now?

Richard, you've clearly forked the topic here into JOSE parallelism,
which we've already addressed by having the API permit string
identifiers - specifically, those from JOSE.

If it means that our hypothetical developer has to wait for every
browser her customers use to be updated, to add another mapping for
HMAC-SHA-3, even when they already support HMAC and SHA-3, because the
IANA name has not yet been assigned (by WebCrypto or, in your
completely separate issue, by JOSE), then yes, I am opposed.

If your issue is about recognizing JOSE strings (which are *NOT*
"HMAC-SHA-256" but instead "HS256"), this has already been addressed.

>
>
>
>>> All I'm suggesting is that we only name things once.
>>>
>>
>> Except we're **not** naming the same things.
>>
>> JOSE is naming a hyper-minimal wire format, where as much context as
>> possible is implied by the name to reduce the need or ability to
>> encode parameters.
>>
>> WebCrypto is defining a developer API, in which algorithms have
>> parameters, definitions, and test cases, in which the parameters are
>> specified in WebIDL.
>>
>> Can we at least recognize that the JOSE vs WebCrypto is an entirely
>> different discussion than what Harry originally raised, which is an
>> IANA registry? And then look at situations such as "In what ways is
>> this different than, say, having an IANA registry for CSS selectors or
>> an IANA registry for HTML element tags or an IANA registry for DOM
>> errors"?
>
> Certainly, we have been ranging far beyond that question, but actually addressing some good, fairly basic questions.
>
> The difference from those other questions is that there aren't other groups that might be defining nearly identical registries, that would want to have a well-defined correspondence with this group's registry.  We are in that situation, and I'm just proposing that we arrange the registries so that the correspondence is equality -- or at least written down somewhere.
>
> I was going to put a concrete proposal here, but thought that would be burying the lede.  So it's in another message in response to the message from Harry that started this thread.
>
> --Richard
>
>
>
>
>
>
>
>
>
>
>
>
>

Received on Thursday, 24 January 2013 03:52:00 UTC