This seems reasonable to me. I'm interested to see a specific take on encryption.
- m&m Matt Miller - <[email protected]> Cisco Systems, Inc. On Aug 17, 2012, at 15:58, Richard L. Barnes wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
