> > Wouldn't it be simpler to have a specific field to indicate the mode?
> > Each mode defines how many dot-separated segments there are, what they
> > hold, and which other header fields indicate the algs the mode uses.
> > If you don't recognize the mode you cannot process the message.
> I agree that having modes can be useful, but I am not sure that it is
> going to help in this situation. The code for dealing with the above
> is actually very simple logic
>
> if (pkAlg exists) {
> if (pkAlg is a signature algorithm) do signature processing and
> return
> else if (pkAlg is a known algorithm) {
> find the key
> process the value
> }
> Else throw an error
> }
>
> If (cwAlg exists ) {
> If unknown algorithm throw error
> If no key then find the key
> Process the value
> }
>
> If (cAlg exists) {
> If unknown alg then throw error
> If no key known then find the key
> If encryption alg then process as encryption and return
> If mac alg then process as mac and return
> }
>
> Throw an error
So let's say we publish JOSE v1; you implement this code; then 6 months later
JOSE v2 adds the option to compress the data before signing it (by allowing
"zip":"DEFLATE" in a JWS). Your code happily processes the message; verifies
the signature; then returns DEFLATE gibberish instead of the expected content.
Yuck.
A "MUST understand everything" rule (if specified and *IMPLEMENTED everywhere*)
might save you by triggering an "unsupported field" error, but such a rule is
wrong for lots of other reasons.
A better approach is for JOSE v2 to defines "t":"sig2". Processing is the same
as "t":"sig" but if a "zip" field is present the content is compressed. Your
old code looks at "t":"sig2" and immediately returns "unsupported mode".
Relying on the presence/absence and values of 3 fields (pkAlg, cwAlg, cAlg) is
not extensible to new modes.
> And now you also start getting compounded modes - want a mode that is
> both agree-wrap-enc and zipped - then you start getting a huge number
> of possible strings to deal with.
Not in practice. One mode string can cover lots of "sub-modes" (eg zipped or
not), as long as the sub-modes are specified when the mode string is defined.
You only need a new mode string when you want something new that could
otherwise be misinterpreted. Instead of every field (about the structure, about
the keys, about revocation info, about key discovery options, metadata about
the content…) needing to be "MUST understand", only the mode string needs to be
understood.
We could pick mode strings corresponding to the top-level contentType in CMS
(eg SignedData, EncryptedData, AuthenticatedData, AuthEnvelopedData,
CompressedData, …).
Or we could be a bit more specific and pick mode strings that cover particular
key establishment techniques (eg AuthEnvelopedData.KeyTransport,
AuthEnvelopedData.KeyAgreement, AuthEnvelopedData.SymmetricKEK,
AuthEnvelopedData.Password, AuthEnvelopedData.IBE, …). I prefer the latter
(since we are only likely to specify a subset of key establishment techniques
at first).
> That is not to say that having some level of modes is not a good idea.
> I would be more than willing to see the typ field become both mandatory
> and slightly more useful - i.e. encryption vs signature vs mac as the
> processing can be very different in the different cases.
--
James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
