Jim Schaad <[email protected]> wrote: > In addition, even if one assigns the content type of OCTET STRING to > this content type when signing using PKCS #7 and no ASN.1 type for CMS > (which is what happens for id-data), the result is that there is > absolutely no difference between the resulting object if you encode by > PKCS #7 or CMS.
Huh. well, there is cmsVersion=1 vs cmsVersion=3, but it's true that there
are some steps in between.
We were further advised that we needed to leave RFC2315 behind in order to be
technically able to use newer algorithms. As one advances through the
documents it seemed that we would be better off with the latest
specification.
Yet, we have push back from some quarters that have RFC2315 (cmsVersion=1)
libraries that they want to use.
> This paragraph should be removed and it should talk about something
> else instead.
Which paragram exactly? Do you mean:
} Note that Section 5.1 of [RFC5652] includes a discussion about how to
} validate a CMS object which is really a PKCS7 object (cmsVersion=1).
} Intermediate systems (such the BRSKI Registrar) which might need to
} evaluate the voucher in flight MUST be prepared for such an older
} format. No signaling is necessary, as the Manufacturer knows the
} capabilities of the pledge, and will use an appropriate format
} voucher for each pledge.
in general, we include CMS format as an exemplar; many of want to move on to
JOSE and COSE signed artifacts... Is that now clear for you?
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
