On 2018-11-18 17:53, Jim Schaad wrote:
-----Original Message-----
From: jose <[email protected]> On Behalf Of Carsten Bormann
Sent: Sunday, November 18, 2018 7:00 AM
To: Anders Rundgren <[email protected]>
Cc: [email protected]
Subject: Re: [jose] Canonical JSON form
On Nov 18, 2018, at 08:53, Anders Rundgren
<[email protected]> wrote:
On 2018-10-11 21:03, Carsten Bormann wrote:
On Oct 11, 2018, at 20:23, Phil Hunt <[email protected]> wrote:
I am not sure of the value of canonicalization. I prefer bytestream
encoding style where the original content goes with the signature.
I’m afraid a lot of people are sitting in front of their screens silently
agreeing, but not typing anything because their hands are tied up in an
interminable facepalm.
Those who are not stuck in an a ever-lasting facepalm may not be entirely
comfortable with signature schemes that completely change the structure of
signed messages. COSE do this as well?
I don’t understand the question. The point of COSE is that the signed message
is not changed at all.
(With JOSE, it needs to be base64-encoded for transfer, but it also isn’t
changed
otherwise.)
COSE does do the same type of wrapping as what the JOSE standard does. In that sense --
that the content being signed and the signature are not at the same level in the encoding
- yes it "completely changes the structure of the signed message".
Well, you can of course add artificial unsigned layers (like the TEEP folks do),
but that smells “workaround" rather than solution.
Again, I don’t understand.
There's no mystery going on here. The TEEP folks needed Signed Data rather
than Signature objects with embedded Data.
JSON can (as I have shown) fairly easily accomplish this without adding
[redundant] unsigned wrapper objects.
Another application I stumbled on is Open Banking, here in a request scenario:
POST /payments HTTP/1.1
x-jws-signature: eyJhbGciOiJFUzI1NiJ9..EzZmI2LxhWyCf9ljJBw-Z3i9uxnJu6XL5ljTY==
Content-Type: application/json
{
"Data": {
...OB specific data..
},
"Risk": {
...OB specific data..
}
}
Using JWS + JSON canonicalization:
POST /payments HTTP/1.1
Content-Type: application/json
{
"Data": {
...OB specific data..
},
"Risk": {
...OB specific data..
},
"x-jws-signature":
"eyJhbGciOiJFUzI1NiJ9..EzZmI2LxhWyCf9ljJBw-Z3i9uxnJu6XL5ljTY"
}
What's the advantage with that you may wonder? Well, signed data becomes a
self-contained object which can
- pass arbitrary proxies
- be stored in a database
- be embedded in another JSON object to for example support countersigning
etc. without losing its edge.
I would consider a similar solution for CBOR/COSE.
Anders
https://mobilepki.org/jws-jcs
> > But maybe what I wrote earlier is still applicable:
How it smells depends on how one looks at the world. For me it smells "this is the
right way to do things". YMMV.
To the people asking for a c14n solution for signature: If you want XMLDSig,
you know where to find it.
The basic approach of having humongous XML documents that get
signatures added to themselves as part of the document only makes sense in
certain processing models that went out of favor with XML.
This.
JOSE does the right thing for more modern applications.
And this.
I’m not opposed to doing some “c14n” work on serialization schemes —
deterministic serialization has other applications than just XMLDSig.
RFC 7049 has some recommendations for “c14n" that are being cleaned up and
updated for 7049bis.
Those are implemented in a few CBOR libraries, albeit not in all.
The RFC 7049 version of “c14n” is in use in some other SDOs’ work.
I definitely do not like giving the message that c14n-based signatures are
the new thing that will replace doing the right thing (JOSE, that is).
And this.
Grüße, Carsten
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
