[pulling the jose list back on the thread]
I agree that too much simplicity can be as much as an impediment as too
much complexity, but I don't think we've hit that here. I could of
course be wrong, but the single-signature use case seems to be pretty
well-established. I'm not arguing that you should never make a breaking
change during the specification process, but that any breaking change,
especially one so deeply fundamental as this, needs to have very strong
support in both group consensus and running code.
So with that in mind: What's the cause for splitting payload and
signature headers? What kind of information constitutes a "payload
header" anyway? Just about every claim that's defined in the header
today is for the signature or encryption. And you need to protect all of
them with the signature in either case.
-- Justin
On 08/23/2012 01:01 PM, Bob Wyman wrote:
Simplicity is good, but sometimes too much simplicity can prevent us
from doing things that would be valuable to our eventual users. In
this case, I will admit that I am asking for a bit of additional
complexity -- but, it should be recognized as well that I am also
calling for additional simplicity in the structuring of the data.
Rather than mixing things up, I suggest separating them into logical
processing groups.
I argue that instead of:
<header>.<payload>.<signature>
we should have:
<payload_header>.<payload>.<signature_header>.<signature>
where payload header contains only that data which is specific to the
payload and the signature_header contains only data relevant to the
signature. Given that the content of the signature_header is what is
currently already defined as part of the <header>, then the added
message size is only several bytes. I cannot see that there is much
added complexity in the code, since any code written will typically
first concern itself with the payload related data, wherever it is,
and then concern itself with the signature related stuff. Frankly, it
looks to me like while their might be more code to handle four parts
rather than three, the code itself would be cleaner and better
structured since it would inevitably tend to reflect the better
compartmentalization and separation of concerns in the encoded data.
One interesting side-effect of my "simplifying" proposal is that what
falls out of it is a simple way to transmit unsigned data. (i.e.
<payload_header>.<payload> without a signature.)...
Certainly, my suggestion is motivated largely by the
multiple-signature use case (which is required for many applications),
but I am also motivated by a desire to see the data structures be
better normalized. And, I would like to do what can be done now to
simplify the process of defining extensions in the future (from a
standards process point of view) as well as simplicity when people
decide to adopt an extension.
The current definition doesn't seem to me to provide much room for
extensions that would handle the multi-signature case. The only
alternative seems to be not an extension but rather a completely new
spec. Clearly, given the process overhead in IETF, that isn't going to
move along slowly. We would probably spend much more time debating the
extension/alternative as would be consumed in aggregate by all the
developers who needed to handle four parts rather than three... In any
case, the harsh reality is that non-core extensions are rarely
implemented if they aren't firmly rooted in the conventions of the
core specification -- no matter what the standard.
How about this as a compromise?
*Consider using the four-part format that I suggest, but stay silent
on the subject of multiple signatures or any other extensions.* Then,
i'll write up a draft that covers a variety of extensions that
leverage the four-part format -- including the multi-signature case.
If this strategy is used, the core spec will be better structured and
it will remain very "simple" -- but it will be simple in a way that
makes it vastly easier and cleaner to define extensions with minimal
divergence from the simple core. Developers will be served by this
approach since it should make it easier for them to incorporate
support for extensions in the future, if they choose to. And, users
will be served because it makes it easier for us to define extensions
that serve their needs.
bob wyman
On Thu, Aug 23, 2012 at 11:17 AM, Justin Richer <[email protected]
<mailto:[email protected]>> wrote:
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] <mailto:[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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
