I'll reiterate that I'd very much like to see the single signer and single recipient cases remain as simple as possible.
On Thu, Aug 23, 2012 at 9:54 AM, Hannes Tschofenig < [email protected]> wrote: > I agree with you, Justin. > > My impression is that the multi-party communication and multi-party > security scenario will either have to live with additional overhead > (Richard, how much overhead are we talking about) or (what is more likely) > there will be a different mechanism used (which is what happened with > security for multi-party communication in the IETF in general). > > Ciao > Hannes > > > On Aug 23, 2012, at 6:17 PM, Justin Richer wrote: > > > I'd like to pose the question of what constitutes "a bit of extra > overhead". Making the overhead mandatory to support in the core can lead to > developer friction for the majority cases. > > > > This reminds me of the discussion on the OAuth list about returning > multiple tokens. Sometimes, yes, you want to return multiple access tokens. > Usually it's just one. We could have made the return value an array instead > of a string, but then you'd force every client to pull out > "access_token[0]" instead of just "access_token", and that's an annoyance > for the non-rare case. In the end, the group decided on supporting > the simple case in the core and letting an extension define the multi-token > format. That extension was never proposed, so I would wager that the > multi-token case was at least rare enough to not force the standardization > question. > > > > I think the same approach should be taken here. Keep the existing, > deployed, simple format of header.payload.signature for the simple > single-signature case. Use a different serialization format for different > use case, such as the JWS-JSON format that Mike's proposed or the multi-dot > format proposed below. I would argue that they're fundamentally different > kinds of objects and that conflating their use cases by forcing the > overhead is a big mistake. > > > > -- Justin > > > > On 08/20/2012 04:16 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >> Here is my view: the muliple recipient case is a rare case. Having a > bit of extra overhead for rare cases is IMHO acceptable to keep the core > spec simpler. > >> > >> hannes > >> > >> Sent from my Windows Phone > >> From: ext Richard L. Barnes > >> Sent: 8/18/2012 12:58 AM > >> To: [email protected] > >> Subject: [jose] Splitting headers > >> > >> Hey all, > >> > >> At IETF 84, I suggested that we take another look at what header > information gets integrity-protected and what doesn't. The main issue > being that in multiple-recipient or multiple-signer scenarios, there's > unnecessary duplication of data if recipient- or signer-specific > information is in the integrity-protected header. > >> > >> Following some on what Bob Wyman proposed this afternoon, I would like > to propose that we split the set of header fields into some logical > groupings: > >> 1. Top-level fields that require integrity protection (e.g., cty or a > digest algorithm parameter) > >> 2. Top-level fields that do not require integrity protection (e.g., x5c) > >> 3. Fields that are specific to a signer (e.g., jwk) > >> 4. Fields that are specific to a recipient (e.g., epk) > >> > >> In this taxonomy, only fields of type (1) need to be base64-encoded for > to preserve their serialization, and fields of type (3) and (4) could be > gathered together into the moral equivalent of SignerInfo and RecipientInfo > objects. All this makes the JSON serialization a lot cleaner, for example: > >> > >> { > >> "type": "S", > >> "header": "[base64-type1]", > >> "params": { /* type2 */ }, > >> "content": "[base64-content]", > >> "signers": [ > >> { /* type3 */ } > >> ] > >> } > >> > >> You can also imagine a reasonable compact serialization, something like: > >> > >> > S.[base64-type1].[base64-type2].[base64-content].[base64-signer1].[base64-signer2]. > ... > >> > >> That encoding even has the benefit that the multi-signer case doesn't > add any overhead over the single-signer case, except for maybe a couple of > "." characters. (Obviously, you would want some structure on how the signer > info gets serialized, but that's another level of detail down. You could > imagine something like "[signer-header].[public-key].[signature-value]".) > >> > >> The additional structure might seem like it's more work to parse, but I > don't think it's really that bad. Given a parsed JOSE object "obj": > >> 1. Decode obj.header and add its fields to obj.params > >> 2. Look through "signers" / "recipients" to find one we understand > >> 3. Verify / decrypt content using signer/recipient info and parameters > >> > >> There are several details to be worked out -- most critically, which > fields go in which groupings -- but I thought I would throw out the general > idea for comment before diving into the details. > >> > >> Cheers, > >> --Richard > >> > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > >> > >> > >> _______________________________________________ > >> jose mailing list > >> > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
