Re: Fwd: Digital Signatures for Credentials

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 16:13:11 UTC