W3C home > Mailing lists > Public > public-credentials@w3.org > November 2014

Re: Fwd: Fwd: Digital Signatures for Credentials

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 18 Nov 2014 19:31:18 +0100
Message-ID: <546B9076.6010306@gmail.com>
To: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>, public-credentials@w3.org
On 2014-11-18 17:20, ☮ elf Pavlik ☮ wrote:
> Feedback from Harry Halpin, who acts as W3C staff contact in Social WG
> and Web Cryptography WG.

It doesn't matter what the IETF or W3C thinks, the notion that you must support
third-rate JSON parsers that doesn't even preserve property order is exaggerated.
Cleartext signatures based on JSON is an already solved problem:

Works without modifications using the built-in JSON parser in all major browsers.

However, I don't really understand the point with graph normalization unless that is an intrinsic part of JSON-LD.


> -------- Forwarded Message --------
> Subject: Re: Fwd: Digital Signatures for Credentials
> Resent-Date: Tue, 18 Nov 2014 16:13:12 +0000
> Resent-From: public-socialweb@w3.org
> Date: Tue, 18 Nov 2014 17:13:02 +0100
> From: Harry Halpin <hhalpin@w3.org>
> To: ☮ elf Pavlik ☮ <perpetual-tripper@wwelves.org>,
> public-socialweb@w3.org <public-socialweb@w3.org>
> I believe if we have to do signed data in the Social Web, we'll use
> JOSE, as that is supported widely, has gone through widespread security
> review in the IETF where it was standardized, and is supported in
> browsers via W3C WebCrypto.
> I believe the largest difference seems to be that JOSE is for generic
> JSON, while Manu's idea for signatures specializes for JSON-LD and thus
> includes a graph normalization step for RDF. There's no reason why that
> step can't be done before before base 64 encoding and signing. JOSE also
> allows algorithm agility and a much more complete stack of
> key/signatures algorithms and functionality. I'm pretty sure any future
> standards-track work out of Web Payments will also be based on JOSE, as
> the W3C has worked closely with IETF over JOSE during its standardization.
> In JOSE, public keys are discovered how keys are normally discovered in
> ASN.1 format (i.e keyservers, etc.), and the opaque blob format (base 64
> encoded) is because signatures works over raw bits, which can be easily
> screwed up in cleartext. Taking strings in and out of base 64 encoding
> is pretty trivial.  Many more web developers, including all major
> browser vendors including Mozilla, use and support JOSE. I don't know of
> anyone uses Manu's alternative to my knowledge outside of a few people
> in his Community Groups.
> In general, I think it's better not to roll one another stacks in the
> crypto space due to security concerns (for example, sending a signature
> separate from the data in cleartext allows the signature to be trivially
> swiped and replaced by another one, i.e. see signature wrapping attacks
> on XML-DSIG), and it's generally not a good idea to fragment standards
> unnecessarily.
>     cheers,
>         harry
> On 11/18/2014 04:53 PM, ☮ elf Pavlik ☮ wrote:
>> I remember some conversation during TPAC about systems behind firewall
>> not fit to make requests back to some other server as required in
>> webmention.org . I think that JSON-LD Secure Messaging could offer some
>> solutions here.
>> Mozilla Open Badges already have hosted version (similar to how pattern
>> used for WebMention works) as well as signed version, both explained in
>> current (pre JSON-LD) spec:
>> https://github.com/openbadges/openbadges-specification/blob/master/Assertion/latest.md#badge-verification
>> -------- Forwarded Message --------
>> Subject: Digital Signatures for Credentials
>> Resent-Date: Mon, 17 Nov 2014 02:32:41 +0000
>> Resent-From: public-credentials@w3.org
>> Date: Sun, 16 Nov 2014 21:32:16 -0500
>> From: Manu Sporny <msporny@digitalbazaar.com>
>> To: Credentials Community Group <public-credentials@w3.org>
>> During the call last week, we touched on the last major item (digital
>> signatures) that needs to be aligned between the Badge Alliance
>> technology stack and the Credentials technology stack. Like all
>> technology, there are upsides and downsides to each approach. I thought
>> I'd try and summarize them in this email.
>> The Credentials technology stack[1] focuses on extensibility via Linked
>> Data / JSON-LD and thus uses a digital signature mechanism that was
>> built for graph-based data.
>> The Badge Alliance technology stack had focused on pure JSON data and
>> re-using the IETF's JOSE digital signature stack. I've written about
>> Digital Bazaar's concerns with JOSE before[2].
>> In general, both technologies allow a developer to:
>> * Digitally sign data
>> * Verify digitally signed data
>> * Express public/private keypairs
>> * Encrypt and decrypt data in message envelopes
>> In this respect, neither technology is that different from what XML
>> Digital Signatures enables one to do.
>> Both SM and JOSE use JSON as the basic container format due to JSON's
>> popularity with developers. When comparing the SM vs. JOSE technology
>> stacks, here are some of the key pros/cons:
>> JSON-LD Secure Messaging Pros:
>> * Clear-text signatures (easier to see/debug what's going on)
>> * Works with any RDF syntax (N-Quads, TURTLE, etc.)
>> * Ensures discoverability of public keys via the Web
>> * Simpler interface for Web developers
>> * Extensible message format due to JSON-LD
>> * Designed to integrate cleanly with HTTP Signatures
>> * Identified as a need for both the Social Web WG and
>>    Web Annotations WG due to dependence on JSON-LD
>> JSON-LD Secure Messaging Cons:
>> * Not an official standard yet
>> * Graph Normalization algorithm is hidden from developers, but
>>    very complex
>> JOSE Pros:
>> * First mover advantage
>> * Already an IETF standard with thorough security review
>> * More software libraries exist for JOSE
>> JOSE Cons:
>> * Signed data is an opaque blob, which is very difficult to try and
>>    debug
>> * Fairly difficult to use for Web developers due to exposing too much
>>    complexity
>> * Format is not extensible, requires coordination through IETF
>> * No standardized public key discoverability mechanism
>> The biggest downside with the SM approach is that it's not a W3C
>> standard yet and that will take some time (1-2 years). The technology is
>> done and there are multiple interoperable implementations out there, so
>> we're not concerned about it not getting through the standardization
>> process once it enters the process. With the recent hallway discussion
>> at W3C TPAC, we feel that we should be able to get the minimum number of
>> W3C member votes necessary to take the specs REC-track.
>> So, with that introduction - are there any thoughts on SM vs. JOSE? Does
>> anyone feel that strongly one way or the other? Any pros/cons that are
>> not in the list above that should be?
>> -- manu
>> [1] http://opencreds.org/specs/source/roadmap/#technology-stack
>> [2] http://lists.w3.org/Archives/Public/public-webpayments/2013Aug/0004.html
Received on Tuesday, 18 November 2014 18:31:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:21 UTC