Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
RFC 5940
Yes
No Objection
Recuse
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert No Objection
(Tim Polk; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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?
(Alexey Melnikov; former steering group member) No Objection
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.
(Dan Romascanu; former steering group member) (was Discuss) No Objection
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) (was Discuss) No Objection
(Peter Saint-Andre; former steering group member) No Objection
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Russ Housley; former steering group member) Recuse
(Sean Turner; former steering group member) Recuse