Hi, I am all for work continuing to improve CWT and expand their use cases, but I think CWTs are mostly useful to request other CWTs. CWTs are great, flexible, and can replace certificates in some places, but I doubt most deployments relying on PKI will ever change to anything else.
What I think C509 certificates needs is a CSR format allowing all types of C509 certificates to be requested. I don't think CWT will or should support that much of RFC 5280. An essential part here is to enable easy implementation in an existing CA. A CA needs to be able to create a X.509 using their existing processes and code and then relatively simple transform it to C509. Similarly a CA need to relatively easily transform the C509 CSR to a DER encoded CertificationRequestInfo and process that with existing processes and code. One could insert a CBOR encoded CertificationRequestInfo in a CWT, but I don’t think it that make much sense as it would only be good to request a C509 certificate. Cheers, John From: Laurence Lundblade <[email protected]> Date: Thursday, 27 May 2021 at 20:01 To: Carsten Bormann <[email protected]> Cc: John Mattsson <[email protected]>, [email protected] <[email protected]> Subject: Re: [COSE] C509 Certification Request (CSR) On May 26, 2021, at 3:45 AM, Carsten Bormann <[email protected]<mailto:[email protected]>> wrote: I think it would be good to check our agreement in this group that having a C509-shaped CSR is not a replacement for or an obstacle to developing requests for CWT-shaped signed assertions. This is the main thing for me. We must not close off pure CBOR CSRs and Certs. We want to eventually get to a place where some one can run a system with no ASN.1/DER. I would write drafts for this stuff now, except I’m committed to the EAT draft and need to finish that. I’d also do implementations. My ctoken<https://protect2.fireeye.com/v1/url?k=19dfcb87-4644f2aa-19df8b1c-8692dc8284cb-ace8aa622a18ecc1&q=1&e=647edb7b-57e5-4503-90b2-b41a3bc1d037&u=https%3A%2F%2Fgithub.com%2Flaurencelundblade%2Fctoken> implementation of CWT and EAT is designed so this stuff can be easily added to it, but again I need to finish EAT. The implementation is also so the code is shared between CWT, EAT and eventually certs and CSRs. You could even do an (incompatible) revision of the FIDO protocol that would re use this code. I kind of agree with Michael’s point that it is wasteful to have three formats (PKCS 10, CWT-based CSR and the thing in between proposed here). I also see any transition to a pure CBOR/CWT infrastructure as very long involved with many drafts being authored. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
