BRSKI-AE: Alternative Enrollment Protocols in BRSKI
draft-ietf-anima-brski-ae-13

[Ballot comment]
Thanks for this document. I have two minor comments/nits:

- please alphabetize your terminology section.

- in, “The following terms are described partly in addition.”

I don’t know what you mean by “partly“. Would the sentence be correct if you deleted that word?

[Ballot comment]
Thank you to Meral Shirazipour for the GENART review.

** Section 4.2.1
  As a more general solution, the BRSKI discovery mechanism can be
  extended to provide up-front information on the capabilities of
  registrars.  Future work such as [I-D.eckert-anima-brski-discovery]
  may provide this.
Does it make sense to reference and promise work on an individual, expired I-D?

** Section 7 notes that the Security Considerations of RFC8995 apply.  What of the privacy consideration of RFC8895 (Section 10)? Do they apply or need any refinement (e.g., Section 10.2)?

[Ballot comment]
I'm leaving my old discuss text below, just because I can. 

The authors pointed me to RFC8995 section 5.6 and 11.4, which nicely explains how the chain between pledge, MASA, and registrar works to ensure that the registrar is the legit registrar.  In the process, one of the authors suggested that the voucher process could be added to figure 2, which I'd be happy to see, if and only if it doesn't make the figure unweildy. 

Thanks to the authors for the quick response and for politely pointing me to the referenced RFCs.

----------------------------------------------------------------------
old DISCUSS:
----------------------------------------------------------------------

While this draft clearly outlines the requirements for proof of possession and
integrity/authentication of the pledge, I did not see any discussion on
integrity/authentication of the RA/CA.  How can the pledge determine if it is
requesting certificates (either its own or CA) from the proper RA/CA?  One of
the advantages of EST is that the pledge can verify the EST server certificate,
and an on-path attack is harder when there is an adequate TLS session.  Is that
the case with CMP (or SCEP)?  If so, either point me to where that is
documented or add a couple of sentences on how that is done.  If not, please
add a section to the Security Considerations.

[Ballot discuss]
While this draft clearly outlines the requirements for proof of possession and integrity/authentication of the pledge, I did not see any discussion on integrity/authentication of the RA/CA.  How can the pledge determine if it is requesting certificates (either its own or CA) from the proper RA/CA?  One of the advantages of EST is that the pledge can verify the EST server certificate, and an on-path attack is harder when there is an adequate TLS session.  Is that the case with CMP (or SCEP)?  If so, either point me to where that is documented or add a couple of sentences on how that is done.  If not, please add a section to the Security Considerations.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-anima-brski-ae-12

Thank you for the work put into this document (and the SVG figures). It is sometimes hard to read with very long sentences.

Please find below just one non-blocking NIT points.

Special thanks to Toerless Eckert for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# NITS (non-blocking / cosmetic)

## Section 1

As English is not my primary language, I find weird the use of "production" rather than "manufacturing" in `during its production`.

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-anima-brski-ae-12

#GENERIC COMMENTS
#================
## The text contains many acronyms making it not easy to digest when not familiar with ANIMA technology. (i am not that familiar with ANIMA)

## I provided a few rewrites of text to help the structure and simplify reading the content, while keeping the original message, and hope it helps improve document quality

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

11 Abstract
12
13   This document defines an enhancement of Bootstrapping Remote Secure
14   Key Infrastructure (BRSKI, RFC 8995).  It supports alternative
15   certificate enrollment protocols, such as CMP, that use authenticated
16   self-contained signed objects for certification messages.

[minor]
Possibly we could make the abstract slightly higher level to describe the content of the draft. What about the following proposed alternative abstract:

"
This document defines enhancements to the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol, known as BRSKI-AE (Alternative Enrollment). BRSKI-AE extends BRSKI to support alternative enrollment mechanisms beyond those originally specified, allowing for flexibility in network device onboarding scenarios. The enhancements address use cases where the existing BRSKI mechanisms may not be feasible or optimal, providing a framework for integrating other automated bootstrapping and enrollment techniques. This document also updates the BRSKI reference architecture to accommodate these alternative methods, ensuring secure and scalable deployment across a range of network environments.
"

