Subject: [jose] Splitting headers

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 17 Aug 2012 17:58:27 -0400

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 17 Aug 2012 22:24:26 +0000

This seems reasonable to me.

I'm interested to see a specific take on encryption.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

On Aug 17, 2012, at 15:58, Richard L. Barnes wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 17 Aug 2012 18:52:19 -0400

> I'm interested to see a specific take on encryption.

In the same "outline" form as for signature below:

{
    "type": "E",
    "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",
    "mac": "[base64-mac]",
    "recipients": [
        { /* type3 */ }
    ]
}

Similar compact encoding tricks can be applied here as in the signature case.

--Richard

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 20 Aug 2012 11:30:58 +1000

> 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.

The unnecessary duplication could be avoided while retaining full header integrity protection if the JOSE syntax explicitly supported multiple recipients/signers.

Richard’s JSMS draft, and Mike’s JWS-JS/JWE-JS drafts show that people want specs for the multiple recipients/signers situations so I think we would be better off supporting these cases in the core syntax from the start.

Multiple recipients/signers does add some complexity to the simplest (and commonest) cases, but I suspect the change can be really quite minor for a party that knows they only ever want to support a single recipient/signer. The change basically just moves a few fields from a top-level JSON object to the first JSON object in an array. Syntax overhead is 8 bytes, using "r" for recipients.

FROM     { ..., "x":123, "y":456, ... }
TO       { ..., "r":[{"x":123, "y":456}], ... }

With support in the core for multiple recipients/signers, full integrity protection would only cause duplication when multiple parties are added *at separate times* (ie after a JOSE message has been created). The XMPP use case did need this (Alice creates a JOSE message for Bob; later Bob’s server adds Bob's phone and Bob’s laptop as new recipients), but that feels like quite a specialized case that JOSE need not optimize for.

> 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:

Would another possibility for #2 be wrapping a JOSE message as the content of another unprotected JOSE message that has the fields not requiring protection? For example (without base64url-encoding for clarity):

  { "alg":"none", "x5c":["MIIE3…"], "ocsp":["MIeR…"]}.<inner-JOSE-message>.

--
James Manger

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 20 Aug 2012 08:27:27 -0400

Hey James,

>  { "alg":"none", "x5c":["MIIE3…"], "ocsp":["MIeR…"]}.<inner-JOSE-message>.

I guess you could, but what would be the benefit?  The "wrapping" doesn't really seem to add anything.

--Richard