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

[Deb Cooley <[e-mail]>]

Table 1:
 - I'd like the authors to check both the Identifier Descriptions and the
ASN.1 structures.  I see a mix/match of pop/POP, as well as
'IssuerandSerialNumber'.  Just confirm for me that these are actually all
correct.
 - And someone added the word 'Section' to each row, when somewhere else
(maybe 10004) Section was removed from every row (this is picky).  But now
that I see it - it will drive me crazy.

Section 6.8:  More POP/Pop, please be sure it is correct.  It is different
within the section

Section 6.8, 6.17, 6.18:  OF/of?  which is correct?

Section 6.11:  IssuerName is defined incorrectly.  It  "is the name of the
issuer of the certificate to be revoked".  Right????

Do me a favor and do a global search for 'pop' and be sure the
capitalization is correct - normal abbreviation, ASN.1, whatever.  It seems
to be everywhere, and I know it is supposed to be different in some
places....

Deb



On Tue, Jun 2, 2026 at 10:56 PM Megan Ferguson <
[e-mail]> wrote:

> Sean, Joe, *AD,
>
> [*AD - please add review and approval of the changes that appear in
> Section 3.2.1.2.2 as well as Section 6.11 to the previous request (see the
> Final Review status page below for a list of AD actions necessary.]
>
> Thank you for sending along these changes.  We have updated as requested
> and re-posted the files for your review.
>
> Note that we have raised the change to Section 6.11 for AD review as we
> had previously heard the following from Russ regarding that same change in
> the version we originally sent to AUTH48:
>
> > 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.
>
> Further, we’d appreciate input on our follow up question about the changes
> to the capitalization of the following:
>
> > 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.
>
> We don’t believe we’ve seen responses to the following so far yet either:
>
> >
> > #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).
>
> 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)
>
> https://www.rfc-editor.org/authors/rfc10002-lastdiff.html (AUTH48 changes
> only)
> https://www.rfc-editor.org/authors/rfc10002-lastrfcdiff.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 Jun 2, 2026, at 5:00 PM, Joe Mandel <[e-mail]> wrote:
> >
> > Hi Megan,
> >
> > A couple of additional changes.
> >
> > In Section 3.2.1.2.2:
> >
> > OLD:
> > 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 of
> unsupportedExt.
> >
> > NEW:
> >
> > If a certification request is denied due to the inability to handle a
> requested extension
> > and a Full PKI Response is returned, the server MUST return a
> CMCFailInfo value with
> > the value of unsupportedExt.
> >
> > There are a few instances where there should be a space in Sections
> 3.2.1, 4.2.1, Appendix A.1.
> >
> > OLD:
> > “SIZE(“
> >
> > NEW:
> > “Size (“
> >
> > Thanks,
> > Joe
> >
> >> On May 29, 2026, at 1:39 PM, Megan Ferguson <
> [e-mail]> wrote:
> >>
> >> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>
>