106   This approach provides the following advantages.  The origin of
107   requests and responses can be authenticated independent of message
108   transfer.  This supports end-to-end authentication (proof of origin)
109   also over multiple hops, as well as asynchronous operation of
110   certificate enrollment.  This in turn provides architectural
111   flexibility where and when to ultimately authenticate and authorize
112   certification requests while retaining full-strength integrity and
113   authenticity of certification requests.

[major]
I am not sure what is the correlation between (proof of origin) and "end-to-end authentication". Why is the prrof of origin between brakets?

[minor]
I found this paragraph unfortunatly strucured. What about following proposal:

"
This approach offers several distinct advantages. It allows for the authentication of the origin of requests and responses independently of the message transfer mechanism. This capability facilitates end-to-end authentication (proof of origin) across multiple hops and supports the asynchronous operation of certificate enrollment. Consequently, this provides architectural flexibility in determining the location and timing for the ultimate authentication and authorization of certification requests, while ensuring the integrity and authenticity of those requests is maintained with full cryptographic strength.
"

137   The goals of BRSKI-AE are to provide an enhancement of BRSKI for
138   LDevID certificate enrollment using, alternatively to EST, a protocol
139   that
140
141   *  supports end-to-end authentication over multiple hops
142
143   *  enables secure message exchange over any kind of transfer,
144       including asynchronous delivery.
145
146   Note that the BRSKI voucher exchange of the pledge with the registrar
147   and MASA uses authenticated self-contained objects, so the voucher
148   exchange already has these properties.
149
150   The well-known URI approach of BRSKI and EST messages is extended
151   with an additional path element indicating the enrollment protocol
152   being used.
153
154   Based on the definition of the overall approach and specific
155   endpoints, this specification enables the registrar to offer multiple
156   enrollment protocols, from which pledges and their developers can
157   then pick the most suitable one.
158
159   It may be noted that BRSKI (RFC 8995) specifies how to use HTTP over
160   TLS, but further variants are known, such as Constrained BRSKI
161   [I-D.ietf-anima-constrained-voucher] using CoAP over DTLS.  In the
162   sequel, 'HTTP' and 'TLS' are just references to the most common case,
163   where variants such as using CoAP and/or DTLS are meant to be
164   subsumed - the differences are not relevant here.
165
166   This specification is sufficient together with its references to
167   support BRSKI with the Certificate Management Protocol (CMP,
168   [RFC9480]) profiled in the Lightweight CMP Profile (LCMPP,
169   [RFC9483]).  Combining BRSKI with a protocol or profile other than
170   LCMPP will require additional IANA registrations based on the rules
171   specified in this document.  It may also require additional
172   specifications for details of the protocol or profile (similar to
173   [RFC9483]), which are outside the scope of this document.

[minor]
A possible alternate rewrite to make the text easier to read:

"
The objectives of BRSKI-AE are to enhance BRSKI by enabling LDevID certificate enrollment through the use of an alternative protocol to EST, which:

* Supports end-to-end authentication across multiple hops.
* Facilitates secure message exchange over any type of transfer mechanism, including asynchronous delivery.

It should be noted that the BRSKI voucher exchange between the pledge, registrar, and MASA involves the use of authenticated self-contained objects, which inherently possess these properties.

The existing well-known URI structure used for BRSKI and EST messages is extended by introducing an additional path element that specifies the enrollment protocol being employed.

This specification allows the registrar to offer multiple enrollment protocols, enabling pledges and their developers to select the most appropriate one based on the defined overall approach and specific endpoints.

It is important to recognize that BRSKI (RFC 8995) specifies the use of HTTP over TLS, but variations such as Constrained BRSKI [I-D.ietf-anima-constrained-voucher], which uses CoAP over DTLS, are also recognized. In this context, 'HTTP' and 'TLS' are used as references to the most common implementation, though variants using CoAP and/or DTLS are implied where applicable, as the distinctions are not pertinent here.

This specification, together with its referenced documents, is sufficient to support BRSKI with the Certificate Management Protocol (CMP, [RFC9480]) as profiled in the Lightweight CMP Profile (LCMPP, [RFC9483]). Integrating BRSKI with a protocol or profile other than LCMPP will necessitate additional IANA registrations, as detailed in this document. Furthermore, additional specifications may be required for the details of the protocol or profile, which fall outside the scope of this document.
"

