After having sent this message and while mowing my driveway, I did come up with an additional option for the dotted notation question. One could restrict the use of MAC to a small subset of the scenarios below (basically just the first) and the number of data fields would then be the same as the current document since that is currently the only option that is permitted.
This would require a change in the algorithm descriptions, but not in the dotted notation. Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Jim Schaad > Sent: Saturday, July 21, 2012 7:19 PM > To: 'Mike Jones'; [email protected] > Subject: [jose] JSE/JWE algorithm factoring > > <personal> > > 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. > > If you look at signature algorithms, you need to specify the following > items: > > 1. Where do you find the key to use > 2. What is the public key operation you are using, and > 3. What is the cryptographic hash function you are using. > > We now normally combine items 2 and 3 together to make a single signature > algorithm. > > > If you look at a complete MAC and at encryption systems, you need to > specify > a subset of the following items: > > 1. Where is the key you need to use. > 2. What is the public key operation you are using. > 3. What is the KDF function to go from the public key result to a symmetric > key. > 4. What is the key wrap algorithm to go from a symmetric key to a symmetric > key > 5. What is the content algorithm being used with the symmetric key. > > For the purposes of this discussion, I am ignoring the issues with doing a > composite AEAD algorithm and assuming that is atomically specified. > > If we then look at the different scenarios that need to be supported we do > the following: > > a) Directly encrypt or MAC with a known symmetric key: items 2, 3 and 4 are > omitted, item 5 is specified and item 1 is optionally specified. > b) Use known symmetric key and random CEK: items 2 and 3 are omitted, > items > 4 and 5 are specified, item 1 is optionally specified > c) Use a key agreement algorithm but not a random CEK: Items 4 is omitted. > Items 2, 3, and 5 are specified, item 1 is optionally specified. > d) For a traditional key transport algorithm: items 3 and 4 are omitted. > Items 2 and 5 are specified and items 1 is optionally specified. > e) For RSA-KEM with a random CEK: Items 2, 3, 4 and 5 are specified and item > 1 is optionally omitted. > > You also need to look at the data fields that need to be provided. For > signature algorithms, the output field is the signature value itself. For > the complete MAC/Encryption case you have three different fields: > > 1. The encrypted content field > 2. The random CEK encrypted some how > 3. The authentication value to be used. > > Using the same scenarios as above, the encrypted content is present for > encryption cases and not for MAC cases > > a) Only field 3 is present > b) Both data fields 2 and 3 are present > c) Only field 3 is present > d) Both data fields 2 and 3 are present > e) There are two different versions of 2 present (one for a completely > random value and one for the random CEK) as well as field 3. > > Ok - that is the background information, now for the proposal: > > 1) We specify that if algorithm 2 requires an algorithm 3 then they will be > specified together as a single algorithm name > 2) Any algorithm name not required is omitted. The steps of how to process > will deal with the case of an omitted name. The only place where this > presents some interesting issues is when looking for a key to be used and > deciding what type of key is going to be needed. There will be a couple of > extra steps over what is currently needed as more than one field will need > to be examined before you know if you are looking for a public key algorithm > or a symmetric key algorithm. > 3) Each of the algorithms 2, 4 and 5 will be specified as their own > distinct field names. Algorithm name 2 will be overloaded by additionally > specifying a signature algorithm in this field. > 4) Algorithm 5 will specify both MAC and content encryption algorithm. > 5) Any encryption/MAC algorithm which does not use a random CEK value is > not appropriate for use in cases where there is going to be more than one > recipient. > 6) How do I figure out if it is signed, MAC-ed or encrypted? If content > algorithm is absent, then treat as signed. If content algorithm field > contains a MAC algorithm treat as MAC-ed. If content algorithm contains an > encryption algorithm treat as encrypted. Otherwise treat as unknown > object. > > There is an issue that needs to be dealt with for the dot notation that is > currently being used. If you have a full MAC item (with a random CEK) then > the current dot structure is insufficient to handle that case. I can see a > couple of possible answers: > > 1) Allow MACs to have either 2 or 3 dots depending on the situation. > 2) Allow the number of dotted fields to vary for all types depending on the > algorithms being used. This means that there could be anywhere from 2 to 4 > dots depending on the set of items selected. > 3) Make all of them fixed at 3 dots and take the hit of the extra character > in some cases. > 4) Leave signed at 2 dots, but make MAC and encryption always be 3 dots. > > An example of each scenario above: > > {"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"} > > I am completely unwedded to the names of anything in the examples, I just > choose some simple short names that are representative and easy for me to > remember: > pkAlg - public key algorithm - either a signature algorithm, a key > agreement/key derivation pair or a key transport algorithm (also a key > transport + key derivation for RSA-KEM) > cwAlg - key wrap algorithm > cAlg - content algorithm - either an AEAD algorithm or a MAC algorithm > > jim > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
