How does “eContentType of 40” work given the first two elements of an OID are encoded in one byte?
From: Daniel Van Geest <[email protected]> Date: Thursday, September 25, 2025 at 4:21 PM To: Michael Richardson <[email protected]>, "[email protected]" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: [lamps] Re: EUF-CMA and CMS users, RFC8366bis Michael, I'm not familiar with the document, but section 6.1 says. The IETF evolution of PKCS#7 is CMS [RFC5652]. A CMS-signed voucher, the default type, contains a ContentInfo structure with the voucher content. An eContentType of 40 indicates that the content is a JSON- encoded voucher. So it looks like you have your own content type assigned which is not id-data. RFC 5652 mandates that if the content type is not id-data then SignedAttributes MUST be present. So you might be covered already? Of course if the verifier doesn't actually fail decoding when the content type is not id-data and SignedAttributes is not present then that doesn't help. The one CMS implementation I'm familiar with doesn't appear to enforce this. BTW, the paragraph above refers to a ContentInfo structure, and then an eContentType field. ContentInfo doesn't contain an eContentType field, it contents a contentType field. I suppose one could go through the chaining logic like I just did, but perhaps the above paragraph should specify that the ContentInfo structure's contentType field's value is id-signedData. The ContentInfo's content field is then a SignedData whose encapContentInfo field has an eContentType of 40. Also, draft-vangeest-lamps-cms-euf-cma-signeddata has a PR which (I believe) will make it ready for WG adoption, though I don't know if that helps your situation. We're targeting publishing it as a BCP and it will say, among other things, to actually enforce the non-id-data/signedAttrs check. Regards, Daniel On 2025-09-25 8:15 p.m., Michael Richardson wrote: RFC8366 is being revised (it's in WGLC now!). It specified CMS-signed JSON. The recent KEM thread reminded me. The EUF-CMA concerns were in slides at: https://datatracker.ietf.org/meeting/121/materials/slides-121-lamps-cms-euf-cma-00 and https://datatracker.ietf.org/meeting/122/materials/slides-122-lamps-euf-cma-for-cms-signeddata-00 I'm not really sure how in the Voucher and Voucher Request that an attacker would be able to specify an arbitrary attacker-chosen message, however, it seems prudent to specify the work-around. An attacker can do the re-arrange attack. (Back in 2017 when we developed it, we were just barely able to cross out PKCS7 and say CMS. And we couldn't get to JOSE at the time. Since then, we have JOSE and COSE signed versions in other documents) My understanding is that if we write down that SignedAttributes are mandatory that the problem is solved: https://www.ietf.org/archive/id/draft-vangeest-lamps-cms-euf-cma-signeddata-01.html#name-always-never-use-signedattr We didn't say anything in RFC8366 about this. That CMS verifiers SHOULD all be willing to accept that variation already, so I think that signers can just unilaterly switch. Verifiers may need to be tolerant for a period of time, although deployment is not widespread, and the trend is towards JWS and COSE. Since we (LAMPS) did not (yet) adopt draft-vangeest-lamps-cms-euf-cma-signeddata, I'm not sure if that's a good enough reference to reference for the full explanation. I would be very happy if someone could suggest two sentences that captures it all... a nice WGLC comment. Hey: review draft-ietf-anima-rfc8366bis entirely! -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Spasm mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Spasm mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
