[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Les Hazlewood <[e-mail]>]

>
> This is also prohibited by draft-ietf-jose-fully-specified-algorithms
> (It requires what alg to be independent of enc).
>

Hi Illari,


Thanks for the explanation, I appreciate it.


However, I think this is a huge mistake.


The entire purpose of JOSE is to have a JSON-compatible metadata format for
message sending and receiving; with all the flexibility, convenience,
expressiveness and human-readability that implies, which is a really good
thing, and solidifies the ability to be flexible over time, which is ideal
for an RFC.


But then to have a new specification that constrains the most important
security aspect of this down to a single string?  For a few downstream
specifications that don’t represent the bulk of JOSE/JWT use cases?


It’s saying “all the reasons we’ve chosen JOSE headers parameters, and all
that implies - we’re going to ignore that and force-stuff it all into a
single value for the convenience of *some* downstream specifications, all
the while imposing this new inconvenient reality on ALL JOSE/JWT scenarios.”


Respectfully, this is incredibly regressive.  Data models *should* reflect
the best-case modeling scenario, with rich expression, modularity, etc.  If
a new “single string alg” concept needs to exist for downstream
specifications and/or convenience, *those* specification working groups
should define such and not impose this on the JOSE/COSE specifications at
large.  It’s crippling and will forever impact how any algorithms and their
potential parameters are defined in the future, and just doesn't make sense
to be forced on a general-purpose messaging format.


Additionally, such an initiative breaks the concepts of `alg` and `enc` as
they are defined today.  They are and always have been separate
concepts.  `alg`
is a *key* management algorithm, it is not an encryption algorithm.  That
HPKE is composed of both operations isn’t a reason to force it into the
existing `alg` construct - that's trying to do too much and force things
that don’t make sense in a single header parameter that has been
well-defined for a decade.


Any new specification that defines a single string cipher suite definition
should be *additive*, not regressive.  A new header could be defined (e.g.
`csuite`) and that can have that string for the times when it may be needed.
Although anecdotal, I will say that not once in 10 years of maintaining
probably the most-used JOSE/JWT library for the JVM and Android has anyone
ever had a problem with separate `alg` and `enc` headers, and that includes
all the OpenID Connect scenarios I’ve supported both professionally and as
an open-source maintainer.


Or if a new header isn’t desired, there’s no reason an additive
specification can’t say “If you want a single string, combine the `alg` and
`enc` header with a hyphen, and that’s your cipher suite”.   To say that an
implementation - which *must* parse the JSON header and lookup at least one
parameter (`alg`) anyway - cannot lookup another header and concatenate the
two before processing that value doesn’t seem to hold water in any scenario
I can think of.  That’s all that’s needed for cipher suite negotiation for
protocols that need a single string.


I’m not saying that cipher suite negotiation isn’t valuable.  I’m saying
it’s 1) only valuable to a relatively small set of use cases and 2) is
easily obtainable by looking at existing headers and 3) it’s fundamentally
regressive to a) shoehorn a new composite algorithm into a header that was
never designed as such and b) force *all* JOSE implementations to operate
with this concept when it’s not needed most of the time.


Implementations do not need to be forced this concept on a general-purpose
messaging format which has many more implications than OpenID Connect and a
few other downstream specifications.


Most respectfully, and gratefully,


Les