175 1.1.  Supported Scenarios
176
177   BRSKI-AE is intended to be used in situations like the following.
178
179   *  Pledges and/or the target domain reuse an already established
180       certificate enrollment protocol different from EST, such as CMP.
181
182   *  The application scenario indirectly excludes the use of EST for
183       certificate enrollment, for reasons like these:
184
185       -  The Registration Authority (RA) is not co-located with the
186         registrar while it requires end-to-end authentication of
187         requesters.  Yet EST does not support end-to-end authentication
188         over multiple hops.
189
190       -  The RA or certification authority (CA) operator requires
191         auditable proof of origin for Certificate Signing Requests
192         (CSRs).  This is not possible with TLS because it provides only
193         transient source authentication.
184
195       -  Certificates are requested for types of keys, such as Key
196         Encapsulation Mechanism (KEM) keys, that do not support signing
197         (nor alternative forms of single-shot proof of possession like
198         those described in [RFC6955]).  This is not supported by EST
199         because it uses CSRs in PKCS #10 [RFC2986] format, which can
200         only use proof-of-possession methods that need just a single
201         message, while proof of possession for KEM keys, for instance,
202         requires receiving a fresh challenge value beforehand.
203
204       -  The pledge implementation uses security libraries not providing
205         EST support or uses a TLS library that does not support
206         providing the so-called tls-unique value [RFC5929], which is
207         needed by EST for strong binding of the source authentication.
208
209   *  No full RA functionality is available on-site in the target
210       domain, while connectivity to an off-site RA may be intermittent
211       or entirely offline.
212
213   *  Authoritative actions of a local RA at the registrar is not
214       sufficient for fully and reliably authorizing pledge certification
215       requests.  This may be due to missing data access or due to an
216       insufficient level of security, for instance regarding the local
217       storage of private keys.
217
219   Bootstrapping can be handled in various ways, depending on the
220   application domains.  The informative Appendix A provides
221   illustrative examples from various industrial control system
222   environments and operational setups motivating the support of
223   alternative enrollment protocols.

[minor]
possible rewrite for readability

"
BRSKI-AE is designed for use in scenarios such as the following:

* Pledges and/or the target domain leverage an existing certificate enrollment protocol other than EST, such as CMP.

* The application context precludes the use of EST for certificate enrollment due to factors such as:

    - The Registration Authority (RA) is not co-located with the registrar and requires end-to-end authentication of requesters, which EST does not support over multiple hops.

    - The RA or Certification Authority (CA) operator mandates auditable proof of origin for Certificate Signing Requests (CSRs), which cannot be provided by TLS as it only offers transient source authentication.

    - Certificates are required for key types, such as Key Encapsulation Mechanism (KEM) keys, that do not support signing or other single-shot proof of possession methods, as described in [RFC6955]. EST, which relies on CSRs in PKCS #10 [RFC2986] format, does not accommodate these key types because it necessitates proof-of-possession methods that operate within a single message, whereas proof of possession for KEM keys requires prior receipt of a fresh challenge value.

    - The pledge implementation employs security libraries that do not support EST or uses a TLS library lacking support for the "tls-unique" value [RFC5929], which EST requires for the strong binding of source authentication.

* Full RA functionality is not available on-site within the target domain, and connectivity to an off-site RA may be intermittent or entirely offline.

* Authoritative actions by a local RA at the registrar are insufficient for fully and reliably authorizing pledge certification requests, potentially due to a lack of access to necessary data or inadequate security measures, such as the local storage of private keys.

Bootstrapping may be managed in various ways depending on the application domain. Appendix A provides illustrative examples from different industrial control system environments and operational contexts that justify the support of alternative enrollment protocols.
"

258   CSR:  Certificate Signing Request

[minor]
other entries have a RFC associated as reference, but this one has not? Is that intentional?

847   BRSKI-AE provides generalizations to the addressing scheme defined in
848   BRSKI [RFC8995], Section 5 to accommodate alternative enrollment
849   protocols that use authenticated self-contained objects for
850   certification requests.  In existing RAs/CAs supporting such an
851   enrollment protocol (see also Section 5), these generalizations can
852   be employed without modifications.

[minor]
This seems to read odd. What about the following alternative:

"
BRSKI-AE extends the addressing scheme outlined in [RFC8995], Section 5, to support alternative enrollment protocols that utilize authenticated, self-contained objects for certification requests. These extensions are designed to be compatible with existing Registration Authorities (RAs) and Certification Authorities (CAs) that already support such enrollment protocols, enabling their use without requiring any modifications.
"

