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]>: > > > On Mar 8, 2023, at 1:13 PM, Christopher Allen < > [email protected]> wrote: > > On Wed, Mar 8, 2023 at 1:04 PM Laurence Lundblade <[email protected]> > wrote: > >> On Mar 8, 2023, at 12:50 PM, Christopher Allen < >> [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 — 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] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
