W3C home > Mailing lists > Public > public-webcrypto@w3.org > March 2014

Re: [Bug 24963] Export Key with "jwk" operations should return a JWK, rather than an ArrayBuffer

From: Mark Watson <watsonm@netflix.com>
Date: Wed, 12 Mar 2014 08:28:38 -0700
Message-ID: <CAEnTvdCxFn7=nb+f6nfp0p=4Dw+=E6eOdCwq0XH5EDGaoL++5Q@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Alexey Proskuryakov <ap@webkit.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Tue, Mar 11, 2014 at 11:00 PM, Ryan Sleevi <sleevi@google.com> wrote:

>
> On Mar 6, 2014 9:13 PM, "Alexey Proskuryakov" <ap@webkit.org> wrote:
> >
> > (re-sent from correct address)
> >
> > As an implementor, I'm fine with exporting into an ArrayBuffer, as well
> as with importing from buffers. This is consistent with other formats, and
> - especially when importing - nicely avoids any complications that could
> arise while ingesting arbitrary JavaScript objects with their getters,
> loops and such.
> >
>
> Can you explain this?
>
> The complications are either addressed by WebIDL - in which case, they
> don't apply - or they equally apply to our use of the Algorithm dictionary,
> which means we have to solve them independent of this change.
>
> ArrayBuffer is natural for ASN.1 types because they are byte oriented. JWK
> is object oriented, and does not have the same formatting concerns that
> ASN.1 has.
>
​I don't know why you keep repeating this, when I have pointed out many
times that JWK is as much a serialized data format as ASN.1.

>From JWK: "A JSON Web Key (JWK) is a JavaScript Object Notation (JSON)
data structure
that represents a cryptographic key."​
​From JSON (RFC7159):​ "JavaScript Object Notation (JSON) is a lightweight,
text-based, language-independent data interchange format."

​Yes, JSON was discovered in the EcmaScript object literal notation, but
many languages have internal data structures ​that can easily map to/from
JSON data (Python, Groovy, Scala, ...) as well as Javascript. And ASN.1
structures can just as well be represented in such a form.

> Having implemented two ASN.1 parsers in EcmaScript, and having worked with
> JWK now, it continues to feel unnatural and non-intuitive that we express
> JWKs as ArrayBuffers.
>
​And as a developer (Developer > Implemetor as you point out) it feels
natural to take the structure I've received on the wire and pass it
straight to WebCrypto.

I agree that in some cases it's simpler to pass the Javascript object,
especially when the wire protocol is itself JSON and the JWK is embedded in
some larger JSON structure.

Hence my suggestion that we support both. I think it would be easy to get
consensus on that.

...Mark​




