Re: Fwd: Re: Fwd: Digital Signatures for Credentials

On 11/18/2014 11:20 AM, ☮ elf Pavlik ☮ wrote:
> Feedback from Harry Halpin, who acts as W3C staff contact in Social WG
> and Web Cryptography WG.
>
> -------- 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.

It's true that these are pros for an existing technology. As Manu 
mentioned, there are also drawbacks for JOSE -- as is the case for any 
technology. I think there's a debate worth having here. Note that the 
pros listed here can only be the result of a technology that has been 
around longer than the alternatives under consideration. A new 
technology that addresses the drawbacks of JOSE, while bringing along 
less undesirable drawbacks of its own, could similarly go through 
security review, make use of W3C WebCrypto, and potentially gain wide 
use. These aren't advantages that speak to the technology itself.

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

Just to be clear: The JSON-LD solution can also work for generic JSON in 
the same way that the JOSE solution does. JOSE effectively strips away 
the JSON formatting in the signed payload by obscuring everything as a 
base64 blob. You could just as easily take a base64 blob and put it in a 
JSON-LD container as you could put it in a JOSE JSON container. So the 
JSON-LD approach already supports what JOSE does, as you can mark up a 
JOSE JSON message as JSON-LD. Using an RDF normalization algorithm to 
produce a canonical serialization to be digitally signed adds value. For 
example, it works with *more* than just JSON; it allows you digitally 
sign data that is transported using any RDF syntax. I'd expect that kind 
of technology to be very valuable to the Social Web -- and the Web in 
general.

By the way, let's be careful not to use language that personalizes this 
by making it seem like it's "Manu's idea" -- this is a much older and 
more widespread idea. That may not be your intent.

> There's no reason why that
> step can't be done before before base 64 encoding and signing.

This is true. But you don't have to be locked into a JOSE JSON syntax, 
rather you can use any RDF syntax, if you take the RDF normalization 
approach to digital 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.

This isn't related to digital signatures that rely on RDF normalization, 
per se, rather it relates to a philosophical difference between the 
Secure Messaging approach and the JOSE and IETF approach. The JOSE 
approach is to specify and implementation all possible (with appropriate 
security considerations) crypto algorithms. Extensions are centralized 
via the IETF process. The Secure Messaging approach is to recommend only 
one very good algorithm and require that just that algorithm be 
implemented. This can change as needed as the crypto space evolves. It 
then allows for algorithmic agility by using the decentralized 
extensibility inherent in Linked Data. These are simply different ways 
to approach the same problem; it's subjective which is preferred and I 
would expect people to differ.

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

The proposed alternative key discovery mechanism is much more "Web 
first". A key resides at a URL. You follow your nose to that URL and 
you'll find Linked Data there that describes the key, including 
information such as who supposedly owns the key. The URL for that owner 
is where you can get more Linked Data to confirm that the same key has 
been listed. This information can be used to assert ownership over the 
key. This same mechanism has been used with WebID. I'd expect this 
approach to be attractive to the Social Web (and again, the Web in general).

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

That's because it's an alternative; a new technology that hasn't yet 
been standardized. This sounds like begging the question, a round about 
way of restating definitions that ignores the point of contention. I 
think the definition of a new alternative *requires* that there be less 
adoption. The point of contention is whether or not the new alternative 
(Secure Messaging and/or RDF normalization-based digital signatures) 
should be used over the existing JOSE stack. Also, just for clarity, the 
technology is new, but has some basis in ideas that been around for a while.

As an aside: perhaps you are just using terms like "Manu's alternative" 
to describe this technology in a quick way, but when you couple that 
with "his Community Groups" in the same sentence it makes it sound like 
you're dismissing the technology as a personal idea of his. Manu is 
certainly a vocal, active member, and leader in the Community Groups 
you're referencing. But your choice of words seems disparaging to the 
other members in those groups and to others who have worked on these 
ideas or parts of them for much longer than those groups have existed. 
I'm going to give you the benefit of the doubt that this is 
unintentional; I'd just suggest using different language in the future.

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

I do agree that we shouldn't fragment standards unnecessarily. I also 
think that the Secure Messaging/RDF-normalization approach brings a lot 
to the table. The main benefit of the JOSE approach appears to be age 
(and thus, adoption, et. al) -- as you mentioned. That's useful, but 
something an alternative can gain with time. I think a debate in this 
space is appropriate.

-Dave


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


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Wednesday, 19 November 2014 16:32:13 UTC