Hannes, By what metric of "rare"? In the XMPP case, different appearances of a JID count as multiple recipients (at the crypto layer), and in XMPP, multiple appearance is very common (e.g., laptop vs. phone).
--Richard On Aug 20, 2012, at 4: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
