Hi Michael, That list of RFCs was created from a package of all RFCs, a grep for "id-data", and some tired eyeballs, so I would not be surprised if it's incomplete. Any additions or modifications that anyone has would be appreciated.
What we were looking for was any RFC that uses the id-data OID for the eContentType field of the EncapsulatedContentInfo type within the SignedData type. The problem described in our draft theoretically only applies to protocols which use id-data as the eContentType value. For any other eContentType value, RFC 5652 mandates the use of signed attributes and so removal of the signed attributes should be detected. I say "theoretically" and "should be" because an implementation may be lax in its parsing and either accept a non-id-data eContentType which doesn't have signedAttributes, or might not check that the eContentType is the correct value for the protocol (allowing them to parse id-data content without signed attributes). So this may be something the BCP needs to call out. With that said, RFC8366 uses the id-ct-animaJSONVoucher content type, and so was not intended to be included in the list in the draft. On the other hand, SZTP (RFC8572) allows the content type to be id-ct-sztpConveyedInfoXML, id-ct-sztpConveyedInfoJSON, or id-data, so it was included in the list in the draft. We are far from being experts on the corpus of CMS SignedData-related RFCs and so will rely on the group for further feedback in this area. If we write a BCP and it goes beyond "don't use the id-data content type; if you do use id-data, here are some checks you should do," we may need to call for an additional author. Daniel On 2025-03-19 8:41 a.m., Michael Richardson wrote: 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><mailto:mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ Spasm mailing list -- sp...@ietf.org<mailto:sp...@ietf.org> To unsubscribe send an email to spasm-le...@ietf.org<mailto:spasm-le...@ietf.org>
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
