Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
RFC 5940
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2015-10-14
|
06 | (System) | Notify list changed from housley@vigilsec.com, turners@ieca.com to (None) |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Jari Arkko |
|
2012-08-22
|
06 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
|
2010-08-20
|
06 | Amy Vezza | [Note]: 'RFC 5940' added by Amy Vezza |
|
2010-08-20
|
06 | Amy Vezza | State changed to RFC Published from RFC Ed Queue by Amy Vezza |
|
2010-08-19
|
06 | (System) | RFC published |
|
2010-06-10
|
06 | (System) | IANA Action state changed to No IC from In Progress |
|
2010-06-10
|
06 | (System) | IANA Action state changed to In Progress |
|
2010-06-10
|
06 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
|
2010-06-10
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2010-06-10
|
06 | Cindy Morgan | IESG has approved the document |
|
2010-06-10
|
06 | Cindy Morgan | Closed "Approve" ballot |
|
2010-06-10
|
06 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
|
2010-06-04
|
06 | (System) | Removed from agenda for telechat - 2010-06-03 |
|
2010-06-03
|
06 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
|
2010-06-03
|
06 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
|
2010-06-03
|
06 | (System) | New version available: draft-turner-additional-cms-ri-choices-06.txt |
|
2010-06-03
|
06 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded by Gonzalo Camarillo |
|
2010-06-03
|
06 | Dan Romascanu | [Ballot discuss] I have a similar concern to the one that is being expressed by Jari, and supplementary to this I would like to discuss … [Ballot discuss] I have a similar concern to the one that is being expressed by Jari, and supplementary to this I would like to discuss the reasons for the WG taking upon itself the administration of the OID space. At least in OPS we ran away from undertaking such tasks, one of the reasons being that WGs are not supposed to be perenial. Then where are the OIDs listed, so that questions liek the ones asked by Jari about the id-ri nodes allocation can be avoided? |
|
2010-06-03
|
06 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
|
2010-06-03
|
06 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
|
2010-06-03
|
06 | Adrian Farrel | [Ballot comment] I stumbled a bit over some (very) small points of language. If you have a mind to, a little polish might enhance the … [Ballot comment] I stumbled a bit over some (very) small points of language. If you have a mind to, a little polish might enhance the reader-experience. Also one question about tracking codepoints. No need to discuss any of these nits with me. Just "Do The Right Thing" (TM), and move on. 1. Are you adding choices as you say in the document title, or formats as you say in the Abstract? I think there is only choice to be made from a list of formats; and you are adding some more formats that can be included in the list. This choice/format seems to run through the document. 2. In the Introduction | The intent | is to provide information sufficient to determine whether the | certificates and attribute certificates carried elsewhere in the CMS | protecting content are revoked. a. Is this a compound noun: the "CMS protecting content", i.e. the CMS content that provides protection. Or a compound adjective applied to a noun: the content that protects CMS. Or adjectival: the certificate are carried elsewhere in the CMS and protect content. I think you can give this just one meaning by re-wording. b. "are revoked": is this "have been revoked", "are in a revoked state", or "are to be revoked"? 3. In the Introduction | However, there may be more | revocation status information than necessary or there may be less | revocation status information than necessary. Is this *really* helpful? Necessary for what? The information may be where? Why is this a "however"? 4. In the Introduction | This document specifies two | other formats: Online Certificate Status Protocol (OCSP) responses | [OCSP] and Server-Based Certificate Validation Protocol (SCVP) | responses [SCVP]. | | Section 2 discusses the RevocationInformation structure. Section 3 | defines a mechanism to carry OCSP responses. Section 4 defines a | mechanism to carry SCVP requests and responses. Second para says SCVP req and rsp. First para only rsp. 5. Section 6 | 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. Where are these object identifiers tracked to stop accidental double allocation and to allow reference back to defining documents? Does the PKIX WG have a registry? Why not use an IANA registry with the delegated allocation policy? |
|
2010-06-03
|
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2010-06-02
|
06 | Jari Arkko | [Ballot discuss] The document says: For convenience, the ASN.1 definition of the RevocationInfoChoices type from [CMS] is repeated here: ... The … [Ballot discuss] The document says: For convenience, the ASN.1 definition of the RevocationInfoChoices type from [CMS] is repeated here: ... The revocation information choices are defined under the following object identifier arc: id-ri OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) ri(16) } ... 3. OCSP Response ... id-ri-ocsp-response OBJECT IDENTIFIER ::= { id-ri 2 } ... 4. SCVP Request and Response ... id-ri-scvp OBJECT IDENTIFIER ::= { id-ri 4 } Here it is unclear to me if THIS document is the first one to introduce id-ri, or if the id-ri definition is part of the "convenience copy" from [CMS]. This should be clarified. After some number of greps and Google searches I cannot find an RFC that would be doing this, or a registry defining the name space under id-ri. Secondly, if this document is definining id-ri, why does the numbering go from 2 to 4, skipping 1 and 3? I could be missing something obvious here The reference section has this RFC: [CMS-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, May 2010. Which does not exist. Perhaps its being published, but then its certainly not from May 2010. I would not normally complain about this, but the inability to find this reference prevented me from doing an effective search of the references to find the proper ASN.1. |
|
2010-06-02
|
06 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
|
2010-06-02
|
06 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded by David Harrington |
|
2010-06-02
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
|
2010-06-01
|
06 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
|
2010-06-01
|
06 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded by Stewart Bryant |
|
2010-06-01
|
06 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded by Peter Saint-Andre |
|
2010-06-01
|
06 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
|
2010-05-31
|
06 | Russ Housley | [Ballot Position Update] New position, Recuse, has been recorded by Russ Housley |
|
2010-05-27
|
06 | Sean Turner | [Ballot Position Update] New position, Recuse, has been recorded by Sean Turner |
|
2010-05-27
|
06 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded for Tim Polk |
|
2010-05-27
|
06 | Tim Polk | Ballot has been issued by Tim Polk |
|
2010-05-27
|
06 | Tim Polk | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk |
|
2010-05-26
|
06 | Alexey Melnikov | [Ballot comment] 4. SCVP Request and Response Unlike OSCP, SCVP permits unprotected and protected responses, where protected responses can be digitally signed or … [Ballot comment] 4. SCVP Request and Response Unlike OSCP, SCVP permits unprotected and protected responses, where protected responses can be digitally signed or include message authentication codes. While this provides more flexibility, it complicates when an SCVP response can be validated by entities other I think the word "implementations" is missing after "complicates". than the entity that generated the SCVP request. |
|
2010-05-26
|
06 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
|
2010-05-26
|
06 | Alexey Melnikov | Created "Approve" ballot |
|
2010-05-11
|
05 | (System) | New version available: draft-turner-additional-cms-ri-choices-05.txt |
|
2010-05-10
|
06 | Tim Polk | Placed on agenda for telechat - 2010-06-03 by Tim Polk |
|
2010-05-10
|
06 | Tim Polk | Note field has been cleared by Tim Polk |
|
2010-05-07
|
04 | (System) | New version available: draft-turner-additional-cms-ri-choices-04.txt |
|
2010-04-27
|
06 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Charlie Kaufman. |
|
2010-04-19
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2010-04-16
|
06 | Amanda Baber | IANA comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2010-03-24
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
|
2010-03-24
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
|
2010-03-22
|
06 | Amy Vezza | Last call sent |
|
2010-03-22
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
|
2010-03-22
|
06 | Tim Polk | State Changes to Last Call Requested from Publication Requested by Tim Polk |
|
2010-03-22
|
06 | Tim Polk | Last Call was requested by Tim Polk |
|
2010-03-22
|
06 | (System) | Ballot writeup text was added |
|
2010-03-22
|
06 | (System) | Last call text was added |
|
2010-03-22
|
06 | (System) | Ballot approval text was added |
|
2009-12-10
|
06 | Russ Housley | 1.a - Carl Wallace is the Shepherd. He's personally reviewed the document and knows it is ready for IESG publication. 1.b - The document has … 1.a - Carl Wallace is the Shepherd. He's personally reviewed the document and knows it is ready for IESG publication. 1.b - The document has been reviewed by key IETF members. There are no concerns about depth or breadth of the reviews. 1.c - There is no need for wider review. 1.d - There are no specific concerns that the AD and/or IESG should be aware of. 1.e - The consensus is solid. 1.f - There has been no threat of an appeal. 1.g - The Shepherd has personally verified that the document satisfies all I-D nits. 1.h - The document splits it references. 1.i - The document has an IANA consideration and it is consistent with the main body (there are no IANA considerations). 1.j - The reviewer has personally verified the ASN.1. 1.h - Write-up is as follows: 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. |
|
2009-12-10
|
06 | Russ Housley | Draft Added by Russ Housley in state Publication Requested |
|
2009-12-07
|
03 | (System) | New version available: draft-turner-additional-cms-ri-choices-03.txt |
|
2009-10-14
|
02 | (System) | New version available: draft-turner-additional-cms-ri-choices-02.txt |
|
2009-10-09
|
01 | (System) | New version available: draft-turner-additional-cms-ri-choices-01.txt |
|
2009-10-05
|
00 | (System) | New version available: draft-turner-additional-cms-ri-choices-00.txt |