> > If there is value in exporting to a JS object, it may indeed be that the
> change is best to discuss after entering LC, when more people join the
> discussion.
>
> We already entered LC, after it was decided on Monday's telecon. This
> thread is trying to put forward a concrete proposal, as was requested on
> the call entering LC.
>
> >
> > - WBR, Alexey Proskuryakov
> >
> > 06 марта 2014 г., в 20:51, Mark Watson <watsonm@netflix.com> написал(а):
> >
> >> Ryan,
> >>
> >> I'm not opposed to making changes in LC, including this JWK one. In
> fact I'm sure we will need to make changes. LC feedback could be far more
> substantial than this JWK issue, which is actually pretty in terms of the
> effect on users of the API (there is nothing that you can do with the API
> now which couldn't trivially still be done if the object form of import /
> export was also supported.)
> >>
> >> What I'm opposed to is forever delaying LC over the fact that such
> changes are possible.
> >>
> >> ...Mark
> >>
> >>
> >> On Thu, Mar 6, 2014 at 8:37 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>> On Thu, Mar 6, 2014 at 8:20 PM, Mark Watson <watsonm@netflix.com
> > wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Thu, Mar 6, 2014 at 7:01 PM, Ryan Sleevi <sleevi@google.com
> > wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thu, Mar 6, 2014 at 6:14 PM, Mark Watson <watsonm@netflix.com
> > wrote:
> >>>>>>
> >>>>>> Ryan,
> >>>>>>
> >>>>>> I do not believe we should consider replacing the existing JSON
> import/export format with an object representation as proposed. The
> serialized JSON format has been stable for some time and aligns with the
> other formats which are also serialized objects as would be seen in a wire
> protocol.
> >>>>>
> >>>>>
> >>>>> Is it correct to say your argument is on two points:
> >>>>> 1) You oppose change
> >>>>
> >>>>
> >>>> No, I oppose revisiting things we discussed and decided on long ago
> at this stage, where we are close to completion.
> >>>
> >>>
> >>> Isn't the point to gain feedback from users and implementors?
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>> 2) You feel JWK is better suited as a wire format
> >>>>>
> >>>>> To the point 1:
> >>>>> I do not believe that opposition purely on the grounds of "change"
> is a good or encouraging sign, especially considering the aggressive push
> by you to advance to Last Call.
> >>>>
> >>>>
> >>>> I would not call my push to advance especially aggressive - we've
> been dragging our feet filling in the boilerplate and resolving the last
> few issues for a long time now. This specification is very close to having
> multiple interoperable implementations (perhaps already has if you count
> Polycrypt and NfWebCrypto) which is a milestone which goes with a *much*
> more advanced formal status. What I find difficult to understand is the
> strong push to delay and delay over minor issues. If we don't move this
> forwards we won't get the deployment experience we need to turn it from a
> nice piece of paper into a real part of the web platform.
> >>>
> >>>
> >>> Polycrypt and NfWebCrypto having implemented early drafts that the WG
> agreed was not the right approach.
> >>>
> >>> Neither have been updated to reflect any work on the draft.
> >>>
> >>> As was expressed on the call by Microsoft, Last Call within the Web
> Apps sector has typically reflects a much more advanced state than we're in
> - a belief that the spec is ready and that we're not going to be wasting
> the time of reviewers and the community by changing things further.
> >>>
> >>> It equally signifies a rubicon of compatibility - that as we go
> forward, our ability to change, to explore, and to make sure we're
> adequately serving the users of the Web Platform.
> >>>
> >>> Our last draft was published http://www.w3.org/TR/WebCryptoAPI/
> >>>
> >>> It reflects an API that is fundamentally different than what we have
> now. We have removed some features (eg: "multi-part operations"),
> significantly altered some (eg: the derivation of promises), and added
> significant new APIs (eg: deriveBits).
> >>>
> >>> Likewise, during this time, multiple vendors have been pursuing
> implementations, gaining implementation experience and validating that the
> API does _not_ require significant changes - a process strongly discouraged
> during/after Last Call.
> >>>
> >>> I think your characterization of "dragging out feet" is entirely
> unfair to these efforts.
> >>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> We have a priority of constituencies -
> http://www.w3.org/TR/html-design-principles/#priority-of-constituencies -
> which is users > authors > implementors > specifiers > purity.
> >>>>>
> >>>>> We have not been afraid to make other changes to "long stable"
> artifacts - just look at the changes to KeyAlgorithm or to the handling of
> RSA keys for two examples of changes for aspects of the spec that had been
> in even _longer_.
> >>>>
> >>>>
> >>>> The KeyAlgorithm change was a change with hardly any externally
> visible effects (test cases didn't need to change to accommodate that). I'm
> not sure what RSA change you are referring to.
> >>>
> >>>
> >>> The change to make the Hash as part of the creation, rather than the
> operation parameters.
> >>>
> >>> It remains to be seen whether or not ECDSA needs to make a similar
> change.
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> We previously discussed this in
> https://www.w3.org/2012/webcrypto/track/issues/14
> >>>>>
> >>>>> You can see that even back then, there was positive reaction towards
> exposing actual JWK-like objects.
> >>>>>
> >>>>> Our choice of DOMString was largely arbitrary, to avoid the
> additional specification of objects, and because wrap would need to work on
> the UTF-8 bytestring (hence no modification during wrapping)
> >>>>
> >>>>
> >>>> We didn't choose DOMString - the serializations are all passed
> accross the APIs in ArrayBuffers. JSON is encoded in UTF-8.
> >>>>
> >>>>>
> >>>>>
> >>>>> Since naturally the question arises is "what new information exists
> to cause us to revisit this?", I think the prime example is the case of
> ECDSA keys and how "alg" is handled, for example. Likewise, in the
> development of a JOSE JWS/JWE system, having the JWK as an actual object -
> for inclusion within other dictionaries and message formatting - is far
> more valuable to developers than requiring the additional parsing. This is
> especially true for public key export of JWK, for which applications may
> process further or embed in true messages as objects, rather than
> b64encoded UTF-8 strings.
> >>>>
> >>>>
> >>>> I'm not opposed to exposing the JWK as an object. Just that this
> should be an additional capability and shouldn't be something that delays
> our Last Call, especially since you raise it so late.
> >>>>
> >>>> ...Mark
> >>>
> >>>
> >>> Mark,
> >>>
> >>> This is _exactly_ the time to raise it. It seems like you would
> equally oppose it if we received feedback to the same effect during LC,
> since it would be a change. That doesn't seem a positive sign for LC, or
> for soliciting feedback.
> >>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> To the point 2:
> >>>>> As you can see on ISSUE-14, this is not entirely true. Applications
> developing JWE/JWS systems, or using the JWK types, are not necessarily
> interchanging at a wire format level. If anything, JOSE is uniquely suited
> to expose Keys as true Javascript objects.
> >>>>>
> >>>>> The priority of "What makes sense for developers" should hopefully
> be clear that one would expect JWK to be a Javascript object, especially
> when obtained from a Javascript API, and that allows full mutation and
> modification.
> >>>>>
> >>>>>
> >>>>> At this stage, we stand with no interoperable implementations, and a
> clearly acknowledge spec that is in progress. I fail to see why we cannot
> or should not revisit this issue, especially as implementation efforts have
> begun, and the use cases continue to mature.
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> Introducing a new object representation aligned with JWK is a great
> idea as an *additional* format, not a replacement - perhaps for a future
> version of the specification.
> >>>>>>
> >>>>>> ...Mark
> >>>>>>
> >>>>>> ---------- Forwarded message ----------
> >>>>>> From: <bugzilla@jessica.w3.org>
> >>>>>> Date: Thu, Mar 6, 2014 at 4:22 PM
> >>>>>> Subject: [Bug 24963] Export Key with "jwk" operations should return
> a JWK, rather than an ArrayBuffer
> >>>>>> To: watsonm@netflix.com
> >>>>>>
> >>>>>>
> >>>>>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24963
> >>>>>>
> >>>>>> --- Comment #1 from Ryan Sleevi <sleevi@google.com> ---
> >>>>>> Bug filed based on this thread -
> >>>>>>
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0059.html
> >>>>>>
> >>>>>> Specifically,
> >>>>>>
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0063.html and
> >>>>>>
> http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0064.html
> >>>>>>
> >>>>>> --
> >>>>>> You are receiving this mail because:
> >>>>>> You are on the CC list for the bug.
> >
> >
> >
> > - WBR, Alexey Proskuryakov
> >
> >
>
Received on Wednesday, 12 March 2014 15:29:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:22 UTC