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
