Daniel Van Geest <daniel.vange...@cryptonext-security.com> wrote:
> 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.
I didn't remember that SZTP (which uses RFC8366 vouchers as well) did some
other things with CMS. ... So I hope Kent will respond to your propposed
mitigations.
> 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.
:-)
I'm just glad to understand that I don't need to anything in RFC8366bis.
Thank you for your document.
--
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
