The slides at LAMPS today https://datatracker.ietf.org/meeting/122/materials/slides-122-lamps-euf-cma-for-cms-signeddata-00
relate to https://www.ietf.org/archive/id/draft-vangeest-lamps-cms-euf-cma-signeddata-01.html SZTP is mentioned in the slides, but I think it's really RFC8366. We are revising RFC8366 now, so we could include whatever mitigration required. Reading through draft-vangeest-lamps-cms-euf-cma-signeddata.w We use an eContentType of 43, being id-ct-animaJSONVoucher. My understanding from the cms-euf-cma document is that since we don't use id-data as the eContentType, that there may be nothing to do. I think we have no use of signed attributes. I could be wrong, because my reading of draft-vangeest-lamps-cms-euf-cma-signeddata is that we are supposed to Always Use them if we do not use id-data. 4.2. Always/Never use SignedAttributes in Your Protocol Individually update each protocol which use CMS to always require or forbid signed attributes. In particular, if an eContentType other than id-data is used, Section 5.3 of [RFC5652] requires that signed attributes are used. During verification, ensure that you are receiving the expected (non-id-data) eContentType and that signed attribues are present. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
