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
