Daniel Van Geest <[email protected]> wrote: > 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?
Good point.
PS: SZTP depends upon 8366 too.
> 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.
Seems like maybe we just goofed in how we described things in 8366.
> 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
So I think that we do an informative reference to your document, even before
adoption, saying something like:
The attack described in [cms-euc-cma-signeddata] does not apply as
RFC5652 mandates that SignedAttributes MUST be present.
Implementers should check that their CMS library enforces this.
--
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]
