Subject: [Cose] ISSUE: Algorithm parameters grouping and location

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 May 2015 09:34:36 -0700

Questions:

1.  Should we create a grouping for algorithm parameters?

2.  Should we move IV from a top level item to an algorithm parameter?

Discussion:

When one looks at algorithm parameters there are two types, those that are
long term (i.e. shared secrets, public keys, curves) and for a specific
usage (nonces, iteration counts).  The current system places all of the
short term algorithm parameters into the protected or unprotected header
map.  Thus for ECDH you get

{"protected": {"apu": "base64", "apv": "base64", "alg": "ECDH-ES", "kid":
"my first key"}}

If you grouped them together you would get

{"protected": {"alg":"ECDH-ES", "kid": "my first key",
"alg-params":{"apu":"base64", "apv":"base64"}}

I think that I remember this issue being discussed briefly in the JOSE
working group and the decisions was made to keep things flat because it was
thought to be simpler.   (The proposal was not quite the same as alg and
alg-params were folded together.) If this change was made it would be at a
cost of 2 bytes for every structure.  The major benefit would probably be
seen at registration time as it is easier to figure out if there are
registry duplication where each registration would be on a per algorithm
basis rather than on a global basis.  It might be possible to have a range
of values in the header key table that has the values re-used for different
algorithms rather than to have different identifiers used for different
algorithms.   This might mean that "nonce" and "salt" could have the same
key identification value since one of them is for AES-GCM and one of them is
for PBSE key derivation.  Thus their usage should never overlap.

As part of thinking about this, I was also wondering if we should move the
IV from a top level item to become a header parameter.  This is a wash in
terms of size when maps are used and a gain of one byte per recipient if
more than one recipient is used for encryption if arrays are used at the top
level.  There is no big reason to do it from a size perspective, but it
makes sense to do it from a conceptual perspective as it is the only
"per-use" algorithm parameter which is at the top level and not in the
header maps.  It did not make any real difference for JOSE since the same
structure was not used for both the content and recipient encryption and all
content encryption algorithms required an IV to be present.

Jim