Cryptographic Message Syntax (CMS) Content Constraints Extension
RFC 6010

Note: This ballot was opened for revision 06 and is now closed.

(Tim Polk) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

(Alexey Melnikov) No Objection

Comment (2010-05-08 for -)
No email
send info
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) No Objection

(Sean Turner) (was Discuss, No Objection) No Objection

Comment (2010-05-19)
No email
send info
[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.

(Russ Housley) Recuse