> -----Original Message-----
> From: Manger, James H [mailto:[email protected]]
> Sent: Sunday, July 22, 2012 7:10 PM
> To: Jim Schaad; [email protected]
> Subject: RE: [jose] JSE/JWE algorithm factoring
>
> Jim,
>
> > Here is another proposal for the people who originally designed the
> > system to take pot shots at, but one which I think might clean up a
> > few things.
> >
> > {"pkAlg":"RSAv1.5-SHA256"}
> > {"cAlg":"HMAC-SHA256"}
> > {"cAlg":"HMAC-SHA256", "cwAlg":"AES-WRAP-256"}
> > {"pkAlg":"ECDH-256-KDF1", "cAlg":"HMAC-SHA256"}
> > {"pkAlg":"ECDH-256-KDF1","cwAlg":"AES-WRAP-256","cAlg":"AES128"}
> > {"pkAlg":"RSAv1.5","cAlg":"AES128"}
> > {"pkAlg":"RSA-KEM-KDF1","cwAlg":"AES-WRAP-256","cAlg":"HMAC-
> SHA256"}
>
>
> So to process such a value, the recipient:
> * Looks for the presence or absence of 3 header fields ("pkAlg", "cAlg",
> "cwAlg") giving 8 possible combinations
> * Determines if the "cAlg" value is a MAC or encryption algorithm or
> unrecognized tripling the 4 combinations when "cAlg" is present
>
> That gives 16 possible "modes". The code can now use a switch statement for
> the mode-specific processing. Better hope that future modes fit within this
> model: eg a checksum might have to pretend to be a MAC algorithm; mode
> that just compresses data (uhmm ).
If this is the way that you are going to define modes then you have vastly
understated the number of modes that might exist.
5 types of pkAlg (sig, key agree, key transport, RSA-KEM like, unknown, absent)
3 types of cwAlg (known, unknown, absent)
4 types of cAlg (encryption, mac, unknown, absent)
5 or 6 ways to retrieve the key information
Total = somewhere around 300?
However some of the things that you add are binary - either you understand and
do it or you don't. Adding Zip does not double the number of modes, just the
number of test cases if you are being exhaustive in testing. In practice
however the number of test cases that need to be added is dependent on the
number of code paths that are modified not on the complete possible tree of
values.
>
> 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
There are a large number of test cases, but that is different than modes. Some
of the modes currently make no sense. Why have a cwAlg and no cAlg? We are
not currently in the business of transporting keys for later use. It might
make sense later but not now. If the cAlg is unknown - who cares about the
rest of the algs as you can't go anywhere with it anyway.
>
> Examples:
> {"t":"sig", "sig":"RSAv1.5-SHA256"}
> {"t":"mac", "mac":"HMAC-SHA256"}
> {"t":"wrap-mac", "mac":"HMAC-SHA256", "wrap":"AES-WRAP-256"}
> {"t":"agree-mac", "kag":"ECDH-256-KDF1", "mac":"HMAC-SHA256"}
> {"t":"agree-wrap-enc", "kag":"ECDH-256-KDF1", "wrap":"AES-WRAP-256",
> "enc":"AES128"} {"t":"transport-enc", "kt":"RSAv1.5", "enc":"AES128"}
> {"t":"transport-wrap-mac", "kt":"RSA-KEM-KDF1", "wrap":"AES-WRAP-256",
> "mac":"HMAC-SHA256"}
>
> Want a mode that just compresses data? Define "t":"zip".
> Want a MAC mode with the same structure as "t":"mac" but where
> unrecognized fields MUST be understood? Define "t":"mac!".
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.
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.
Jim
>
> --
> James Manger
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
