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
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
