Anders, Yes, the X.509 certificate data *must* be bstr-encoded because it uses a different encoding mechanism. My point about the C509 certificate data is that bstr-embedding it also has benefits to users, including separating concerns of handling C509 data from decoding/validating it and avoiding duplicate decoding by different entities. Existing CBOR libraries already provide optimized APIs to avoid resource duplication for bstr-embedded CBOR. The only penalty is the additional bstr head size, which for the examples in the C509 doc would be 2-3 additional bytes per certificate.
I'm not suggesting that these C509 certificates must always be bstr-embedded, just when contained within the "COSE_C509" structure used in COSE headers. This would allow a COSE decoder to not need to also and always be a C509 decoder/validator to handle "c5c" and "c5b" headers. This especially applies to situations where the COSE decoder logic is "yes I see the headers are there and I don't care about them right now". Using bstr-embedding also allows a simplified COSE handler to do things like generate and compare c5t header values without needing to care about decoding C509 at all, because the thumbprint hash is made on the encoded C509 data without concern for its contents. Brian S. > -----Original Message----- > From: Anders Rundgren <[email protected]> > Sent: Sunday, March 9, 2025 1:03 AM > To: Göran Selander <[email protected]>; Sipos, > Brian J. <[email protected]>; [email protected] > Subject: Re: [COSE] Re: [EXT] I-D Action: draft-ietf-cose-cbor-encoded-cert- > 13.txt > > APL external email warning: Verify sender [email protected] > before clicking links or attachments > > On 2025-03-07 13:50, Göran Selander wrote: > > Thanks Brian, great feedback and proposal! > > > > I recorded it as issue #222 <https://github.com/cose-wg/CBOR- > certificates/issues/222>. > > > > Let’s think this over soon so we could make the update before WGLC. > > The reason for bstr-ing X.509 certificates is because they are in ASN.1. > > Anders > > > > > Göran > > > > *From: *Sipos, Brian J. <[email protected]> > > *Date: *Tuesday, 4 March 2025 at 15:28 > > *To: *[email protected] <[email protected]> > > *Subject: *[COSE] Re: [EXT] I-D Action: > > draft-ietf-cose-cbor-encoded-cert-13.txt > > > > Authors, > > I think the C509 contents and definition are in good shape. One comment / > suggestion that I ran into when handling C509 data is related to the current > "direct" CBOR form of the C509 certificate when carried in a COSE header as > either "c5c" or "c5b" (and referenced by a "c5u"). > > > > The current definition of this container is > > COSE_C509 = C509Certificate / [ 2* C509Certificate ] which > > requires the handlers of the container to either decode the C509 contents > itself or use a CBOR decoder to skip over the "C509Certificate" items (which > likely contain deeply nested structure and is not a trivial activity [1] and > not > universally supported by CBOR libraries). > > > > This is in contrast to the X.509 container, defined in RFC 9360 as > > COSE_X509 = bstr / [ 2*certs: bstr ] Which relieves the > > handler of that item of caring what are the exact contents of the contained > bstr item(s). > > > > Would it seem sensible to rework the C509 container as (something equivalent > to) the following? > > COSE_C509 = C509CertData / [ 2* C509CertData ] > > C509CertData = bstr .cbor C509Certificate This relieves the > > handler of the container from needing to decode the bstr items, but also > allows an aware handler to validate the embedded CBOR item just as is required > today. The expense is the bstr wrapper item, which for small-ish certificates > would be an overhead of 2-3 bytes per certificate. > > > > I understand that one of the main purposes of C509 is to reduce encoded > > size, > but I think the current direct container contents also forces handlers to > expend > processing/memory resources to skip or decode the certificate contents even if > that handler just passes the encoded certificate along to different > entities/layers. > > > > Any thoughts about this alternative "bstr embedded" container? > > Thanks, > > Brian S. > > > > [1] > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2Flaurencelundblade%2FQCBOR%2Fblob%2F83c4af09d3752afa64ae66 > e2a3 > > 382192bf682541%2Finc%2Fqcbor%2Fqcbor_decode.h%23L1014C1- > L1014C28&data= > > > 05%7C02%7Cgoran.selander%40ericsson.com%7C22cead1a3f31436834f308dd5 > b28 > > > dc2c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63876695324713 > 1877%7 > > > CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > MCIsIlA > > > iOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o > Cl00 > > L4uj%2F4dwioCXXZPGOA%2Fmn7ISju6lClbdS6uyys%3D&reserved=0 > > > <https://github.com/laurencelundblade/QCBOR/blob/83c4af09d3752afa64ae6 > > 6e2a3382192bf682541/inc/qcbor/qcbor_decode.h#L1014C1-L1014C28> > > > > > >> -----Original Message----- > >> From: [email protected] <[email protected]> > >> Sent: Monday, March 3, 2025 2:56 PM > >> To: [email protected] > >> Cc: [email protected] > >> Subject: [EXT] [COSE] I-D Action: > >> draft-ietf-cose-cbor-encoded-cert-13.txt > >> > >> APL external email warning: Verify sender > >> [email protected] before clicking links or attachments > >> > >> Internet-Draft draft-ietf-cose-cbor-encoded-cert-13.txt is now > >> available. It is a work item of the CBOR Object Signing and Encryption > >> (COSE) > WG of the IETF. > >> > >> Title: CBOR Encoded X.509 Certificates (C509 Certificates) > >> Authors: John Preuß Mattsson > >> Göran Selander > >> Shahid Raza > >> Joel Höglund > >> Martin Furuhed > >> Name: draft-ietf-cose-cbor-encoded-cert-13.txt > >> Pages: 77 > >> Dates: 2025-03-03 > >> > >> Abstract: > >> > >> This document specifies a CBOR encoding of X.509 certificates. > >>The > >> resulting certificates are called C509 Certificates. The CBOR > >> encoding supports a large subset of RFC 5280 and all certificates > >> compatible with the RFC 7925, IEEE 802.1AR (DevID), CNSA, RPKI, > >>GSMA > >> eUICC, and CA/Browser Forum Baseline Requirements profiles. When > >> used to re-encode DER encoded X.509 certificates, the CBOR > >>encoding > >> can in many cases reduce the size of RFC 7925 profiled > >>certificates > >> with over 50% while also significantly reducing memory and code > >>size > >> compared to ASN.1. The CBOR encoded structure can alternatively > >>be > >> signed directly ("natively signed"), which does not require re- > >> encoding for the signature to be verified. The TLSA selectors > >> registry defined in RFC 6698 is extended to include CBOR > >> certificates. The document also specifies C509 Certificate > >>Signing > >> Requests, C509 COSE headers, a C509 TLS certificate type, and a > >>C509 > >> file format. > >> > >> The IETF datatracker status page for this Internet-Draft is: > >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat > >> atracker.ietf.org%2Fdoc%2Fdraft-ietf-cose-cbor-encoded-cert%2F&data=0 > >> > 5%7C02%7Cgoran.selander%40ericsson.com%7C22cead1a3f31436834f308dd5b > 28 > >> > dc2c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63876695324715 > 6492% > >> > 7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDA > wMCIsI > >> > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata > =7z > >> oUeBAQCP60vezGHIx2R40XiPnB3pYj44AsgzqmKHs%3D&reserved=0 > >> <https://datatracker.ietf.org/doc/draft-ietf-cose-cbor-encoded-cert/> > >> > >> There is also an HTML version available at: > >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > >> .ietf.org%2Farchive%2Fid%2Fdraft-ietf-cose-cbor-encoded-cert-13.html& > >> > data=05%7C02%7Cgoran.selander%40ericsson.com%7C22cead1a3f31436834f3 > 08 > >> > dd5b28dc2c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63876695 > 32471 > >> > 70234%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLj > AuMDA > >> > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sd > >> > ata=Ir0FLLuv8LjL4LwUX69xQj2k%2Fy6wauvw%2BhFD%2BhXP4C4%3D&reserved > =0 > >> <https://www.ietf.org/archive/id/draft-ietf-cose-cbor-encoded-cert-13 > >> .html> > >> > >> A diff from the previous version is available at: > >> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Faut > >> hor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-cose-cbor-encoded-cer > >> t- > 13&data=05%7C02%7Cgoran.selander%40ericsson.com%7C22cead1a3f314368 > 3 > >> > 4f308dd5b28dc2c%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638 > 76695 > >> > 3247182721%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLj > >> > AuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C% > 7C% > >> > 7C&sdata=oBHjkj%2BBou2qw%2BSbnsde4g3YwKKU%2F6bbaJw8x2LR5iU%3D&r > eserve > >> d=0 > >> <https://author-tools.ietf.org/iddiff?url2=draft-ietf-cose-cbor-encod > >> ed-cert-13> > >> > >> Internet-Drafts are also available by rsync at: > >> rsync.ietf.org::internet-drafts > >> > >> > >> _______________________________________________ > >> COSE mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > > COSE mailing list -- [email protected] > > To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