921 5.1.  BRSKI-CMP: BRSKI-AE instantiated with CMP
922
923   Instead of referring to CMP as specified in [RFC4210] and [RFC9480],
924   this document refers to the Lightweight CMP Profile (LCMPP) [RFC9483]
925   because the subset of CMP defined there is sufficient for the
926   functionality needed here.
927
928   When using CMP, adherence to the LCMPP [RFC9483] is REQUIRED.  In
929   particular, the following specific requirements apply (cf.
930   Figure 2).
931
932   *  CA Certs Request (1) and Response (2):
933       Requesting CA certificates is OPTIONAL.
934       If supported, it SHALL be implemented as specified in [RFC9483],
935       Section 4.3.1.
936
937   *  Attribute Request (3) and Response (4):
938       Requesting certification request attributes is OPTIONAL.
939       If supported, it SHALL be implemented as specified in [RFC9483],
940       Section 4.3.3.
941
942       Alternatively, the registrar MAY modify the contents of the
943       requested certificate contents as specified in [RFC9483],
944       Section 5.2.3.2.
945
946   *  Certification Request (5) and Response (6):
947       Certificates SHALL be requested and provided as specified in the
948       LCMPP [RFC9483], Section 4.1.1 (based on CRMF) or [RFC9483],
949       Section 4.1.4 (based on PKCS #10).
950
951       Proof of possession SHALL be provided in a way suitable for the
952       key type.  Proof of identity SHALL be provided by signature-based
953       protection of the certification request message as outlined in
954       [RFC9483], Section 3.2 using the IDevID secret.
955
956       When the registrar forwards a certification request by the pledge
957       to a backend RA/CA, the registrar is RECOMMENDED to wrap the
958       original certification request in a nested message signed with its
959       own credentials as described in [RFC9483], Section 5.2.2.1.  This
960       explicitly conveys the consent by the registrar to the RA while
961       retaining the original certification request message with its
962       proof of origin provided by the pledge signature.
963
964       In case additional trust anchors (besides the pinned-domain-cert)
965       need to be conveyed to the pledge, this SHOULD be done in the
966       caPubs field of the certification response rather than in a CA
967       Certs Response.
968
969   *  Certificate Confirm (7) and PKI/Registrar Confirm (8):
970       Explicit confirmation of new certificates to the RA/CA MAY be used
971       as specified in [RFC9483], Section 4.1.1.
972
973       Note that independently of the certificate confirmation within
974       CMP, enrollment status telemetry with the registrar at BRSKI level
975       will be performed as described in [RFC8995], Section 5.9.4.
976
977   *  If delayed delivery of CMP messages is needed (for instance, to
978       support enrollment over an asynchronous channel), it SHALL be
979       performed as specified in Section 4.4 and Section 5.1.2 of
980       [RFC9483].
981
982   How messages are exchanged between the registrar and backend PKI
983   components (i.e., RA and/or CA) is out of scope of this document.
984   Since CMP is independent of message transfer, the mechanism for this
985   exchange can be freely chosen according to the needs of the
986   application scenario.  For the applicable security considerations,
987   see Section 7.  Further guidance can be found in [RFC9483],
988   Section 6.
989
990   BRSKI-AE with CMP can also be combined with Constrained BRSKI
991   [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment
992   message transport as described by CoAP Transport for CMP [RFC9482].
993   In this scenario, the EST-specific parts of
994   [I-D.ietf-anima-constrained-voucher] do not apply.
995
996   For BRSKI-AE scenarios where a general solution (cf.  Section 4.2.1)
997   for discovering registrars with CMP support is not available, the
998   following minimalist approach MAY be used.  Perform discovery as
999   defined in BRSKI [RFC8995], Appendix B but using the service name
1000   "brski-registrar-cmp" (defined in Section 6) instead of "brski-
1001   registrar" (defined in [RFC8995], Section 8.6).  Note that this
1002   approach does not support join proxies.

[minor]
proposed readability rewrite:

"
In this document, references to CMP follow the Lightweight CMP Profile (LCMPP) [RFC9483] rather than [RFC4210] and [RFC9480], as the subset of CMP defined in LCMPP sufficiently meets the required functionality.

Adherence to the LCMPP [RFC9483] is REQUIRED when using CMP. The following specific requirements apply (refer to Figure 2):

  * CA Certificates Request (1) and Response (2): Requesting CA certificates is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.1.

  * Attribute Request (3) and Response (4): Requesting certification request attributes is OPTIONAL. If supported, it SHALL be implemented as specified in [RFC9483], Section 4.3.3.

  Alternatively, the registrar MAY modify the requested certificate contents as specified in [RFC9483], Section 5.2.3.2.

  * Certification Request (5) and Response (6): Certificates SHALL be requested and provided as specified in LCMPP [RFC9483], Section 4.1.1 (based on CRMF) or Section 4.1.4 (based on PKCS #10).

  Proof of possession SHALL be provided in a manner suitable for the key type. Proof of identity SHALL be provided by signature-based protection of the certification request message as outlined in [RFC9483], Section 3.2, using the IDevID secret.

  When the registrar forwards a certification request from the pledge to a backend RA/CA, it is RECOMMENDED that the registrar wraps the original certification request in a nested message signed with its own credentials, as described in [RFC9483], Section 5.2.2.1. This approach explicitly conveys the registrar's consent to the RA while retaining the original certification request with the proof of origin provided by the pledge's signature.

  If additional trust anchors, beyond the pinned-domain-cert, need to be conveyed to the pledge, this SHOULD be done in the caPubs field of the certification response rather than through a CA Certificates Response.

  * Certificate Confirm (7) and PKI/Registrar Confirm (8): Explicit confirmation of new certificates to the RA/CA MAY be used as specified in [RFC9483], Section 4.1.1.

  Note that independent of certificate confirmation within CMP, enrollment status telemetry with the registrar at the BRSKI level will be performed as described in [RFC8995], Section 5.9.4.

  * If delayed delivery of CMP messages is required (e.g., to support enrollment over an asynchronous channel), it SHALL be performed as specified in Section 4.4 and Section 5.1.2 of [RFC9483].

The mechanisms for exchanging messages between the registrar and backend PKI components (i.e., RA and/or CA) are outside the scope of this document. CMP's independence from the message transfer mechanism allows for flexibility in choosing the appropriate exchange method based on the application scenario. For applicable security considerations, refer to Section 7. Further guidance can be found in [RFC9483], Section 6.

BRSKI-AE with CMP can also be combined with Constrained BRSKI [I-D.ietf-anima-constrained-voucher], using CoAP for enrollment message transport as described by CoAP Transport for CMP [RFC9482]. In such scenarios, the EST-specific parts of [I-D.ietf-anima-constrained-voucher] do not apply.

For BRSKI-AE scenarios where a general solution for discovering registrars with CMP support is not available (cf. Section 4.2.1), the following minimalist approach MAY be used: perform discovery as defined in BRSKI [RFC8995], Appendix B, but use the service name "brski-registrar-cmp" (as defined in Section 6) instead of "brski-registrar" (as defined in [RFC8995], Section 8.6). Note that this approach does not support join proxies.
"

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-anima-brski-ae-11. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

First, in the Service Name and Transport Protocol Port Number Registry located at:

https://www.iana.org/assignments/service-names-port-numbers/

a single new service name is to be assigned as follows:

Service Name: brski-registrar-cmp
Transport Protocol: tcp
Description: Bootstrapping Remote Secure Key Infrastructure registrar with CMP capabilities according to the Lightweight CMP Profile (LCMPP, [RFC9483])
Assignee: IESG
Contact: IETF Chair
Reference: [ RFC-to-be ]

NOTE: This document lists the IESG as the contact for the registration, but according to RFC 6335 this should be the IETF Chair . This should be updated in the document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-19):

From: The IESG
To: IETF-Announce
CC: anima-chairs@ietf.org, anima@ietf.org, draft-ietf-anima-brski-ae@ietf.org, mjethanandani@gmail.com, tte@cs.fau.de
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (BRSKI-AE: Alternative Enrollment Protocols in BRSKI) to Proposed Standard


The IESG has received a request from the Autonomic Networking Integrated
Model and Approach WG (anima) to consider the following document: -
'BRSKI-AE: Alternative Enrollment Protocols in BRSKI'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-06-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines an enhancement of Bootstrapping Remote Secure
  Key Infrastructure (BRSKI, RFC 8995).  It supports alternative
  certificate enrollment protocols, such as CMP, that use authenticated
  self-contained signed objects for certification messages.

About This Document

  This note is to be removed before publishing as an RFC.

  Status information for this document may be found at
  https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/.

  Source for this draft and an issue tracker can be found at
  https://github.com/anima-wg/anima-brski-ae.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-anima-brski-ae/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document has good good consensus by all active WG members involved in BRSKI.
There where no dissenting opinions raised.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This document did evolve significantly and beneficially over the course of its life in the WG
through the input and work by WG members. See list of acknowledgements in the document. The
Shepherd does not think that any consensus on issues was ever rough though.

Mayor changes involved renaming/refocussing from "async" enrolment (which is still
a key, but not the only target benefit) over to "alternative" enrolments with
signed standalone message seucrity or when revisiting the part of the discovery mechanism to remove
more advanced mechanisms into a future document as they may take longer to finish.
All changes where resolved without without disagreements in the WG.

The document issues raised and resolved can be seen in the github:

  https://github.com/anima-wg/anima-brski-ae/issues

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

From David.von.Oheimb@siemens.com:
  Siemens has non-public implementations for the CMP instance of BRSKI-AE,
  for both the pledge and registrar side, in C and Java.
  These have been used as a PoC and for interop testing.   

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This work closely depends on the work by the same co-authors in LAMPS, RFC9483.
Coordination with that WG was through the co-authors. Aka: this draft is to a good
extend an application of RFC9483 and RFC9483 was shaped by the needs of BRSKI-AE
as a subset of CMP.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not contain any formal languages anymore after one reorg of
document content in the ANIMA WG which moved all YANG into draft-ietf-anima-rfc8366bis
(because YAND didn't allow us to partition ourmodel across multiple BRSKI extension
documents including BRSKI-AE).  The YANGDOCTORS early review for BRSKI-AE (red)
was therefore updated by a last call review to ensure it is clear that the red early
review is not applicable anymore.

The document does not include any other formal definitions requiring review other
than one IANA request for a service name.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA. (see above).

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA. (see above).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd did his final WGLC review against rev -08, see:

https://mailarchive.ietf.org/arch/msg/anima/QyEq3iB_GsYHO84b1bXpXLADCqg

-09 does resolve all remaining issue of that review and all other issues WGLC
raised against the document by WG members had also been closed on before.

The Shepherd thinks this work is needed for the use cases it addresses, clearly written,
complete, corectly designed and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Shepherd has looked through [6], and think that all the typical aspects mentioned
that are touched by this document, especially the security aspects are well reviewed,
as also shown by SECIDR Last Call review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Requested RFC publication type: Proposed Standard.
This is correctly reflected by Datatracker.

This document defines the protocol extension of BRSKI (RFC8995) to support the
CMP by using it's lightweight profile defined in RFC9483. This spec therefore describes
mechanim requiring interoperability between a number of parties (pledge, registrar,
possibly further transport entities and RA/CA).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was made to the WG mailing list during WGLC. All authors confirmed
that they are not aware of any IPR for which disclosures have not yet been filed.
Note: no disclosures have been filed according to Datatracker.

14. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, each author/editor confirmed willingness to be named as such.

Total number of authors is 3.

The shepherd thinks that the sole listed contributor 'Eliot Lear' is fine to be listed
as such from prior communications, but has sent a reconfirming query to Eliot during this
Shepherd writeup. If the reply should be negative, the Shepherd will make sure his mentioning
is fixed in the next revision of the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

After re-running IDNITS one oversight was found.
The document should put a reference against [RFC8366] after the first mentioning
of the word Voucher. This has been opened as an issue on github and will be fixed
on the next revision of the document.

All the formal requirements from the Content Guidelines are met in the understanding of
the Shepherd.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd is not sure if 802.1AE does necessarily have to be listed as normative
(instead of informative) given how it is primarily used as a reference for terminology which
has been used in prior IETF PKI related  security RFCs without similar degree of due diligence
of origin referencing. However, the decision to make it normative was not challenged by
SECDIR Last Call review and the document is also freely available from IEEE, so the
Shepherd has no concerns with the choice.

All other normative and informative reference do well match the way they are referenced by
the document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

In the understanding of the Shepherd, the IANA section is complete and consistent
with the content of the document. There is only the registration of one new
service-name for BRSKI Registrars with CMP support.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

This document has good good consensus by all active WG members involved in BRSKI.
There where no dissenting opinions raised.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This document did evolve significantly and beneficially over the course of its life in the WG
through the input and work by WG members. See list of acknowledgements in the document. The
Shepherd does not think that any consensus on issues was ever rough though.

Mayor changes involved renaming/refocussing from "async" enrolment (which is still
a key, but not the only target benefit) over to "alternative" enrolments with
signed standalone message seucrity or when revisiting the part of the discovery mechanism to remove
more advanced mechanisms into a future document as they may take longer to finish.
All changes where resolved without without disagreements in the WG.

The document issues raised and resolved can be seen in the github:

  https://github.com/anima-wg/anima-brski-ae/issues

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

From David.von.Oheimb@siemens.com:
  Siemens has non-public implementations for the CMP instance of BRSKI-AE,
  for both the pledge and registrar side, in C and Java.
  These have been used as a PoC and for interop testing.   

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This work closely depends on the work by the same co-authors in LAMPS, RFC9483.
Coordination with that WG was through the co-authors. Aka: this draft is to a good
extend an application of RFC9483 and RFC9483 was shaped by the needs of BRSKI-AE
as a subset of CMP.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not contain any formal languages anymore after one reorg of
document content in the ANIMA WG which moved all YANG into draft-ietf-anima-rfc8366bis
(because YAND didn't allow us to partition ourmodel across multiple BRSKI extension
documents including BRSKI-AE).  The YANGDOCTORS early review for BRSKI-AE (red)
was therefore updated by a last call review to ensure it is clear that the red early
review is not applicable anymore.

The document does not include any other formal definitions requiring review other
than one IANA request for a service name.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA. (see above).

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

NA. (see above).

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Shepherd did his final WGLC review against rev -08, see:

https://mailarchive.ietf.org/arch/msg/anima/QyEq3iB_GsYHO84b1bXpXLADCqg

-09 does resolve all remaining issue of that review and all other issues WGLC
raised against the document by WG members had also been closed on before.

The Shepherd thinks this work is needed for the use cases it addresses, clearly written,
complete, corectly designed and ready to be handed off to the responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Shepherd has looked through [6], and think that all the typical aspects mentioned
that are touched by this document, especially the security aspects are well reviewed,
as also shown by SECIDR Last Call review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Requested RFC publication type: Proposed Standard.
This is correctly reflected by Datatracker.

This document defines the protocol extension of BRSKI (RFC8995) to support the
CMP by using it's lightweight profile defined in RFC9483. This spec therefore describes
mechanim requiring interoperability between a number of parties (pledge, registrar,
possibly further transport entities and RA/CA).

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes. An IPR call was made to the WG mailing list during WGLC. All authors confirmed
that they are not aware of any IPR for which disclosures have not yet been filed.
Note: no disclosures have been filed according to Datatracker.

14. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes, each author/editor confirmed willingness to be named as such.

Total number of authors is 3.

The shepherd thinks that the sole listed contributor 'Eliot Lear' is fine to be listed
as such from prior communications, but has sent a reconfirming query to Eliot during this
Shepherd writeup. If the reply should be negative, the Shepherd will make sure his mentioning
is fixed in the next revision of the document.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

After re-running IDNITS one oversight was found.
The document should put a reference against [RFC8366] after the first mentioning
of the word Voucher. This has been opened as an issue on github and will be fixed
on the next revision of the document.

All the formal requirements from the Content Guidelines are met in the understanding of
the Shepherd.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The Shepherd is not sure if 802.1AE does necessarily have to be listed as normative
(instead of informative) given how it is primarily used as a reference for terminology which
has been used in prior IETF PKI related  security RFCs without similar degree of due diligence
of origin referencing. However, the decision to make it normative was not challenged by
SECDIR Last Call review and the document is also freely available from IEEE, so the
Shepherd has no concerns with the choice.

All other normative and informative reference do well match the way they are referenced by
the document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

NA.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

In the understanding of the Shepherd, the IANA section is complete and consistent
with the content of the document. There is only the registration of one new
service-name for BRSKI Registrars with CMP support.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This document was put into WG last call, but state change in datatracker was missed.
It did pass all WG last call comments except discovery issues, which are being worked on now (07/2023)