Skip to main content

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