> -----Original Message----- > From: Manger, James H [mailto:[email protected]] > Sent: Sunday, July 22, 2012 11:19 PM > To: Jim Schaad; [email protected] > Subject: RE: [jose] JSE/JWE algorithm factoring > > > > 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.
I am not trying to make it extensible to new "modes", I am trying to get a better way to do the current two modes that we have - signing, mac-ing and encrypting. If we create a new Fudge mode then it needs to define its behavior and may or may not use these fields, just like in the current proposal. > > > > 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. This is the same as for my proposal. > > > 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
