On Aug 17, 2012, at 6:24 PM, Matt Miller (mamille2) wrote:
> This seems reasonable to me.
>
> I'm interested to see a specific take on encryption.
In the same "outline" form as for signature below:
{
"type": "E",
"header": "[base64-type1]",
"params": { /* type2 */ },
"content": "[base64-content]",
"recipients": [
{ /* type3 */ }
]
}
Note that because we've removed the recipient-specific parameters from the
top-level "header" field, the integrity check value is the same for every
recipient. So if you're using an algorithm that integrates the ICV into the
ciphertext (e.g., CCM), it will be part of the "content" value; otherwise, we
could add an "integrity-check" field at the top level.
While I'm covering the different cases, note that MAC is a hybrid of these two.
The MAC key is wrapped for each recipient, but the MAC value is
constant/top-level.
{
"type": "A",
"header": "[base64-type1]",
"params": { /* type2 */ },
"content": "[base64-content]",
"mac": "[base64-mac]",
"recipients": [
{ /* type3 */ }
]
}
Similar compact encoding tricks can be applied here as in the signature case.
--Richard
>
>
> - 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
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
