Re: [Cose] Issue: Encoding for a single recipient or structure

["Jim Schaad" <[e-mail]>]

 

 

From: Brian Campbell [mailto:[e-mail]] 
Sent: Thursday, July 02, 2015 10:14 AM
To: Carsten Bormann
Cc: Justin Richer; Jim Schaad; [e-mail]
Subject: Re: [Cose] Issue: Encoding for a single recipient or structure

 

Some things translate more directly than others :)

Indeed the dot joined base64url encoded segments are very array like. And with CBOR that encoding and dot joining is unneeded.

The JOSE experience I'm suggesting this WG consider is the relative simplicity afforded by compact serializations and the widespread use they have seen.

[JLS]  I don’t know how much of this is because it is easy, or because that was the format that was being used by “everybody” before it even came into the working group.  Remember how many decisions boiled down to – we can’t change this, it would break all of the existing code.


 
Conceptualizing the compact serializations as arrays, you have this for signatures/macs:

 

    [protected_header, payload, signature]

and this for encryption:


    [protected_header, encrypted_key, initialization_vector, ciphertext, authentication_tag]



There's just a single recipient or just one signature. There's only one place for headers and they are always protected. It's a (relatively) simple and consistent processing model. The message can be processed or not. There's real value in the simplicity. 






 

On Thu, Jul 2, 2015 at 1:36 AM, Carsten Bormann <[e-mail] <mailto:[e-mail]> > wrote:

I'm not sure the JOSE experience translates to COSE.

In JOSE, there are two different forms, one array-based (a dot-joined
sequence of base64 encodings of the array elements) and one map-based.
COSE doesn't need that choice.

All I can read from the JOSE experience cited here is a strong indicator
that we want to go for arrays, not maps, at least for the outer structure.

Now whether that is shaped*)

[pr, un, ciph, [r1, r2]]

or

[pr, un, ciph, r1]

or

[pr, un, ciph, *r1]

(where *r1 means tha the contents of r1 is expanded right in place)

becomes less of a complexity argument:
[pr, un, ciph, [r1]]
really isn't that much more complex than
[pr, un, ciph, r1]
except for that one 0x81 byte wasted; in a pinch, we can also go for

[pr, un, ciph, r1, r2]
(which is another way of saying:
[pr, un, ciph, *[r1, r2]]
)

Making the array variable size disables JOSE's hack of using the array
size for distinguishing JWE from JWS.  But we don't need that; CBOR has
tags.

Grüße, Carsten

*) I'm leaving msg_type out here, see other thread.