On Wed, Mar 8, 2023 at 9:50 AM Laurence Lundblade <[email protected]> wrote:
> I’m redirecting this to the COSE work group. > I appreciate that. > There are other groups like the CRFG <https://irtf.org/cfrg> that might > be even better. The CBOR work group is not the right place for it. > We'd brought it up in the CBOR group as we'd like to see them take up, or at least support, the Gordian Envelope internet draft https://datatracker.ietf.org/doc/draft-mcnally-envelope/ as a possible graph store (both labeled nodes and labeled edges are options) alternative. Gordian Envelope does not define any public-key cryptography, it only has one cryptographic function, SHA-256, which is used to order the hash tree. I'd like to avoid CFRG for Gordian Envelope as it is really about a structure. That being said, someone in the CBOR group suggested it needed cryptographic agility in case SHA-256 was deprecated, thus my post to the group. We'd prefer to have just iterate to a known but unused tag for v2 should that happen, rather than support legacy-style cryptographic agility approaches. This is what Wireguard is now doing — in effect one suite. I have a few comments: > > COSE is not an end-end system with guaranteed interoperability. It has to > be profiled to interoperate. It is designed to serve a huge range of use > cases so it has a lot of options. > > COSE mostly does take a cipher suite approach as much as it can. The main > author is no longer with us to discuss this, but I suspect it is for some > of the reasons you give. I mostly like cipher suites myself. > I agree that COSE has a number of nice features over JOSE, but it does inherit some architectural challenges from it. The biggest challenge for our purposes, it still signs a blob, and really is designed more for point-to-point between two parties, rather than data at rest that may reside with many different holders (in our educational claims case, the data from an educational institution about a student may be held by a student loan service, a job service, a sub-contractor, a primary contractor, an insurance company, etc.) I particularly like your statement in the CBOR list about the underlying dCBOR format that we have built reference libraries for (and a spec now at https://datatracker.ietf.org/doc/draft-mcnally-deterministic-cbor/ ) On Tue, Mar 7, 2023 at 9:59 AM Laurence Lundblade <[email protected]> wrote: > The things that convinced me about dCBOR being necessary for the use case > were: > - data at rest > - very complicated protocol > - desire to byte-compare serialized data > - independently (separate apps, servers and clients) encoding data to be > compared and signed There is no reason why a COSE object couldn't sign a Gordian Envelope as its blob, or a Gordian Envelope wrap a CBOR object, but in both cases, you lose some features. > 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 don’t think dCBOR has anything to do with crypto agility so I’m not sure > why you mention it. > You are correct, dCBOR is used by Gordian Envelope, and that was why I brought up my article https://www.blockchaincommons.com/musings/musings-agility/ about concerns with cryptographic-agility-focused architectures. I primarily work on EAT > <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat> a derivative > of CWT/JWT. EAT is also intended for lots of use cases and to be profiled. > Your comments here are making be consider adding text that recommends that > EAT profiles allow only very a limited numbers of algorithms. > You might want to look at the text in W3C Verifiable Claims 1.0 at §5.2 "Protecting Application Developers" https://www.w3.org/TR/vc-data-integrity/#protecting-application-developers which has some good language. I'd love to see what you come up with! Thanks again for continuing this discussion! -- Christopher Allen
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
