Additional Cryptographic Message Syntax (CMS) Revocation Information Choices
Note: This ballot was opened for revision 06 and is now closed.
(Tim Polk) Yes
(Jari Arkko) (was Discuss) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Ralph Droms) No Objection
(Lars Eggert) No Objection
(Adrian Farrel) No Objection
Comment (2010-06-03 for -** No value found for 'p.get_dochistory.rev' **)
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?
(David Harrington) No Objection
(Alexey Melnikov) No Objection
Comment (2010-05-26 for -** No value found for 'p.get_dochistory.rev' **)
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.