Re: IANA registry for WebCrypto?

On Wed, Jan 23, 2013 at 3:41 PM, Richard Barnes <rbarnes@bbn.com> wrote:
> Can you state clearly what the "grave and serious security threat" this would pose?

You're not seriously asking me to explain why MD5 would be bad for
JOSE, are you?

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

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

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

>
>
>
>
> On Jan 18, 2013, at 9:21 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> I would be thoroughly surprised and quite disappointed if JOSE were to
>> have any interest in specifying SEED, GOST, AES-CTR, 3DES, or SHA1.
>>
>> JOSE has the unique opportunity of no legacy or interoperability, and
>> should absolutely strive to represent secure compositions, such as
>> authenticated encryption.
>>
>> The WebCrypto API does not have that luxury, nor does it represent the
>> same grave and serious security threat that it would to JOSE.
>>
>> I note Mike has chimed in on the bug you opened in JOSE, noting as he
>> did here that JOSE had already discussed this as well. The consensus
>> reached here was hashed, rehashed, and put to bed - and was always in
>> full cooperation and awareness of the JOSE work. I again express my
>> serious misgivings about revisiting this.
>>
>> On Fri, Jan 18, 2013 at 3:37 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>> Speaking as another JOSE WG participant: That JOSE decision was made before this question was raised.  (Plus, if you look closely, it was asked in terms of mandating support, not specifying.)  So it's entirely possible to re-open the discussion.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>> On Jan 18, 2013, at 6:26 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
>>>
>>>> For context, it's important to understand that an explicit consensus call was made in the JOSE working group about whether to support algorithm identifiers as structured objects or as simple strings.  The consensus was to use only strings.  See http://www.ietf.org/mail-archive/web/jose/current/msg01219.html.  From a IETF/ JOSE process point of view, this is a closed issue.
>>>>
>>>> I also disagree that what JOSE has isn't extensible.  The registry defined at http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-6.1 explicitly provides the algorithm extension mechanism.
>>>>
>>>> Anyway, I'm not going to continue discussing JOSE issues on the WebCrypto list, but I believe it's important to this discussion to understand that this particular decision isn't likely to be revisited by JOSE.
>>>>
>>>>                              Cheers,
>>>>                              -- Mike
>>>>
>>>> -----Original Message-----
>>>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>>>> Sent: Friday, January 18, 2013 3:15 PM
>>>> To: Ryan Sleevi
>>>> Cc: Harry Halpin; public-webcrypto@w3.org
>>>> Subject: Re: IANA registry for WebCrypto?
>>>>
>>>> OK, let's up-level a little bit here.
>>>>
>>>> We're not talking about File object or the One True JSON Encoding.  We're talking about tiny little simple objects to configure an algorithm.  The biggest difference is between BigInt/ArrayBufferView and their serialized forms.
>>>>
>>>> What JOSE has right now is not perfect.  It's not extensible, and it's poorly laid out.
>>>> What WebCrypto has right now is not perfect.  It's too verbose (see other email on 'params').
>>>>
>>>> JOSE might benefit from better encapsulation ({name: "PBKDF2", iterations: "..."}).
>>>> WebCrypto might benefit from some shortcuts ("HMAC-SHA-256").
>>>>
>>>> This is not a huge degree of compromise.  I was just hopeful that folks would be open to trying to find a mutually agreeable solution.  Would it help if I proposed something concrete?
>>>>
>>>> --Richard
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Jan 18, 2013, at 5:08 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>>>
>>>>> On Fri, Jan 18, 2013 at 1:57 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>>>>>> Richard,
>>>>>>>
>>>>>>> It's very clear from both charters that JOSE and WebCrypto are
>>>>>>> separate projects, separate efforts, and seek to meet a separate set
>>>>>>> of goals. While there is some commonality, I strongly object to the
>>>>>>> suggestion that they are at all related in purpose enough to derive
>>>>>>> value from sharing algorithms.
>>>>>>>
>>>>>>> In all the people I've talked to who have expressed interests or use
>>>>>>> cases for this API, not a single person has expressed any interest
>>>>>>> in JOSE. It's certainly clear that the use of JWE, JWT, JW*, JWK,
>>>>>>> while certainly possible through this API, are NOT the sole intended
>>>>>>> consumers.
>>>>>>>
>>>>>>> At it's core, JOSE is a wire format. The WebCrypto API is an API. No
>>>>>>> amount of rechartering in either WG is going to change this reality.
>>>>>>> The decisions made should best reflect their intended purposes and
>>>>>>> use cases, and should not be arbitrarily and unnecessarily joined.
>>>>>>>
>>>>>>> It does not make any sense to me whatsoever to have an API
>>>>>>> definition handled through an IANA registry nor through a wire
>>>>>>> representational form, especially one as inefficient (for *Web
>>>>>>> Apps*) and programmer-unfriendly as JOSE.
>>>>>>>
>>>>>>> JOSE MUST make decisions that best reflect its' design requirements
>>>>>>> - including efficient URL representation - while the WebCrypto API
>>>>>>> MUST make decisions that best reflect users' and authors' needs -
>>>>>>> which extend well beyond JOSE. There is an inherent incompatibility
>>>>>>> in these MUSTs - a point I well understood that we'd previously
>>>>>>> reached consensus on, as reflected in the decisions on ISSUE-13.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ryan,
>>>>>>
>>>>>> I can't agree that WebCrypto and JOSE are as separate as you claim.  WebCrypto needs to represent crypto constructs in JavaScript, JOSE in JSON; the difference in concept is only really serialization.  If we don't coordinate, we're going to have duplication.  These babies are inherently conjoined.
>>>>>
>>>>> No. That's not the difference in concept.
>>>>>
>>>>> For example, no matter how creative JOSE tries to get, it will never
>>>>> be able to *efficiently* represent a File object in JSON.
>>>>>
>>>>> JSON as a wire format is very, very different than native JavaScript
>>>>> objects, and while you can certainly go from a JSON into an object
>>>>> that retains some semblance, we should not be conflating the two.
>>>>>
>>>>>>
>>>>>> As far as the need for JW* from users, the lack of interest is not actually that surprising.  It's a network effect thing.  Right now, everyone you're trying to talk to is speaking some ancient ASN.1 language that your JS has to interoperate with.  If JOSE lives up to its charter, it should be a web-friendly replacement for things like CMS and PKCS12, so that future applications can not have to deal with ASN.1.  The trick for WebCrypto is to be able to support the legacy stuff while also looking forward.
>>>>>
>>>>> I disagree on the network effect thing - but I certainly didn't come
>>>>> here to bash JOSE.
>>>>>
>>>>>>
>>>>>> We do agree, however, that the current JOSE specs are developer-hostile, especially in the web environment.  It prioritizes wire compactness over developer utility in the worst possible way.  That's a major flaw in a JOSE, and a discussion that we should have over there.
>>>>>>
>>>>>> Maybe I'm the only one who's fantasizing about a world where building secure apps is actually straightforward, with JOSE as a secure object format instead of CMS, and WebCrypto for the processing instead of platform APIs.  But I think that's the world we should be trying to build here, and we shouldn't be stopped by the failings of our current *draft* specs.
>>>>>>
>>>>>> --Richard
>>>>>
>>>>> The API should remain neutral. Which was the conclusion of ISSUE-13. I
>>>>> don't object to JOSE for high-level, and have certainly been trying to
>>>>> evangelize it if only to explain why some of the security decisions of
>>>>> the API have been intentionally deferred to the protocol and
>>>>> representational forms, but I think it's a much more serious misstep
>>>>> to imply one is inherently superior or the future.
>>>>>
>>>>> JOSE is simply not an alternative to ASN.1 nor an alternative to other
>>>>> representational forms. While it may be convenient, again, the use
>>>>> cases that JOSE sets out to solve are not in line with the use cases
>>>>> that this API tries to solve. No matter how much fantasizing happens,
>>>>> you're not going to see a world where SSH is suddenly replaced with a
>>>>> JOSE-based form, nor are you going to see XMLDSig suddenly disappear
>>>>> in favour of the one true JOSE form.
>>>>>
>>>>> Again, I'm quite supportive of JOSE solving the problems it attempts
>>>>> to solve, but I firmly believe, as I have always asserted, that we're
>>>>> talking a square peg in a round hole when it's suggested that JOSE and
>>>>> WebCrypto have significant enough overlap that all users of WebCrypto
>>>>> should be gated on JOSE's needs.
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Received on Thursday, 24 January 2013 00:20:28 UTC