Authors,
While reviewing this document during AUTH48, please resolve (as necessary)
the following questions, which are also in the source file.
1) <!--[rfced] We had a few questions related to the following text:
Original:
CMC also requires the use of the transport document and the
requirements usage document along with this document for a full
definition.
a) While this text appeared in RFC 5272, might it be helpful to the
reader to include further document info here (no citation brackets as
it is in the Abstract)? Also, what is "the usage requirements" doc?
"Certificate Management Messages over CMS (CMC): Compliance
Requirements"?
Perhaps:
CMC also requires the use of the transport document (RFC 10003) and the
compliance document (RFC 10004) along with this document for a full
definition.
b) The Introduction does not include this text (but is otherwise
nearly identical to the Abstract). Please review if this text (or
similar) should be added to the Introduction as well.
-->
2) <!--[rfced] Would it be helpful to share a citation(s) with the reader
regarding what the existing CMS specification is (as was done for
PKCS #10 and CRMF?
Original:
The protocol must be based as much as possible on the existing CMS,
PKCS #10 [PKCS10] and CRMF (Certificate Request Message Format)
[CRMF] specifications.
-->
3) <!--[rfced] Will the reader already know what the "S/MIME core
documents are?
Original:
Support must exist for the mandatory algorithms used by S/MIME.
Support should exist for all other algorithms cited by the S/MIME
core documents.
-->
4) <!--[rfced] Note that we have made some changes in the "Changes Since"
sections in order to clarify which revision is being talked about
and to address tense shifts and the like. Please let us know any
objections or if further updates are necessary. -->
5) <!--[rfced] Please review as this is a sentence fragment:
Original:
Clarified that subjectKeyIdentifier choice used with id-alg-
noSignature.
-->
6) <!--[rfced] Perhaps the following might be added to the list in the
Terminology section (as there isn't an easy way to expand on
first use)?
HMAC: Hashed Message Authentication Code
-->
7) <!--[rfced] Please confirm that the changes from asterisk (*) to
carrot (^) in Figure 2 are intentional. -->
8) <!--[rfced] Please review instances of "value with the ...value"
(there are many throughout the document, below is just an
example):
Original:
If rejected and a PKI Response is returned, the CA MUST return a PKI
Response with the CMCFailInfo value with the value badRequest.
Perhaps:
If rejected and a PKI Response is returned, the CA MUST return a PKI
Response with the CMCFailInfo failure code with the value badRequest.
-->
9) <!--[rfced] In the following, would it make sense to clarify if this
text is discussing is a Simple or Full PKI Response?
Original:
If a certification request is denied due to the inability to handle a
requested extension and a PKI Response is returned, the server MUST
return a PKI Response with a CMCFailInfo value with the value
unsupportedExt.
-->
10) <!--[rfced] How may we update the following? As "archival" is
adjectival, what is it modifying?
Original:
EnvelopedData can also be used to wrap private key material for key
archival.
-->
11) <!--[rfced] We note these two very similar sentences in Sections 4.1 and
4.2.
Please review to ensure the variance is intentional.
Section 4.1:
...clients SHOULD provide a mechanism to enable the user to use the certificate
as a trust anchor
Section 4.2:
...clients MAY provide a mechanism to enable the user to explicitly use the
certificate as a trust anchor.
-->
12) <!--[rfced] Please review whether the following (or any text marked
"Note:" or appearing in parentheses in the document) should be
formatted in an <aside> element (defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"); see
https://authors.ietf.org/en/rfcxml-vocabulary#aside.
Original:
Note: In RFC 2797, this ASN.1 type was named ResponseBody. It has
been renamed to PKIResponse for clarity and the old name kept as a
synonym.
-->
13) <!--[rfced] We had the following questions related to the CMC Control
Attributes table:
a) For the id-cmc-popLinkRandom and id-cmc-popLinkWitness entries,
both point to Section 6.3.1 in the Section column. For the ease of
the reader, may we make these point to 6.3.1.3 and 6.3.1.2,
respectively?
b) For the id-cmc-controlProcessed entry, we note that Section 6.19
uses ControlList in the ASN.1 (instead of ControlsProcessed).
We also note the Identifier Description column of this table uses
"id-cmc-controlProcessed" (singular control) while the ASN.1 Structure
column lists "ControlsProcessed" (plural).
Please let us know what, if any, updates are necessary.
Original (from Section 6.3.1):
The Control Processed control is identified by the OID:
id-cmc-controlProcessed OBJECT IDENTIFIER ::= { id-cmc 32 }
The Control Processed control has the ASN.1 definition:
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
Further note: please review the spacing of "SIZE (1..MAX)" with a
space between SIZE and the parenthesis in Section 6.3.1 and "SEQUENCE
SIZE(1..MAX)" with no space before the parenthesis in Appendix A.1
relate to this entry.
c) Looking at the pattern displayed in the table, please review the
use of "CMCCertid" in the ASN.1 Structure column for
id-cmc-confirmCertAcceptance. We would have expected to see
IssuerAndSerialNumber.
Same as above for id-cmc-authData: instead of AuthPublish, we were
expecting BodyPartID.
Please review and confirm these appear as desired or let us know how
you'd like to update.
d) For id-cmc-popLinkWitnessV2, the ASN.1 Structure column lists
"OCTET STRING". While the ASN.1 in Section 6.3.1.1 ends in OCTET
STRING, we would have thought this would have been listed the same way
other SEQUENCE entries were listed with "PopLinkWitnessV2" listed in
the ASN.1 Structure column (as was the pattern with others ending with
OCTET STRING like id-cmc-encryptedPOP, for example). Please review.
e) Please review the id-cmc-identityProofV2 entry: we note that the
entry in this table uses "IdentityProofV2" while the corresponding
ASN.1 in Section 6.2.1 uses IdentifyProofV2 (identity vs. identify).
Please let us know what, if any, updates should be made.
Note: In general, identifyProof vs. identityProof may be a greater
inconsistency throughout the doc (or at least Section 6.2.1 and
6.2.2). Please review that as well.
e) We see the table entry "id-cmc-lraPOPWitness". In Section 6.8,
please review the use of LraPopWitness in the ASN.1 definition (note
the difference in capping of POP) and let us know if any updates for
uniformity are necessary to either Table 1 or Section 6.8 (we would
have expected to see LraPopWitness in the ASN.1 Structure column to
match the pattern of the other entries).
Original in Section 6.8:
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= { id-cmc 11 }
The RA POP Witness control has the ASN.1 definition:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
The fields in LraPOPWitness have the following meaning:
-->
14) <!--[rfced] Please review the following mismatch in numbers (33
vs. 34) for the following and let us know if any updates are
necessary to make these uniform.
Section 6.3.1.1:
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
Appendix A.1:
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
Section 6.2.1:
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
Appendix A.1:
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
-->
15) <!--[rfced] What is the subject of the verb "applies"? This sentence
may need rephrasing.
Original:
There are two cases that require an RA to remove or change encryption
encryption, applies to both EnvelopedData or AuthEnvelopedData, in a
PKI Request.
-->
16) <!--[rfced] The last two paragraphs of the IANA Considerations list things
that should not be changed.
While these were likely helpful for IANA during processing, should these be
removed from the document before publication as an RFC? -->
17) <!-- [rfced] For the reference entry [PASSWORD] Please review the following:
NIST SP 800-63-3
(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-3.pdf)
has been withdrawn
and replaced by NIST SP 800-63-4
(https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-4.pdf).
Note that the Appendix A of NIST SP 800-63-3 was titled "Appendix A —
Definitions and Abbreviations".
Appendix A of NIST SP 800-63-4 is titled "Appendix A — List of Symbols,
Abbreviations, and Acronyms".
May we update this reference to point to NIST SP 800-63-4?
-->
18) <!--[rfced] How does "the example below shows relate to the rest of
the sentence (shows is transitive and needs an object):
Original:
This section looks at the messages that would flow in the event that
an enrollment is done for an encryption-only certificate using a
direct POP method; the example below shows.
Perhaps:
This section looks at the messages that would flow in the event that
an enrollment is done for an encryption-only certificate using a
direct POP method; an example message follows.
-->
19) <!--[rfced] The following sentence is hard to follow. Perhaps the
verb "is" is missing? If not, please rephrase.
Original:
Instead of assuming that the certification requester already has a
signing-only certificate as in Appendix B.3, here the No Signature
mechanism from Appendix C.1, the public key is for a KEM, and the
EnvelopedData uses the KEMRecipientInfo from [CMS-KEM].
Perhaps:
Instead of assuming that the certification requester already has a
signing-only certificate (as in Appendix B.3), here the No Signature
mechanism is from Appendix C.1, the public key is for a KEM, and the
EnvelopedData uses the KEMRecipientInfo from [CMS-KEM].
-->
20) <!--[rfced] We had the following questions/comments related to
abbreviation use throughout the document:
a) Note that we have updated to use either EE or End-Entity (capped
and hyphenated) throughout for consistency. Please let us know any
objections.
b) When expanded, CRMF stands for "Certificate Request Message
Format". Is it redundant to use CRMF certification request?
c) When expanded, POP stands for "Proof-of-Possession". Is it
redundant to use "POP proof"?
-->
21) <!--[rfced] We had the following questions about terminology used
throughout the document:
a) We see both PKI enrollment request and PKI Request. Should the
capping be made uniform (or the use of enrollment)?
b) Are Proof-of-Identity and Identification and Identity Proof the
same? If so, should they be made uniform (and which form)? Note that
we capped Proof-of-Identity consistently throughout.
c) Should instances of "SEQUENCE of" be made "SEQUENCE OF" (capping
OF)? For example:
Section 6.8:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
Appendix A.1:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
d) We see both NULL and null used in the text.
Please review and let us know if/how these should be made uniform.
e) We see both "subject alternative name" and "subject alternate name".
Please let us know if/how these should be made consistent.
f) We note most uses of "control" are lowercase after the name of the
control (e.g, "Response Information control"). However, we see
"Response Body Control" with capitalized Control. Please review and
let us know if/how to update.
g) In Appendix B, we see some comments with PBKF2 while elsewhere in
the document, we see PBKDF2. Please review and let us know if/how to
update.
h) In Appendix B.2, we see "id-cmc-BatchResponse". Elsewhere in the
document, we see "id-cmc-batchResponses" (note the caps and
pluralization).
i) Please review the following and let us know if/how they may be made
consistent.
"certs-only" vs. certs-only
Attribute object vs. ATTRIBUTE object
bocyPartID vs. BodyPartID vs. body part identity
bodyPartPath vs. BodyParPath
CertificationRequest vs. CertRequest
challenge/response vs. challenge-response
ExtendedFailureInfo vs. ExtendedFailInfo
responseBody vs. Response Body
subject information access extension (but Subject Information Access type)
-->
22) <!--[rfced] We see the following terms surrounded by <tt> tags in the
XML. However, there are a great many instances in which they are
used without the <tt>.
<tt>AuthenticatedData</tt>
<tt>AuthEnvelopedData</tt>
<tt>badMessageCheck</tt>
<tt>bodyPartID</tt>
<tt>certificationRequest</tt>
<tt>CMCFailInfo</tt>
<tt>cmsSequence</tt>
<tt>contentInfo</tt>
<tt>controlSequence</tt>
<tt>crm</tt>
<tt>Data</tt>
<tt>EncapsulatedContentInfo</tt>
<tt>EnvelopedData</tt>
<tt>orm</tt>
<tt>otherMsgSequence</tt>
<tt>PKIData</tt>
<tt>PKIResponse</tt>
<tt>RecipientInfo</tt>
<tt>reqSequence</tt>
<tt>requestMessageType</tt>
<tt>requestMessageValue</tt>
<tt>SignedData</tt>
<tt>SignerInfo</tt>
<tt>TaggedContentInfo</tt>
<tt>tcr</tt>
We have included instances of these uses that may need to be tagged in
the file at:
https://www.rfc-editor.org/authors/draft-ietf-lamps-rfc5272bis-11nott.txt
Note: the above is just a dump of grep results (somewhat messy).
-->
23) <!--[rfced] Following up on our document intake email question about
sourcecode: there were a number of uses of <artwork> that seemed to be ASN.1
snippets.
We have updated these to <sourcecode type="asn.1">.
However, there are some <artwork> elements remaining that we were
uncertain about. Please search <artwork> in the xml and let us know
which (if any) of them may be updated to use <sourcecode> as well as
what (if any) type should be listed (see
https://rpc-wiki.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
for the current list of types).
-->
24) <!--[rfced] There are a great many warnings for lines being too long.
Please
review and let us know how we may update to fit these modules inside
the character limit. List included below for convenience.
(5529): Warning: Artwork too wide, reducing indentation from 3 to 0
(5693): Warning: Artwork too wide, reducing indentation from 3 to 0
(4567): Warning: Too long line found (L3710), 3 characters longer than 72
characters:
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
(4567): Warning: Too long line found (L3716), 2 characters longer than 72
characters:
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
(4567): Warning: Too long line found (L3723), 3 characters longer than 72
characters:
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
(4567): Warning: Too long line found (L3726), 2 characters longer than 72
characters:
Name, id-pkix, PublicKeyAlgorithms, SignatureAlgorithms, id-ad, id-kp
(4567): Warning: Too long line found (L3728), 3 characters longer than 72
characters:
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
(4567): Warning: Too long line found (L3729), 1 characters longer than 72
characters:
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }
(4567): Warning: Too long line found (L3738), 3 characters longer than 72
characters:
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
(4567): Warning: Too long line found (L3749), 1 characters longer than 72
characters:
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
(4567): Warning: Too long line found (L3765), 1 characters longer than 72
characters:
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
(4567): Warning: Too long line found (L3770), 3 characters longer than 72
characters:
CMC-ContentTypes CONTENT-TYPE ::= { ct-PKIData | ct-PKIResponse, ... }
(4567): Warning: Too long line found (L3851), 1 characters longer than 72
characters:
algorithm AlgorithmIdentifier{PUBLIC-KEY,
(4567): Warning: Too long line found (L3878), 2 characters longer than 72
characters:
otherMsgValue OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }
(4567): Warning: Too long line found (L4041), 1 characters longer than 72
characters:
POPAlgs MAC-ALGORITHM ::= { maca-hMAC-SHA1 | maca-hMAC-SHA256, ... }
(4567): Warning: Too long line found (L4107), 2 characters longer than 72
characters:
id-ExtensionReq OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
(4567): Warning: Too long line found (L4252), 1 characters longer than 72
characters:
bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference
(4567): Warning: Too long line found (L4277), 1 characters longer than 72
characters:
macAlgorithm AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
(4567): Warning: Too long line found (L4293), 1 characters longer than 72
characters:
{ TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }
(5205): Warning: Too long line found (L4350), 1 characters longer than 72
characters:
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
(5205): Warning: Too long line found (L4393), 1 characters longer than 72
characters:
alg-hMAC-SHA512-224 ALGORITHM ::= { IDENTIFIER id-hmacWithSHA512-224
(5205): Warning: Too long line found (L4396), 1 characters longer than 72
characters:
alg-hMAC-SHA512-256 ALGORITHM ::= { IDENTIFIER id-hmacWithSHA512-256
-->
25) <!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this
nature typically result in more precise language, which is
helpful for readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice.
-->
Thank you.
Megan Ferguson
RFC Production Center
*****IMPORTANT*****
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc10002.xml
https://www.rfc-editor.org/authors/rfc10002.html
https://www.rfc-editor.org/authors/rfc10002.pdf
https://www.rfc-editor.org/authors/rfc10002.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc10002-diff.html
https://www.rfc-editor.org/authors/rfc10002-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc10002-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc10002
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC 10002 (draft-ietf-lamps-rfc5272bis)
Title : Certificate Management over CMS (CMC)
Author(s) : J. Mandel, Ed.,
S. Turner, Ed.
WG Chair(s) : Russ Housley, Tim Hollebeek
Area Director(s) : Deb Cooley, Christopher Inacio
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
