Re: [CFRG] options == bad?

[Kai Mindermann <[e-mail]>]

Hi,

sounds a lot like you are going for some of the ideas I presented/drafted in https://datatracker.ietf.org/doc/html/draft-kaimindermann-securecryptoconfig a while ago.
There is also a demonstration implementation done here: https://github.com/secureCryptoConfig/secureCryptoConfigInterface 

Its of very big importance to leave as much of the decisions regarding crypto parameters to the crypto experts/libraries and only expose the needed parameters.
(Of course, there can also still be an interface that allows all the possible parameters for power users / experts).

What I have no concrete idea about yet are tunable parameters, e.g. some of the argon2id parameters may depend on the runtime environment. (see https://datatracker.ietf.org/doc/html/draft-kaimindermann-securecryptoconfig#section-6.2.5)
Also, regarding hashing output formats, there seems to be no standard yet in relation/similar to COSE/JOSE, right? I am aware of https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md though.



Mit freundlichen Grüßen / Best regards
Kai Mindermann

-- 
Kai Mindermann
Senior Consultant
M [phone]
 
[e-mail]
www.ic-consult.com
 
iC Consult Gesellschaft für Systemintegration und Kommunikation mbH
Standort: Zettachring 8a | 70567 Stuttgart | Germany
Verwaltung: Huyssenallee 99-103 | 45128 Essen | Germany
Geschäftsführer: Dr. Andreas Neumann
HRB 116170 Amtsgericht München

-----Ursprüngliche Nachricht-----
Von: CFRG <[e-mail]> Im Auftrag von Manu Sporny
Gesendet: Donnerstag, 18. August 2022 16:40
An: Stephen Farrell <[e-mail]>
Cc: [e-mail]
Betreff: Re: [CFRG] options == bad?

[Sie erhalten nicht h?ufig E-Mails von [e-mail]. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]

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/

_______________________________________________
CFRG mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/cfrg