Subject: Re: [jose] JOSE top-level syntax proposal

From: "Vladimir Dzhuvinov / NimbusDS" <[email-masked]>
Date: Thu, 31 May 2012 04:01:52 -0700

Hi James,

If I understand correctly, the main purpose of these prefixes is to
enable the message/alg type to be determined without decoding the
header? Do you see any particular cases/scenarios where this could
matter?

Apart from this, the prefix seems redundant to me.

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : [email-masked]

-------- Original Message --------
Subject: [jose] JOSE top-level syntax proposal
From: "Manger, James H" <[email-masked]>
Date: Thu, May 31, 2012 1:56 am
To: "[email-masked]" <[email-masked]>

Here is a concrete proposal for the syntax of JOSE messages that
explicitly indicates the mode of protection, independently of specific
algorithm values.

jwsec = ("Z" "." header64 "." compressed64) /
 ("S" "." header64 "." data64 "." signature64) /
 ("I" "." header64 "." data64 "." checksum64) /
 ("E" "." header64 "." enckey64 "." ciphertext64 "." mac64) /
 (ext "." header64 *("." component64))

ext = 1*b64url ; future modes

header64 = 1*b64url ; base64url-encoded UTF-8-encoded JSON object

; the following 8 items hold base64url-encoded byte arrays
compressed64 = *b64url
data64 = *b64url
signature64 = *b64url
checksum64 = *b64url
enckey64 = *b64url
ciphertext64 = *b64url
mac64 = *b64url
component64 = *b64url

b64url = %x41-5A / %x61-7A / %x30-39 / %x2D / %x5F
 ; A-Z a-z 0-9 - _

Mode "Z" carries unsecured data that is optionally compressed.
Mode "I" carries unsecured data with a checksum to detect accidental
errors.
Mode "S" provide data origin authentication.
Mode "E" provides confidentiality.

--
James Manger

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

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 1 Jun 2012 00:50:37 +1000

> header? Do you see any particular cases/scenarios where this could

The "E" prefix tells you that you have an encrypted message, so your initial code can immediately pass it to your decryption class without having to know all the encryption algorithm identifiers.
I think the (nice looking) Nimbus code, for instance, splits on dots, base64url-decodes, interprets as UTF-8, parses as JSON, extracts the "alg" element, looks up the alg value to learn its type... then sees it is an encrypted message and passes the original string to the encryption code (where splitting/decoding/interpreting/parsing happens all over again).

The "S" prefix immediately tells you the 3rd dot-separated segment is the content. Knowing that is sufficient to do things with the content even if you don't have the signature verification key, or even if you don't recognize the signature algorithm.
For instance, a web app firewall might perform some sanity checks on the content.
Or (if your app accepts unprotected and signed messages), you can convert a signed message to an unprotected one when the signing algorithm is unrecognized. At least that doesn't punish the sender for trying to offer some security (by signing), even if you don't support that algorithm yet.

If a new mode is defined (such as the checksum mode mentioned recently) you can recognize that straight away and offer an appropriate error message, instead of thinking it is an unknown signature algorithm or a message with a missing header element.

As a bonus, a message's mode is instantly obvious to developers (without cut 'n pasting a header into a base64url decoding tool).

> Apart from this, the prefix seems redundant to me.

Even if there is always enough info somewhere in a header to distinguish a message's mode (signed/encrypted/unprotected/...) so that a prefix is theoretically redundant, the prefix is a far easier, more direct, way to determine the mode.

P.S. My "Z" mode should be changed to "U" for unprotected, and compression should be integrated into all modes (ie not be a separate mode).

--
James Manger