> On Mar 8, 2023, at 12:10 PM, Christopher Allen > <[email protected]> wrote: > > On Wed, Mar 8, 2023 at 9:50 AM Laurence Lundblade <[email protected] > <mailto:[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/ > <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.
OK. No worries. > > 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.) Have you looked at detached payloads in COSE? It’s not very prominent in the RFC, but it’s definitely there and works. It allows for signing something that is not included in the COSE message. It can produce nice compact CBOR structures that just hold the signature bytes, the algorithm ID and maybe a key ID. The SUIT draft makes very heavy use of detached payloads. t_cose supports them. With detached payloads you pretty much get to make up your own rules for what the detached payload is. The only requirement is that the verifier some how have the same payload bytes that signer signed. You seem to understand that requirement :-) LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
