<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
