Cryptographic Message Syntax (CMS) Content Constraints Extension
RFC 6010
Yes
No Objection
Recuse
Note: This ballot was opened for revision 06 and is now closed.
(Tim Polk; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
1. Introduction The CMS SignedData [RFC5652] construct is used to sign many things, including cryptographic module firmware packages [RFC4108] and certificate management messages [RFC5272]. Similarly, the CMS AuthenticatedData and CMS AuthEnvelopedData constructs provide authentication, which can be affiliated with an originator's static public key. CCC information is conveyed via an extension in a This is the first use of the CCC acronym, so it should be expanded here (not not 2 pagraphs below). certificate or trust anchor object that contains the originator's or signer's public key. Is the extra complexity of having absenceEqualsUnconstrained worth it?
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss, No Objection) No Objection
[Updated: Removed original 12. Two new comments.] Here are my comments on this draft: 13) In this I-D the reference for ASN.1 in '97, but in PKIX/SMIME New ASN.1 it's '02. 14) Sec 3.1: r/if the certification path is valid for a signed CMS object/if the certification path is valid for a given context.
(Stewart Bryant; former steering group member) No Objection
(Russ Housley; former steering group member) Recuse