Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com> Subject: Protocol Action: 'Additional CMS Revocation Information Choices' to Proposed Standard The IESG has approved the following document: - 'Additional CMS Revocation Information Choices ' <draft-turner-additional-cms-ri-choices-06.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-turner-additional-cms-ri-choices-06.txt
Technical Summary The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information choices. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP). Working Group Summary This I-D was forwarded to the S/MIME WG, but there was not enough interest to support adopting it as a WG item. Nevertheless, there were a few key members who provided comments off-list on the I-D. The discussions on the draft centered on the handling of unsigned SCVP mechanism; there was no controversy w.r.t. the OCSP mechanism. The changes to SCVP mechanism include allowing the request to be optionally included, requiring that the SCVP response be signed, and bolstering the security considerations. Document Quality This I-D is short at 8 pages (2 pages of technical content). There are no known implementations at this time. Personnel Carl Wallace is the document Shepherd. Tim Polk is the responsible Security Area AD. RFC Editor Note In section 6, please make the following substitution: OLD This document makes use of object identifiers. These object identifiers are defined in an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates. NEW This document makes use of object identifiers. These object identifiers are defined in an arc delegated by IANA to the PKIX Working Group. The current contents of the arc are located here: http://www.imc.org/ietf-pkix/pkix-oid.asn They were obtained by sending a request to firstname.lastname@example.org. When the PKIX WG closes, this arc and registration procedures will be transferred to IANA. No further action by IANA is necessary for this document or any anticipated updates.