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 -----Original Message----- 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
