Hi, I would make a substantial distinction between these two: 1) IETF COSE work, COSE libraries and the like 2) End applications, standards that drive end-end use cases like WIFi, FIDO and Bluetooth and SDOs that have interop logo programs
For example to use the FIDO logo in your FIDO product your product must pass an interoperability test against many other products old and new. This testing results in pretty good implementation of crypto agility in FIDO. It motivates the design of the FIDO protocol to do a thorough job of crypto agility. The IETF doesn’t have a logo program or any other means of enforcement or motivation. The IETF doesn’t have the legal, financial and market position to do this. To me COSE and COSE libraries are mostly flexible tool kits for the construction of end-end applications and other protocols. COSE needs to be profiled to give guaranteed interoperability. The success or failure of crypto agility seems more tied to the end use case than it does to COSE or COSE libraries. Even the app ecosystem in which the protocol runs helps. For example, the Apple ecosystem is better at SW updates, so crypto agility will work for apps and protocols in it than elsewhere. Granted, if we do a bad job designing COSE, HPKE or EAT, it will make it harder for applications that make use of COSE, HPKE and EAT to achieve successful crypto agility, but we don’t have control in the end. LL > On Mar 11, 2023, at 9:50 PM, AJITOMI Daisuke <[email protected]> wrote: > > Hello, > > I read the article about cryptoagility with interest. I'd like to make some > comments. > > In recent work here, COSE HPKE > <https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/> is however going for > the full agility that you criticize. > > I'm one of the people who insisted on making COSE-HPKE be more > cryptoagility-oriented, but on the other hand, I'm also an implementor of > PASETO <https://github.com/paseto-standard/paseto-spec>, which was born out > of the criticism of the cryptoagility-oriented JOSE. > > PASETO is a platform-agnostic security token spec, which is designed as a > versioned protocol > <https://paragonie.com/blog/2018/03/paseto-platform-agnostic-security-tokens-is-secure-alternative-jose-standards-jwt-etc>, > which is an opposite of the cryptoagility approach. At least, I like PASETO > very much because it's well designed and easy-to-implement. > > PASETO v1/v2* were released in 2018 and then v3/v4* were released in 2021 > (*The differences between v1/v3 and v2/v4 is whether the cryptographic > algorithm is NIST compliant or not). After that, early in 2022, v1/v2 were > deprecated officially (at least, on the official reference implementation). > > So, did the version update go well? > > At least as far as I can see, it does not appear to have worked. In 2019, > Okta announced the PASETO v2 support but I have not heard the version updated > after that. Replit, which is a cloud IDE provider, adopted PASETO in 2022, > but the adopted version was v2, which had already been deprecated. My paseto > implementation seems to be used by replit SDK and has been downloaded > thousands times per day but it means that the used version is v2 > (deprecated). The other day, I found an article introducing PASETO written in > 2023 but the sample code in the article was based on v2... > > I don't know yet whether the PASETO attempt was a success or a failure, but > at least at this point I feel that the version update is not easy and cannot > attract the attention of OSS developers and communities as much as the first > release does. Actually, the number of v3/v4 implementations is fewer than > v1/v2 and few PASETO implementations remove v1/v2 support. > > On the other hand, JOSE appears to be more popular and successful than PASETO > despite the failure that its spec has vulnerabilities which allows downgrade > attacks (alg:none, etc.). It would be because many security practitioners and > researchers check the specs and implementations and the security BCPs are > maintained and updated continuously. Furthermore, recently, I feel that the > number of apps using EdDSA(curve25519) based JWT instead of RS256 or ES256 > are increasing. It would be one of the evidences the cryptoagility feature is > working well. > > Of course, it is clear that there are many flaws in the cryptoagility > approach as you mentioned. > > IMHO, one of the best current practices I'm thinking of is to make > standardized versatile crypto data container specs (like JOSE/COSE) be > cryptoagility-oriented as much as possible and be widely spread, and to make > the upper layer applications using these crypto data container specs use very > restricted number of algorithms or adopt versioning to mitigate the drawbacks > of the cryptoagility approach. This might be the same as the EAT thing that > Laurence mentioned. > > Shortly speaking, it means that this kind of layering is important. > > As demonstrated by PASETO, the version update is not easy for a versatile > crypto data container layer (like JOSE, COSE, or PASETO), which was > demonstrated by PASETO, but on the other hand, it's obvious that it's > relatively easy for the version of a specific application to be updated. > > -- > AJITOMI Daisuke > > 2023年3月9日(木) 6:22 Laurence Lundblade <[email protected] > <mailto:[email protected]>>: > > >> On Mar 8, 2023, at 1:13 PM, Christopher Allen >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Wed, Mar 8, 2023 at 1:04 PM Laurence Lundblade <[email protected] >> <mailto:[email protected]>> wrote: >>> On Mar 8, 2023, at 12:50 PM, Christopher Allen >>> <[email protected] >>> <mailto:[email protected]>> wrote: >>> I was aware that COSE RFC 9338 had an optional detached form, but I wasn't >>> able to find a specific section about it. Is it defined further by another >>> RFC or internet-draft? >> Search for “detached” in RFC 9052. >> >> Thanks. Though I think it is more than just "not prominent", it is almost >> hidden there. Even more so in RFC 9228. (IMHO it at least deserved a >> sub-section or appendix with examples.) > > Yeah, COSE is a pretty large standard. It could be filled in more, more > examples, more implementations. It’s getting there though. > > >> There are not really any rules for detached stuff in 9052. It might be >> transmitted parallel with the COSE_Sign or not. It might be data at rest. It >> might not be CBOR. If it is CBOR it doesn’t have to be any type of CBOR. It >> might be reconstructed from other data in some deterministic way… The only >> thing is that the payload verifier must be able to somehow have the same >> bytes as the signer. This is a good thing as it allows the application to do >> what ever it needs to do. In your case it will be dCBOR. :-) >> >> That makes sense. >> >> Is there an exemplary library or code base out there that implements >> detached COSE, in particular with text cases and test vectors that we could >> use to experiment with, or to build our own library in rust? > > https://github.com/laurencelundblade/t_cose > <https://github.com/laurencelundblade/t_cose> — see > short_circuit_self_detached_content_test(). I believe the SUIT guys have also > done a lot of implementation of detached with t_cose > > LL > _______________________________________________ > COSE mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/cose > <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
