Re: [CFRG] options == bad?

[Manu Sporny <[e-mail]>]

On Wed, Aug 17, 2022 at 8:57 PM Stephen Farrell
<[e-mail]> wrote:
> My own bias is to want as few as possible, but that always
> seems to lose out to a tendency to want to enable whatever
> future uses people can reasonably envisage, which can soon
> lead to a combinatoric explosion.

Stephen, how timely! :).

There is currently work happening[1] at W3C in the Verifiable
Credentials WG that is exploring exactly this topic. As an Editor on a
number of these specifications, I have an action to engage with CFRG
on the topic.

We have a need to define new identifiers for cryptography suites that
combine data transformation (such as canonicalization) with "approved
IETF/NIST/FIPS cryptography". The JOSE/COSE algorithms only help us so
much, and there is concern wrt. the optionality of all of the
algorithms that could be used. You can read some very draft-y language
that we're debating at present, speaking to what Stephen raised, here:

(Don't read too much into the existing text in the draft, it's
pre-FPWD at present and is undergoing many changes)
https://pr-preview.s3.amazonaws.com/w3c/vc-data-integrity/pull/36.html#versioning-cryptography-suites

> So if even 2 options for eddsa (RFC8032) turns out to be a
> problem, I wonder if we're doing all this right and how we
> might maybe do it better. I'd hope if there is a way to do
> it better then CFRG would be the place to do that.

There is a subset of the VC community that feels like just blanket
adopting ALL the Recommended and Optional values in JOSE/COSE
Algorithms registry is going to not only harm adoption (due to interop
difficulty), but also give the developers using this technology a
number of dangerous options (if we provide the ability to pick among a
set of parameters where they have little to no understanding wrt. the
ramifications).

So, the proposal is to aggressively profile what's in the current
JOSE/COSE algorithms registry and provide "cryptographic suites" that
have identifiers like "ecdsa-2022" or "eddsa-v1" instead of the
typical parametric approach: "RSASSA-PKCS1-v1_5-SHA1". What we are
trying to do, in effect, is publish highly focused profiles (every
couple of years) of existing CFRG-approved crypto... and eliminate as
much optionality as possible because the developers in the market
verticals involved (universities, retail, supply chain, HR) often do
not have a deep understanding of cryptography, but use it anyway.

> I don't have much in the way of concrete suggestions for a
> way to improve matters, other than maybe it'd be a plan to
> require a justification for each option when stuff gets to
> RG last call or something.

There are at least two levels to this discussion. The first is how
much optionality to have in the cryptographic primitives. The second
is how much optionality to expose to non-expert developers in
"cryptographic suites" and software libraries.

The VCWG is focused on the second item, presuming that CFRG/NIST/FIPS
is going to continue to pump out algorithms with large amounts of
parametric variability. In effect, we're trying to contain the
parameterization at the first layer (CFRG approved algorithms and
parameters), at the second layer (through the use of highly
constrained cryptographic suites).

So, this raises a number of questions:

Can "we" come to ground on what an appropriate minimal set of
parameters is for, as an example, a particular type of Elliptic Curve
digital signature algorithm (to address 80% of the use cases) for a
given period of time (and publish that as a "cryptography suite")?
That is, can we say "For the year 2022, we believe these fixed
parameters for ECDSA are good enough for 80% of the use cases" and
then revisit the parameters again in 2027 and publish a new
cryptographic suite definition? For example, P-256 seems like it could
meet 80% of the use cases in the market this year? If not, what about
P-384? If not that, what about P-521? If we fail there, perhaps we say
the ECDSA cryptosuite MUST support both P-256 and P-521 and call THAT
the cryptographic suite for ECDSA for 2022?

Do we think we can get to an "asymmetric-signature-2022" cryptography
suite? If so, would that be EdDSA w/ Ed25519? or would we pick ECDSA
since EdDSA has a bit to go to get to NIST/FIPS compliant HSMs? Do we
think we could get to a "recommended-signature-2022"?

I fully realize how heated these sorts of debates could become, but if
we can narrow the parameters for a given year (like safecurves did
from time to time) don't we increase both interoperability and safety?

We would love to see some debate in/guidance from CFRG on the topic. Thoughts?

-- manu

[1]https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html#deliverables

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/