[auth48] Re: RFC-to-be 10002 draft-ietf-lamps-rfc5272bis for your review

[Megan Ferguson <[e-mail]>]

Russ,

Thank you for reviewing!  We have reverted as suggested. 

To clarify, does it need to be LraPopWitness (with Pop) not LraPOPWitness (with capped POP)?  We went with the former per your message; please let us know if we should update.

You may now review these reversions as well as the addition of HMAC to the Terminology section as suggested by Joe in the files below.

The files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc10002.txt
 https://www.rfc-editor.org/authors/rfc10002.pdf
 https://www.rfc-editor.org/authors/rfc10002.html
 https://www.rfc-editor.org/authors/rfc10002.xml

The diff files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc10002-diff.html (comprehensive)
 https://www.rfc-editor.org/authors/rfc10002-rfcdiff.html (side by side)

 https://www.rfc-editor.org/authors/rfc10002-auth48diff.html (AUTH48 changes only)
 https://www.rfc-editor.org/authors/rfc10002-auth48rfcdiff.html (side by side)

The Final Review status page exists here:
 https://www.rfc-editor.org/auth48/rfc10002

Thank you.

Megan Ferguson
RFC Production Center

> On May 29, 2026, at 1:16 PM, Russ Housley <[e-mail]> wrote:
> 
> Megan:
> 
> The changes made in Section 6.8 are incorrect.  The ASN.1 type MUST begin with a capital latter, so LraPopWitness was correct.
> 
> This change also needs to be reversed in the ASN.1 module (Appendix A).
> 
> The change in Section 6.11 is a problem.  issuerName is the issuer name in the certificate.  With this change, it couls be interpreted as the subject name.
> 
> Russ
> 
> 
> 
>> On May 29, 2026, at 12:56 PM, Megan Ferguson <[e-mail]> wrote:
>> 
>> Hi Joe and Sean (and *AD),
>> 
>> ---
>> *AD - please review and approve the changes to Table 1 and changes to the ASN.1 or pseudocode in the following sections: 3.2.1.2.2, 6.2.1, 6.2.2, 6.8, 6.17, 6.18, A.1, A.2, and B.2 (all of which are highlighted in the AUTH48 diff below).
>> ---
>> 
>> Thank you for your reply and guidance.  We have updated as requested.
>> 
>> We had a few questions/comments to follow up on:
>> 
>> #6 (Adding HMAC to Terminology): We were unsure if your response indicated you’d like us to add this to the list or not?  If so, please provide the exact text you’d like us to use.
>> 
>> #7 (Using asterisk * in Figure 2 to match use in the same figure in RFC 5272): We have updated to use the asterisk in both the ascii and SVG renderings.  Please review and confirm that these both now appear as desired.
>> 
>> #21(b)(Regarding Proof-of-Identity): Please clarify if you’d like us to make any future changes and/or if you are okay with the changes we’ve already made:
>> 
>>>>> 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.
>>>> 
>>>> Proof-of-Identity is a process and Identification and Identity Proof are two controls. We will review the proposed changes that you make.
>> 
>> 
>> #22 (<tt> tags used inconsistently): Note that we have updated to ensure that all terms that used <tt> inconsistently in the originally submitted XML file now use them consistently throughout.  However, it is likely that similar types of terms do not use <tt> (either in the original or now).  If further updates are desired, please provide the specific details (either via email or feel free to update the edited XML file linked below and email that back if that’s easier).  If not, please just confirm that you’d like to keep the file as is.
>> 
>> #23 (<artwork> to <sourcecode> in Appendix B): Per your response, we have updated all the <artwork> used in Appendix B to instead be <sourcecode type=“pseudocode”>.  Please review and let us know any objections.
>> 
>> #24 (line too long warnings): Is it possible for us to cut the whitespace at the left that exists beginning with “EXPORTS ALL"?  Most of the warnings are between 1 and 3 characters too long: there are 3 empty spaces to the left.  However, note that this would bring “BEGIN” in line with everything after “EXPORTS All”.  If this solution is not possible, we will need the authors to provide the breaks (which you are welcome to do in the edited XML file if this is easier than copy/paste in email).
>> 
>> Please review carefully as we do not make changes once the document is published as an RFC.
>> 
>> The files have been posted here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc10002.txt
>>  https://www.rfc-editor.org/authors/rfc10002.pdf
>>  https://www.rfc-editor.org/authors/rfc10002.html
>>  https://www.rfc-editor.org/authors/rfc10002.xml
>> 
>> The diff files have been posted here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc10002-diff.html (comprehensive)
>>  https://www.rfc-editor.org/authors/rfc10002-rfcdiff.html (side by side)
>> 
>>  https://www.rfc-editor.org/authors/rfc10002-auth48diff.html (AUTH48 changes only)
>>  https://www.rfc-editor.org/authors/rfc10002-auth48rfcdiff.html (side by side)
>> 
>> The Final Review status page exists here:
>>  https://www.rfc-editor.org/auth48/rfc10002
>> 
>> Thank you.
>> 
>> Megan Ferguson
>> RFC Production Center
>> 
>> 
>>> On May 28, 2026, at 11:17 AM, Joe Mandel <[e-mail]> wrote:
>>> 
>>> Please see our responses below. 
>>> 
>>> Joe and Sean
>>> 
>>>> On May 22, 2026, at 10:41 AM, [e-mail] wrote:
>>>> 
>>>> 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"?
>>> 
>>> Yes, that is correct.
>>>> 
>>>> 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.
>>> Yes, we agree with this text.
>>>> 
>>>> 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.
>>> 
>>> This text can be added to the introduction.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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.
>>>> -->
>>> 
>>> Let’s add a reference for RFC 5652 and RFC 5083.
>>>> 
>>>> 
>>>> 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.
>>>> -->
>>> 
>>> Yes, the vast majority of people implementing this will know that we’re referring to 8550/8551. FYI - 8550bis/8551bis are being developed now and we don’t see any reason to wait for them
>>>> 
>>>> 
>>>> 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. -->
>>> 
>>> This looks good to us.
>>>> 
>>>> 
>>>> 5) <!--[rfced] Please review as this is a sentence fragment:
>>>> 
>>>> Original:
>>>> Clarified that subjectKeyIdentifier choice used with id-alg-
>>>> noSignature.
>>>> -->
>>> 
>>> Clarified that the subjectKeyIdentifier choice must be 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 
>>>> 
>>>> -->
>>> 
>>> HMAC refers to the Hashed Message Authentication Code. CMC uses the ASN.1 module defined in [HMAC-ALGS].
>>>> 
>>>> 
>>>> 7) <!--[rfced] Please confirm that the changes from asterisk (*) to
>>>>   carrot (^) in Figure 2 are intentional. -->
>>> 
>>> We’d prefer to not use the carrot (^), but used it because we had issues rendering the asterisk in aasvg. If you have a way to fix it or have a better symbol we are open to suggestions.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>> 
>>> Yes, these are called values in Section 6.1.4.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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.
>>> 
>>> New:
>>> 
>>> If a Simple PKI Request is denied due to the inability to handle a
>>> requested extension and a Full PKI Response is returned, the server MUST
>>> return a Full 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.
>>>> -->
>>> 
>>> Let’s use this: 
>>> 
>>> EnvelopedData can also be used to wrap private key material that is to be archived.
>>> 
>>> Note that the same change needs to be made for AuthEnvelopedData two sections later.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> -->
>>> 
>>> Yes, this is intentional.
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> -->
>>> 
>>> Yes, we agree that these should be in an aside.
>>>> 
>>>> 
>>>> 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?
>>> Those are better sections to point to.
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> 
>>> Please change the table entry to ControlList
>>>> 
>>>> 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.
>>> Please add a space for readability, like this: SIZE (1..MAX).
>>>> 
>>>> 
>>>> 
>>>> 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.
>>> 
>>> We agree, this should be IssuerAndSerialNumber.
>>>> 
>>>> Same as above for id-cmc-authData: instead of AuthPublish, we were
>>>> expecting BodyPartID.
>>> We agree, this should be 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.
>>> 
>>> We agree, this should be PopLinkWitnessV2.
>>>> 
>>>> 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.
>>> 
>>> Please change the ASN.1 to “IdentityProofV2 ::= SEQUENCE { “ in section 6.2.1.
>>>> 
>>>> 
>>>> 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.
>>> 
>>> In Section 6.2.2 this should be IdentityProof ::= OCTET STRING”.
>>>> 
>>>> 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:
>>> 
>>> This should be lraPOPWitness.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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 }
>>> Please update Appendix A.1 to be: id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
>>>> 
>>>> 
>>>> 
>>>> Section 6.2.1:
>>>> id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
>>>> 
>>>> Appendix A.1:
>>>> id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
>>> 
>>> Please update Appendix A.1 to be: id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
>>>> 
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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.
>>> We reworded the sentence, but are open to suggestions:
>>> 
>>> There are two cases that require an RA to remove or change encryption
>>> in a PKI Request, and both cases are true regardless whether
>>> EnvelopedData or AuthEnvelopedData is used.
>>>> 
>>>> 
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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? -->
>>> 
>>> Please leave this in the document.
>>>> 
>>>> 
>>>> 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?
>>> 
>>> We agree with this change.
>>>> -->
>>>> 
>>>> 
>>>> 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.
>>> 
>>> We like the suggested text, thank you.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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].
>>> 
>>> We like the suggested text, thank you.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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.
>>> 
>>> We agree with this change.
>>>> 
>>>> b) When expanded, CRMF stands for "Certificate Request Message
>>>> Format".  Is it redundant to use CRMF certification request?
>>>> 
>>> You can remove “certification request” when it appears after CRMF.
>>> 
>>> in s6.3, we can then change this to match s6.3.1:
>>> 
>>> on the PKCS #10 or CRMF request
>>> 
>>> to:
>>> 
>>> on the certification request (PKCS #10 or CRMF).
>>> 
>>>> c) When expanded, POP stands for "Proof-of-Possession".  Is it
>>>> redundant to use "POP proof"?
>>>> 
>>> We’d like to keep “proof” the way it is. 
>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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)?
>>> 
>>> We reviewed the instances and think they are correct as is.
>>>> 
>>>> 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.
>>> 
>>> Proof-of-Identity is a process and Identification and Identity Proof are two controls. We will review the proposed changes that you make. 
>>> 
>>> Also upon review, I noted that in s6.2 this sentence refers to the wrong section - it should refer to v2 and that’s in s6.2.1:
>>> 
>>> OLD:
>>> 
>>> If clients support the Full PKI
>>>  Request, clients MUST implement this method of identity proof
>>>  (Section 6.2.2).
>>> 
>>> NEW:
>>> 
>>> If clients support the Full PKI
>>>  Request, clients MUST implement this method of identity proof
>>>  (Section 6.2.1).
>>> 
>>>> 
>>>> 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
>>>> }
>>> 
>>> Yes, capitalize “OF”.
>>>> 
>>>> 
>>>> d) We see both NULL and null used in the text.  
>>>> Please review and let us know if/how these should be made uniform.
>>> 
>>> Let’s make them a uniform “NULL”.
>>>> 
>>>> e) We see both "subject alternative name" and "subject alternate name".  
>>>> Please let us know if/how these should be made consistent.
>>> 
>>> This should be subject alternative name.
>>>> 
>>>> 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.
>>> 
>>> This should be “Response Body control”.
>>>> 
>>>> 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.
>>> 
>>> Please change these to PBKDF2.
>>>> 
>>>> h) In Appendix B.2, we see "id-cmc-BatchResponse".  Elsewhere in the
>>>> document, we see "id-cmc-batchResponses" (note the caps and
>>>> pluralization).
>>> 
>>> This should be plural, id-cmc-batchResponses.
>>>> 
>>>> i) Please review the following and let us know if/how they may be made
>>>> consistent.
>>>> 
>>>> "certs-only" vs. certs-only
>>> 
>>> “certs-only"
>>>> Attribute object vs. ATTRIBUTE object
>>> No change.
>>>> bocyPartID vs. BodyPartID vs. body part identity
>>> No change.
>>>> bodyPartPath vs. BodyParPath
>>> No change.
>>>> CertificationRequest vs. CertRequest
>>> No change.
>>>> challenge/response vs. challenge-response
>>> challenge-response
>>>> ExtendedFailureInfo vs. ExtendedFailInfo
>>> No change.
>>>> responseBody vs. Response Body
>>> No change.
>>>> subject information access extension (but Subject Information Access type)
>>> 
>>> Change to extension.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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).
>>> 
>>> Please add the tags.
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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).
>>> 
>>> If this is referring to the artwork tags in Appendix B, this is PseudoCode. Do you think this change should still be made?
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 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
>>>> 
>>> 
>>> Yes, these should be changed.
>>>> -->
>>>> 
>>>> 
>>>> 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.
>>>> -->
>>> 
>>> We reviewed.
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> *  [e-mail] (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).
>>>> 
>>>> *  [e-mail], 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,
>>>>      [e-mail] 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
>>> 
>> 
>