I'd like to pose the question of what constitutes "a bit of extra
overhead". Making the overhead mandatory to support in the core can lead
to developer friction for the majority cases.
This reminds me of the discussion on the OAuth list about returning
multiple tokens. Sometimes, yes, you want to return multiple access
tokens. Usually it's just one. We could have made the return value an
array instead of a string, but then you'd force every client to pull out
"access_token[0]" instead of just "access_token", and that's an
annoyance for the non-rare case. In the end, the group decided on
supporting the simple case in the core and letting an extension define
the multi-token format. That extension was never proposed, so I would
wager that the multi-token case was at least rare enough to not force
the standardization question.
I think the same approach should be taken here. Keep the existing,
deployed, simple format of header.payload.signature for the simple
single-signature case. Use a different serialization format for
different use case, such as the JWS-JSON format that Mike's proposed or
the multi-dot format proposed below. I would argue that they're
fundamentally different kinds of objects and that conflating their use
cases by forcing the overhead is a big mistake.
-- Justin
On 08/20/2012 04: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
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
