[Anima] Sheng/Robert/*: Re: Result//Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023

Toerless Eckert <tte@cs.fau.de> Thu, 23 February 2023 22:41 UTC

Date: Thu, 23 Feb 2023 23:40:59 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Sheng Jiang <shengjiang@bupt.edu.cn>, rwilton@cisco.com
Cc: anima <anima@ietf.org>, anima-chairs <anima-chairs@ietf.org>, draft-ietf-anima-brski-prm <draft-ietf-anima-brski-prm@ietf.org>, ietf <ietf@kovatsch.net>
Message-ID: <Y/fre68xSqMN5t6d@faui48e.informatik.uni-erlangen.de>
References: <tencent_60984BB55FBEF6DB66EC162D@qq.com> <1DF98913804DAEAB+202302201141452626417@bupt.edu.cn> <F5CBD70D6B467BBA+2023022011512622530413@bupt.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F5CBD70D6B467BBA+2023022011512622530413@bupt.edu.cn>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/qdqOciUPrNTtUm3OGX0Bmjv0pW4>
Subject: [Anima] Sheng/Robert/*: Re: Result//Re: WGLC for draft-ietf-anima-brski-prm-06, ends Feb. 15th, 2023
Precedence: list

Dear ANIMA-WG, Sheng, Authors

Sorry for being this late, but unfortunately, i did not manage to finish my review
of subject draft in time. In fact, even with what i am including here (which took me
about a week to work through), i am only about half way through.

This is very important and good work, unfortunately, i think there is a a range of issues
in the document, most i think easy to fix textually, and i tried to provide such fixes
everywhere i could, a few requiring some hopefully productive discussion, and even
fewer some additional text that needs to be written.

I have top posted my mayor concerns [major] summarizing what i discovered when reading
the text so far.

I have more editorial and some other [major] concerns throughout the document.

Given all those deadlines coming and going, i am not sure how to best proceed. All the
ANIMA documents are of course now top of mind and queue for me and i would like to see
them all finish timely, but hopefully also with high quality. I hope that my review
help towards thats goal, but alas timely and high quality are always somewhat contradictory.

Cheers
Toerless

[major] - missing discovery mechanisms

The document is missing specification of a single working discovery mechanism
of registrar by registrar-agent.

The mechanisms provided by RFC8995 to discover a registrar are IMHO not sufficient
for BRSKI-PRM because they explicitly only discover a BRSKI capable registrar,
but not a BRSKI-PRM capable one.

In th same way as i think we did introduce modified discovery mechanisms in
constrain brski / proxiy draft, i think we need to include appropriately
modified BRSKI service discovery option(s) that indicate that the registrar
supports BRSKI-PRM as specified in this document.

I'll be happy to help craft the text for that (just didn't want to spend time
now focussing on review).

Likewise, i would appreciate if we could also include a GRASP based discovery
of pledges by registrar-agent. Happy to propose text for that too. Primarily
because GRSP is so easily specified and extensible to distinguish different
protocol options, that even when its not of interest to implementers, it does give
good guidance of what parameters to look for in whatever discover mechanism
one does then wants to pick.

[major] - missing justification of this work

This is really not functional major, but motivationally major: I can not find in the document
good high-level text about the core logic change wrt to security of PRM versus BRSKI,
and while reading the text it felt like for a long time that the spec was doing something
unnecessarily additional, because its exactly the opposite of what BRSKI tries to
achieve:

Aka: In BRSKI, the whole idea is for everything in the deployment to be automated,
so a pledge barely needs someone to physically unbox it, connect it to power
and likely ethernet. And the whole proximity assertion is really just a
"secure connection" assertion - the pledge could be around the globe away from the
registrar - given the use of join-proxy across a WAN based ACP.

So when you come from that mindset (as i did when starting to read the doc here),
the whole overhead of the registrar-agent to create agent signed-data, which is then
reflected and signed via the pledge, so that the registrar can ultimately know
which registrar-agent was involved in soliciting the PVR/PER from the pledge looks
counter-productive: It adds complexity and process overhead by virtue of having an
LDevID authenticated registrar-agent. And its technically not necessary:

To achieve an equivalent to BRSKI's "secure connection" assertion, it would be perfectly fine
to let the new self-signed PVR/PER and their responses be forwarded by
whatever or whomever between pledge and registrar. Any pizza delivery service with
USB sticks would be fine. So why all this registrar-agent-data complexity ?

This is i think where there needs to be positive justification of the actual
value add of this core new concept. I came up with the following, but you folks
might likely have other or better justifications too that are not written down:

Suggestest text (intro section or the like):
---
BRSKI-PRM enhances the enrollment message flow so that the registrar will
cryptographically know which registrar-agent was performing the BRSKI-PRM
message passing with the pledge. Network operations may choose not to be interested
in which registrar-agent performed this operation. In this case, BRSKI-PRM
achieves similar secure enrollment properties as BRSKI, with the difference, that this is
not achieved via a secure TLS connection but via forwarding of signed message
objects. On the other hand, if the registrar does choose to take the registrar-agent
information that is tracked by BRSKI-PRM into account, then this can provide additional security
validation that are not achievable in BRSKI through cryptographic means alone.

In one (likely common) example, the registrar-agent is an application on
some mobile device (notebook, tablet, phone) of a trusted installer person who first
verifies the presence and correct physical installation (location and any other
properties) of the pledge before initiating enrollment of the pledge via simple
clicks on the registrar-agent-appplication. Later, software on the registrar
can therefore take the execution of those physical installation steps as
granted because it can verify the identity of the installer/registrar-agent
through the BRSKI-PRM agent-signed-data. In contrast, with BRSKI no trusted
installer had to be on location (which often may be a benefit), but in return,
not only could many aspects of the installation be performed incorrectly and
there is no accountability who was responsible for verifying the installation,
but it would also easily possible for a pledge to be enrolled that was not
even physically present at the location of the BRSKI join-proxy network,
but instead the pledge could be in a remote attackers location and only
a remote layer 2 bridge would be at the target installation location.
While this attack by itself can not be excluded by the mechanisms of BRSKI-PRM alone,
the tracking of the registrar-agent allows to create more accountability for
verification of the physical installation.

In summary, BRSKI-PRM utilizes the need for support of nomadic network connectivity
of a pledge to also support identification of the registrar-agent that was
performing the enrollment and therefore allows to tie the cryptographic
BRSKI-PRM messaging to other workflows performed during installation as well as
allowing for accountability of the pledges installation.
---

This may be long, and you're more than welcome not to take any of this but to
provide equivalent (but shorter) text of your own, but given the overall
complexity of all our BRSKI (and BRSKI-PRM) stuff i feel it is important to
also have this type of high level explanation and promotion of benefits for
potential adopters - and even to IETF/IESG reviewers, who likely would understand
less of what its good for than adopters.

[comments]

There is of course the more fundamental question if the need for the registrar-agent
to be LDevID authenticated in all cases does limit the applicability and therefore
possible proliferation of BRSKI-PRM by excluding those possible deployments
where BRSKI-PRM could actually be used if the message passing as e.g.: done
by pizza delivery kids and USB sticks - and where the whole agent-signed-data
stuff would be seen as unnecessary overhead. And there are IMHO easy options
of how one could still ue BRSKI-PRM beneficially in these cases. But there
are so many options that i think one would either have to write a lot of
text or be really wiggly. We had to do some amount of such text in RFC8995 wrt
to the different deployment options of MASA. I will not ask for any such text,
but if other reviewers down the road are worried about this, then the IMHO best answer
(which we also gave for MASA in RFC8995 review) is that we will pursue in this
first document the most useful and secure protocol option we think the industry
needs, and if there is need later for lower security options, we can write another RFC.

[major] concerns about appropriateness of agent-proximity / "agent-provided-proximity-registrar-certificate"

I don't think the mechanisms described in the document for the
"agent-provided-proximity-registrar-certificate" are correct.

For once, it is unclear, what purpose it serves that can otherwise not be had more
logical/better.

- it creates the new need for the registrar-agent to be provisioned or discover
the value of this field through open ended mechnisms. Most likely it will end up
being implemented as yet one more (unnecessary) nerd knob that can be mis-configured/
mis-provisioned.

- It does seem to remove the ability of BRSKI to effectively support multiple
Registrars for redundancy, failover and load-splitting, because the choice of
a registrar on a registrar-agent is now static through that provisioning. And
simple failover scenarios, wouldn't work.

- If there is operationally a benefit for one registrar-agent to do all exchanges
for one pledge with just one specific registrar, then this can easily be added
as additional registrar discovery/selection constraints by the registrar-agent
without this having to result in any impact on the message object fields or
requirements.

- The naming and inclusion into the message object fields make this mechanism
sound as if there is some form of cryptographic security involved, while in
fact there is not. The fact alone, that the registrar-agent can insert an
arbitrary domain registrar certificate from configuration is already proof
of that - and an attack vector if such a registrar-agent is impaired.

What i would suggest is to change the field to be called "proximity-registrar-agent-cert",
fill it with the agents LDevID, and then use https:// between the agent and
the pledge, at least on the first round, where the PVR/PER are requested. The pledge
must then verify that the TLS certificate of the registrar-agent and match it
against the certificate in that "proximity-registrar-agent-cert" field - and fail
if there is a mismatch.

With that setup, we do actually have the same cryptographic proximity assertion
as we did against the registrar in BRSKI - except of course now against the
agent instead of the registrar.

Now, if the whole goal of the original field is to enable the MASA to assert
the new agent-proximity in the same fashion is it can with RFC8995 assert the
"proximity", then i think no more work than the right text for MASA validating
the registrar-voucher-request is needed:

In RFC8995/5.5.5 the MASA checks
that the registrar that signed the registrar-voucher-request is also the
registrar in the prior-signed-voucher-request proximity-registrar-cert, and
that that prior-signed-voucher-request was signed by the same pledge (serial number)
that is indicated in the registrar-voucher-request.

IMHO, the equivalent for the agent-proximity assertion is that the MASA
asserts that the LDevID of the registrar-agent as contained in the prior-signed-voucher-request
new proximity-registrar-agent-cert field can be authenticated by the registrar's domain CA,
and (unchanged from BRSKI) that the prior-signed-voucher-request was signed
by the same pledge (serial number) that is indicated in the registrar-voucher-request.
As described in RFC8995 Section 5.5.2 - 5.5.5, the domain CA MAY be derived from
the CMS signature of the registrars voucher-request. If the registrar is aware
that this is done by the MASA, then it SHOULD include in its CMS signature certificate
chain all the certs of its certificate chain to also cover the LDevID of the
reigstrar-agent.

[major] explanations about responder mode being a pledge-only, or a lifetime condition.

This document introduces support for pledges that want to operate in responder mode,
but what it does not diskuss is whether this is a condition that the pledge only
requires while being a pledge or whether it is a lifetime condition. The document
needs to make a statement about this. To me it sounds as if during the lifetime
both options may be desirable - for different type of deployments. Even if this
document wants to be scoped to just one option "prm only during initial enrol",
or "prm during lifetime", do we need to make sure that this document does not introduce
mechanisms which would later make the other option more difficult.

[major] certificate renewal/rekeying

The document does define a mechanism for PRM certificate enrollment, something
neither BRSKI nor BRSKI-coaps (constrained brski) do. Both let EST/EST-coaps RFCs handle
certificate enrollment proper.

By trading into EST territory, i think that BRSKI-PRM needs to not only
answer how to do initial enrolment, but also re-enrolment: certificate renewal/rekeying.

This should be in this document, because the enrolled pledges in question will
need some form of renewal/rekeying support, and because we have so far never tried to
split up enrollment procedures for initial and re-enrollment into separate drafts
(not only EST, but also other enrollments, such as CMC), and i am worried that a
later separate re-enrolment draft could become a lot more difficult.

[major] use of registrar endpoints for responder vs. initiator mode

If i am not mistaken, JSON with JWS could be a popular encoding/authentication format that
BRSKI and/or EST deployment might want to choose even for non-PRM, but "simple"
initiator mode pledges and enrolled clients.

We do not need to be concerned about specifying the messages for such non-PRM modes
in this spec, but i think we should at least not make future work to support JSON
with JWS in BRSKI/EST harder.

If i understand it correctly, voucher requests from agent to registrar would use
according to this spec:

URL operation path: /requestvoucher
Content-Type: application/voucher-jws+json

Now assume a registrar would not support BRSKI PRM but some future "normal" BRSKI
just with JWS+JSON encoding of voucher using some future draft defined
"ietf-voucher-request:voucher" requestvoucher representation (no PRM!).

Should such a simple JWS+JSON form of BRSKI not logically expect to be able
to use exactly the same combination of operation path and Content-Type ?
I think this would be the preferred choice.

But if both BRSKI-PRM and non PRM would want to use the same combination of
operation path and content type, then a registrar would not be able to
signal the highly useful HTTP 415 (unsupported media type error) when
it was not supporting on of the two options. Nor could the initiator explicitly
ask for the right option - because both PRM and non-PRM would share the
same media-type.

Long story short, i would suggest to change the media-type for PRM to:

application/voucher+prm+ws+json

The same consideration should be used for any other media type this
document uses where the endpoint could likely be shared between
PRM and non-PRM in the future.

Of course, there are alternatives like introducing PRM specific endpoints.
I really have no good criteria to pick one over the other, a.a.: to
me "/requestvoucher-prm" would be equally fine.

Rest of comments inline, following, numbering from idnits.

----
idnits 2.17.1

draft-ietf-anima-brski-prm-06.txt:

Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------

No issues found here.

Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------

No issues found here.

Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------

No issues found here.

Miscellaneous warnings:
----------------------------------------------------------------------------

-- Found something which looks like a code comment -- if you have code
sections in the document, please surround them with '<CODE BEGINS>' and
'<CODE ENDS>' lines.

No idea what the correct response to this IDNITS concern is. ignore ?
Can not remember having seen this yet.

== Outdated reference: A later version (-07) exists of
draft-ietf-anima-rfc8366bis-00

2 ANIMA WG S. Fries
3 Internet-Draft T. Werner
4 Intended status: Standards Track Siemens
5 Expires: 15 July 2023 E. Lear
6 Cisco Systems
7 M. Richardson
8 Sandelman Software Works
9 11 January 2023

11 BRSKI with Pledge in Responder Mode (BRSKI-PRM)
12 draft-ietf-anima-brski-prm-06

14 Abstract

16 This document defines enhancements to bootstrapping a remote secure
17 key infrastructure (BRSKI, RFC8995) to facilitate bootstrapping in
18 domains featuring no or only time limited connectivity between a
19 pledge and the domain registrar. It specifically targets situations
20 in which the interaction model changes from a pledge-initiated-mode,
21 as used in BRSKI, to a pledge-responding-mode as described in this
22 document. To support the pledge-responding mode, BRSKI-PRM
23 introduces a new component, the registrar-agent, which facilitates
24 the communication between pledge and registrar during the
25 bootstrapping phase. To establish the trust relation between pledge
26 and domain registrar, BRSKI-PRM relies on object security rather than
27 transport security.

29 The approach defined here is agnostic with respect to the underlying
30 enrollment protocol which connects the pledge and the domain
31 registrar to the Domain CA.

33 About This Document

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

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

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

43 Status of This Memo

45 This Internet-Draft is submitted in full conformance with the
46 provisions of BCP 78 and BCP 79.

48 Internet-Drafts are working documents of the Internet Engineering
49 Task Force (IETF). Note that other groups may also distribute
50 working documents as Internet-Drafts. The list of current Internet-
51 Drafts is at https://datatracker.ietf.org/drafts/current/.

53 Internet-Drafts are draft documents valid for a maximum of six months
54 and may be updated, replaced, or obsoleted by other documents at any
55 time. It is inappropriate to use Internet-Drafts as reference
56 material or to cite them other than as "work in progress."

58 This Internet-Draft will expire on 15 July 2023.

60 Copyright Notice

65 This document is subject to BCP 78 and the IETF Trust's Legal
66 Provisions Relating to IETF Documents (https://trustee.ietf.org/
67 license-info) in effect on the date of publication of this document.
68 Please review these documents carefully, as they describe your rights
69 and restrictions with respect to this document. Code Components
70 extracted from this document must include Revised BSD License text as
71 described in Section 4.e of the Trust Legal Provisions and are
72 provided without warranty as described in the Revised BSD License.

74 Table of Contents

76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
78 3. Scope of Solution . . . . . . . . . . . . . . . . . . . . . . 7
79 3.1. Supported Environments and Use Case Examples . . . . . . 7
80 3.1.1. Building Automation . . . . . . . . . . . . . . . . . 8
81 3.1.2. Infrastructure Isolation Policy . . . . . . . . . . . 9
82 3.1.3. Less Operational Security in the Target-Domain . . . 9
83 3.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 9
84 4. Requirements Discussion and Mapping to Solution-Elements . . 9
85 5. Architectural Overview . . . . . . . . . . . . . . . . . . . 11
86 5.1. Pledge-Responder-Mode (PRM): Registrar-Agent Communication
87 with Pledges . . . . . . . . . . . . . . . . . . . . . . 12
88 5.2. Agent-Proximity Assertion . . . . . . . . . . . . . . . . 15
89 5.3. Behavior of Pledge in Pledge-Responder-Mode . . . . . . . 16
90 5.4. Behavior of Registrar-Agent . . . . . . . . . . . . . . . 17
91 5.4.1. Discovery of Registrar by Registrar-Agent . . . . . . 19
92 5.4.2. Discovery of Pledge by Registrar-Agent . . . . . . . 19
93 6. Bootstrapping Data Objects and Corresponding Exchanges . . . 19
94 6.1. Request Objects Acquisition by Registrar-Agent from
95 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 22

97 6.1.1. Pledge-Voucher-Request (PVR) - Trigger . . . . . . . 24
98 6.1.2. Pledge-Voucher-Request (PVR) - Response . . . . . . . 25
99 6.1.3. Pledge-Enrollment-Request (PER) - Trigger . . . . . . 28
100 6.1.4. Pledge-Enrollment-Request (PER) - Response . . . . . 28
101 6.2. Request Object Handling initiated by the Registrar-Agent on
102 Registrar, MASA and Domain CA . . . . . . . . . . . . . . 31
103 6.2.1. Connection Establishment (Registrar-Agent to
104 Registrar) . . . . . . . . . . . . . . . . . . . . . 33
105 6.2.2. Pledge-Voucher-Request (PVR) Processing by
106 Registrar . . . . . . . . . . . . . . . . . . . . . . 33
107 6.2.3. Registrar-Voucher-Request (RVR) Processing (Registrar
108 to MASA) . . . . . . . . . . . . . . . . . . . . . . 34
109 6.2.4. Voucher Issuance by MASA . . . . . . . . . . . . . . 37
110 6.2.5. MASA issued Voucher Processing by Registrar . . . . . 38
111 6.2.6. Pledge-Enrollment-Request (PER) Processing
112 (Registrar-Agent to Registrar) . . . . . . . . . . . 41
113 6.2.7. Request Wrapped-CA-certificate(s) (Registrar-Agent to
114 Registrar) . . . . . . . . . . . . . . . . . . . . . 42
115 6.3. Response Object Supply by Registrar-Agent to Pledge . . . 43
116 6.3.1. Pledge: Voucher Response Processing . . . . . . . . . 44
117 6.3.2. Pledge: Voucher Status Telemetry . . . . . . . . . . 45
118 6.3.3. Pledge: Wrapped-CA-Certificate(s) Processing . . . . 46
119 6.3.4. Pledge: Enrollment Response Processing . . . . . . . 47
120 6.3.5. Pledge: Enrollment Status Telemetry . . . . . . . . . 47
121 6.3.6. Telemetry Voucher Status and Enroll Status Handling
122 (Registrar-Agent to Domain Registrar) . . . . . . . . 48
123 6.4. Request Pledge-Status by Registrar-Agent from Pledge . . 50
124 6.4.1. Pledge-Status - Trigger (Registrar-Agent to
125 Pledge) . . . . . . . . . . . . . . . . . . . . . . . 51
126 6.4.2. Pledge-Status - Response (Pledge -
127 Registrar-Agent) . . . . . . . . . . . . . . . . . . 53
128 7. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 57
129 7.1. Voucher Request Artifact . . . . . . . . . . . . . . . . 57
130 7.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 57
131 7.1.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 57
132 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
133 8.1. BRSKI .well-known Registry . . . . . . . . . . . . . . . 61
134 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 61
135 10. Security Considerations . . . . . . . . . . . . . . . . . . . 62
136 10.1. Denial of Service (DoS) Attack on Pledge . . . . . . . . 62
137 10.2. Misuse of acquired PVR and PER by Registrar-Agent . . . 63
138 10.3. Misuse of Registrar-Agent Credentials . . . . . . . . . 63
139 10.4. Misuse of mDNS to obtain list of pledges . . . . . . . . 64
140 10.5. YANG Module Security Considerations . . . . . . . . . . 64
141 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 64
142 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
143 12.1. Normative References . . . . . . . . . . . . . . . . . . 64
144 12.2. Informative References . . . . . . . . . . . . . . . . . 66

146 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 68
147 A.1. Example Pledge Voucher Request - PVR (from Pledge to
148 Registrar-agent) . . . . . . . . . . . . . . . . . . . . 68
149 A.2. Example Parboiled Registrar Voucher Request - RVR (from
150 Registrar to MASA) . . . . . . . . . . . . . . . . . . . 70
151 A.3. Example Voucher Response (from MASA to Pledge, via
152 Registrar and Registrar-agent) . . . . . . . . . . . . . 74
153 A.4. Example Voucher Response, MASA issued Voucher with
154 additional Registrar signature (from MASA to Pledge, via
155 Registrar and Registrar-agent) . . . . . . . . . . . . . 75
156 Appendix B. History of Changes [RFC Editor: please delete] . . . 77
157 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 85
158 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85

160 1. Introduction

162 BRSKI as defined in [RFC8995] specifies a solution for secure zero-
163 touch (automated) bootstrapping of devices (pledges) in a (customer)
164 site domain. This includes the discovery of network elements in the

s/network elements/BRSKI registrar/ ? Or am i overlooking another option ?

165 customer site/domain and the exchange of security information
166 necessary to establish trust between a pledge and the domain.

168 Security information about the customer site/domain, specifically the
169 customer site/domain certificate, is exchanged utilizing voucher

probably s/is/are/

maybe "exchanged and authenticated"

170 request objects and voucher response objects as defined in [RFC8995].
171 Voucher objects are specified in [RFC8366]. Vouchers are signed
172 objects from the Manufacturer's Authorized Signing Authority (MASA).
173 The MASA issues the voucher object and provides it via the domain
174 registrar to the pledge.

176 For the certificate enrollment of devices, BRSKI relies on EST
177 [RFC7030] to request and distribute customer site/domain specific
178 device certificates. EST in turn relies on a binding of the
179 certification request to an underlying TLS connection between the EST
180 client and the EST server.

Maybe more precise: relies for authentication and authorization of the
certification request on the credentials used by for underlying TLS

182 BRSKI addresses scenarios in which the pledge initiates the
183 bootstrapping acting as a client (this document refers to this
184 approach as pledge-initiator-mode). In industrial environments the
185 pledge may behave as a server and thus does not initiate the
186 bootstrapping with the domain registrar. In this scenario, it is
187 expected that the pledge will be triggered to generate bootstrapping
188 requests in the customer site/domain. This document refers to this
189 approach as pledge-responder-mode and

191 * introduces the registrar-agent as new component to facilitate the
192 communication between the pledge and the registrar, as the pledge
193 is in responder mode, and acts as server. For the interaction
^^^^^^^^^^^^^^^^^^^^^

Let me go on a quick rant here:

My problem is that in my understanding, client/server are overloaded terms. Whether we use
BRSKI-classic or PRM, the Registrar is IMHO logically always the server of
BRSKI enrolment services. And the pledge is always the client of these
services. Then HTTP also uses the term client/server (it does not use initiator/responder),
but thats only wrt to the HTTP (session) layer. Not the service that is served/consumed
SOAP, which also reverses roles complains therefore heavily over HTTP (rfc4743).

Aka: with PRM, the REgistrar is still the registration service provider (service) and
the pledge its consumer (client), but on the HTTP side we've reversed client/server
roles. And that makes the use of client/server confusing.

So i would suggest you pick including mix and match as you like from the following choices:

- Use "HTTP client", "HTTP server"
- And if the intent of the use client/server is not for HTTP only in the context
where you use it, add another appropriate prefix (BRSKI service for example).
- best: Use HTTP initiator / HTTP responder only, not client/server

But no unqualified use of client/server.

194 with the domain registrar the registrar-agent will use existing
195 BRSKI [RFC8995] endpoints as well as additional endpoints defined

endpoints (see below in this section)

although it would be better to avoid forward pointers to the below explanation/
introduction of the term and pull that explanation into its first use if possible.

196 in this document. The registrar-agent may be implemented as an
197 integrated functionality of a commissioning tool or be co-located
198 with the registrar itself.

200 * specifies the interaction (data exchange and data objects) between
201 a pledge acting as server and a registrar-agent and the domain
202 registrar. The security is addressed on the application layer
203 only to enable usage of arbitrary transport means between the
204 pledge and the domain registrar via the registrar-agent.
205 Connectivity between the pledge and the registrar-agent may be via
206 IP-based networks (wired or wireless) but also via Bluetooth or
207 NFC.

I want I2C (such as SMBus between BMC and CPU on servers..).
Derailing aside: "But also others, such as Bluetooth ..."

209 * allows the application of registrar-agent credentials to establish
210 TLS connections to the domain registrar. These registrar-agent
211 credentials are different from the pledge's IDevID.

213 The term endpoint used in the context of this document is similar to
214 resources in CoAP [RFC7252] and also in HTTP [RFC9110]. It is not
215 used to describe a device. Endpoints are accessible via .well-known
216 URIs.

Please use throughout the document a more explicit term like
"protocol endpoint" or "service endpoint". I at least am really triggered every
time i read the unqualified term. Search google and see what's returned:

https://www.google.com/search?q=computer+networking+what+is+an+endpoint

And given how BRKI/ANIMA is a set of network centric specifications, as opposed
to CoAP/HTTP, which i'd say are much more "protocol" centric, i would fear that
more people than just myself would be confused by the unqualified use of the
term.

Also add to terminology section.

218 To utilize the EST server endpoints on the domain registrar, the

Ok. *sigh* i guss we can't change "EST server" to at least "EST-server" because
of inconsistency with all our prior docs. So keep this term.

219 registrar-agent will act as client towards the domain registrar.

221 The registrar-agent also acts as a client when communicating with a
222 pledge in responder mode. Here, TLS with server-side, certificate-
223 based authentication is not directly applicable, as the pledge only
224 possesses an IDevID certificate. The IDevID does not contain any
225 anchor for which any kind of [RFC6125] validation can be done.
226 Second, the registrar-agent may not be aware of manufacturer trust
227 anchors to validate the IDevIDs. Finally, IDevIDs do not typically
228 set Extended Key Usage (EKU) for TLS WWW Server authentication.

This isn't very persuasively written to make the point.

Maybe something like:

The motivation for object security is that the registrar agent should be lightweight
and as much zero-or auto-provisioned as possible. RFC6125 would fit those
requirements but can not be used. Authentication via the manufacturer trust
anchor as used on BRSKI Registrar does not fit those requirements because
those trust anchor have no automatable provisioning backend option. So
we want a solution similar in spirit to the BRSKI join proxy - don't get involved
in security, just pass on the information - but with reversal of the initiator/responder
assignments. Hence object security model.

230 The inability to effectively do TLS in responder mode is one reason
231 for relying on object security. Another reason is the application on
232 different transports channels, for which TLS may not be available,
233 such as Bluetooth and NFC.

235 Therefore, BRSKI-PRM relies on an additional signature wrapping of
236 the exchanged data objects . For EST [RFC7030] the registrar then
^

... with involvement of the registrar agent

237 needs to do some pre-processing to verify this signature, which is
238 not present in EST.

240 2. Terminology

242 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
243 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
244 "OPTIONAL" in this document are to be interpreted as described in
245 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
246 capitals, as shown here.

248 This document relies on the terminology defined in [RFC8995], section
249 1.2. The following terms are defined additionally:

251 authenticated self-contained object: Describes an object, which is
252 cryptographically bound to the end entity (EE) certificate (IDevID
253 certificate or LDEVID certificate). The binding is assumed to be
254 provided through a digital signature of the actual object using
255 the corresponding private key of the EE certificate.

257 CA: Certification authority, issues certificates.

259 Commissioning tool: Tool to interact with devices to provide
260 configuration data

262 CSR: Certificate Signing Request

264 EE: End entity

266 mTLS: Mutual authenticated Transport Layer Security.

268 on-site: Describes a component or service or functionality available
269 in the customer site/domain.

271 off-site: Describes a component or service or functionality not
272 available within the customer site/domain. It may be at a central
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
on-site ?! (eat your own dog-food ?)

273 site or an internet resident "cloud" service. The connection may

s/connection/on-site to off-site connection/

274 also be temporary and, e.g., only available at times when workers
275 are present on a construction side, for instance.

277 PER: Pledge-enrollment-request is a signature wrapped CSR, signed by
278 the pledge that requests enrollment to a domain

280 POP: Proof of possession (of a private key)

282 POI: Proof of identity (see Section 4)

Abbreviations: POP/POI: You do only use these abbreviations when defining and explaining the terms.
Suggest to remove these two abbreviations throughout the document and stick
to the full terms, unless you really start using the abbreviations in the
document (such as in pictures).

Please change terms throughout document to proof-of-possession and proof-of-identity,
as this is what rfc7030 uses. Please define terms here, and not later in
section 4. Suggest to use definitions from rfc5272, include reference to it
for both definitions, and as necessary expand from "server" to "recipient" for
proof of identity.

284 PVR: Pledge-Voucher-Request is a request for a voucher signed by the
285 Pledge to the Registrar.

This can easily be misread as 'request for "a voucher signed by the pledge"',
instead of '"request for a voucher" signed by the Pledge'. Please rephrase to
remove such ambiguity.

287 RA: Registration authority, an optional system component to which a
288 CA delegates certificate management functions such as
289 authorization checks.

291 RER: Registrar-enrollment-request is the CSR of PER sent to the CA

s/of/of a/

292 by the registrar (RA/LRA)

294 RVR: Registrar-Voucher-Request is a request for a voucher signed by
295 the Registrar to the MASA. It may contain the PVR received from
296 the pledge.

298 This document includes many examples that would contain many long
299 sequences of base64 encoded objects with no content directly
300 comprehensible to a human reader.

300 In order to keep them readable the
301 examples use the token "base64encodedvalue==" whenever such a thing
302 occurs. This token is in fact valid base64. The full examples are
303 in appendix.

Suggest rewrite of 300-303:

In order to keep those examples short, they use the token "base64encodedvalue=="
as a placeholder for base64 data. The full base64 data is included in
the appendices of this document.

305 This protocol unavoidably has a mix of both base64 encoded data (as
306 is normal for many JSON encoded protocols), and also BASE64URL
307 encoded data, as specified by JWS. The later is indicated by a
308 string like "BASE64URL(THING)"

310 3. Scope of Solution

312 3.1. Supported Environments and Use Case Examples

314 BRSKI-PRM is applicable to environments where pledges may have
315 different behavior: pledge-responder-mode, or pledges may have no

pledges in initiator mode ?

316 direct connection to the domain registrar. Either way pledges are

direct and/or continuous connection ?

317 expected to be managed by the same registrar.

Both type of pledges can be supported via the same registrar ... and registrar agent ??
or else ... but using different registar agent setups.

319 This can be motivated by pledges deployed in environments not yet
320 connected to the operational customer site/domain network, e.g., at a
321 construction site where a building is going up.

323 Another environment relates to the assembly of cabinets, which are
324 prepared in advance to be installed on a customer site/domain.

326 As there is no direct connection to the registrar available in these
327 environments the solution specified allows the pledges to act in a
328 server role so they can be triggered for bootstrapping e.g., by a
329 commissioning tool.

331 As BRSKI focuses on the pledge in a client role, initiating the
332 bootstrapping (pledge-initiated-mode), BRSKI-PRM defines pledges

focusses on vs defines ? pick one term for both cases. Suggest defines
as you also use this later.

333 acting as a server (pledge-responder-mode) responding to PVR and PER
334 and consumption of the results.

336 The following examples motivate support of BRSKI-PRM to support
337 pledges acting as server as well as pledges with limited connectivity
338 to the registrar.

340 While BRSKI-PRM defines support for pledges in responder mode, there
341 may be pledges which can act as both initiator or responder. In
342 these cases BRSKI-PRM can be combined with BRSKI as defined in
343 [RFC8995] or BRSKI-AE [I-D.ietf-anima-brski-ae] to allow for more
344 bootstrapping flexibility.

346 A pledge which can initiate, SHOULD listen for BRSKI messages as
347 described in [RFC8995], Section 4.1. Upon discovery of a potential
348 Registrar,

These are not BRSKI message.

But this also seems to duplicate in a possible non-consistent fashio
requiremens from RFC8995

348 it SHOULD initiate the bootstrapping to that Registrar.
349 At the same time (so as to avoid the Slowloris-attack described in
350 [RFC8995]), it SHOULD also respond to the pledge-responder-mode
351 connections described in this document.

Whole paragraph replace ?

An RFC8995 complaint pledge thats also supports BRSKI PRM
SHOULD be able to respond to pledge-responder-mode connections described in this
document in parallel to initiating bootstrapping to the registar to avoid
the Slowloris attack described in [RFC8995].

353 Once a pledge with such combined functionality has been bootstrapped,
354 it MAY act as client for enrollment or re-enrollment of further
355 certificates needed, e.g., using the enrollment protocol of choice.

"re-enrolment of further certificates" sounds wrong (where was the initial
enrolment of further certificates ?).

Is cert and/or key renewal supported via PRM ? Would be good to state.

356 If it still acts as server, the defined endpoints can be used to

BRSKI-PRM defined <qualifier> enpoints ?

357 trigger a Pledge-Enrollment-Request (PER) for further certificates.

359 3.1.1. Building Automation

361 In building automation a typical use case exists where a detached
362 building (or a cabinet) or the basement of a building is equipped
363 with sensors, actuators and controllers, but with only limited or no
364 connection to the central building management system. This limited
365 connectivity may exist during installation time or also during
366 operation time.

368 During the installation, for instance, in the basement, a service
369 technician collects the device specific information from the basement
370 network and provides them to the central building management system.
371 This could be done using a laptop, common mobile device, or dedicated
372 commissioning tool to transport the information. The service
373 technician may visit every new house in a subdivision collecting

s/house/building/

374 device specific information before connecting to the Registrar.

376 A domain registrar may be part of the central building management
377 system and already be operational in the installation network. The
378 central building management system can then provide operational
379 parameters for the specific devices in the basement. These
380 operational parameters may comprise values and settings required in
381 the operational phase of the sensors/actuators, among them a
382 certificate issued by the operator to authenticate against other
383 components and services. These operational parameters are then
384 provided to the devices in the basement facilitated by the service
385 technician's laptop.

Just a thought:

Might be useful to mention the registrar-agent here so the description ties
into this specification... mention that it could run for example on the
technican's laptop ?

387 3.1.2. Infrastructure Isolation Policy

389 This refers to any case in which the network infrastructure is
390 normally isolated from the Internet as a matter of policy, most
391 likely for security reasons. In such a case, limited access to a
392 domain registrar may be allowed in carefully controlled short periods
393 of time, for example when a batch of new devices are deployed, but
394 prohibited at other times.

396 3.1.3. Less Operational Security in the Target-Domain

398 The registration authority (RA) performing the authorization of a
399 certificate request is a critical PKI component and therefore
400 requires higher operational security than other components utilizing
401 the issued certificates. CAs may also require higher security in the
402 registration procedures. There may be situations in which the
403 customer site/domain does not offer enough security to operate a RA/
404 CA and therefore this service is transferred to a backend that offers
405 a higher level of operational security.

407 3.2. Limitations

409 The mechanism described in this document presumes the availability of
410 the pledge and the registrar-agent to communicate with another. This
411 may not be possible in constrained environments where, in particular,
412 power must be conserved. In these situations, it is anticipated that
413 the transceiver will be powered down most of the time. This presents
414 a rendezvous problem: the pledge is unavailable for certain periods
415 of time, and the registrar-agent is similarly presumed to be
416 unavailable for certain periods of time.

Can you rewrite this as "Challenge" and explaining that this requires sufficiently
longer period of uptime of the registrar-agent and/or additional workarounds
such as manually waking up pledges through some physcial operation on them ?
(shake to wake ;-).

If you keep it as Limitation, it sounds like the solution can not work
for these environments - without saying so much, and without hinting at
what else one would potentially then need to do. Leaves the reader with
unanswered questions...

418 4. Requirements Discussion and Mapping to Solution-Elements

420 Based on the intended target environment described in Section 3.1 the
421 following requirements are derived to support bootstrapping of
422 pledges in responder mode (acting as server).

424 * To facilitate the communication between a pledge in responder mode
425 and registrar, additional functionality is needed either on the
426 registrar or as a stand-alone component. This new functionality
427 is defined as registrar-agent and acts as an agent of the
428 registrar to trigger the pledge to generate requests for voucher
429 and enrollment. These requests are then provided by the
430 registrar-agent to the registrar. This requires the definition of
431 pledge endpoints to allow interaction with the registrar-agent.

433 * The communication between the registrar-agent and the pledge MUST
434 NOT rely on transport layer security (TLS) because the pledge does
435 not have a certificate that can easily be verified by [RFC6125]
436 methods. It is also more difficult to use TLS over other
437 technology stacks (e.g., BTLE).

see discussion earlier in the text where you made this argument already and
think if the text here can similarily be improved to make this
argument stronger.

439 * The use of authenticated self-contained objects provides a work
440 around for both the TLS challenges, and the technology stack
441 challenge.

It seems these first three bullet points detail primarily the pledge<->
registrar-agent leg. It seems they would flow better if you numbered all
points, then reorder 2, 3, 1, and in 1 you would pick up and not
say "requests" but "request objects", as a conclusion of points 2, 3.

443 * By contrast, the registrar-agent can be authenticated by the
444 registrar as a component, acting on behalf of the registrar. In
445 addition the registrar must be able to verify, which registrar-
^ delete
446 agent was in direct contact with the pledge.

"had on-site contact with" - "direct" sounds like sub-ip (subnet) connectivity,
which is probably correct too, but you did not introduce that condition
yet i think. And it probably depends a lot on which mechanisms are used
for discovery between pledge and registrar-agent. If that was some form
of mesh network like in thread, this would be an L3 connection, so "direct"
would not be correct ?

448 * It would be inaccurate for the voucher request and voucher
449 response to use an assertion with value "proximity" in the

insert reference to rfc8366 section defining proximity.

450 voucher, as the pledge was not in direct contact with the
451 registrar for bootstrapping. Therefore a new "agent-proximity"
452 assertion value is necessary for distinguishing assertions the
453 MASA can state.

Maybe delete "the MASA can state" because you didn't explain what/how
asertions are used and so you might rather open questions for readers here
that you don't answer directly.

455 At least the following properties are required for the voucher and
456 enrollment processing:

458 * Proof of Identity (POI): provides data-origin authentication of a
459 data object, e.g., a voucher request or an enrollment request,
460 utilizing an existing IDevID. Certificate updates may utilize the
461 certificate that is to be updated.

463 * Proof of Possession (POP): proves that an entity possesses and
464 controls the private key corresponding to the public key contained
465 in the certification request, typically by adding a signature
466 computed using the private key to the certification request.

As said in terminology section, pls. don't (re)define terms here.

468 Solution examples based on existing technology are provided with the
469 focus on existing IETF RFCs:

471 * Voucher requests and responses as used in [RFC8995] already
472 provide both, POP and POI, through a digital signature to protect
^ ^
remove
473 the integrity of the voucher, while the corresponding signing
474 certificate contains the identity of the signer.

476 * Certification requests are data structures containing the
477 information from a requester for a CA to create a certificate.
478 The certification request format in BRSKI is PKCS#10 [RFC2986].
479 In PKCS#10, the structure is signed to ensure integrity protection
480 and proof of possession of the private key of the requester that
481 corresponds to the contained public key. In the application
482 examples, this POP alone is not sufficient. A POI is also
483 required for the certification request and therefore the
484 certification request needs to be additionally bound to the
485 existing credential of the pledge (IDevID). This binding supports
486 the authorization decision for the certification request and may
487 be provided directly with the certification request. While BRSKI
488 uses the binding to TLS, BRSKI-PRM aims at an additional signature
489 of the PKCS#10 using existing credentials on the pledge (IDevID).
490 This allows the process to be independent of the selected
491 transport.

This explanation is conflating too many things in one big paraagraph. REstructure to split between explaining
first the need for signed message objects first and then say afterwards in a new
paragraph that such signed message objects already exist and are commonly used, such as
PKCS#10, and that this has only to be adopted to BRSKI-PRM.

49 5. Architectural Overview

495 For BRSKI with pledge in responder mode, the base system architecture
496 defined in BRSKI [RFC8995] is enhanced to facilitate the new use
497 cases in which the pledge acts as server. The pledge-responder-mode
498 allows delegated bootstrapping using a registrar-agent instead of a
499 direct connection between the pledge and the domain registrar.

This does IMHO not explain the fundamental reasoning from requirement to solution.

Something like this... ?

1. The use cases that BRSKI-PRM intends to facilitate require support for nomadic,
short-term, non-planned connectivity of the pledge to the BRSKI infrastructure.

2. This is enabled primarily through the use of self-authenticated message objects
that can be propagated independent of underlying transport mechanisms, unlike
TLS that is used in BRSKI and requires an ongoing, reliable network connection.

3. To support the use of such message objects across arbitrary thranspors with minimal
changes to existing BRSKI components, the new function of the registrar-agent is introduced,
which is front-ending the BRSKI registrar and allowing arbitrary (nomadic) transport for
authenticated message object with the pledge and TLS with the Registrar.

Just check how you avoid also duplication of text with section 4. IMHO
everything relaetd to explanation because of use-case requirements could best
be done only in section 4.

501 Necessary enhancements to support authenticated self-contained
502 objects for certificate enrollment are kept at a minimum to enable
503 reuse of already defined architecture elements and interactions.

505 For the authenticated self-contained objects used for the
506 certification request, BRSKI-PRM relies on the defined message
507 wrapping mechanisms of the enrollment protocols stated in Section 4
508 above.

510 The security used within the document for bootstrapping objects
511 produced or consumed by the pledge bases on JOSE [RFC7515]. In

s/bases/is based/

512 constrained environments it may provided based on COSE [RFC9052] and

s/may/may be/

513 [RFC9053].

515 An abstract overview of the BRSKI-PRM protocol can be found in
516 [BRSKI-PRM-abstract].

518 5.1. Pledge-Responder-Mode (PRM): Registrar-Agent Communication with
519 Pledges

521 To support mutual trust establishment between the domain registrar
522 and pledges not directly connected to the customer site/domain, this
523 document specifies the exchange of authenticated self-contained
524 objects (the voucher request/response as known from BRSKI and the
525 enrollment request/response as introduced by BRSKI-PRM) with the help
526 of a registrar-agent.

528 This leads to extensions of the logical components in the BRSKI
529 architecture as shown in Figure 1. Note that the Join Proxy is
530 neglected in the figure as not needed by the registrar-agent. The

Suggest to replace note sentence with:

In the BRSKI-PRM setup, the registrar-agent replaces the RFC8995 Join Proxy.

531 registrar-agent interacts with the pledge to transfer the required
532 data objects for bootstrapping, which are then also exchanged between
533 the registrar-agent and the domain registrar. The addition of the

Suggest new paragraph start here.

534 registrar-agent influences the sequences of the data exchange between
535 the pledge and the domain registrar as described in [RFC8995]. To
536 enable reuse of BRSKI defined functionality as much as possible,
537 BRSKI-PRM:

539 * uses existing endpoints where the required functionality is
540 provided

s/is provided/meets BRSKI-PRM requirements/

542 * enhances existing endpoints with new supported media types, e.g.,
543 for JWS voucher

545 * defines new endpoints where additional functionality is required,
546 e.g., for wrapped certification request, CA certificates, or new
547 status information.

549 +------------------------+
550 +---- Drop Ship ----------| Vendor Service |
551 | +------------------------+
552 | | M anufacturer| |
553 | | A uthorized |Ownership|
554 | | S igning |Tracker |
555 | | A uthority | |
556 | +--------------+---------+
557 | ^
558 | | BRSKI-
559 | BRSKI-PRM | MASA
560 | .............................|.........
561 V . v .
562 +-------+ . +-----------+ +-----------+ .
563 | | . | | | | .
564 |Pledge | . | Registrar | BRSKI | Domain | .
565 | | . | Agent | EST | Registrar | .
566 | |<------>| |<----->| (PKI RA) | .
567 | | . | LDevID| | | .
568 | | . +-----------+ +-----+-----+ .
569 |IDevID | . | .
570 | | . +------------------+-----+ .
571 +-------+ . | Key Infrastructure | .
572 . | (e.g., PKI Certificate | .
573 . | Authority) | .
574 . +------------------------+ .
575 .......................................
576 "Domain" components

578 Figure 1: Architecture overview using registrar-agent

The picture is missing to show what is "on-site" vs. "off-site".

Suggest to use the following picture.

I am also unclear whose LDevID is shown in the Registrar Agent box.
If it is the Pledges IDevID, then i would suggest to remove it, because
its kinda misleading. If its the Registrar Agent LDevID to indicate
it needs to be enrolled in domain to be trusted by Registrar, then
i suggest to qualify term with e.g.: "agent LDevID".

+---- Drop Ship --------| Vendor Service |
| +------------------------+
| | M anufacturer| |
| | A uthorized |Ownership|
| | S igning |Tracker |
| | A uthority | |
| +--------------+---------+
| ^
| agent can move | BRSKI-
| off-site <=> on-site | MASA
......|................ ............|......................
. V . . v .
. +-------+ +-----------+ +-----------+ .
. | | | | | | .
. |Pledge | | Registrar | BRSKI | Domain | .
. | | | Agent | EST | Registrar | .
. | |<------->| |<----->| (PKI RA) | .
. | |BRSKI-PRM| | | | .
. | | +-----------+ +-----+-----+ .
. |IDevID | . . ^ | .
. | | . . | +--+---------------+ .
. +-------+ . . | |Key Infrastructure| .
. . . Pledges | PKI Certificate | .
. . . Provision | Authority, ... | .
. . . Data +------------------+ .
....................... ...................................
"on-site" Domain compontent "off-site" Domain components

580 The following list describes the components in a (customer) site
581 domain:

583 * Pledge: The pledge is expected to respond with the necessary data
584 objects for bootstrapping to the registrar-agent. The protocol

s/is expected to respond/responds/

585 used between the pledge and the registrar-agent is assumed to be
586 HTTP in the context of this document. Other protocols may be used
587 like CoAP, Bluetooth, or NFC, but are out of scope of this

Bluetooth or NFC do sound like physcial connection methods, and they are too.
suggest

Any other protocols can be used as long as they can or could be made to support
the exchange of the necesssary data objects. This includes CoAP or protocol
to be used over Bluetooth or NFC connections.

Question: Given how all required authentication seems to be attached to the
data objects, it seems as if every individual request/reply could be a
separate new HTTP connection. Correct ? If yes, then that would be good to
write that and contrast it to BRSKI.

588 document. A pledge acting as a server during bootstrapping leads
589 to some differences to BRSKI:

591 - Discovery of the pledge by the registrar-agent must be
592 possible.

594 - As the registrar-agent must be able to request data objects for
595 bootstrapping of the pledge, the pledge must offer
596 corresponding endpoints.

598 - The registrar-agent MAY provide additional data to the pledge

Lowercase the MAY. Its not specific enough to be actionable here.

599 in the context of the voucher triggering request, that the
600 pledge includes into the PVR. This allows the registrar to
601 identify, with which registrar-agent the pledge was in contact.

603 - Order of exchanges in the call flow may be different as the

"The order".

604 registrar-agent collects both, PVR and PER, at once and
605 provides them to the registrar. This approach is used in order
606 to allow for bulk bootstrapping of several devices in a single
607 pass through a new site by the commissioning personnel.

[major]

This point needs to be explained in more details. Maybe even earlier than here,
where it might be lost in a long list of points. If you explain it later,
please add forward pointer.

Coming from BRSKI it is IMHO absolutely non-obvious how this would work. A
Pledge in BRSKI does not issue a a CSR unless it trusts the Registrar because
of the received voucher.

So, i can see how a Pledge would simply not use a certificate that it receives
in the course of this process if the voucher it also receives fails to
live up to expectation (aka: Pledge does not trust the voucher, because
e.g. MASA got hacked/spoofed). But the presence of the PER and the certificate
itself could open up new venues of attacks (unclear to me), and at least
there is the issue for the domain having to figure out that the pledge
ultimate does not want to use the certificate at all. In BRSKI this is
implicit by the pledge never issuing a CSR. In this reordered approach it
would have to be an explicit message that the domain would have to poll.

Are these considerations/concerns valid, or am i overlooking something ?

609 - The data objects utilized for the data exchange between the
610 pledge and the registrar are self-contained authenticated
611 objects (signature-wrapped objects).

The following is a way too long bullet point. Check out if you can not
better create another sub-level of sections, e.g.: 5.1.1 ... 5.1.x to
make 5.1 more readable. At least the picture and explanation, and then
one for pledge and agent and registrar respectively. And break up the following bullet
point into digestable paragraphs (and un-bullet everything as much as
possible).

613 * Registrar-agent: provides a communication path to exchange data
614 objects between the pledge and the domain registrar. The
615 registrar-agent brokers in situations in which the domain
616 registrar is not directly reachable by the pledge. This may be

...by the pledge ... or to convert between the supported responder mode
protocols supported by the pledge to the common BRSKI-PRM protocol
between registrar-agent and registrar. ???

Correct ? If so, pls. add.

617 due to a different technology stack or due to missing
618 connectivity. The registrar-agent triggers a pledge to create
619 bootstrapping artifacts such as the voucher-request and the

Going even deeper into the dungeon of consistent and non-redundant
language, you shoud consider to replace all use of data objects in the document
with "signed artifacts" given how that is what all the other BRSKI RFCs use.

*sigh* (i have to say stuff like this, but have been subjected to it
myself as well, and think/hope it did help me own RFCs too.).

620 enrollment-request on one or multiple pledges and performs a
621 (bulk) bootstrapping based on the collected data. The registrar-
622 agent is expected to possess information about the domain
623 registrar: the registrar EE certificate, LDevID(CA) certificate,
624 IP address, either by configuration or by using the discovery
625 mechanism defined in [RFC8995]. There is no trust assumption
626 between the pledge and the registrar-agent as only authenticated
627 self-contained objects are used, which are transported via the
628 registrar-agent and provided either by the pledge or the
629 registrar. The trust assumption between the registrar-agent and
630 the registrar is based on the LDevID of the registrar-agent,
631 provided by the PKI responsible for the domain. This allows the
632 registrar-agent to authenticate towards the registrar, e.g., in a
633 TLS handshake. Based on this, the registrar is able to
634 distinguish a pledge from a registrar-agent during the TLS session
635 establishment and also to verify that the registrar-agent is
636 authorized to perform the bootstrapping of the distinct pledge.

[major]

I don't understand why it would be necessary for the registrar-agent to be authenticated
for the role of registrar-agent. In BRSKI, we did not have such a level of
security, but instead the pledge-proxy simply needed an LDevID of the domain
because communications across the domain was secured, and the brski-proxy was
effectively just poking a hole into this security for the purpose of exposing
boostrap communications to the registrar. So to me the question is how this
would need or benefit from being different with BRSKI-PRM

If you come up and write some good reasons why the registrar-agent need to
be authenticated by the registrar specifically for the role as registrar-agent,
then this also requires IMHO a standardization of some attribute in the LDevID
to express this. Otherwise the "whatever" domain LDevID would just give what it
gives in BRSKI: Ability to communicate across the domain. Every domain member
welcome to do it (performn registrar-agent function).

I think that just replicating what BRSKI has (LDevID for just supporting
securei domain communications to registar) should suffice. I am a great fan of
role based security though, so i would welcome the definitoin of certificate
attributes that are designated to registrar-agent function, but thats more
work, and maybe if you want to close down on this draft rather something
to be done as add-on work/draft.

638 * Join Proxy (not shown): same functionality as described in
639 [RFC8995] if needed. Note that a registrar-agent may use a join
640 proxy to facilitate the TLS connection to the registrar, in the
641 same way that a BRSKI pledge would use a join proxy. This is
642 useful in cases where the registrar-agent does not have full IP
643 connectivity via the domain network, or cases where it has no
644 other means to locate the registrar on the network.

[major]

I don't think that the most obvious deployment option would be to suggest to combine
separate join-proxy and registrar-agent nodes working together. This really is
an option that this doc does not specify sufficient methods for and which i
think is not needed.

I would suggest that the most easily deployed option is simply one where
the registrar-agent can perform all the same required elements for selecting
and talking to the registrar as we defined for join proxy:

- Discovery of registrar supporting one or more methods in support of BRSKI-PRM.
This is what my first top-posted major comment was about. Aka: modified
BRSKI-registrar discovery options that indicate one or more of PRM method
support (JSON encoded signed artefact exchange).

- Secure communications with registrar solely by having a domain certificate (LDevID).

If we would go with an approach as described in your paragrah, that a registrar-agent should
be able to use some join-proxy, then this certainly would not work reliably
without also extending discovery on the join-proxy by the registrar-agent. An unmodified join-proxy
would just connect to a registrar thats supports BRSKI, but not find a registrar
that supports BRSKI-PRM.

If there is a strong use-case reason to support this combination
(pledge<=>registrar-agent<=>join-proxy<=>registrar) then that would require
defining extensions to join-proxy such that it can discover PRM capable registrars
and also announce them, so that the registrar-agent can find/use a join-proxy
that can pass through PRM traffic to a PRM capable registrar.

This is because i think if we do not want to create additional deployment concerns
of BRSKI, we can not expect that every BRSKI capable registrar will also be
extended to support BRSKI-PRM or vice versa. These registrars should easily be
allowed to come from different vendors and need to be able to be combined in the
same network without conflating their implementation expectations because
potentially hundreds of proxies in the network can't keep them apart.

This was btw a pain point for me when we defined BRSKI, that we did not get to
a point in defining discovery such that we specified proxy operations in a way
that it would be able to recognize all type of different BRSKI methods,
replicte those methods in service announcements to pledges, mapped to different
port numbers, and then based on the pledge initiated connection (port number)
connect the pledge to the appropriate registrar. But we had too much to do with
BRSKI proper to add such functionality.

Aka: suggest to replace the join proxy text with something summarizing what
i said above:

join-proxy and registrar-agent are two complementary methods
in support of pledge enrollment. registrar-agent is re-using concepts
of join-proxy wrt to use of LDevID and discovery, but needs new discovery
option to find/select a registrar supporting PRM - and then of course
based on what PRM method (JSON, ...) the registrar offers also use
those PRM option signed artefacts with the pledge.

646 * Domain Registrar: In general the domain registrar fulfills the
647 same functionality regarding the bootstrapping of the pledge in a
648 (customer) site domain by facilitating the communication of the
649 pledge with the MASA service and the domain PKI service. In
650 contrast to [RFC8995], the domain registrar does not interact with
651 a pledge directly but through the registrar-agent. The registrar

I thought RFC8995 always says that communications is via join-proxy, even if
join-proxy is logically just a function co-located on the registrar node. So
this sentence would be incorrect if i remember correctly.

652 detects if the bootstrapping is performed by the pledge directly
653 or by the registrar-agent.

This sentence seems to contradict the prior sentence statement "the registrar
does not interact a pledge directly."

IMHO its just as in BRSKI: logically registrar always interacts with pledge
indirectly via registrar-agent. Registrar agent may be co-located with
registrar, but this only makes sense if the reason for use of registar-agent
is not the nomadic connectivity of the pledge, but the choice of only
supporting protocols only suitable for PRM on the pledge.

655 * The manufacturer provided components/services (MASA and Ownership
656 tracker) are used as defined in [RFC8995]. For issuing a voucher,
657 the MASA may perform additional checks on a voucher-request, to
658 issue a voucher indicating agent-proximity instead of
659 (registrar-)proximity.

Maybe clearer: a MASA is able to support enrollment via registar-agent without
changes unless it checks the vouchers proximity indication, in which case
it would need to be enhanced to also accept the agent-proximity as defined in
this document.

661 5.2. Agent-Proximity Assertion

663 "Agent-proximity" is a statement, that the proximity registrar
^

Is this in voucher request or voucher ? Please be explicity about the object,
who sends/forwards/receives it.

664 certificate was provided via the registrar-agent as defined in

"proximity registrar certificate" ???

665 Section 6 and not directly to the pledge. "Agent-proximity" is

Maybe i am confused (i am emulating a clueless reader ;-), but
should this not be written in the hypothetical ?

If a voucher request indicates agent-proximity (to the MASA), then this
indicates that the certificate that would be issued to the pledge via
a registrar-agent and hence it conveys only a very weak assertion of
the requesting domain to be in possession of the pledge and no guarantee
for even the ability to deliver the voucher and later the certificate
to the pledge.

Something like that ???

665 Section 6 and not directly to the pledge. "Agent-proximity" is
666 therefore a weaker assertion then "proximity". It is defined as
667 additional assertion type in [I-D.ietf-anima-rfc8366bis]. This can

Please make sure origin of agent-proximity extension is clear:

Suggest:
This document introduces agent-proximity as a new assertion type in support of
BRSKI-PRM enrollments into [I-D.ietf-anima-rfc8366bis].

With you existing text one may ask "what did rfc8366bis introduce this assertion type originally
for".
667 additional assertion type in [I-D.ietf-anima-rfc8366bis]. This can
668 be verified by the registrar and also by the MASA during the voucher-
669 request processing. Note that at the time of creating the voucher-
670 request, the pledge cannot verify the registrar's registrar EE
^^^^^^^^^^^^^^^^^^^^^ duplicate ?
671 certificate and has no proof-of-possession of the corresponding
672 private key for the certificate.

Suggest to reorder the explanation from the creation of the voucher through
its final consumption.

Aka: pledge creates a PVR. That contains the agent-proximity assertion
by virtue of using BRSKI-PRM and therefore knowing that the PVR will be
passed via a registrar-agent.

Then the registrar does what...

Then the MASA receives it and determines whether a agent-proximity assertion
is acceptable.

I also guess that if agent-proximity by itself is insufficient to make the
registrar accept the enrollment, that it must be avble to make it become
acceptable if the registrar is able to consult additional "out-of-scope" information,
e.g.: some information about what pledges are expected to be enrolled, or the like ?

Aka: The most simple example of how the agent-proximity assertion would
be used (instead of just being ignored/always accepted) would be good. And
of course only for plegdes that will not support a multitude of enrollment
options, but only BRSKI-PRM, because thats the most important option IMHO.

The pledge therefore accepts the
673 registrar EE certificate provisionally until it receives the voucher
674 as described in Section 6.3. See also [RFC8995] "PROVISIONAL accept
675 of server cert".

reorder. This predates generation of PVR, right ? This is when registrar-agent
sends T-PVR, right ? Needs to come first in this section.

677 Trust handover to the domain is established via the "pinned-domain-
678 certificate" in the voucher.

Should have a forward pointer to wherever you're describing the sending/reception
of the voucher later.

680 In contrast to the above, "proximity" provides a statement, that the
681 pledge was in direct contact with the registrar and was able to
682 verify proof-of-possession of the private key in the context of the
683 TLS handshake. The provisionally accepted registrar EE certificate

Please reorder: This should go before any explanation of the new agent
proximity assertion, because its the background needed to understand the
new stuff, and usually its easier to read in chronological order.

Connection via a join-proxy is not direct contact.
"verify proof-of-possession" - who verifies whom ?
(plege verifies registrar). But ultimately the goal is the authentication
of the registrar cert via the TLS handshake, and the purpose is to include
that cert as the proximity-registrar-cert into the voucher-request.

Aka: Please check the text from Section 3 in RFC8995 and rewrite accordingly.

Something like: "In BRSKI, the pledge authenticates the LDevID of the registrar
via the TLS handshake and then includes that LDevId as the "proximity-registrar-cert"
into the voucher request to allow for the MASA to decide whether or how to respond
to the voucher-request."

And then: "In contract, in BRSKI-PRM, the pledge can only authenticate the LDevID of
the registrar-agent from its Trigger PVR message and hence include the new
... to allow for not only the MASA, but also the registrar to decide whether or
how to proceed with the BRSKI-PRM voucher request.

683 TLS handshake. The provisionally accepted registrar EE certificate

Please write which message the registrar EE certificarte is carried in given how
you did not have an actual step-by-step description of the message elements and
their sequence, so readers have to guess what you are referring to.

Also: Why does the document calls it registrar "EE certificate" instead of registrar
LDevID ? If there is a good reason, make it clear. Else try to minimize redundant
terminology and maybe just use pledge/registrar-agent/registrar LDevID.

[ side note:
I guess we could also use "domain certificate", but i hesitate to recommend that
over LDevID because to me "domain certificate" implied the ability to mutually
authenticate one another via those domain certificates (as we do in ACP), but
for many use-cases i would assume that the LDevID handed out might only allow
some asymmetric authentication , aka: enrolled pledges with some cloud peers,
but not with each other. In any case there are no requirements made here for
what authentication is expected to ensure from the enrollment.]

684 can be verified after the voucher has been processed by the pledge.
685 As the returned voucher includes an additional signature by the
686 registrar as defined in Section 6.2.5, the pledge can also verify
687 that the registrar possesses the corresponding private key.

Unless i am not correctly guessing at something not yet explained in the doc,
the pledge will always want to do a POI for an LDevID, and not just for a
private key.

689 5.3. Behavior of Pledge in Pledge-Responder-Mode

691 The pledge is triggered by the registrar-agent to generate the PVR
692 and PER as well as for the processing of the responses and the
^

collected by the registrar agent from the registrar at some later point in time ??

693 generation of status information. Due to the use of the registrar-
^

In all interactions with the registrar-agent the pledge is hence acting as the
responder, leading to the name BRSKI-PRM.

(reconfirmation is never bad ;-))

694 agent, the interaction with the domain registrar is changed as shown
695 in Figure 3. To enable interaction with the registrar-agent, the
^
as a responder

696 pledge provides endpoints using the BRSKI defined endpoints based on
697 the "/.well-known/brski" URI tree.

699 The following endpoints are defined for the _pledge_ in this

Purpose of underscores ? If needed, explain, if not, remove.

700 document. The endpoints are defined with short names to also
701 accommodate for the constraint case. The URI path begins with
702 "http://www.example.com/.well-known/brski" followed by a path-suffix
703 that indicates the intended operation.

[mayor]
Coming to mind now/here reading http:// again:

I would expect someone will ask during IETF/IESG review why not to allow
allow or even recommend https:// instead of http://, e.g.: to prohibit
eavesdropping of enrollments. Or at least write into the security section
what security challenges (such as eavesdropping) the use of http:// could
have.

Personally, i think it could be useful to suggest that implementations MAY
support https:// to proibit eavesdropping or other DoS attacks, especially
when enrollment is across a radio network such as WiFi, where common
path/link encryptions like PSK are highly vulnerable.

Right now i am a bit confused about whether the registrar-agent (or only
the registrar) needs to authenticate the IDevID of the PVR/PER before
passing them on, but if it does need to authenticate them, then it would
of course also be no problem to authenticate the pledges HTTPs identity,
because that too would be the IDevID of the pledge (as for PVR/PER).

705 Operations and their corresponding URIs:

707 +=======================================+================+=========+
708 | Operation | Operation path | Details |
709 +=======================================+================+=========+
710 | Trigger pledge-voucher-request | /tv | Section |
711 | creation - Returns PVR | | 6.1 |
712 +---------------------------------------+----------------+---------+
713 | Trigger pledge-enrollment-request - | /te | Section |
714 | Returns PER | | 6.1 |
715 +---------------------------------------+----------------+---------+
716 | Provide voucher to pledge - Returns | /sv | Section |
717 | pledge-voucher-status | | 6.3 |
718 +---------------------------------------+----------------+---------+
719 | Provide enrollment response to pledge | /se | Section |
720 | - Returns pledge-enrollment-status | | 6.3 |
721 +---------------------------------------+----------------+---------+
722 | Provide CA certs to pledge | /cc | Section |
723 | | | 6.3 |
724 +---------------------------------------+----------------+---------+
725 | Query bootstrapping status of pledge | /ps | Section |
726 | - Returns pledge-status | | 6.4 |
727 +---------------------------------------+----------------+---------+

Maybe overdoing it a bit with the terseness of the operation paths.
tpvr, tper, ppvr, pper, pcac, qbs or the like would be nicer for any human
troubleshooter (aka: soemthing easily to remember from the name of the operations).
This would still be in-ine with e.g.: the up to 4-letter paths in rfc9148,
which i'd assume would be our reference for "appropriate for constrained devices".

729 Table 1: Endpoints on the pledge

731 5.4. Behavior of Registrar-Agent

733 The registrar-agent as a new component provides connectivity between

s/connectivity/a message passing service/

734 the pledge and the domain registrar. It facilitates the exchange of
735 data between the pledge and the domain registrar, which are the
736 voucher request/response, the enrollment request/response, as well as
737 related telemetry and status information.

You just introduced different terms in 5.3. What you use here seem to be
the original terms which are now valid only on the registrar-agent/registrar
leg. Would help to elaborate on that. Maybe even have a table mapping the
names between the two legs ?

739 For the communication with the pledge the registrar-agent utilizes
740 communication endpoints provided by the pledge. The transport in
741 this specification is based on HTTP but may also be done using other
742 transport mechanisms. This new component changes the general
743 interaction between the pledge and the domain registrar as shown in
744 Figure 1.

746 For the communication with the registrar, the registrar-agent uses
747 the endpoints of the domain registrar side already specified in
748 [RFC8995] if suitable. The EST [RFC7030] standard endpoints used by

Suggest to improve sentence:

[RFC8995] (derived from EST [RFC7030]) where suitable. these endpoints do not expect...

749 BRSKI do not expect signature wrapped-objects, which are used b
^y
750 BRSKI-PRM. This specifically applies for the enrollment request and
751 the provisioning of CA certificates. To accommodate the use of
752 signature-wrapped object, the following additional endpoints are
753 defined for the _registrar_. Operations and their corresponding URIs:

Again _: Explain || Remove

755 +===================================+=================+=========+
756 | Operation | Operation path | Details |

Btw: Whats the difference between Operational path and endpoint ?
Just wondering if we could use endpoint instead of operational path to
reduce terminology... or why its called operational path when its
just the last part thereof. Aka: would make more sense to me if the
whole path was called operartional path and whats shown here would
be called endpoint. But i haven't tried to fully inhale the terminology.

757 +===================================+=================+=========+
758 | Supply PER to registrar | /requestenroll | Section |
759 | | | 6.2.6 |
760 +-----------------------------------+-----------------+---------+
761 | Request (wrapped) CA certificates | /wrappedcacerts | Section |
762 | - Returns wrapped CA Certificates | | 6.2.7 |
763 +-----------------------------------+-----------------+---------+

On the leg to the pledge you clearly seem to consider constraiend
pledges given the terse Operations path. So i wonder if we could escape
duplicating operations path for the agent/registrar leg by simply introducing
only short operations path (up to four characters).

Of course, this isn't the whole picture, because if someone has a constrained
registrar then one would want to use constrained-proxy style brski coap spec
with a coap bindng for the operations paths.

So, no strong opinions here. Just thinking that i've come to hate all the
duplication we have re constrained/unconstrained, so anything we could
reduce in duplication would be welcome by me.

765 Table 2: Additional endpoints on the registrar

767 For authentication to the domain registrar, the registrar-agent uses
768 its LDevID(RegAgt). The provisioning of the registrar-agent LDevID

>From what i've learned reading so far, the registrar-agent needs the
LDevID for:

- potentially for abilty to communicate with registrar (like in BRSKI)
- in support of signing the Trigger-PVR/PER objects so that the Pledge can
generate the agent proximity field(s) for the voucher.

Correct ?

Which as mentioned in before shuold be made clear on the first place where
the text talks about this.

Still not sure what reason would demand authentication to the registrar though.

Expand on first Use: RegAgt. Also put into terminology section.
But: is it really needed ? (can't say as i don't know what it means)

There is another maybe useful implication that is worth writing about,
as it shows how the process can be resilient (not sure exactly where in the
text though:

registrar agent is on staff notebook. Using your stairs up/down paradiwm from
your github picture. Agent notebook collects PVR/PER from 100 pledges.
Goes up stairs to connect to registrar. Gets replies.

Creates backup of replies.

registrar agent/notebook brought down stairs by agent. Falls down stairs,
notebook dead. Take new notebook, restore data. BUT: new notebook has
different LDevID. But that does not matter. New notebook can perfectly
well be used to perform second run, delivering voucher CA certificates
etc - instead of having to reget new PVR/PER from pledges (which is
likely the more convoluted/expensive part of the process than talking with the registrar).

This works because upon delivering the replies to the pledge, all the
authentication needed by the pledge is in the signed objects. Doesn't matter
who delivers them how. Could even be a different transport than during
querying of PVR/PER.

769 is out of scope for this document, but may be done in advance using a
770 separate BRSKI run or by other means like configuration. It is
771 recommended to use short lived registrar-agent LDevIDs in the range
772 of days or weeks as outlined in Section 10.3.

774 The registrar-agent will use its LDevID(RegAgt) when establishing a
775 TLS session with the domain registrar for TLS client authentication.
776 The LDevID(RegAgt) certificate MUST include a SubjectKeyIdentifier
777 (SKID), which is used as reference in the context of an agent-signed-
778 data object as defined in Section 6.1. Note that this is an
779 additional requirement for issuing the certificate, as [IEEE-802.1AR]
780 only requires the SKID to be included for intermediate CA
781 certificates. [RFC8995] makes a similar requirement. In BRSKI-PRM,
782 the SKID is used in favor of a certificate fingerprint to avoid
783 additional computations.

RFC8995 has a SHOULD for SKID in certs. Please provide stronger textual justification
that this is increased to MUST here because right now you're just
repeating the same justification as BRSKI (avoidance of hash calculation), so
no good reason for different requirements level conclusion.
Else change to SHOULD/RECOMMEND like in RFC8995.

785 Using an LDevID for TLS client authentication of the registrar-agent
786 is a deviation from [RFC8995], in which the pledge's IDevID
787 credential is used to perform TLS client authentication. The use of
788 the LDevID(RegAgt) allows the domain registrar to distinguish, if
789 bootstrapping is initiated from a pledge or from a registrar-agent
790 and to adopt different internal handling accordingly.

[major]

Strongly suggest to remove that paragraph. A registrar can not distinguish
whether a connecting client wants BRSKI or BRSKI-PRM because any BRSKI
registrar can also be a full EST-server doing renewals, and whenever a
client connects for renewals, it will/SHOULD use its LDevID.

I also do not see how it would be necessary or or beneficial to use such a
logic. The intent and semantic of request/replies is indicated via
the operational path called and the Content-Type header field.

When BRSKI-PRM want to support logically the same function as BRSKI or EST7030,
but with different message formats, then it can re-use the same operational
path but indicate a different Content-Type header field. When it wants to
introduce a modified / new function, it should specify a new operational
path.

Isn't BRSKI-PRM already doing this ? Aka: Why even the need to consider
different behavior based on type of identity provided by client - beyond what
RFC7030 specifies (aka: If you come with an LDevID you're obviously
enrolled, but if you then do the BRSKI-PRM operational path and/or
Content-Type, then the identity is not from the TLS connection but from the
message itself).

If a registrar
791 detects a request that originates from a registrar-agent it is able
792 to switch the operational mode from BRSKI to BRSKI-PRM. This may be
793 supported by a specific naming in the SAN (subject alternative name)
794 component of the LDevID(RegAgt) certificate. Alternatively, the
795 domain may feature a CA specifically for issuing registrar-agent
796 LDevID certificates. This allows the registrar to detect registrar-
797 agents based on the issuing CA.

Suggest to replace this and prior paragraph with text according to what i wrote
above about how BRSKI and BRSKI-PRM can be supported across the same TLS port.

799 As BRSKI-PRM uses authenticated self-contained data objects between
800 the pledge and the domain registrar, the binding of the pledge
801 identity to the requests is provided by the data object signature
802 employing the pledge's IDevID. The objects exchanged between the
^^^^^^^^^^^^^^^^^^^^^
803 pledge and the domain registrar used in the context of this
^^^^^^^^^^^^^^^^^^^^^^^^^^^

These two marked parts of the sentene read like duplication. The objects exchanged, the objects used in the context...
Rephrase ?

804 specifications are JOSE objects.

806 In addition to the LDevID(RegAgt), the registrar-agent is provided
807 with the product-serial-number(s) of the pledge(s) to be
808 bootstrapped.

How ? in which message is the product serial number ? Why is it not simply
part of the LDevID that the agent already gets ?

Or are we now talking about a completely separate side channel feeding information
to the registrar agent. One that is not shown in Figure 1 ? (if so, please
add to figure 1).

808 bootstrapped. This is necessary to allow the discovery of pledge(s)
809 by the registrar-agent using mDNS (see Section 5.4.2) The list may be

So this information is not needed unless a discovery mechanism like mDNS is
used that is using the product-serial-numbers ?

809 by the registrar-agent using mDNS (see Section 5.4.2) The list may be
^^^^

list of product-serial-number that is required or potentially able to be enrolled ?

810 provided by administrative means or the registrar agent may get the
811 information via an interaction with the pledge. For instance,
^^ s/an/a prior/
812 [RFC9238] describes scanning of a QR code, the product-serial-number
813 would be initialized from the 12N B005 Product Serial Number.

This whole text from 806 to here would probably fit better into 5.4.2, even if
need be by changing the title of that section.

815 According to [RFC8995] section 5.3, the domain registrar performs the
816 pledge authorization for bootstrapping within his domain based on the
817 pledge voucher-request object.

819 The following information MUST be available at the registrar-agent:

821 * LDevID(RegAgt): own operational key pair.

823 * Registrar EE certificate: certificate of the domain registrar.

825 * Serial-number(s): product-serial-number(s) of pledge(s) to be
826 bootstrapped.

There is no explanation how 819-826 are justified from 815-817. RFC8995 only
required the IDevID. Key par may or may not be implied, but why confuse the
matter and not stick to the wording of RFC8995 ? The serial-number in RFC8995
is also not a separate entity from the IDevID but required to be included
in the IDevID. Your text is confusing in this respect because it talks about
the serial number out of context, so its unclear if you're changing what
RFC8995 expects or not. The Registrar EE certificate is not mentioned in
5.3 at all. What purpose does it serve here in this text ?

828 5.4.1. Discovery of Registrar by Registrar-Agent

830 The discovery of the domain registrar may be done as specified in
831 [RFC8995] with the deviation that it is done between the registrar-

please add section reference

832 agent and the domain registrar. Alternatively, the registrar-agent

And (picking up the top posted major concern) that the registrar-agent
must be able to recognize from the service announcement that the registrar
supports BRSKI-PRM with a particular set of registrar-agent supported
encoding options, such as the specified here JOSE object encoding.

833 may be configured with the address of the domain registrar and the
834 certificate of the domain registrar.

[major]

1) address or domain name of the domain registrar.
2) would also suggest to say that the registrar LDevID SHOULD have the id-kp-cmcRA extended key usage attribute ("Certificate Management over CMS (CMC) Updates" [RFC6402]), but if not, then the registrar-agent MUST be configured with the certificate(s) of permitted domain registrar(s).

This is inline with what we wrote in RFC8994/RFC8995 to authenticate registrar i think.

836 5.4.2. Discovery of Pledge by Registrar-Agent

838 The discovery of the pledge by registrar-agent should be done by
839 using DNS-based Service Discovery [RFC6763] over Multicast DNS
840 [RFC6762] to discover the pledge. The pledge constructs a local host
841 name based on device local information (product-serial-number), which
842 results in "product-serial-number._brski-pledge._tcp.local".

844 The registrar-agent MAY use

846 * "product-serial-number._brski-pledge._tcp.local", to discover a
847 specific pledge, e.g., when connected to a local network.

849 * "_brski-pledge._tcp.local" to get a list of pledges to be
850 bootstrapped.

852 A manufacturer may allow the pledge to react on mDNS discovery
853 without his product-serial-number contained. This allows a
854 commissioning tool to discover pledges to be bootstrapped in the
855 domain. The manufacturer may opt out of this functionality as

s/domain/subnet/

I am too lay to look it up, but there should be not more than TTL=1, aka:
subnet local mDNS these days. If need be i can inquire pointer from DNS folks
for where this is now said in IETF.

[major]

This domain vs. subnet to me issue that this whole section should be elevated to
say (IMHO) (at around 838: :

Pledges and registrar-agents SHOULD support domain-wide
DNS-SD based DNS-SD discovery when the domain supports this for pledges.
Pledges and registrar-agents SHOULD support subnet local mDNS if no other discovery mechanisms are
available.

Aka: I do think/hope to correctly remember that Thread supports domain-wide
DNS-SD based discovery, although i am a bit fuzzy about how this would work
for pledges. I fear that the well-working unicast-based DNS-SD in Thread is
not working for pledges, but only once you're enrolled, but then they may
do have some domain wide mDNS *yuck* (not sure).

856 outlined in Section 10.4.

This sounds like the "may allow" is really a MAY, aka: thin recommendation
(because of the "may opt out" - aka: default is opt-in).

858 To be able to detect the pledge using mDNS, network connectivity is
859 required. For Ethernet it is provided by simply connecting the

For unsecured Ethernets

860 network cable. For WiFi networks, connectivity can be provided by
861 using a pre-agreed SSID for bootstrapping. The same approach can be
862 used by 6LoWPAN/mesh using a pre-agreed PAN ID. How to gain network
863 connectivity is out of scope of this document.

Please start at 858 with "Establishing network connectivity between
pledges and registrar-agent is out of scope...." and then bring the examples.

Given how PSK doesn't work well, and the domains credentials are unknown
to the pledges, making this wireless enrolment network somewhat secure is
actually some form of a challenge. I would actually go with two SSID, one
with WPA2 secured to which the LDevID of the domain gives access (and
hence only register-agents can connect to, and a second (unprotected) SSID for just
pledges that is bridged to the other SSID, but with packet filtering,
denying anything put the known-to-be-required messages from pledges can
be sent, e.g.: especially not TCP packets initiating connecting (so only
responder TCP can be on it). And mDNS replies ;-)

Hack hack hack ;-) Just thinking out lout, add to appendix if you like the idea.
given how it does latch onto a specific property of BRSKI-PRM this might
be easier with BRSKI-PRM than it was for other mechanisms.

865 6. Bootstrapping Data Objects and Corresponding Exchanges

867 The interaction of the pledge with the registrar-agent may be
868 accomplished using different transport means (protocols and/or
869 network technologies). This specification descibes the usage of HTTP
870 as in BRSKI [RFC8995]. Alternative transport channels may be CoAP,

BRSKI relies on HTTPs not HTTP. Try to fix up text accordingly.
(hint: it's about the transactions not the security).

871 Bluetooth Low Energy (BLE), or Nearfield Communication (NFC). These

As mentioned in before, BLE and NFC are more comprehensive and usually understood
to be physcial layer terms (or that too). Same rephrasing suggestions as earlier
in the text.

872 transport means may differ from, and are independent of, the ones
873 used between the registrar-agent and the registrar. Transport
874 channel independence is realized by data objects which are not bound
875 to specific transport security. Therefore, authenticated self-
^
insert:
and stay the same across the pledge<=>registrar-agent and the registrar-agent<=>registrar legs.

876 contained objects (here: signature-wrapped objects) are applied for
877 data exchanges between the pledge and the registrar.
^

insert:
with the registrar-agent just being a message store-and-forward agent.

879 The registrar-agent provides the domain registrar certificate
880 (registrar EE certificate) to the pledge to be included in the PVR
881 leaf "agent-provided-proximity-registrar-certificate". This enables
882 the registrar to verify that it is the desired registrar for handling
883 the request.

[major]

Let me open up the discussion that i think this "agent-provided-proximity-registrar-certificate"
does not make sense, but that instead this field needs to be the "agent

Now i am wondering what if any purpose the LDevID of the registrar-agent has
in its dealings with the pledge. should the pledge verify that the LDevID
of the registrar-agent can be authenticated by the same trust anchors as
those of the registrar ?

885 The registrar certificate may be configured at the registrar-agent or
886 may be fetched by the registrar-agent based on a prior TLS connection
887 with this domain registrar. In addition, the registrar-agent

how about: Registars MUST support configuration of the registrar certificate.
In the absence of such configuration the registrar-agent SHOULD default to the registrar
certificate from whom it did receive its own LDevID. Registrar agents MAY
have any other appropriate mechanisms.

I am not so sure if recommending/mentioning the prior (whatever) TLS connection
is useful... But keep it in the text if you like.

888 provides agent-signed-data containing the pledge product-serial-
889 number, signed with the LDevID(RegAgt). This enables the registrar
^
To the registrar.

This seems to imply that the registrar-agent is either extracting the serial
number from the IDevID (why ?) or that it has this whole orthogonal means
of discovering the serial numbers, such as via mDNS ? It would be good
to be more crisp here, because when reading this one wonder what/how this
stuff works. As necessary forward pointer.

890 to verify and log, which registrar-agent was in contact with the
891 pledge, when verifying the PVR.

This explanation is not satisfactory, because from where i stand, the IDevID
of the pledge signed by the LDevID of the registar-agent would suffice. Don't
see another value of the separate serial number.

I may be misunderstanding something here...

893 The registrar MUST fetch the LDevID(RegAgt) certificate based on the

fetch from where ?

894 SubjectKeyIdentifier (SKID) in the header of the agent-signed-data
895 from the PVR. The registrar includes the LDevID(RegAgt) certificate

The registrar will get the connecting registrar-agent LDevID from the
TLS exchange with the registrar-agent. Is the text in 893-895 explicitly
meant to indicate that that connecting LDevID MUST NOT be relied upon ?
Because otherwise that is of course also where it should/could get
the LdevID from to match the SKID in the message right ?

Aka: This explanation seems incomplete wrt to what the relevance of the
LDevID in the TLS is to the registrar vs. the relevance of the the SKID in
the message.

896 information into the RVR if the PVR asked for the assertion "agent-
897 proximity".

In BRSKI-PRM the PVR will always include agent-proximity, right ? So the
RVR will also include it, right ? If not, then i think readers would like
to learn about exceptions here. If true, then readers might like to read
this statement as a reconfirmation of how BRSKI-PRM works.

899 The MASA in turn verifies the registrar EE certificate is included in
900 the PVR ("prior-signed-voucher-request" of RVR) in the "agent-

I thought PVR stands for Plege Voucher Request. Now you're introducing a new
expansion that you don't even explain ?? Please clarify in text.

901 provided-proximity-registrar-certificate" leaf and may assert the PVR
902 as "verified" or "logged" instead of "proximity", as there is no
903 direct connection between the pledge and the registrar.

This is confusing to read 'instead of proximity'. Suggest to write here just
that MASA can MASA can assert "verified" and "logged" as it does in BRSKI.

905 In addition, the MASA can state the assertion "agent-proximity" as
906 follows: The MASA can verify the signature of the agent-signed-data
907 contained in the prior-signed-voucher-request, based on the provided
908 LDevID(RegAgt) certificate in the "agent-sign-cert" leaf of the RVR.
909 If both can be verified successfully, the MASA can assert "agent-
910 proximity" in the voucher.

And insert here: This agent-proximity is the equivalent to the proximity assertion
by the MASA when using BRSKI. It is a stronger assertion than logged, but it is
weaker than verified, which relies on ownership tracking.

912 Depending on the MASA verification policy, it may also respond with a
913 suitable 4xx or 5xx status code as described in section 5.6 of

error status code

914 [RFC8995]. The voucher then can be supplied via the registrar to the
915 registrar-agent.

s/The voucher then can/When successfull, the voucher will/

917 Figure 2 provides an overview of the exchanges detailed in the
918 following sub sections.

920 +--------+ +-----------+ +-----------+ +--------+ +---------+
921 | Pledge | | Registrar | | Domain | | Domain | | Vendor |
922 | | | Agent | | Registrar | | CA | | Service |
923 | | | (RegAgt) | | (JRC) | | | | (MASA) |
924 +--------+ +-----------+ +-----------+ +--------+ +---------+
925 | | | | Internet |
926 | discover | | | |
927 | pledge | | | |
928 | mDNS query | | | |
929 |<----------------| | | |
930 |---------------->| | | |
931 | | | | |

933 trigger PVR (tPVR) and PER (tPER) generation on pledge
934 |<----- tPVR -----| | | |
935 |------ PVR ----->| | | |
936 | | | | |
937 |<----- tPER -----| | | |
938 |------ PER ----->| | | |
939 ~ ~ ~ ~ ~

941 provide PVR to infrastructure
942 | |<------ TLS ----->| | |
943 | | [Reg-Agt authenticated | |
944 | | and authorized?] | |
945 | |------ PVR ------>| | |
946 | | [Reg-Agt authorized?] | |
947 | | [accept device?] | |
948 | | [contact vendor] | |
949 | | |------------ RVR --------->|
950 | | | [extract DomainID]
951 | | | [update audit log]
952 | | |<--------- Voucher --------|
953 | |<---- Voucher ----| | |
954 | | | | |

956 provide PER to infrastructure
957 | |------- PER ----->| | |
958 | | |---- CSR ---->| |
959 | | |<--- Cert ----| |
960 | |<-- Enroll-Resp---| | |
961 | | | | |
962 query cACerts from infrastructure
963 | |--- cACert-Req -->| | |
964 | |<-- cACert-Resp---| | |
965 ~ ~ ~ ~ ~

967 provide voucher and certificate and collect status info
968 |<--- Voucher ----| | | |
969 |---- vStatus --->| | | |
970 |<--- cACerts ----| | | |
971 |<--Enroll-Resp---| | | |
972 |--- eStatus ---->| | | |
973 ~ ~ ~ ~ ~

975 provide voucher status and enroll status to registrar
976 | |<------ TLS ----->| | |
977 | |---- vStatus --->| | |
978 | | |--- req device audit log-->|
979 | | |<---- device audit log ----|
980 | | [verify audit log]
981 | | | | |
982 | |---- eStatus --->| | |
983 | | | | |

985 Figure 2: Overview pledge-responder-mode exchanges

987 The following sub sections split the interactions between the
988 different components into:

990 * Section 6.1 describes the request object acquisition by the
991 registrar-agent from pledge.

993 * Section 6.2 describes the request object processing initiated by
994 the registrar-agent to the registrar and also the interaction of
995 the registrar with the MASA and the domain CA including the
996 response object processing by these entities.

998 * Section 6.3 describes the supply of response objects between the
999 registrar-agent and the pledge including the status information.

1001 * Section 6.4 describes the general status handling and addresses
1002 corresponding exchanges between the registrar-agent and the
1003 registrar.

Suggest to number these points and number the sections in the above picture
accordingly. Check that text in picture best matches text in bullet list.
Mention in intro text (987) that the following numbered list expands on the phases shown
in the picture.

1005 6.1. Request Objects Acquisition by Registrar-Agent from Pledge

1007 The following description assumes that the registrar-agent has
1008 already discovered the pledge. This may be done as described in
1009 Section 5.4.2 based on mDNS or similar.

s/mDNS/DNS-SD/

1011 The focus is on the exchange of signature-wrapped objects using
1012 endpoints defined for the pledge in Section 5.3.

1014 Preconditions:

1016 * Pledge: possesses IDevID

1018 * Registrar-agent: possesses/trusts IDevID CA certificate and has
1019 own LDevID(RegAgt) credentials for the registrar domain (site).

s/IdevID/pledges IDevID/

[major]

Why is this trust into pledges IDevID needed ? If the registrar-agent would simply query and
send any PVR it can find (potentially limited by configured list of serial
numbers) to the registrar, we wold continue with the fairly failsafe
registrar-centralized diagnostics. If we do validation of IDevID on
registrar-agent, then we hav potentially many registrar agents that all
have to be perfectly configured to operate correctly, and we need to
invent another new diagnostics channel to recognize in our central
backend (registrar) any unforeseen failures. Aka: pledges who have a different
trust chain than what the vendor promised the to have (don't ask me about
how much mess up in certificate management lage vendors can have. Especially
when they go around shopping/integrating companies into product lines...).

Just because somebody needs to carry around a notebook doesn't mean we want
to reduce visibility into whats going on/is-connected to the on-site
networks. And also not push it off to "some other out-of-scope technology" (IMHO).

1020 In addition, the registrar-agent MUST know the product-serial-
1021 number(s) of the pledge(s) to be bootstrapped. The registrar-
1022 agent MAY be provided with the product-serial-number(s) in
1023 different ways:

1025 - configured, e.g., as a list of pledges to be bootstrapped via
1026 QR code scanning

1028 - discovered by using standard approaches like mDNS as described
1029 in Section 5.4.2

s/mDNS/DNS-SD/

... and shown in Figure 2.

1031 - discovered by using a vendor specific approach, e.g., RF
1032 beacons. The registrar-agent SHOULD have synchronized time.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this only for vendor specific mechanisms ? If so, then remove, unless
you can point to another place elaborating on that mechanism (external reference
is fine).

If this requirement is independent of vendor specific approaches, then please
make a list item of its own and have at least some place here in the document
or external reference explaining this (could be pointing to appropriate
RFC8995 section if its the same requirement).

1034 * Registrar: possesses/trusts IDevID CA certificate and has own
1035 registrar EE credentials.

Given how you seem to be listing the preconditions here for all components
of the system and not only the plege/registrar-agent leg, its probavbly better
to make this a separate subsection of its own (e.g. 6.1: preconditions, 6.2: plegde/registar-collection)
Otherwise the mention of registrar in 1034/1035 is confusing.

1037 +--------+ +-----------+
1038 | Pledge | | Registrar |
1039 | | | Agent |
1040 | | | (RegAgt) |
1041 +--------+ +-----------+
1042 | |-create
1043 | | agent-signed-data
1044 |<--- trigger pledge-voucher-request ----|
1045 |-agent-provided-proximity-registrar-cert|
1046 |-agent-signed-data |
1047 | |
1048 |----- pledge-voucher-request ---------->|-store PVR
1049 | |
1050 |<----- trigger enrollment request ------|
1051 | (empty) |
1052 | |
1053 |------ pledge-enrollment-request ------>|-store (PER)
1054 | |

1056 Figure 3: Request collection (registrar-agent - pledge)

1058 Note: The registrar-agent may trigger the pledge for the PVR or the
1059 PER or both. It is expected that this will be aligned with a service
1060 technician workflow, visiting and installing each pledge.

1062 6.1.1. Pledge-Voucher-Request (PVR) - Trigger

1064 Triggering the pledge to create the PVR is done using HTTP POST on
1065 the defined pledge endpoint: "/.well-known/brski/tv"

1067 The registrar-agent PVR trigger Content-Type header is: application/
1068 json. Following parameters are provided in the JSON object:

1070 * agent-provided-proximity-registrar-cert: base64-encoded registrar
1071 EE TLS certificate.

1073 * agent-signed-data: base64-encoded JSON-in-JWS object.

1075 The trigger for the pledge to create a PVR is depicted in the
1076 following figure:

1078 {
1079 "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
1080 "agent-signed-data": "base64encodedvalue=="
1081 }

1083 Figure 4: Representation of trigger to create PVR

1085 The pledge provisionally accepts the agent-provided-proximity-
1086 registrar-cert, it SHOULD verify it after a voucher is received. The
1087 pledge will be unable to verify the agent-signed-data itself as it
1088 does not possess the LDevID(RegAgt) certificate and the domain trust
1089 has not been established at this point of the communication. It
1090 SHOULD be done, after the voucher has been received.
^
and authenticated by the pledge.

1092 The agent-signed-data is a JSON-in-JWS object and contains the
1093 following information:

1095 The header of the agent-signed-data contains:

1097 * alg: algorithm used for creating the object signature.

1099 * kid: MUST contain the base64-encoded bytes of the
1100 SubjectKeyIdentifier (the "KeyIdentifier" OCTET STRING value),
1101 excluding the ASN.1 encoding of "OCTET STRING" of the
1102 LDevID(RegAgt) certificate.

s/,excluding the ASN.1 encoding of "OCTET STRING" of the LDevID(RegAgt) certificate./
of the LDevID(RegAgt) certificate, excluding the (unnecessary) ASN.1 encoding of "OCTET STRING"./

Q: Where would i find an example ASN.1 encoding of SubjectKeyIdentifier ?
It sounds as if ASN.1 would actually include in the encoding the encoded
value for "OCTET STRING" which sounds weird and almost unbelievable. But if
true, and you want to optimize it, i would like to see an example, because
i wonder if this is a single concatenated string, and if so if there is a separator
that also does not belong to the actual SubjectKeyIdentifier.

In any case, adding a reference would help, especially if this is all correct,
and readers like me can't believe it but want to look it up.

1104 The body of the agent-signed-data contains an "ietf-voucher-request-
1105 prm:agent-signed-data" element (defined in Section 7.1):

1107 * created-on: MUST contain the creation date and time in yang:date-
1108 and-time format.

I think i did ask at another place where i think you wrote the registrar-agent needs
a clock, what the purpose of that would be, and here i wonder what is most important
in the use-case about the clock requirement. To that extend i think that the total accuracy of this
clock is far less relevant than ensuring that there is no resetting of time, something
which we always have trouble with certificates and wiggled ourselves around in
RFC8994/RFC8995.

To that end, it might be useful to put here something like:

The registrar agent MUST ensure that
created-on times are monotonically increasing, for example by persistently storing
the last generated created-on time as lower reference for future created-on times in case
there are issues with the local clock on the registrar agent.

This will ensure that a registrar, or whatever backend later looks at these times
will at least know relative time of creation reliably. Vetter than not having it.

1110 * serial-number: MUST contain the product-serial-number as type
1111 string as defined in [RFC8995], section 2.3.1. The serial-number
1112 corresponds with the product-serial-number contained in the
1113 X520SerialNumber field of the IDevID certificate of the pledge.

[major]

i don't think i have seen text that explains this MUST. Such text is needed - but
i am not convinced this should be a MUST.

When this is a MUST, this means that the prior - insecure - discovery such as
mDNS MUST succeed in delivering the real serial-number, or else a PVR trigger
will not return a PVR, because the serial-number will not match. This makes the
discovery an additional, unnecessary attack vector of possible disturbers on
the same LAN/subnet. It also makes in the absence of attackers, but simply
any type of operational/implementation issues the retrieval of a PVR more
difficult than it should be. For otherwise self-protecting pledges, this
PVR interaction may be the only one through which the device can be identified.

Aka: I would say that this field should be completely optional and up to the
registrar-agent to include an set.

However: I can see how a Trigger PVR without any identification of the intended
target may be an issue (although i can right now not come up with an idea about
what issue), so maybe what may be needed is an alternative string field
triggered-target where we leave it up to the registrar-agents software what
to put into it. Something like for example: "probe 123456: Bldg5 LAN17 MAC xx:xx:xx:xx:xx:xx IP ZZZ.ZZZ.ZZZ.ZZZ"

But just speculating about benefits here...

1115 # The agent-signed-data in General JWS Serialization syntax
1116 {
1117 "payload": "BASE64URL(ietf-voucher-request-prm:agent-signed-data)",
1118 "signatures": [
1119 {
1120 "protected": "BASE64URL(UTF8(JWS Protected Header))",
1121 "signature": "base64encodedvalue=="
1122 }
1123 ]
1124 }

1126 # Decoded payload "ietf-voucher-request-prm:agent-signed-data"
1127 representation in JSON syntax

1129 "ietf-voucher-request-prm:agent-signed-data": {
1130 "created-on": "2021-04-16T00:00:01.000Z",
1131 "serial-number": "callee4711"
1132 }

1134 # Decoded "JWS Protected Header" representation in JSON syntax
1135 {
1136 "alg": "ES256",
1137 "kid": "base64encodedvalue=="
1138 }

1140 Figure 5: Representation of agent-signed-data in General JWS
1141 Serialization syntax

1143 6.1.2. Pledge-Voucher-Request (PVR) - Response

1145 Upon receiving the voucher-request trigger, the pledge SHALL
1146 construct the body of the PVR as defined in [RFC8995]. It will
1147 contain additional information provided by the registrar-agent as
1148 specified in the following. This PVR becomes a JSON-in-JWS object as
1149 defined in [I-D.ietf-anima-jws-voucher]. If the pledge is unable to
1150 construct the PVR it SHOULD respond with a HTTP error code to the
1151 registrar-agent to indicate that it is not able to create the PVR.

1153 The following client error responses MAY be used:

1155 * 400 Bad Request: if the pledge detected an error in the format of
1156 the request, e.g. missing field, wrong data types, etc. or if the
1157 request is not valid JSON even though the PVR media type was set
1158 to application/json.

1160 * 403 Forbidden: if the pledge detected that one or more security
1161 parameters from the trigger message to create the PVR were not
1162 valid, e.g., the LDevID (Reg) certificate.

1164 The header of the PVR SHALL contain the following parameters as
1165 defined in [RFC7515]:

1167 * alg: algorithm used for creating the object signature.

1169 * x5c: contains the base64-encoded pledge IDevID certificate. It
1170 may optionally contain the certificate chain for this certificate.

[major]

I think the lowercase "may" is insufficient. I tried to find good references
in RFC8995, but its all so scatterered around. So here is suggested replacement
for the second sentence using some abstract BRSKI reference:

It MUST contain the same certificate chain that would be required in the clients
TLS authentication if it where to use BRSKI-EST to enroll against a registrar.
For example, in the manufacturer publishes for the use by customers only
a CA certificate, but the pledges IDevID was generated via an intermediate
CA, then that intermediate CA needs to be included to allow for successful
authentication of the IDevID.

1172 The payload of the PVR MUST contain the following parameters as part
1173 of the ietf-voucher-request-prm:voucher as defined in [RFC8995]:

1175 * created-on: SHALL contain the current date and time in yang:date-
1176 and-time format. If the pledge does not have synchronized time,
1177 it SHALL use the created-on time from the agent-signed-data,
1178 received in the trigger to create a PVR.

1180 * nonce: SHALL contain a cryptographically strong pseudo-random
1181 number.

1183 * serial-number: SHALL contain the pledge product-serial-number as
1184 X520SerialNumber.

1186 * assertion: SHALL contain the requested voucher assertion "agent-
1187 proximity".

please add to all the applicable bullet points, if applicable: "(different from RFC8995)".
I hope/assume it's just the assertion field.

Btw: This is a general comment for edit runs: including notes if something is
the same or different from how it works in RFC8995 is always helpful i think for
readers/implementers to better understand PRM.

1189 The ietf-voucher-request:voucher is enhanced with additional
1190 parameters:

s/enhanced/extended/ ? (or amend is also fine).

[ "enhanced" is not factual but judgemental.]

1192 * agent-provided-proximity-registrar-cert: MUST be included and
1193 contains the base64-encoded registrar EE certificate (provided as
1194 trigger parameter by the registrar-agent).
^
PVR

And of course see top-posted major concern about this field.

1196 * agent-signed-data: MUST contain the base64-encoded agent-signed-
1197 data (as defined in Figure 5) and provided as trigger parameter.
^^^^^^^^^^^^^^^^^^^^^
as a PVR trigger parameter by the registrar agent

(rather more words than random abbreviations of context in a formal spec document like this).

1199 The enhancements of the YANG module for the ietf-voucher-request with
1200 these new leaves are defined in Section 7.1.

1202 The PVR is signed using the pledge's IDevID credential contained as
1203 x5c parameter of the JOSE header.

1205 # The PVR in General JWS Serialization syntax
1206 {
1207 "payload": "BASE64URL(ietf-voucher-request-prm:voucher)",
1208 "signatures": [
1209 {
1210 "protected": "BASE64URL(UTF8(JWS Protected Header))",
1211 "signature": "base64encodedvalue=="
1212 }
1213 ]
1214 }

1216 # Decoded Payload "ietf-voucher-request-prm:voucher" Representation
1217 in JSON syntax
1218 "ietf-voucher-request-prm:voucher": {
1219 "created-on": "2021-04-16T00:00:02.000Z",
1220 "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
1221 "serial-number": "callee4711",
1222 "assertion": "agent-proximity",
1223 "agent-provided-proximity-registrar-cert": "base64encodedvalue==",
1224 "agent-signed-data": "base64encodedvalue=="
1225 }

1227 # Decoded "JWS Protected Header" Representation in JSON syntax
1228 {
1229 "alg": "ES256",
1230 "x5c": [
1231 "base64encodedvalue==",
1232 "base64encodedvalue=="

Wich one of those two x5c base64 objects is what ? Maybe add # comments on each line with explanation

1233 ],
1234 "typ": "voucher-jws+json"
1235 }

1237 Figure 6: Representation of PVR

1239 The PVR Content-Type is defined in [I-D.ietf-anima-jws-voucher] as
^^^^^^^^^^^^
s/Content-Type/Media-Type/

Content-type is just the name of the HTTP field whose parameter can be a Media-type

1240 application/voucher-jws+json.

1242 The pledge SHOULD include this Content-Type header field indicating
^
insert: Media-Type as the HTTP

Also: this is a MUST, not a SHOULD. Or simply no requirement but just statement of fact.
(The pledge includes this...).

1243 the included media type for the PVR. Note that this is also an
1244 indication regarding the acceptable format of the voucher response.

That sentence is not very elightening but has one just wonder about irrelevant options.
Suggest to delete.

Aka: this spec only specifies voucher-jws+json. And there is no
consideraton of whether/how or when the format of a response could
be different than the form of a reply.

1245 This format is included by the registrar as described in Section 6.2.

1247 6.1.3. Pledge-Enrollment-Request (PER) - Trigger

1249 Once the registrar-agent has received the PVR it can trigger the
^ ,

1250 pledge to generate a PER. As in BRSKI the PER contains a PKCS#10,
^
CSR

1251 but additionally signed using the pledge's IDevID. Note, as the
1252 initial enrollment aims to request a generic certificate, no
1253 certificate attributes are provided to the pledge.

[major]

I do not think this is a reasonable assumption to make (initial LDevID enrollment
always aims for generic certificate). If i wanted to use BRSKI-PRM for ACP
enrollment (not sure if that was even possible), then i would always need
even the first certificate to include the ACP required certificate attributes.
Any other certificate enrollment would just be a waste.

Maybe you just want to explain in this section only the most simple form
PER exchange and add extensions such as CSR attribute later, or they are
not in the document, but then please just write this "..specifying here the
most basic PER option this document calls 'enroll-generic-cert'. See xxxx
for extended / more comprehensive options" (something like that).

1255 Triggering the pledge to create the enrollment-request is done using
1256 HTTP POST on the defined pledge endpoint: "/.well-known/brski/te"

1258 The registrar-agent PER trigger Content-Type header is: application/
1259 json with an empty body by default. Note that using HTTP POST allows
1260 for an empty body, but also to provide additional data, like CSR
1261 attributes or information about the enroll type "enroll-generic-cert"
1262 or "re-enroll-generic-cert". The "enroll-generic-cert" case is shown
1263 in Figure 7.

1265 {
1266 "enroll-type" : "enroll-generic-cert"
1267 }

1269 Figure 7: Example of trigger to create a PER

1271 6.1.4. Pledge-Enrollment-Request (PER) - Response

1273 In the following the enrollment is described as initial enrollment
1274 with an empty HTTP POST body.

1276 Upon receiving the enrollment-trigger, the pledge SHALL construct the

Some consistency of using PVR/PER-trigger vs. expanding voucher-request or enrollment
request would help. I'd go with all TLA given how often you use those TLA with
trigger already.

1277 PER as authenticated self-contained object. The CSR already assures
^^^

PKCS#10 CSR contained in the PER

1278 proof of possession of the private key corresponding to the contained
1279 public key. In addition, based on the additional signature using the
^^^^^^^^^^

s/additional/PER/

1280 IDevID, proof of identity is provided. Here, a JOSE object is being
1281 created in which the body utilizes the YANG module ietf-ztp-types
1282 with the grouping for csr-grouping for the CSR as defined in
1283 [I-D.ietf-netconf-sztp-csr].

1285 Depending on the capability of the pledge, it constructs the
1286 enrollment request (PER) as plain PKCS#10. Note, the focus in this
1287 use case is placed on PKCS#10 as PKCS#10 can be transmitted in

s/Note, the focus in this use case is placed on PKCS#10/BRSKI-PRM uses PKCS#10/

1288 different enrollment protocols in the infrastructure like EST, CMP,
1289 CMS, and SCEP. If the pledge has already implemented an enrollment

s/an enrollment protocol/one of those or othre PKCS#10 based protocols/

1290 protocol, it may leverage that functionality for the creation of the
1291 CSR. Note, [I-D.ietf-netconf-sztp-csr] also allows for inclusion of
1292 certification requests in different formats used by CMP or CMC.

1294 The pledge SHOULD construct the PER as PKCS#10. In BRSKI-PRM it MUST

which alternative to PKCS#10 would make the PER compliant with this spec ?
Any ? Assuming the registrar knows how to deal with any ? Why do we care
here about that option ? Can it not simply be out of scope for this spec
and PKCS10 is for this spec simply the only thing we describe ? Make it
MUST or write "has to" or "is constructing". But SHOULD just opens up all
type of questions i think this doc doesn't want to answer (or shouldn't).

1295 sign it additionally with its IDevID credentials to provide proof-of-
1296 identity bound to the PKCS#10 as described below.

1298 If the pledge is unable to construct the PER it SHOULD respond with a
1299 HTTP 4xx/5xx error code to the registrar-agent to indicate that it is
1300 not able to create the PER.

1302 The following 4xx client error codes MAY be used:

1304 * 400 Bad Request: if the pledge detected an error in the format of
1305 the request or detected invalid JSON even though the PER media
1306 type was set to application/json.

1308 * 403 Forbidden: if the pledge detected that one or more security
1309 parameters (if provided) from the trigger message to create the
1310 PER are not valid.

1312 * 406 Not Acceptable: if the request's Accept header indicates a
1313 type that is unknown or unsupported. For example, a type other
1314 than application/jose+json.

1316 * 415 Unsupported Media Type: if the request's Content-Type header
1317 indicates a type that is unknown or unsupported. For example, a
1318 type other than 'application/json'.

Ok. These seem to be the details i was referring to in before. Maybe put a
forward pointer to this section into the place where you initially mention
the 4xx/5xx.

1320 A successful enrollment will result in a generic LDevID certificate
1321 for the pledge in the new domain, which can be used to request
1322 further (application specific) LDevID certificates if necessary for
1323 operation. The registrar-agent SHALL use the endpoints specified in
1324 this document.

1326 [I-D.ietf-netconf-sztp-csr] considers PKCS#10 but also CMP and CMC as
1327 certification request format. Note that the wrapping signature is
^
of the BRSKI-PRM PER

1328 only necessary for plain PKCS#10 as other request formats like CMP
1329 and CMS support the signature wrapping as part of their own
1330 certificate request format.

Suggest to delete last sentence or move to appendix or further considerations section.
This seems to just derail the focus on what we're specifying given how we're not
specifying CMP or CMS.
Which is relevant here how ? Aka: If this makes the reader stop thinking
about BRSKI-PRM as we want to specify it here and rather start thinking of
this would need to be changed with other request formats, then maybe move
such consierations into some other chapter further below and just put forward
pointer here at best.

1332 The registrar-agent enrollment-request Content-Type header for a
1333 signature-wrapped PKCS#10 is: application/jose+json

1335 The header of the pledge enrollment-request SHALL contain the
1336 following parameter as defined in [RFC7515]:

1338 * alg: algorithm used for creating the object signature.

1340 * x5c: contains the base64-encoded pledge IDevID certificate. It
1341 may optionally contain the certificate chain for this certificate.

Some useful qualification when the may is useful would help. Maybe what i
suggested earlier in the text ?

1343 The body of the pledge enrollment-request SHOULD contain a P10
1344 parameter (for PKCS#10) as defined for ietf-ztp-types:p10-csr in
1345 [I-D.ietf-netconf-sztp-csr]:

1347 * P10: contains the base64-encoded PKCS#10 of the pledge.

1349 The JOSE object is signed using the pledge's IDevID credential, which
1350 corresponds to the certificate signaled in the JOSE header.

1352 # The PER in General JWS Serialization syntax
1353 {
1354 "payload": "BASE64URL(ietf-ztp-types)",
1355 "signatures": [
1356 {
1357 "protected": "BASE64URL(UTF8(JWS Protected Header))",
1358 "signature": "base64encodedvalue=="
1359 }
1360 ]
1361 }

1363 # Decoded Payload "ietf-ztp-types" Representation in JSON Syntax
1364 "ietf-ztp-types": {
1365 "p10-csr": "base64encodedvalue=="
1366 }

1368 # Decoded "JWS Protected Header" Representation in JSON Syntax
1369 {
1370 "alg": "ES256",
1371 "x5c": [
1372 "base64encodedvalue==",
1373 "base64encodedvalue=="

again not knowing whats in which of the two base64. Info into # comments ?

1374 ],
1375 "crit":["created-on"],
1376 "created-on": "2022-09-13T00:00:02.000Z"
1377 }

1379 Figure 8: Representation of PER

1381 With the collected PVR and PER, the registrar-agent starts the
1382 interaction with the domain registrar.

1384 The new protected header field "created-on" is introduced to reflect
1385 freshness of the PER. The field is marked critical "crit" to ensure
1386 that it must be understood and validated by the receiver (here the
1387 domain registrar) according to section 4.1.11 of [RFC7515]. It
1388 allows the registrar to verify the timely correlation between the PER
1389 and previously exchanged messages, i.e., created-on of PER >=
1390 created-on of PVR >= created-on of PVR trigger.

What is timely ? If you have any further text about this, please add forward
reference to it.

Otherwise i am suggesting:

- There is no defined window of time after which a PER would have to be sonsidered
to be expired by the registrar except potentially for expiry of the lifetime of the
IDevID. Instead, validity of a PER based on the created-on field is purely
up to implementation/deployment considerations.

- Registrar MAY consider to ignore any but the newest PER from the same pledge
in the case the registrar has at any point in time more than one pending PER
from the pledge.

... something like this ? would such text make sense ? If there is nothing
for a field declared "critical" that would be some type of loose end in the spec.

1392 As the registrar-agent is intended to facilitate communication
1393 between the pledge and the domain registrar, a collection of requests
1394 from more than one pledge is possible. This allows bulk
1395 bootstrapping of several pledges using the same connection between
1396 the registrar-agent and the domain registrar.

1398 6.2. Request Object Handling initiated by the Registrar-Agent on
1399 Registrar, MASA and Domain CA

1401 The BRSKI-PRM bootstrapping exchanges between registrar-agent and
1402 domain registrar resemble the BRSKI exchanges between pledge and
1403 domain registrar (pledge-initiator-mode) with some deviations.

1405 Preconditions:

1407 * Registrar-agent: possesses its own LDevID(RegAgt) credentials of
1408 the site domain. In addition, it MAY possess the IDevID CA
1409 certificate of the pledge vendor/manufacturer to verify the pledge
1410 certificate in the received request messages. It has the address
1411 of the domain registrar through configuration or by discovery,
1412 e.g., mDNS/DNSSD. The registrar-agent has acquired one or more
1413 PVR and PER objects.

Still wondering bout the need if not downsides of making the registrar agent
verify the IDevID signatures of collected PVR/PER...

1415 * Registrar: possesses the IDevID CA certificate of the pledge
1416 vendor/manufacturer and its own registrar EE credentials of the
1417 site domain.

Can we add "Same requirements as in BRSKI" ?

If not, it would be illuminating what differences there are and to have the
text describe them.

1419 * MASA: possesses its own vendor/manufacturer credentials (voucher
1420 signing key, TLS server certificate) related to pledges IDevID and

s/signing key/signing certificate/ (pledge can not authenticate based on MASA
public key pair unless thats explicitly provisioned, which would be a bad
idea IMHO. Aka: MASA cert...

1421 MAY possess the site-specific domain CA certificate. The latter

"site-specific" is a new term not yet used. And its confusing, because you
use on-site / off-site too. I think you want to say domain certificate for
the registrars domain. Or something like thast

1422 is only necessary if the MASA needs to verify that the domain of
1423 the Registrar is a-priori authorized to enroll a particular
1424 pledge, or a particular type of pledge. In such case is out of
1425 scope of this document how the MASA will obtain the domain CA
1426 certificate. In other cases, a MASA may allow the pledge to
1427 enroll into an anonymous and/or yet-unknown domain and then the
1428 a-priori possession of the domain CA certificate is not needed.

This read a bit as if you make up, maybe unnecessarily some aspects
of the BRSKI defined options of the MASA how and what checks to perform
to make assertions in the voucher.

Aka: if a MASA wants to make a "verified" assertion, that implies an
ownership check, which requires the registrar domin cert to be checked bcause
that indicates the owner. If the MASA wants to just do logged, then thats
not necessary.

Aka: if you want to repeat information from BSRKI you find important to have
here, please make it consistent with that terminology from BSRKI and explicitly
say that you're not writging something new.

If on the other hand you do want to write something new not in BRSKI here,
write so too and explain why/how this is made necessary by the goals of
BRSKI-PRM. Right now i don't see any need for divergence other than the
fairly equivalent agent-proximity assertion (new but same logic as proximity
assertion in BRSKI).

1430 +-----------+ +-----------+ +--------+ +---------+
1431 | Registrar-| | Domain | | Domain | | Vendor |
1432 | agent | | Registrar | | CA | | Service |
1433 | (RegAgt) | | (JRC) | | | | (MASA) |
1434 +-----------+ +-----------+ +--------+ +---------+
1435 | | | Internet |
1436 [voucher + enrollment] | | |
1437 [PVR, PER available ] | | |
1438 | | | |
1439 |<----- mTLS ------>| | |
1440 | [Reg-Agt authenticated | |
1441 | and authorized?] | |
1442 | | | |
1443 |--- Voucher-Req -->| | |
1444 | (PVR) | | |
1445 | [Reg-Agt authorized?] | |
1446 | [accept device?] | |
1447 | [contact vendor] |
1448 | |------------- mTLS ----------->|
1449 | |--------- Voucher-Req -------->|
1450 | | (RVR) |
1451 | | [extract DomainID]
1452 | | [update audit log]
1453 | |<---------- Voucher -----------|
1454 |<---- Voucher -----| | |
1455 | | | |
1456 |--- Enroll-Req --->| | |
1457 | (PER) | | |
1458 | |<----- mTLS ----->| |
1459 | |--- Enroll-Req -->| |
1460 | | (RER) | |
1461 | |<-- Enroll-Resp---| |
1462 |<-- Enroll-Resp ---| | |
1463 | | | |
1464 |--- caCerts-Req -->| | |
1465 |<-- caCerts-Res ---| | |
1466 | | | |

1468 Figure 9: Request processing between registrar-agent and
1469 bootstrapping services

1471 The registrar-agent establishes a TLS connection to the registrar.
1472 As already stated in [RFC8995], the use of TLS 1.3 (or newer) is
1473 encouraged. TLS 1.2 or newer is REQUIRED on the registrar-agent
1474 side. TLS 1.3 (or newer) SHOULD be available on the registrar, but
1475 TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the
1476 MASA, but TLS 1.2 MAY be used.

Hope thats correct. SEC AD review will likely contest anything below TLS 1.3,
so be prepared to explain evidence of ossification in many parts of IOT world
compared to cloud services world.

1478 6.2.1. Connection Establishment (Registrar-Agent to Registrar)

1480 In contrast to BRSKI [RFC8995] TLS client authentication to the
1481 registrar is achieved by using registrar-agent LDevID(RegAgt)
1482 credentials instead of pledge IDevID credentials. Consequently BRSKI
1483 (pledge-initiator-mode) is distinguishable from BRSKI-PRM (pledge-
1484 responder-mode) by the registrar. The registrar SHOULD verify that
^

Other than by deciding based on the client certificate (domain vs. IDevID),
because the BRSKI Operations Path are overloaded in an incompatible fashion
in this document...

Aka: i commented earlier on this. Hope we can resolve that concern quickly.

1485 the registrar-agent is authorized to establish a connection to the
1486 registrar by TLS client authentication using LDevID(RegAgt)
1487 credentials. If the connection from registrar-agent to registrar is
1488 established, the authorization SHALL be verified again based on

Suggestion (uness you see a good reason to vary):
Please decide on SHOULD or SHALL and make it consistent in the document.
I suggest SHOULD.

1489 agent-signed-data contained in the PVR. This ensures that the pledge
1490 has been triggered by an authorized registrar-agent.

1492 The registrar can receive request objects in different formats as
1493 defined in [RFC8995].

Is this true ? Where in RFC8995 are alternative formats for one and the same
type of message specified ? If there is and you want to keep this sentence
please include reference with example.

Whether or not true, i don't see this sentence as useful or necessary. Suggest
to remove.

1493 Specifically, the registrar will receive JSON-
1494 in-JWS objects generated by the pledge for voucher-request and
1495 enrollment-request (instead of BRSKI voucher-request as CMS-signed
1496 JSON and enrollment-request as PKCS#10).

Suggest rewording:

With BRSKI-PRM, the pledge generates PVR and PER as
JSON-in-JWS objects and the registrar agent forwards them to the registrar
(amended with agent-signed data).
In RFC8995, the pledge generates PVR as CMS-signed JSON and PER as PKCS#10
or PKCS#7 according to RFC7030 and inherited by RFC8995.

Aka: BRSKI does not specify the format of PER if i am not mistaken, but
RFC7030 does. And RFC7030 uses different formats depending on which
opertional path the pledge selects.

1498 The registrar-agent SHALL send the PVR by HTTP POST to the registrar
1499 endpoint: "/.well-known/brski/requestvoucher"

1501 The Content-Type header field for JSON-in-JWS PVR is: application/
1502 voucher-jws+json (see Figure 6 for the content definition), as
1503 defined in [I-D.ietf-anima-jws-voucher].

Suggested rewrite:

For BRSKI-PRM, the registrar agent sends the PVR by HTTP POST to the same
registrar endpoint as introduced by BRSKI: "/.well-known/brski/requestvoucher",
but with a Content-Type header field for JSON-in-JWS: ...

1505 The registrar-agent SHOULD set the Accept field in the request-header
1506 indicating the acceptable Content-Type for the voucher-response. The
1507 voucher-response Content-Type header field SHOULD be set to
1508 application/voucher-jws+json as defined in
1509 [I-D.ietf-anima-jws-voucher].

Remove SHOULDs, just write that it does. There is no alternative in this spec, right ?

1511 6.2.2. Pledge-Voucher-Request (PVR) Processing by Registrar

1513 After receiving the PVR from registrar-agent, the registrar SHALL

remove SHALL.

1514 perform the verification as defined in section 5.3 of [RFC8995]. In
1515 addition, the registrar SHALL verify the following parameters from
1516 the PVR:

1518 * agent-provided-proximity-registrar-cert: MUST contain registrar's
1519 own registrar EE certificate to ensure the registrar in proximity
1520 of the registrar-agent is the desired registrar for this PVR.

See top posted major concern about this element/function.

1519 own registrar EE certificate to ensure the registrar in proximity
1520 of the registrar-agent is the desired registrar for this PVR.

1522 * agent-signed-data: The registrar MUST verify that the agent
1523 provided data has been signed with the LDevID(RegAgt) credentials
1524 indicated in the "kid" JOSE header parameter. The registrar MUST
1525 verify that the LDevID(ReAgt) certificate, corresponding to the
1526 signature, is still valid. If the certificate is already expired,
1527 the registrar SHALL reject the request. Validity of used signing
1528 certificates at the time of signing the agent-signed-data is
1529 necessary to avoid that a rogue registrar-agent generates agent-
1530 signed-data objects to onboard arbitrary pledges at a later point
1531 in time, see also Section 10.3. The registrar MUST fetch the
1532 LDevID(RegAgt) certificate, based on the provided
1533 SubjectKeyIdentifier (SKID) contained in the "kid" header
1534 parameter of the agent-signed-data, and perform this verification.
1535 This requires, that the registrar can fetch the LDevID(RegAgt)
1536 certificate data (including intermediate CA certificates if
1537 existent) based on the SKID.

1539 If the registrar is unable to validate the PVR it SHOULD respond with
1540 a HTTP 4xx/5xx error code to the registrar-agent.

1542 The following 4xx client error codes SHOULD be used:

1544 * 403 Forbidden: if the registrar detected that one or more security
1545 related parameters are not valid.

1547 * 404 Not Found status code if the pledge provided information could
1548 not be used with automated allowance, as described in section 5.3
1549 of [RFC8995].

1551 * 406 Not Acceptable: if the Content-Type indicated by the Accept
1552 header is unknown or unsupported.

"Just saying" comment:

I am always concerned about fast diagnostic. I wonder
how in your implementations of any of this HTTP stuff it is possible
that the same error code can have more than one cause, and how you think
this condition would be resolved to its root cause in deployments ?

Of course, this is not a new problem for BRSKI-PRM but for anything across
HTTP, but the more we're embedding HTTP into automated workflows the
more of an issue IMHO this becomes.

In the past i would have suggested to at least include a per error reason
Reason-Phrase string into the error replies, but HTTP2 removed that, and i don't
think IETF would look friendly at a spec that was demanding to use HTTP1.1
just to get the reason. Although i would certainly do this if i was an author
(It's still perfectly valid to use HTTP1.1).

With HTTP2, the only way to provide actual root cause tracing of HTTP error would
be (AFAIK) to not return HTTP error causes, but e.g.: JSON error objects
detailling the error resason. And i have not seen any spec doing this.
So i am very pessimistic about the quick adoption of anything we do in the
face of multi-vendor interoperability issues leading to lot of work
of finding root cause analsysis of root cause issues.

1554 If the validation succeeds, the registrar SHOULD accept the PVR to
1555 join the domain as defined in section 5.3 of [RFC8995]. The
1556 registrar then establishes a TLS connection to MASA as described in
1557 section 5.4 of [RFC8995] to obtain a voucher for the pledge.

Don't use SHOULD. Just write that BRSKI-PRM uses the procedures of BRSKI:

If the validation succeeds, the registrar performs pledge authorization
according to RFC8995, Section 5.3 followed by obtaining a voucher from
the pledges MASA according to RFC8995, Section 5.4 with the modifications
described below in 6.2.3 (... more sections ?).

1559 6.2.3. Registrar-Voucher-Request (RVR) Processing (Registrar to MASA)

I think there could be a statement here like the following:

If the MASA address/URI is learned from the RFC8995 Section 2.3 IDevID
MASA URI extension then the MASA on that URI MUST support the procedures
in this document if the PVR was using JSON-JWS.

If the MASA is only configured on the registrar, then a registrar
supporting BRKSI-PRM and other voucher encoding formats (such as those
in RFC8995) SHOULD support per-message-format MASA address/URI configuration
for the same IDevID TA.

(as in: a single vendor may not use the same MASA for different type of encodings).

1561 The registrar SHALL construct the payload of the RVR as defined in
1562 [RFC8995]. The RVR encoding SHALL be JSON-in-JWS as defined in
1563 [I-D.ietf-anima-jws-voucher].

1565 The header of the RVR SHALL contain the following parameter as
1566 defined for JWS [RFC7515]:

1568 * alg: algorithm used to create the object signature

1570 * x5c: base64-encoded registrar LDevID certificate(s) (It optionally
1571 contains the certificate chain for this certificate)

Would be nice to JWS beginners to add explanation that this is in support
of the JWS signing of the object (also in other places where x5c is mentioned).
(problem is that the field names in JWS are meaningless like 'x5c').

1573 The payload of the RVR MUST contain the following parameter as part
1574 of the voucher-request as defined in [RFC8995]:

add section reference from RFC8995

1576 * created-on: current date and time in yang:date-and-time format of
1577 RVR creation

1579 * nonce: copied from the PVR

1581 * serial-number: product-serial-number of pledge. The registrar
1582 MUST verify that the IDevID certificate subject serialNumber of
1583 the pledge (X520SerialNumber) matches the serial-number value in
1584 the PVR. In addition, it MUST be equal to the serial-number value
1585 contained in the agent-signed data of PVR.

Have these requirements not been specified in before in the text (reception
of PVR section ? I think so. If so, please delete here.

1587 * assertion: voucher assertion requested by the pledge (agent-
1588 proximity). The registrar provides this information to assure
1589 successful verification of agent proximity based on the agent-
1590 signed-data.

1592 * prior-signed-voucher-request: PVR as in [RFC8995]

I think this should primarily be "PVR as received from registrar-agent, see Section x.y".

If there is a section in RFC8995 that specifies additional conditions before
this can be put into the RVR, then also add the reference to RFC8995 and the
appropriate section, else not.

1594 The RVR MUST be enhanced with the following parameter, when the

s/enhanced/extended/

1595 assertion "agent-proximity" is requested, as defined in Section 7.1:

1597 * agent-sign-cert: LDevID(RegAgt) certificate or the LDevID(RegAgt)
1598 certificate including certificate chain. In the context of this
1599 document it is a JSON array of base64encoded certificate
1600 information and handled in the same way as x5c header objects.

1602 If only a single object is contained in the x5c it MUST be the
1603 base64-encoded LDevID(RegAgt) certificate. If multiple certificates
1604 are included in the x5c, the first MUST be the base64-encoded
1605 LDevID(RegAgt) certificate.

indent to be part of prior bullet point.

1607 The MASA uses this information for verification that the registrar-
1608 agent is in proximity to the registrar to state the corresponding
1609 assertion "agent-proximity".

[major]

This paragraph is wrong.

See also my top posted major concern.

For an assertion, the MASA would have to use an object signed by the pledge
that includes information about the other side of the proximity. This is
what the prior-signed-voucher-request is good for: Its signed by the pledge
and includes the cert of the registrar whose proximity the pledge did
validate via the TLS handshake.

If we logically want to map this to BRSKI-PRM, it still needs to be done
via the prior-signed-voucher-request because thats all the pledge signs
and hence what pledge/masa would at this point trust. If we use an
https:// connection between registrar-agent and pledge and the registrar-agent
LDevID, then we can use exactly the same logic as BRSKI, jus now with
registrar-agent LDevID - this is what i proposed in my top-post.

If you folks do not want to use an https:// connection between pledge and
registrar-agent, then i would at least change the name from "agent-proximity"
to "agent-invited" or the like to make it clearer that we use a different
type of assertion. And in this case the pledge would just indicate
that it had received a Trigger PVR that was signed by that LDevID of
the registrar agent thats included in the PVR in the prior-signed-voucher-request.

1611 The object is signed using the registrar EE credentials, which
1612 corresponds to the certificate referenced in the JOSE header.

1614 # The RVR in General JWS Serialization syntax
1615 {
1616 "payload": "BASE64URL(ietf-voucher-request-prm:voucher)",
1617 "signatures": [
1618 {
1619 "protected": "BASE64URL(UTF8(JWS Protected Header))",
1620 "signature": "base64encodedvalue=="
1621 }
1622 ]
1623 }

1625 # Decoded payload "ietf-voucher-request-prm:voucher" representation

global substitute where applicable:

s/Decoded/Example Decoded/

1626 in JSON syntax
1627 "ietf-voucher-request-prm:voucher": {
1628 "created-on": "2022-01-04T02:37:39.235Z",
1629 "nonce": "eDs++/FuDHGUnRxN3E14CQ==",
1630 "serial-number": "callee4711",
1631 "assertion": "agent-proximity",
1632 "prior-signed-voucher-request": "base64encodedvalue==",
1633 "agent-sign-cert": [
1634 "base64encodedvalue==",
1635 "base64encodedvalue==",
1636 "..."
1637 ]
1638 }

1640 # Decoded "JWS Protected Header" representation in JSON syntax
1641 {
1642 "alg": "ES256",
1643 "x5c": [
1644 "base64encodedvalue==",
1645 "base64encodedvalue=="
1646 ],
1647 "typ": "voucher-jws+json"
1648 }

1650 Figure 10: Representation of RVR

1652 The registrar SHALL send the RVR to the MASA endpoint by HTTP POST:
1653 "/.well-known/brski/requestvoucher"

1655 The RVR Content-Type header field is defined in
^ HTTP
1656 [I-D.ietf-anima-jws-voucher] as: application/voucher-jws+json

1658 The registrar SHOULD set the Accept header of the RVR indicating the
1659 desired media type for the voucher-response. The media type is
1660 application/voucher-jws+json as defined in
1661 [I-D.ietf-anima-jws-voucher].

1663 Once the MASA receives the RVR it SHALL perform the verification as
1664 described in section 5.5 in [RFC8995].

Section 5.5 of
^ ^^

1666 In addition, the following processing SHALL be performed for PVR
1667 contained in RVR "prior-signed-voucher-request" field:

1669 * agent-provided-proximity-registrar-cert: The MASA MAY verify that
1670 this field contains the registrar EE certificate. If so, it MUST
1671 correspond to the registrar EE credentials used to sign the RVR.
1672 Note: Correspond here relates to the case that a single registrar
1673 EE certificate is used or that different registrar EE certificates
1674 are used, which are issued by the same CA.

1676 * agent-signed-data: The MASA MAY verify this data to issue "agent-
1677 proximity" assertion. If so, the agent-signed-data MUST contain
1678 the pledge product-serial-number, contained in the "serial-number"
1679 field of the PVR (from "prior-signed-voucher-request" field) and
1680 also in "serial-number" field of the RVR. The LDevID(RegAgt)
1681 certificate to be used for signature verification is identified by
1682 the "kid" parameter of the JOSE header. If the assertion "agent-
1683 proximity" is requested, the RVR MUST contain the corresponding
1684 LDevID(RegAgt) certificate data in the "agent-sign-cert" field of
1685 the RVR. It MUST be verified by the MASA to the same domain CA as
1686 the registrar EE certificate. If the "agent-sign-cert" field is
1687 not set, the MASA MAY state a lower level assertion value, e.g.:
1688 "logged" or "verified". Note: Sub-CA certificate(s) MUST also be
1689 carried by "agent-sign-cert", in case the LDevID(RegAgt)
1690 certificate is issued by a sub-CA and not the domain CA known to
1691 the MASA. As the "agent-sign-cert" field is defined as array
1692 (x5c), it can handle multiple certificates.

I'll not furher comment on these details, lets just discuss and finalize
solution for my high-level top posted concern about the assertion and
what/how to achieve it first and then fix any trailing text details.

1694 If validation fails, the MASA SHOULD respond with an HTTP 4xx client
1695 error status code to the registrar. The HTTP error status codes are
1696 kept the same as defined in section 5.6 of [RFC8995] and comprise the
1697 codes: 403, 404, 406, and 415.

1699 6.2.4. Voucher Issuance by MASA

1701 The expected voucher-response format for BRSKI-PRM (pledge-responder-
1702 mode) application/voucher-jws+json as defined in
1703 [I-D.ietf-anima-jws-voucher] SHOULD be applied. If the MASA detects
1704 that the Accept header of the PVR does not match the application/
1705 voucher-jws+json it SHOULD respond with the HTTP status code 406 Not
1706 Acceptable as the pledge will not be able to parse the response. The
1707 voucher syntax is described in detail by [RFC8366]. Figure 11 shows
1708 an example of the contents of a voucher.

I'd suggest to separate paragraphs and slight rewrite for some deteails, and
of course to remove the SHOULD:

The MASA creates a voucher with Media-Type of application/voucher-jws+json as defined in
[I-D.ietf-anima-jws-voucher].

If the MASA detects that the Accept header of the PVR does not match
application/voucher-jws+json it SHOULD respond with the HTTP status code
"406 Not Acceptable" as the pledge will not be able to parse the response.

The voucher is according to [RFC8366] but as necessary with the new assertion
value specified Section x.x.

1710 # The MASA issued voucher in General JWS Serialization syntax
1711 {
1712 "payload": "BASE64URL(ietf-voucher:voucher)",
1713 "signatures": [
1714 {
1715 "protected": "BASE64URL(UTF8(JWS Protected Header))",
1716 "signature": "base64encodedvalue=="
1717 }
1718 ]
1719 }

1721 # Decoded payload "ietf-voucher:voucher" representation in
1722 JSON syntax
1723 "ietf-voucher:voucher": {
1724 "assertion": "agent-proximity",
1725 "serial-number": "callee4711",
1726 "nonce": "base64encodedvalue==",
1727 "created-on": "2022-01-04T00:00:02.000Z",
1728 "pinned-domain-cert": "base64encodedvalue=="
1729 }

1731 # Decoded "JWS Protected Header" representation in JSON syntax
1732 {
1733 "alg": "ES256",
1734 "x5c": [
1735 "base64encodedvalue==",
1736 "base64encodedvalue=="
1737 ],
1738 "typ": "voucher-jws+json"
1739 }

1741 Figure 11: Representation of MASA issued voucher

1743 The MASA returns the voucher-response (voucher) to the registrar.

1745 6.2.5. MASA issued Voucher Processing by Registrar

1747 After receiving the voucher the registrar SHOULD evaluate it for
1748 transparency and logging purposes as outlined in section 5.6 of
1749 [RFC8995]. The registrar MUST add an additional signature to the
1750 MASA provided voucher using its registrar credentials.

New paragraph here IMHO.

1750 The signature
1751 is created by signing the original "JWS Payload" produced by MASA and
1752 the registrar added "JWS Protected Header" using the registrar EE
1753 credentials (see[RFC7515], section 5.2 point 8. The x5c component of
1754 the "JWS Protected Header" MUST contain the registrar EE certificate
1755 as well as potential intermediate CA certificates up to the pinned
1756 domain certificate. The pinned domain certificate is already
1757 contained in the voucher payload ("pinned-domain-cert").

1759 This signature provides a proof of possession of the private key
1760 corresponding to the registrar EE certificate the pledge received in
1761 the trigger for the PVR (see Figure 4). The registrar MUST use the
1762 same registrar EE credentials used for authentication in the TLS
1763 handshake to authenticate towards the registrar-agent. This ensures
1764 that the same registrar EE certificate can be used to verify the
1765 signature as transmitted in the voucher request as also transferred
1766 in the PVR in the "agent-provided-proximity-registrar-cert".

[major]

I think this section from 1750 - 1766 is wrong.
There is no need for this additional signature of the voucher, because there is
no need for the pledge to to perform verification beyond anything but the vouchers
content according to RFC8995 Section 5.6.1 and an equivalent of Section 5.6.2.

Aka: the Pledge need to verify the MASA signature on the voucher and that
its addressed by the voucher (serial number matching), then the nonce, and
then it can finally accept the pinned domain certificate from the voucher
and use that to perform additional verification. This is where we might need
new text/difference over rfc8995:

Effectively i think that the pledge simply has to check the register-agent
LDevID signature on the trigger messages against the pinned domain certificate,
and if this can't authenticate the Trigger messages, then those trigger
messages will be ignored - as well as the replies that the registrar-agent
may issue for the PER.

Having said this: there may be different benefits wrt. traceability of why one may
need to add a signature of the registrar, but those should then be explained. I
for once would rather like to try to find the simplest form that we know would
be secure instead of just adding signatures without good understanding of need.

1767 Figure 12 below provides an example of the voucher with two
1768 signatures.

1770 # The MASA issued voucher with additional registrar signature in
1771 General JWS Serialization syntax
1772 {
1773 "payload": "BASE64URL(ietf-voucher:voucher)",
1774 "signatures": [
1775 {
1776 "protected": "BASE64URL(UTF8(JWS Protected Header (MASA)))",
1777 "signature": "base64encodedvalue=="
1778 },
1779 {
1780 "protected": "BASE64URL(UTF8(JWS Protected Header (Reg)))",
1781 "signature": "base64encodedvalue=="
1782 }
1783 ]
1784 }

1786 # Decoded payload "ietf-voucher:voucher" representation in
1787 JSON syntax
1788 "ietf-voucher:voucher": {
1789 "assertion": "agent-proximity",
1790 "serial-number": "callee4711",
1791 "nonce": "base64encodedvalue==",
1792 "created-on": "2022-01-04T00:00:02.000Z",
1793 "pinned-domain-cert": "base64encodedvalue=="
1794 }

1796 # Decoded "JWS Protected Header (MASA)" representation in JSON syntax
1797 {
1798 "alg": "ES256",
1799 "x5c": [
1800 "base64encodedvalue==",
1801 "base64encodedvalue=="
1802 ],
1803 "typ": "voucher-jws+json"
1804 }

1806 # Decoded "JWS Protected Header (Reg)" representation in JSON syntax
1807 {
1808 "alg": "ES256",
1809 "x5c": [
1810 "base64encodedvalue==",
1811 "base64encodedvalue=="
1812 ]
1813 }

1815 Figure 12: Representation of MASA issued voucher with additional
1816 registrar signature

If that example is only there for the additional signature, it may need to
go if we decide we don't need the additional signature.

1818 Depending on the security policy of the operator, this signature can
1819 also be interpreted by the pledge as explicit authorization of the
1820 registrar to install the contained trust anchor.
1820 The registrar sends
1821 the voucher to the registrar-agent.

1823 6.2.6. Pledge-Enrollment-Request (PER) Processing (Registrar-Agent to
1824 Registrar)

1826 After receiving the voucher, the registrar-agent sends the PER to the
1827 registrar.

[major]

What happens if there is a potentially repairable error on the PER (enrolment) ?

I think in BRSKI, the pledge would start over again, creating a new voucher
request and then enrolment. Of course we would not want this, because it
would mean the registrar-agent would have to run up and down stairs again.

Maybe something like this:

The registrar agent SHOULD send PVR and (after success of PVR) PER in
one HTTPS connection. Once the registar has returned a voucher for a pledge
to the registrar-agent, it MUST be able to successfully process a PER (enroll the pledge)
even if the PER is received in a separate new HTTPS connection from a prior PER.
This requirement ensures that a temporary failure for PER processing does not require re-triggering
the pledge for new PVR and PER.

This may be a bit paranoid, as i would not know off the top of my head
how a registrar/backend implementation could break this requirement, but better
be safe than sorry when it comes to ensuring there is no additional need
for registrar-agent travel.

1827 registrar. Deviating from BRSKI the PER is not a raw PKCS#10. As
1828 the registrar-agent is involved in the exchange, the PKCS#10 is
1829 wrapped in a JWS object by the pledge and signed with pledge's IDevID
1830 to ensure proof-of-identity as outlined in Figure 8.

This is repeat text from earlier, please start sentence with something like
"As specified in Section x.y, " to avoid confusion about why this text is here

1832 EST [RFC7030] standard endpoints (/simpleenroll, /simplereenroll,
1833 /serverkeygen, /cacerts) on the registrar cannot be used for BRSKI-
1834 PRM. This is caused by the utilization of signature wrapped-objects
1835 in BRSKI-PRM. As EST requires to sent a raw PKCS#10 request to e.g.,
^d
1836 "/.well-known/est/simpleenroll" endpoint, this document makes an
1837 enhancement by utilizing EST but with the exception to transport a
1838 signature wrapped PKCS#10 request. Therefore a new endpoint for
1839 BRSKI-PRM on the registrar is defined as "/.well-known/brski/
1840 requestenroll"

[major]

a) Is it really necessary to create a new endpoint ?

I don't think it is, because the Media-Type of the request will indicate
the new encoding, so why should we not be able to reuse the existing endpoint
given how the semantic stays the say, just the encoding changes. Right ?

b) If it is necessary to create a new endpoint, should this be in /brski/ ?

I think it would be more logical to put it under /est/. This enrollment
request formatting would work perfectly well without BRSKI upfront.

THis is how far i got.

Cheers
Toerless

1842 The Content-Type header of PER is: application/jose+json.

1844 This is a deviation from the Content-Type header values used in
1845 [RFC7030] and results in additional processing at the domain
1846 registrar (as EST server). Note, the registrar is already aware that
1847 the bootstrapping is performed in a pledge-responder-mode due to the
1848 use of the LDevID(RegAgt) certificate for TLS and the provided PVR as
1849 JSON-in-JWS object.

1851 * If the registrar receives a PER with Content-Type header:
1852 application/jose+json, it MUST verify the wrapping signature using
1853 the certificate indicated in the JOSE header.

1855 * The registrar verifies that the pledge's certificate (here
1856 IDevID), carried in "x5c" header field, is accepted to join the
1857 domain after successful validation of the PVR.

1859 * If both succeed, the registrar utilizes the PKCS#10 request
1860 contained in the JWS object body as "P10" parameter of "ietf-sztp-
1861 csr:csr" for further processing of the enrollment request with the
1862 corresponding domain CA. It creates a registrar-enrollment-
1863 request (RER) by utilizing the protocol expected by the domain CA.
1864 The domain registrar may either directly forward the provided
1865 PKCS#10 request to the CA or provide additional information about
1866 attributes to be included by the CA into the requested LDevID
1867 certificate. The approach of sending this information to the CA
1868 depends on the utilized certificate management protocol between
1869 the RA and the CA and is out of scope for this document.

1871 The registrar-agent SHALL send the PER to the registrar by HTTP POST
1872 to the endpoint: "/.well-known/brski/requestenroll"

1874 The registrar SHOULD respond with an HTTP 200 OK in the success case
1875 or fail with HTTP 4xx/5xx status codes as defined by the HTTP
1876 standard.

1878 A successful interaction with the domain CA will result in a pledge
1879 LDevID certificate, which is then forwarded by the registrar to the
1880 registrar-agent using the Content-Type header: application/
1881 pkcs7-mime.

1883 6.2.7. Request Wrapped-CA-certificate(s) (Registrar-Agent to Registrar)

1885 As the pledge will verify it own certificate LDevID certificate when
1886 received, it also needs the corresponding CA certificates. This is
1887 done in EST [RFC7030] using the "/.well-known/est/cacerts" endpoint,
1888 which provides the CA certificates over a TLS protected connection.
1889 BRSKI-PRM requires a signature wrapped CA certificate object, to
1890 avoid that the pledge can be provided with arbitrary CA certificates
1891 in an authorized way. The registrar signed CA certificate object
1892 will allow the pledge to verify the authorization to install the
1893 received CA certificate(s). As the CA certificate(s) are provided to
1894 the pledge after the voucher, the pledge has the required information
1895 (the domain certificate) to verify the wrapped CA certificate object.

1897 To support registrar-agents requesting a signature wrapped CA
1898 certificate(s) object, a new endpoint for BRSKI-PRM is defined on the
1899 registrar: "/.well-known/brski/wrappedcacerts"

1901 The registrar-agent SHALL requests the EST CA trust anchor database
1902 information (in form of CA certificates) by HTTP GET.

1904 The Content-Type header of the response SHALL be: application/
1905 jose+json.

1907 This is a deviation from the Content-Type header values used in EST
1908 [RFC7030] and results in additional processing at the domain
1909 registrar (as EST server). The additional processing is to sign the
1910 CA certificate(s) information using the registrar EE credentials.
1911 This results in a signed CA certificate(s) object (JSON-in-JWS), the
1912 CA certificates are provided as base64 encoded "x5b" in the JWS
1913 payload.

1915 # The CA certificates data with additional registrar signature in
1916 General JWS Serialization syntax
1917 {
1918 "payload": "BASE64URL(certs)",
1919 "signatures": [
1920 {
1921 "protected": "BASE64URL(UTF8(JWS Protected Header))",
1922 "signature": "base64encodedvalue=="
1923 }
1924 ]
1925 }

1927 # Decoded payload "certs" representation in JSON syntax
1928 {
1929 "x5b": [
1930 "base64encodedvalue==",
1931 "base64encodedvalue=="
1932 ]
1933 }

1935 # Decoded "JWS Protected Header" representation in JSON syntax
1936 {
1937 "alg": "ES256",
1938 "x5c": [
1939 "base64encodedvalue==",
1940 "base64encodedvalue=="
1941 ]
1942 }

1944 Figure 13: Representation of CA certificate(s) data with
1945 additional registrar signature

1947 6.3. Response Object Supply by Registrar-Agent to Pledge

1949 It is assumed that the registrar-agent already obtained the
1950 bootstrapping response objects from the domain registrar and can
1951 supply them to the pledge:

1953 * voucher-response - Voucher (from MASA via Registrar)

1955 * wrapped-CA-certificate(s)-response - CA certificates

1957 * enrollment-response - LDevID(Pledge) certificate (from CA via
1958 Registrar)

1960 The registrar-agent will re-connect to the pledge. To contact the
1961 pledge, it may either discover the pledge as described in
1962 Section 5.4.2 or use stored information from the first contact with
1963 the pledge.

1965 Preconditions in addition to Section 6.2:

1967 * Registrar-agent: possesses voucher and LDevID certificate and
1968 optionally CA certificates.

1970 +--------+ +-----------+
1971 | Pledge | | Registrar-|
1972 | | | Agent |
1973 | | | (RegAgt) |
1974 +--------+ +-----------+
1975 | [voucher and enrollment]
1976 | [responses available]
1977 | |
1978 |<------- supply voucher -----------|
1979 | |
1980 |--------- voucher status --------->| - store
1981 | | pledge voucher status
1982 |<----- supply CA certificates ----|
1983 | |
1984 |<--- supply enrollment response ---|
1985 | |
1986 |--------- enroll status ---------->| - store
1987 | | pledge enroll status
1988 |<--- supply CAcerts (optional) ----|
1989 | |

1991 Figure 14: Responses and status handling between pledge and
1992 registrar-agent

1994 The content of the response objects is defined by the voucher
1995 [RFC8366] and the certificate [RFC5280].

1997 The registrar-agent provides the information via distinct pledge
1998 endpoints as following.

2000 6.3.1. Pledge: Voucher Response Processing

2002 The registrar-agent SHALL send the voucher-response to the pledge by
2003 HTTP POST to the endpoint: "/.well-known/brski/sv".

2005 The registrar-agent voucher-response Content-Type header is
2006 application/voucher-jws+json and contains the voucher as provided by
2007 the MASA. An example is given in Figure 11 for a MASA signed voucher
2008 and in Figure 12 for the voucher with the additional signature of the
2009 registrar.

2011 A nonceless voucher may be accepted as in [RFC8995] and may be
2012 allowed by a manufacture's pledge implementation.

2014 To perform the validation of multiple signatures on the voucher
2015 object, the pledge SHALL perform the signature verification in the
2016 following order:

2018 1. Verify MASA signature as described in section 5.6.1 in [RFC8995]

2020 2. Install trust anchor contained in the voucher ("pinned-domain-
2021 cert") provisionally

2023 3. Verify registrar signature as described in section 5.6.1 in
2024 [RFC8995], but take the registrar certificate instead of the MASA
2025 certificate for the verification

2027 4. Validate the registrar certificate received in the agent-
2028 provided-proximity-registrar-cert in the pledge-voucher-request
2029 trigger request (in the field "agent-provided-proximity-
2030 registrar-cert").

2032 If all steps stated above have been performed successfully, the
2033 pledge SHALL terminate the "PROVISIONAL accept" state for the domain
2034 trust anchor and the registrar EE certificate.

2036 If an error occurs during the verification and validation of the
2037 voucher, this SHALL be reported in the reason field of the pledge
2038 voucher status.

2040 6.3.2. Pledge: Voucher Status Telemetry

2042 After voucher verification and validation the pledge MUST reply with
2043 a status telemetry message as defined in section 5.7 of [RFC8995].
2044 The pledge generates the voucher-status and provides it as signed
2045 JSON-in-JWS object in response to the registrar-agent.

2047 The response has the Content-Type application/jose+json and is signed
2048 using the IDevID of the pledge as shown in Figure 15. As the reason
2049 field is optional (see [RFC8995]), it MAY be omitted in case of
2050 success.

2052 # The "pledge-voucher-status" telemetry in general JWS
2053 serialization syntax
2054 {
2055 "payload": "BASE64URL(pledge-voucher-status)",
2056 "signatures": [
2057 {
2058 "protected": "BASE64URL(UTF8(JWS Protected Header))",
2059 "signature": "base64encodedvalue=="
2060 }
2061 ]
2062 }

2064 # Decoded payload "pledge-voucher-status" representation in JSON
2065 syntax
2066 {
2067 "version": 1,
2068 "status": true,
2069 "reason": "Voucher successfully processed",
2070 "reason-context": {
2071 "additional": "JSON"
2072 }
2073 }

2075 # Decoded "JWS Protected Header" representation in JSON syntax
2076 {
2077 "alg": "ES256",
2078 "x5c": [
2079 "base64encodedvalue==",
2080 "base64encodedvalue=="
2081 ]
2082 }

2084 Figure 15: Representation of pledge voucher status telemetry

2086 6.3.3. Pledge: Wrapped-CA-Certificate(s) Processing

2088 The registrar-agent SHALL provide the set of CA certificates
2089 requested from the registrar to the pledge by HTTP POST to the
2090 endpoint: "/.well-known/brski/cc".

2092 As the CA certificate provisioning is crucial from a security
2093 perspective, this provisioning SHALL only be done, if the voucher-
2094 response has been successfully processed by pledge.

2096 The supply CA certificates message has the Content-Type application/
2097 jose+json and is signed using the credential of the registrar pledge
2098 as shown in Figure 13.

2100 The CA certificates are provided as base64 encoded "x5b". The pledge
2101 SHALL install the received CA certificates as trust anchor after
2102 successful verification of the registrar's signature.

2104 The following 4xx client error codes SHOULD be used by the pledge:

2106 * 403 Forbidden: if the validation of the wrapping signature or
2107 another security check fails.

2109 * 415 Unsupported Media Type: if the Content-Type of the request is
2110 in an unknown or unsupported format.

2112 * 400 Bad Request: if the pledge detects errors in the encoding of
2113 the payload.

2115 6.3.4. Pledge: Enrollment Response Processing

2117 The registrar-agent SHALL send the enroll-response to the pledge by
2118 HTTP POST to the endpoint: "/.well-known/brski/se".

2120 The registrar-agent enroll-response Content-Type header, when using
2121 EST [RFC7030] as enrollment protocol between the registrar-agent and
2122 the infrastructure is: application/pkcs7-mime. Note: It only
2123 contains the LDevID certificate for the pledge, not the certificate
2124 chain.

2126 Upon reception, the pledge SHALL verify the received LDevID
2127 certificate. The pledge SHALL generate the enroll status and provide
2128 it in the response to the registrar-agent. If the verification of
2129 the LDevID certificate succeeds, the status SHALL be set to true,
2130 otherwise to FALSE.

2132 6.3.5. Pledge: Enrollment Status Telemetry

2134 The pledge MUST reply with a status telemetry message as defined in
2135 section 5.9.4 of [RFC8995]. As for the other objects, the enroll-
2136 status is signed and results in a JSON-in-JWS object. If the pledge
2137 verified the received LDevID certificate successfully it SHALL sign
2138 the response using its new LDevID credentials as shown in Figure 16.
2139 In the failure case, the pledge SHALL use the available IDevID
2140 credentials. As the reason field is optional, it MAY be omitted in
2141 case of success.

2143 The response has the Content-Type application/jose+json.

2145 # The "pledge-enroll-status" telemetry in General JWS Serialization
2146 syntax
2147 {
2148 "payload": "BASE64URL(pledge-enroll-status)",
2149 "signatures": [
2150 {
2151 "protected": "BASE64URL(UTF8(JWS Protected Header))",
2152 "signature": "base64encodedvalue=="
2153 }
2154 ]
2155 }

2157 # Decoded payload "pledge-enroll-status" representation in
2158 JSON syntax
2159 {
2160 "version": 1,
2161 "status": true,
2162 "reason": "Enrollment response successfully processed",
2163 "reason-context": {
2164 "additional": "JSON"
2165 }
2166 }

2168 # Decoded "JWS Protected Header" representation in JSON syntax
2169 {
2170 "alg": "ES256",
2171 "x5c": [
2172 "base64encodedvalue==",
2173 "base64encodedvalue=="
2174 ]
2175 }

2177 Figure 16: Representation of pledge enroll status telemetry

2179 Once the registrar-agent has collected the information, it can
2180 connect to the registrar to provide it with the status responses.

2182 6.3.6. Telemetry Voucher Status and Enroll Status Handling (Registrar-
2183 Agent to Domain Registrar)

2185 The following description requires that the registrar-agent has
2186 collected the status information from the pledge. It SHALL provide
2187 the status information to the registrar for further processing.

2189 Preconditions in addition to Section 6.2:

2191 * Registrar-agent: possesses voucher status and enroll status from
2192 pledge.

2194 +-----------+ +-----------+ +--------+ +---------+
2195 | Registrar | | Domain | | Domain | | Vendor |
2196 | Agent | | Registrar | | CA | | Service |
2197 | RegAgt) | | (JRC) | | | | (MASA) |
2198 +-----------+ +-----------+ +--------+ +---------+
2199 | | | Internet |
2200 [voucher + enroll ] | | |
2201 [status info available] | | |
2202 | | | |
2203 |<------- mTLS ------->| | |
2204 | | | |
2205 |--- Voucher Status -->| | |
2206 | |--- req-device audit log-->|
2207 | |<---- device audit log ----|
2208 | [verify audit log ]
2209 | | | |
2210 |--- Enroll Status --->| | |
2211 | | | |

2213 Figure 17: Bootstrapping status handling

2215 The registrar-agent MUST provide the collected pledge voucher status
2216 to the registrar. This status indicates if the pledge could process
2217 the voucher successfully or not.

2219 If the TLS connection to the registrar was closed, the registrar-
2220 agent establishes a TLS connection with the registrar as stated in
2221 Section 6.2.

2223 The registrar-agent sends the pledge voucher status without
2224 modification to the registrar with an HTTP-over-TLS POST using the
2225 registrar endpoint "/.well-known/brski/voucher_status". The Content-
2226 Type header is kept as application/jose+json as described in
2227 Figure 14 and depicted in the example in Figure 15.

2229 The registrar SHALL verify the signature of the pledge voucher status
2230 and validate that it belongs to an accepted device in his domain
2231 based on the contained "serial-number" in the IDevID certificate
2232 referenced in the header of the voucher status.

2234 According to [RFC8995] section 5.7, the registrar SHOULD respond with
2235 an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx status
2236 codes as defined by the HTTP standard. The registrar-agent may use
2237 the response to signal success / failure to the service technician
2238 operating the registrar agent. Within the server logs the server
2239 SHOULD capture this telemetry information.

2241 The registrar SHOULD proceed with collecting and logging status
2242 information by requesting the MASA audit-log from the MASA service as
2243 described in section 5.8 of [RFC8995].

2245 The registrar-agent MUST provide the pledge's enroll status to the
2246 registrar. The status indicates the pledge could process the enroll-
2247 response (certificate) and holds the corresponding private key.

2249 The registrar-agent sends the pledge enroll status without
2250 modification to the registrar with an HTTP-over-TLS POST using the
2251 registrar endpoint "/.well-known/brski/enrollstatus". The Content-
2252 Type header is kept as application/jose+json as described in
2253 Figure 14 and depicted in the example in Figure 16.

2255 The registrar MUST verify the signature of the pledge enroll status.
2256 Also, the registrar SHALL validate that the pledge is an accepted
2257 device in his domain based on the contained product-serial-number in
2258 the LDevID certificate referenced in the header of the enroll status.
2259 The registrar SHOULD log this event. In case the pledge enroll
2260 status indicates a failure, the pledge was unable to verify the
2261 received LDevID certificate and therefore signed the enroll status
2262 with its IDevID credential. Note that the verification of a
2263 signature of the status information is an addition to the described
2264 handling in section 5.9.4 of [RFC8995].

2266 According to [RFC8995] section 5.9.4, the registrar SHOULD respond
2267 with an HTTP 200 OK in the success case or fail with HTTP 4xx/5xx
2268 status codes as defined by the HTTP standard. Based on the failure
2269 case the registrar MAY decide that for security reasons the pledge is
2270 not allowed to reside in the domain. In this case the registrar MUST
2271 revoke the certificate. The registrar-agent may use the response to
2272 signal success / failure to the service technician operating the
2273 registrar agent. Within the server log the registrar SHOULD capture
2274 this telemetry information.

2276 6.4. Request Pledge-Status by Registrar-Agent from Pledge

2278 The following assumes that a registrar-agent may need to query the
2279 status of a pledge. This information may be useful to solve errors,
2280 when the pledge was not able to connect to the target domain during
2281 the bootstrapping. The pledge MAY provide a dedicated endpoint to
2282 accept status-requests.

2284 Preconditions:

2286 * Registrar-agent: possesses LDevID (RegAgt), list of serial numbers
2287 of pledges to be queried and a list of corresponding manufacturer
2288 trust anchors to be able to verify signatures performed with the
2289 IDevID credential.

2291 * Pledge: may already possess domain credentials and LDevID(Pledge),
2292 or may not possess one or both of these.

2294 +--------+ +-----------+
2295 | Pledge | | Registrar-|
2296 | | | Agent |
2297 | | | (RegAgt) |
2298 +--------+ +-----------+
2299 | |
2300 |<--- pledge-status request -----|
2301 | |
2302 |---- pledge-status response --->|
2303 | |

2305 Figure 18: Pledge-status handling between registrar-agent and pledge

2307 6.4.1. Pledge-Status - Trigger (Registrar-Agent to Pledge)

2309 The registrar-agent requests the pledge-status via HTTP POST on the
2310 defined pledge endpoint: "/.well-known/brski/ps"

2312 The registrar-agent Content-Type header for the pledge-status request
2313 is: application/jose+json. It contains information on the requested
2314 status-type, the time and date the request is created, and the
2315 product serial-number of the pledge contacted as shown in Figure 19.
2316 The pledge-status request is signed by registrar-agent using the
2317 LDevID(RegAgt) credential.

2319 The following Concise Data Definition Language (CDDL) [RFC8610]
2320 explains the structure of the format for the pledge-status request.
2321 It is defined following the status telemetry definitions in BRSKI
2322 [RFC8995]. Consequently, format and semantics of pledge-status
2323 requests below are for version 1. The version field is included to
2324 permit significant changes to the pledge-status request and response
2325 in the future. A pledge or a registrar-agent that receives a pledge-
2326 status request with a version larger than it knows about SHOULD log
2327 the contents and alert a human.

2329 <CODE BEGINS>
2330 status-request = {
2331 "version": uint,
2332 "created-on": tdate ttime,
2333 "serial-number": text,
2334 "status-type": text
2335 }
2336 <CODE ENDS>

2338 Figure 19: CDDL for pledge-status request

2340 The status-type defined for BRSKI-PRM is "bootstrap". This indicates
2341 the pledge to provide current status information regarding the
2342 bootstrapping status (voucher processing and enrollment of the pledge
2343 into the new domain). As the pledge-status request is defined
2344 generic, it may be used by other specifications to request further
2345 status information, e.g., for onboarding to get further information
2346 about enrollment of application specific LDevIDs or other parameters.
2347 This is out of scope for this specification.

2349 Figure 20 below shows an example for querying pledge-status using
2350 status-type bootstrap.

2352 # The registrar-agent request of "pledge-status" in general JWS
2353 serialization syntax
2354 {
2355 "payload": "BASE64URL(status-request)",
2356 "signatures": [
2357 {
2358 "protected": "BASE64URL(UTF8(JWS Protected Header))",
2359 "signature": "base64encodedvalue=="
2360 }
2361 ]
2362 }

2364 # Decoded payload "status-request" representation in JSON syntax
2365 {
2366 "version": 1,
2367 "created-on": "2022-08-12T02:37:39.235Z",
2368 "serial-number": "pledge-callee4711",
2369 "status-type": "bootstrap"
2370 }

2372 # Decoded "JWS Protected Header" representation in JSON syntax
2373 {
2374 "alg": "ES256",
2375 "x5c": [
2376 "base64encodedvalue==",
2377 "base64encodedvalue=="
2378 ]
2379 }

2381 Figure 20: Example of registrar-agent request of pledge-status
2382 using status-type bootstrap

2384 6.4.2. Pledge-Status - Response (Pledge - Registrar-Agent)

2386 If the pledge receives the pledge-status request with status-type
2387 "bootstrap" it SHALL react with a status response message based on
2388 the telemetry information described in section Section 6.3.

2390 The pledge-status response Content-Type header is application/
2391 jose+json.

2393 The following CDDL explains the structure of the format for the
2394 status response, which is :

2396 <CODE BEGINS>
2397 status-response = {
2398 "version": uint,
2399 "status":
2400 "factory-default" /
2401 "voucher-success" /
2402 "voucher-error" /
2403 "enroll-success" /
2404 "enroll-error" /
2405 "connect-success" /
2406 "connect-error",
2407 ?"reason" : text,
2408 ?"reason-context" : { $$arbitrary-map }
2409 }
2410 <CODE ENDS>

2412 Figure 21: CDDL for pledge-status response

2414 Different cases for pledge bootstrapping status may occur, which
2415 SHOULD be reflected using the status enumeration. This document
2416 specifies the status values in the context of the bootstrapping
2417 process and credential application. Other documents may enhance the
2418 above enumeration to reflect further status information.

2420 The pledge-status response message is signed with IDevID or LDevID,
2421 depending on bootstrapping state of the pledge.

2423 * "factory-default": Pledge has not been bootstrapped. Additional
2424 information may be provided in the reason or reason-context. The
2425 pledge signs the response message using its IDevID(Pledge).

2427 * "voucher-success": Pledge processed the voucher exchange
2428 successfully. Additional information may be provided in the
2429 reason or reason-context. The pledge signs the response message
2430 using its IDevID(Pledge).

2432 * "voucher-error": Pledge voucher processing terminated with error.
2433 Additional information may be provided in the reason or reason-
2434 context. The pledge signs the response message using its
2435 IDevID(Pledge).

2437 * "enroll-success": Pledge has processed the enrollment exchange
2438 successfully. Additional information may be provided in the
2439 reason or reason-context. The pledge signs the response message
2440 using its LDevID(Pledge).

2442 * "enroll-error": Pledge enrollment response processing terminated
2443 with error. Additional information may be provided in the reason
2444 or reason-context. The pledge signs the response message using
2445 its IDevID(Pledge).

2447 The reason and the reason-context SHOULD contain the telemetry
2448 information as described in section Section 6.3.

2450 As the pledge is assumed to utilize the bootstrapped credential
2451 information in communication with other peers, additional status
2452 information is provided for the connectivity to other peers, which
2453 may be helpful in analyzing potential error cases.

2455 * "connect-success": Pledge could successfully establish a
2456 connection to another peer. Additional information may be
2457 provided in the reason or reason-context. The pledge signs the
2458 response message using its LDevID(Pledge).

2460 * "connect-error": Pledge connection establishment terminated with
2461 error. Additional information may be provided in the reason or
2462 reason-context. The pledge signs the response message using its
2463 LDevID(Pledge).

2465 The pledge-status responses are cumulative in the sense that connect-
2466 success implies enroll-success, which in turn implies voucher-
2467 success.

2469 Figure 22 provides an example for the bootstrapping-status
2470 information.

2472 # The pledge "status-response" in General JWS Serialization syntax
2473 {
2474 "payload": "BASE64URL(status-response)",
2475 "signatures": [
2476 {
2477 "protected": "BASE64URL(UTF8(JWS Protected Header))",
2478 "signature": "base64encodedvalue=="
2479 }
2480 ]
2481 }

2483 # Decoded payload "status-response" representation in JSON syntax
2484 {
2485 "version": 1,
2486 "status": "enroll-success",
2487 "reason-context": {
2488 "additional" : "JSON"
2489 }
2490 }

2492 # Decoded "JWS Protected Header" representation in JSON syntax
2493 {
2494 "alg": "ES256",
2495 "x5c": [
2496 "base64encodedvalue==",
2497 "base64encodedvalue=="
2498 ],
2499 "typ": "jose+json
2500 }

2502 Figure 22: Example of pledge-status response

2504 In case "factory-default" the pledge does not possess the domain
2505 certificate resp. the domain trust-anchor. It will not be able to
2506 verify the signature of the registrar-agent in the bootstrapping-
2507 status request. In cases "vouchered" and "enrolled" the pledge
2508 already possesses the domain certificate (has domain trust-anchor)
2509 and can therefore validate the signature of the registrar-agent. If
2510 validation of the JWS signature fails, the pledge SHOULD respond with
2511 the HTTP 403 Forbidden status code. The HTTP 406 Not Acceptable
2512 status code SHOULD be used, if the Accept header in the request
2513 indicates an unknown or unsupported format. The HTTP 415 Unsupported
2514 Media Type status code SHOULD be used, if the Content-Type of the
2515 request is an unknown or unsupported format. The HTTP 400 Bad
2516 Request status code SHOULD be used, if the Accept/Content-Type
2517 headers are correct but nevertheless the status-request cannot be
2518 correctly parsed.

2520 7. Artifacts

2522 7.1. Voucher Request Artifact

2524 The following enhancement extends the voucher-request as defined in
2525 [RFC8995] to include additional fields necessary for handling
2526 bootstrapping in the pledge-responder-mode.

2528 7.1.1. Tree Diagram

2530 The following tree diagram is mostly a duplicate of the contents of
2531 [RFC8995], with the addition of the fields agent-signed-data,
2532 registrar-proximity-certificate, and agent-signing certificate. The
2533 tree diagram is described in [RFC8340]. Each node in the diagram is
2534 fully described by the YANG module in Section Section 7.1.2.

2536 module: ietf-voucher-request-prm

2538 grouping voucher-request-prm-grouping
2539 +-- voucher
2540 +-- created-on? yang:date-and-time
2541 +-- expires-on? yang:date-and-time
2542 +-- assertion? enumeration
2543 +-- serial-number string
2544 +-- idevid-issuer? binary
2545 +-- pinned-domain-cert? binary
2546 +-- domain-cert-revocation-checks? boolean
2547 +-- nonce? binary
2548 +-- last-renewal-date? yang:date-and-time
2549 +-- prior-signed-voucher-request? binary
2550 +-- proximity-registrar-cert? binary
2551 +-- agent-signed-data? binary
2552 +-- agent-provided-proximity-registrar-cert? binary
2553 +-- agent-sign-cert? binary

2555 7.1.2. YANG Module

2557 The following YANG module extends the [RFC8995] Voucher Request to
2558 include a signed artifact from the registrar-agent (agent-signed-
2559 data) as well as the registrar-proximity-certificate and the agent-
2560 signing certificate.

2562 <CODE BEGINS> file "ietf-voucher-request-prm@2022-07-05.yang"
2563 module ietf-voucher-request-prm {
2564 yang-version 1.1;

2566 namespace "urn:ietf:params:xml:ns:yang:ietf-voucher-request-prm";
2567 prefix vrprm;
2568 import ietf-restconf {
2569 prefix rc;
2570 description
2571 "This import statement is only present to access
2572 the yang-data extension defined in RFC 8040.";
2573 reference "RFC 8040: RESTCONF Protocol";
2574 }

2576 import ietf-voucher-request {
2577 prefix vcr;
2578 description
2579 "This module defines the format for a voucher request,
2580 which is produced by a pledge as part of the RFC8995
2581 onboarding process.";
2582 reference
2583 "RFC 8995: Bootstrapping Remote Secure Key Infrastructure";
2584 }

2586 organization
2587 "IETF ANIMA Working Group";

2589 contact
2590 "WG Web: <http://tools.ietf.org/wg/anima/>
2591 WG List: <mailto:anima@ietf.org>
2592 Author: Steffen Fries
2593 <mailto:steffen.fries@siemens.com>
2594 Author: Eliot Lear
2595 <mailto: lear@cisco.com>
2596 Author: Thomas Werner
2597 <mailto: thomas-werner@siemens.com>
2598 Author: Michael Richardson
2599 <mailto: mcr+ietf@sandelman.ca>";

2601 description
2602 "This module defines the format for a voucher-request form the
2603 pledge in responder mode. It bases on the voucher-request
2604 defined in RFC 8995, which is a superset of the voucher itself.
2605 It provides content to the MASA for consideration
2606 during a voucher-request.

2608 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
2609 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
2610 'MAY', and 'OPTIONAL' in this document are to be interpreted as
2611 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
2612 they appear in all capitals, as shown here.

2617 Redistribution and use in source and binary forms, with or
2618 without modification, is permitted pursuant to, and subject
2619 to the license terms contained in, the Simplified BSD License
2620 set forth in Section 4.c of the IETF Trust's Legal Provisions
2621 Relating to IETF Documents
2622 (https://trustee.ietf.org/license-info).

2624 This version of this YANG module is part of RFC xxxx; see the
2625 RFC itself for full legal notices.";

2627 revision 2022-07-05 {
2628 description
2629 "Initial version";
2630 reference
2631 "RFC XXXX: BRSKI for Pledge in Responder Mode";
2632 }

2634 // Top-level statement
2635 rc:yang-data voucher-request-prm-artifact {
2636 // YANG data template for a voucher-request.
2637 uses voucher-request-prm-grouping;
2638 }
2639 // Grouping defined for future usage
2640 grouping voucher-request-prm-grouping {
2641 description
2642 "Grouping to allow reuse/extensions in future work.";
2643 uses vcr:voucher-request-grouping {

2645 augment voucher {
2646 description "Base the voucher-request-prm upon the
2647 regular one";

2649 leaf agent-signed-data {
2650 type binary;
2651 description
2652 "The agent-signed-data field contains a JOSE [RFC7515]
2653 object provided by the Registrar-Agent to the Pledge.

2655 This artifact is signed by the Registrar-Agent
2656 and contains a copy of the pledge's serial-number.";
2657 }

2659 leaf agent-provided-proximity-registrar-cert {
2660 type binary;
2661 description
2662 "An X.509 v3 certificate structure, as specified by
2663 RFC 5280, Section 4, encoded using the ASN.1
2664 distinguished encoding rules (DER), as specified
2665 in ITU X.690.
2666 The first certificate in the registrar TLS server
2667 certificate_list sequence (the end-entity TLS
2668 certificate; see RFC 8446) presented by the
2669 registrar to the registrar-agent and provided to
2670 the pledge.
2671 This MUST be populated in a pledge's voucher-request
2672 when an agent-proximity assertion is requested.";
2673 reference
2674 "ITU X.690: Information Technology - ASN.1 encoding
2675 rules: Specification of Basic Encoding Rules (BER),
2676 Canonical Encoding Rules (CER) and Distinguished
2677 Encoding Rules (DER)
2678 RFC 5280: Internet X.509 Public Key Infrastructure
2679 Certificate and Certificate Revocation List (CRL)
2680 Profile
2681 RFC 8446: The Transport Layer Security (TLS)
2682 Protocol Version 1.3";
2683 }

2685 leaf-list agent-sign-cert{
2686 type binary;
2687 min-elements 1;
2688 description
2689 "An X.509 v3 certificate structure, as specified by
2690 RFC 5280, Section 4, encoded using the ASN.1
2691 distinguished encoding rules (DER), as specified
2692 in ITU X.690.
2693 This certificate can be used by the pledge,
2694 the registrar, and the MASA to verify the signature
2695 of agent-signed-data. It is an optional component
2696 for the pledge-voucher request.
2697 This MUST be populated in a registrar's
2698 voucher-request when an agent-proximity assertion
2699 is requested.
2700 It is defined as list to enable inclusion of further
2701 certificates along the certificate chain if different
2702 issuing CAs have been used for the registrar-agent
2703 and the registrar.";
2704 reference
2705 "ITU X.690: Information Technology - ASN.1 encoding
2706 rules: Specification of Basic Encoding Rules (BER),
2707 Canonical Encoding Rules (CER) and Distinguished
2708 Encoding Rules (DER)
2709 RFC 5280: Internet X.509 Public Key Infrastructure
2710 Certificate and Certificate Revocation List (CRL)
2711 Profile";

2713 }
2714 }
2715 }
2716 }
2717 }
2718 <CODE ENDS>

2720 Examples for the PVR are provided in Section 6.2.

2722 8. IANA Considerations

2724 This document requires the following IANA actions.

2726 8.1. BRSKI .well-known Registry

2728 IANA is requested to enhance the Registry entitled: "BRSKI Well-Known
2729 URIs" with the following endpoints:

2731 URI Description Reference
2732 tv create pledge-voucher-request [THISRFC]
2733 te create pledge-enrollment-request [THISRFC]
2734 sv supply voucher response [THISRFC]
2735 se supply enrollment response [THISRFC]
2736 cc supply CA certificates to pledge [THISRFC]
2737 ps query pledge status [THISRFC]
2738 requestenroll supply PER to registrar [THISRFC]
2739 wrappedcacerts request wrapped CA certificates [THISRFC]

2741 9. Privacy Considerations

2743 In general, the privacy considerations of [RFC8995] apply for BRSKI-
2744 PRM also. Further privacy aspects need to be considered for:

2746 * the introduction of the additional component registrar-agent

2748 * no transport layer security between registrar-agent and pledge

2750 The credential used by the registrar-agent to sign the data for the
2751 pledge should not contain any personal information. Therefore, it is
2752 recommended to use an LDevID certificate associated with the
2753 commissioning device instead of an LDevID certificate associated with
2754 the service technician operating the device. This avoids revealing
2755 potentially included personal information to Registrar and MASA.

2757 The communication between the pledge and the registrar-agent is
2758 performed over plain HTTP. Therefore, it is subject to disclosure by
2759 a Dolev-Yao attacker (an "oppressive observer")[onpath]. Depending
2760 on the requests and responses, the following information is
2761 disclosed.

2763 * the Pledge product-serial-number is contained in the trigger
2764 message for the PVR and in all responses from the pledge. This
2765 information reveals the identity of the devices being bootstrapped
2766 and allows deduction of which products an operator is using in
2767 their environment. As the communication between the pledge and
2768 the registrar-agent may be realized over wireless link, this
2769 information could easily be eavesdropped, if the wireless network
2770 is unencrypted. Even if the wireless network is encrypted, if it
2771 uses a network-wide key, then layer-2 attacks (ARP/ND spoofing)
2772 could insert an on-path observer into the path.

2774 * the Timestamp data could reveal the activation time of the device.

2776 * the Status data of the device could reveal information about the
2777 current state of the device in the domain network.

2779 10. Security Considerations

2781 In general, the security considerations of [RFC8995] apply for BRSKI-
2782 PRM also. Further security aspects are considered here related to:

2784 * the introduction of the additional component registrar-agent

2786 * the reversal of the pledge communication direction (push mode,
2787 compared to BRSKI)

2789 * no transport layer security between registrar-agent and pledge

2791 10.1. Denial of Service (DoS) Attack on Pledge

2793 Disrupting the pledge behavior by a DoS attack may prevent the
2794 bootstrapping of the pledge to a new domain.

2796 A DoS attack with a faked registrar-agent may block the bootstrapping
2797 of the pledge due to state creation on the pledge (the pledge may
2798 produce a voucher-request, and refuse to produce another one). One
2799 mitigation may be that the pledge does does not limited the number of
2800 voucher requests it creates until at least one has finished, or a
2801 single onboarding state may expire after a certain time.

2803 10.2. Misuse of acquired PVR and PER by Registrar-Agent

2805 A registrar-agent that uses previously requested PVR and PER for
2806 domain-A, may attempt to onboard the device into domain-B. This can
2807 be detected by the domain registrar while PVR processing. The domain
2808 registrar needs to verify that the "proximity-registrar-cert" field
2809 in the PVR matches its own registrar EE certificate. In addition,
2810 the domain registrar needs to verify the association of the pledge to
2811 its domain based on the product-serial-number contained in the PVR
2812 and in the IDevID certificate of the pledge. (This is just part of
2813 the supply chain integration) Moreover, the domain registrar verifies
2814 if the registrar-agent is authorized to interact with the pledge for
2815 voucher-requests and enroll-requests, based on the LDevID(RegAgt)
2816 certificate data contained in the PVR.

2818 Misbinding of a pledge by a faked domain registrar is countered as
2819 described in BRSKI security considerations [RFC8995] (section 11.4).

2821 10.3. Misuse of Registrar-Agent Credentials

2823 Concerns of misusage of a registrar-agent with a valid
2824 LDevID(RegAgt), may be addressed by utilizing short-lived
2825 certificates (e.g., valid for a day) to authenticate the registrar-
2826 agent against the domain registrar. The LDevID(RegAgt) certificate
2827 may be acquired by a prior BRSKI run for the registrar-agent, if an
2828 IDevID is available on registrar-agent. Alternatively, the LDevID
2829 may be acquired by a service technician from the domain PKI system in
2830 an authenticated way.

2832 In addition it is required that the LDevID(RegAgt) certificate is
2833 valid for the complete bootstrapping phase. This avoids that a
2834 registrar-agent could be misused to create arbitrary "agent-signed-
2835 data" objects to perform an authorized bootstrapping of a rogue
2836 pledge at a later point in time. In this misuse "agent-signed-data"
2837 could be dated after the validity time of the LDevID(RegAgt)
2838 certificate, due to missing trusted timestamp in the registrar-agents
2839 signature. To address this, the registrar SHOULD verify the
2840 certificate used to create the signature on "agent-signed-data".
2841 Furthermore the registrar also verifies the LDevID(RegAgt)
2842 certificate used in the TLS handshake with the registrar-agent. If
2843 both certificates are verified successfully, the registrar-agent's
2844 signature can be considered as valid.

2846 10.4. Misuse of mDNS to obtain list of pledges

2848 To discover a specific pledge a registrar-agent may request the
2849 service name in combination with the product-serial-number of a
2850 specific pledge. The pledge reacts on this if its product-serial-
2851 number is part of the request message.

2853 If the registrar-agent performs DNS-based Service Discovery without a
2854 specific product-serial-number, all pledges in the domain react if
2855 the functionality is supported. This functionality enumerates and
2856 reveals the information of devices available in the domain. The
2857 information about this is provided here as a feature to support the
2858 commissioning of devices. A manufacturer may decide to support this
2859 feature only for devices not possessing a LDevID or to not support
2860 this feature at all, to avoid an enumeration in an operative domain.

2862 10.5. YANG Module Security Considerations

2864 The enhanced voucher-request described in section Section 7.1 is
2865 bases on [RFC8995], but uses a different encoding based on
2866 [I-D.ietf-anima-jws-voucher]. Therefore similar considerations as
2867 described in [RFC8995] section 11.7 (Security Considerations) apply.
2868 The YANG module specified in this document defines the schema for
2869 data that is subsequently encapsulated by a JOSE signed-data Content-
2870 type as described in [I-D.ietf-anima-jws-voucher]. As such, all of
2871 the YANG-modeled data is protected against modification. The use of
2872 YANG to define data structures via the "yang-data" statement, is
2873 relatively new and distinct from the traditional use of YANG to
2874 define an API accessed by network management protocols such as
2875 NETCONF [RFC6241] and RESTCONF [RFC8040]. For this reason these
2876 guidelines do not follow the template described by [RFC8407] section
2877 3.7 (Security Considerations Section).

2879 11. Acknowledgments

2881 We would like to thank the various reviewers, in particular Brian E.
2882 Carpenter, Oskar Camenzind, Hendrik Brockhaus, and Ingo Wenda for
2883 their input and discussion on use cases and call flows. Further
2884 review input was provided by Jesser Bouzid, Dominik Tacke, and
2885 Christian Spindler. Special thanks to Esko Dijk for the in deep
2886 review and the improving proposals. Support in PoC implementations
2887 and comments resulting from the implementation was provided by Hong
2888 Rui Li and He Peng Jia.

2890 12. References

2892 12.1. Normative References

2894 [I-D.ietf-anima-jws-voucher]
2895 Werner, T. and M. Richardson, "JWS signed Voucher
2896 Artifacts for Bootstrapping Protocols", Work in Progress,
2897 Internet-Draft, draft-ietf-anima-jws-voucher-05, 24
2898 October 2022, <https://www.ietf.org/archive/id/draft-ietf-
2899 anima-jws-voucher-05.txt>.

2901 [I-D.ietf-anima-rfc8366bis]
2902 Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T.,
2903 and Q. Ma, "A Voucher Artifact for Bootstrapping
2904 Protocols", Work in Progress, Internet-Draft, draft-ietf-
2905 anima-rfc8366bis-00, 31 January 2022,
2906 <https://www.ietf.org/archive/id/draft-ietf-anima-
2907 rfc8366bis-00.txt>.

2909 [I-D.ietf-netconf-sztp-csr]
2910 Watsen, K., Housley, R., and S. Turner, "Conveying a
2911 Certificate Signing Request (CSR) in a Secure Zero Touch
2912 Provisioning (SZTP) Bootstrapping Request", Work in
2913 Progress, Internet-Draft, draft-ietf-netconf-sztp-csr-14,
2914 2 March 2022, <https://www.ietf.org/archive/id/draft-ietf-
2915 netconf-sztp-csr-14.txt>.

2917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2918 Requirement Levels", BCP 14, RFC 2119,
2919 DOI 10.17487/RFC2119, March 1997,
2920 <https://www.rfc-editor.org/info/rfc2119>.

2922 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
2923 Housley, R., and W. Polk, "Internet X.509 Public Key
2924 Infrastructure Certificate and Certificate Revocation List
2925 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
2926 <https://www.rfc-editor.org/info/rfc5280>.

2928 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
2929 DOI 10.17487/RFC6762, February 2013,
2930 <https://www.rfc-editor.org/info/rfc6762>.

2932 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
2933 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
2934 <https://www.rfc-editor.org/info/rfc6763>.

2936 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
2937 "Enrollment over Secure Transport", RFC 7030,
2938 DOI 10.17487/RFC7030, October 2013,
2939 <https://www.rfc-editor.org/info/rfc7030>.

2941 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
2942 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2943 2015, <https://www.rfc-editor.org/info/rfc7515>.

2945 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
2946 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
2947 <https://www.rfc-editor.org/info/rfc8040>.

2949 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2950 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2951 May 2017, <https://www.rfc-editor.org/info/rfc8174>.

2953 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
2954 "A Voucher Artifact for Bootstrapping Protocols",
2955 RFC 8366, DOI 10.17487/RFC8366, May 2018,
2956 <https://www.rfc-editor.org/info/rfc8366>.

2958 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
2959 Definition Language (CDDL): A Notational Convention to
2960 Express Concise Binary Object Representation (CBOR) and
2961 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
2962 June 2019, <https://www.rfc-editor.org/info/rfc8610>.

2964 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
2965 and K. Watsen, "Bootstrapping Remote Secure Key
2966 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
2967 May 2021, <https://www.rfc-editor.org/info/rfc8995>.

2969 12.2. Informative References

2971 [BRSKI-PRM-abstract]
2972 "Abstract BRSKI-PRM Protocol Overview", April 2022,
2973 <https://raw.githubusercontent.com/anima-wg/anima-brski-
2974 prm/main/pics/brski_prm_overview.png>.

2976 [I-D.ietf-anima-brski-ae]
2977 von Oheimb, D., Fries, S., and H. Brockhaus, "BRSKI-AE:
2978 Alternative Enrollment Protocols in BRSKI", Work in
2979 Progress, Internet-Draft, draft-ietf-anima-brski-ae-03, 24
2980 October 2022, <https://www.ietf.org/archive/id/draft-ietf-
2981 anima-brski-ae-03.txt>.

2983 [IEEE-802.1AR]
2984 Institute of Electrical and Electronics Engineers, "IEEE
2985 802.1AR Secure Device Identifier", IEEE 802.1AR, June
2986 2018.

2988 [onpath] "can an on-path attacker drop traffic?", n.d.,
2989 <https://mailarchive.ietf.org/arch/msg/saag/
2990 m1r9uo4xYznOcf85Eyk0Rhut598/>.

2992 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
2993 Request Syntax Specification Version 1.7", RFC 2986,
2994 DOI 10.17487/RFC2986, November 2000,
2995 <https://www.rfc-editor.org/info/rfc2986>.

2997 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
2998 Verification of Domain-Based Application Service Identity
2999 within Internet Public Key Infrastructure Using X.509
3000 (PKIX) Certificates in the Context of Transport Layer
3001 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
3002 2011, <https://www.rfc-editor.org/info/rfc6125>.

3004 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
3005 and A. Bierman, Ed., "Network Configuration Protocol
3006 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
3007 <https://www.rfc-editor.org/info/rfc6241>.

3009 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
3010 Application Protocol (CoAP)", RFC 7252,
3011 DOI 10.17487/RFC7252, June 2014,
3012 <https://www.rfc-editor.org/info/rfc7252>.

3014 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
3015 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
3016 <https://www.rfc-editor.org/info/rfc8340>.

3018 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
3019 Documents Containing YANG Data Models", BCP 216, RFC 8407,
3020 DOI 10.17487/RFC8407, October 2018,
3021 <https://www.rfc-editor.org/info/rfc8407>.

3023 [RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
3024 "Handling Long Lines in Content of Internet-Drafts and
3025 RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
3026 <https://www.rfc-editor.org/info/rfc8792>.

3028 [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
3029 Structures and Process", STD 96, RFC 9052,
3030 DOI 10.17487/RFC9052, August 2022,
3031 <https://www.rfc-editor.org/info/rfc9052>.

3033 [RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
3034 Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
3035 August 2022, <https://www.rfc-editor.org/info/rfc9053>.

3037 [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
3038 Ed., "HTTP Semantics", STD 97, RFC 9110,
3039 DOI 10.17487/RFC9110, June 2022,
3040 <https://www.rfc-editor.org/info/rfc9110>.

3042 [RFC9238] Richardson, M., Latour, J., and H. Habibi Gharakheili,
3043 "Loading Manufacturer Usage Description (MUD) URLs from QR
3044 Codes", RFC 9238, DOI 10.17487/RFC9238, May 2022,
3045 <https://www.rfc-editor.org/info/rfc9238>.

3047 Appendix A. Examples

3049 These examples are folded according to [RFC8792] Single Backslash
3050 rule.

3052 A.1. Example Pledge Voucher Request - PVR (from Pledge to Registrar-
3053 agent)

3055 The following is an example request sent from a Pledge to the
3056 Registrar-agent, in "General JWS JSON Serialization".
3057 The message size of this PVR is: 4649 bytes

3059 =============== NOTE: '\' line wrapping per RFC 8792 ================

3061 {
3062 "payload":
3063 "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3NlcnRpb24\
3064 iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5\
3065 vbmNlIjoiTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjI\
3066 tMDQtMjZUMDU6MTY6MTcuNzA5WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbWl0eS1yZWd\
3067 pc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW9HQ0NxR1N\
3068 NNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01\
3069 CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd05qRTRNVEp\
3070 hRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzN\
3071 NeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibEpsWjJsemR\
3072 ISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNksvaTc5b1J\
3073 rSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1dSZmZlV2t\
3074 5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUUdDQ3NHQVF\
3075 VRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQVlEVlIwUkJ\
3076 FRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1WlhTQ0huSmx\
3077 aMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdncWhrak9QUVF\
3078 EQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUmF1YnBDN01\
3079 hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaDR4SVhrMSI\
3080 sImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRnBZVW0xTVd\
3081 GcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VVhSak1teHV\
3082 ZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSmFrbDNUV3B\
3083 KZEUxRVVYUk5hbHBWVFVSVk5rMUVZelpPUkVWMVRrUlJORmRwU1hOSmJrNXNZMjFzYUd\
3084 KRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaXdpYzJsbmJ\
3085 tRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYVVwWlkwaHd\
3086 jMVJWZERSaVNFSkNUbXBvYWxaVVZrZFZWVEZaVmxoYWRWTldVVEpWV0dNNVNXbDNhVmx\
3087 YZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrY3pWM2hHU0d\
3088 WMFdGQTRiR3hTVmkwNWRXSnlURmxxU25aUllUWmZlUzFRYWxGWk5FNWhkMW81Y0ZKaGI\
3089 yeE9TbTlFTm1SbFpXdHVTVjlGV0daemVWWlRZbmM0VTBONlRWcE1iakJoUVhWb2FVZFp\
3090 UakJSSW4xZGZRPT0iLCJhZ2VudC1zaWduLWNlcnQiOlsiTUlJQjFEQ0NBWHFnQXdJQkF\
3091 nSUVZbWQ0T1RBS0JnZ3Foa2pPUFFRREFqQStNUk13RVFZRFZRUUtEQXBOZVVKMWMybHV\
3092 aWE56TVEwd0N3WURWUVFIREFSVGFYUmxNUmd3RmdZRFZRUUREQTlVWlhOMFVIVnphRTF\
3093 2WkdWc1EwRXdIaGNOTWpJd05ESTJNRFEwTWpNeldoY05Nekl3TkRJMk1EUTBNak16V2p\
3094 BOU1STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1\
3095 SY3dGUVlEVlFRRERBNVNaV2RwYzNSeVlYSkJaMlZ1ZERCWk1CTUdCeXFHU000OUFnRUd\
3096 DQ3FHU000OUF3RUhBMElBQkd4bHJOZmozaVJiNy9CUW9kVys1WWlvT3poK2pJdHlxdVJ\
3097 JTy9XejdZb1czaXdEYzNGeGV3TFZmekNyNU52RDEzWmFGYjdmcmFuK3Q5b3RZNVdMaEo\
3098 2alp6QmxNQTRHQTFVZER3RUIvd1FFQXdJSGdEQWZCZ05WSFNNRUdEQVdnQlJ2b1QxdWR\
3099 lMmY2TEVRaFU3SEhqK3ZKL2Q3SXpBZEJnTlZIUTRFRmdRVVhwemxNS3hscEE2OGNVNUZ\
3100 RTVhVdm5JVDZRd3dFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBd0l3Q2dZSUtvWkl6ajB\
3101 FQXdJRFNBQXdSUUlnYzJ5NnhvT3RvUUJsSnNnbE9MMVZ4SEdvc1R5cEVxUmZ6MFF2NFp\
3102 FUHY0d0NJUUNWeWIyRjl6VjNuOTUrb2xnZkZKZ1pUV0V6NGRTYUYzaHpSUWIzWnVCMjl\
3103 RPT0iLCJNSUlCekRDQ0FYR2dBd0lCQWdJRVhYakhwREFLQmdncWhrak9QUVFEQWpBMU1\
3104 STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1ROHd\
3105 EUVlEVlFRRERBWlVaWE4wUTBFd0hoY05NVGt3T1RFeE1UQXdPRE0yV2hjTk1qa3dPVEV\
3106 4TVRBd09ETTJXakErTVJNd0VRWURWUVFLREFwTmVVSjFjMmx1WlhOek1RMHdDd1lEVlF\
3107 RSERBUlRhWFJsTVJnd0ZnWURWUVFEREE5VVpYTjBVSFZ6YUUxdlpHVnNRMEV3V1RBVEJ\
3108 nY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVRsRzBmd1QzM29leloxdmtIUWJldGV\
3109 ibWorQm9WK1pGc2pjZlF3MlRPa0pQaE9rT2ZBYnU5YlMxcVppOHlhRVY4b2VyS2wvNlp\
3110 YYmZ4T21CanJScmNYbzJZd1pEQVNCZ05WSFJNQkFmOEVDREFHQVFIL0FnRUFNQTRHQTF\
3111 VZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUdEQVdnQlRvWklNelFkc0Qvai8rZ1gvN2N\
3112 CSnVjSC9YbWpBZEJnTlZIUTRFRmdRVWI2RTliblh0bitpeEVJVk94eDQvcnlmM2V5TXd\
3113 DZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBUG5CMHcxTkN1cmhNeEp3d2ZqejdnRGlpeGt\
3114 VWUxQU1o5ZU45a29oTlFVakFpRUF3NFk3bHR4V2lQd0t0MUo5bmp5ZkRObDVNdUVEQml\
3115 teFIzQ1hvWktHUXJVPSJdfX0",
3116 "signatures":[{
3117 "protected":"eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVN\
3118 U1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBe\
3119 EthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQ\
3120 0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNNUXN3Q\
3121 1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNUk13RVFZR\
3122 FZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1WjBSbGRtb\
3123 GpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUmNCalpjR\
3124 UVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbXZhS0N2T\
3125 XgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdCQjhXSFcxa\
3126 GMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkSXdRWU1CY\
3127 UFGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQW9HQ0NzR\
3128 0FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFnTkhBR\
3129 EJFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxcUhpZ0lnW\
3130 ENtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il0sImFsZ\
3131 yI6IkVTMjU2In0",
3132 "signature":"Y_ohapnmvbwjLuUicOB7NAmbGM7igBfpUlkKUuSNdG-eDI4BQ\

3134 yuXZ2aw93zZId45R7XxAK-12YKIx6qLjiPjMw"
3135 }]
3136 }

3138 Figure 23: Example Pledge Voucher Request - PVR

3140 A.2. Example Parboiled Registrar Voucher Request - RVR (from Registrar
3141 to MASA)

3143 The term parboiled refers to food which is partially cooked. In
3144 [RFC8995], the term refers to a Pledge voucher-request (PVR) which
3145 has been received by the Registrar, and then has been processed by
3146 the Registrar ("cooked"), and is now being forwarded to the MASA.

3148 The following is an example Registrar voucher-request (RVR) sent from
3149 the Registrar to the MASA, in "General JWS JSON Serialization". Note
3150 that the previous PVR can be seen in the payload as "prior-signed-
3151 voucher-request". The message size of this RVR is: 13257 bytes

3153 =============== NOTE: '\' line wrapping per RFC 8792 ================

3155 {
3156 "payload":
3157 "eyJpZXRmLXZvdWNoZXItcmVxdWVzdC1wcm06dm91Y2hlciI6eyJhc3NlcnRpb24\
3158 iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiY2FmZmUtOTg3NDUiLCJ\
3159 ub25jZSI6ImM1VEVPb29NTE5hNEN4L1UrVExoQ3c9PSIsInByaW9yLXNpZ25lZC12b3V\
3160 jaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbTFNV0ZwMlpGZE9\
3161 iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYVVrMlpYbEthR01\
3162 6VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1pFaHJhVXhEU25\
3163 wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFWa3lSbTFhYlZWMFQxUm5NMDVFVldsTVE\
3164 wcDFZakkxYWxwVFNUWkpiVTB4VmtWV1VHSXlPVTVVUlRWb1RrVk9ORXd4VlhKV1JYaHZ\
3165 VVE5qT1ZCVFNYTkpiVTU1V2xkR01GcFhVWFJpTWpScFQybEplVTFFU1hsTVZFRjVURlJ\
3166 KZVZaRVFUTlBhazE2VDJwQk5FeHFSVFZPYkc5cFRFTkthRm95Vm5Wa1F6RjNZMjA1TW1\
3167 GWFVteGFRekYzWTIwNU5HRlhNWEJrU0d0MFkyMVdibUZZVGpCamJVWjVURmRPYkdOdVV\
3168 XbFBhVXBPVTFWc1JGSkdVa1JSTUVacFZESmtRbVF3YkVOUlYyUktVakJHV1ZkWVRuZFR\
3169 WMVoyVkZWR2RsSXdUa1JqVldSVVZGUlJOVkZyUms1Uk1ERkhaRE5vUkdWclJrdFJiV1J\
3170 QVm10S1FsZFdVa0poTUZwVFZGWktTbVF3VmtKWFZWSlhWVlpHVEZKRlJuTlViVlpXVkc\
3171 1YWFWZEZTbTlaYlRWeVpVVmFWVkZXVWtOYU1EVlhVV3RHZWxSVlVrWk5WRlpXVFRGYWN\
3172 GbDZTbk5oTWtaWVVtNXNiRlpGVmxGVVZVVjNVakJGZUZaVlZrTmtNMlJJVmtab2MxWkh\
3173 SbGxWYlhoT1ZXdFdNMUpJWkZwU1JscFNWVlZTUlZGWGFFOWFWbHBQWTBkU1NGWnJVbEp\
3174 XUlVac1VtNWpkMlZWTVVWU1dHeE9Va1pHTTFSdWNFcE5WVFZGWVVkR1IyUjZRalpVVlZ\
3175 KR1pWVXhSVlZZWkU5bGEydDRWR3RTYjFsVk1VaFRXR2hFWld0R1MxRnRaRTlXYTBwQ1Y\
3176 xWlNRbUV3V2xOVVZrcEtaREJXUWxkVlVsZFZWa1pNVWtWR2MxUnRWbFpVYmxwcFYwVkt\
3177 iMWx0TlhKbFJWcEZVVlpPUTFvd05WZFJhMFo2VkZWTmQwMVVWbFpOTVZwd1dYcEtjMkV\
3178 4YkZsVGFsWk9WVlJvTTFKR1JscFNSbHBTVlZWb1JWRldjRTlhVmxwUFkwZFNTRlpZYUV\
3179 oU1JVWllVVzFrVDFaclNrSlVWVEZGVFVSRk1WWlVTbk5OUm5CWFUyMTRZVTF0ZURaYVJ\
3180 XaExZVWRPY1ZGc2NFNVJhekZJVVc1c2VGSXhUazVPUkd4Q1dqQldTRkV3VG5oU01VNU9\
3181 Ua1JzUW1Rd1ZrbFJWRUpLVVZWS1NsVklhRmhrVlRGSlVucG9TMVJIV2taVlJVVTFUMWh\
3182 hZDAxdVZrbFNWVFZxVlROc2JWa3pWVE5VUjJSYVRraEJlRTVGUmtOT01GSk9XbFJGTkU\
3183 xSVRrWmxSV1J4VkZOME0yTnJOVFJPTURVMVdWaE9lRXQ2Um5CTlJXUlVVVEZKTlU1VVV\
3184 UTk5SRVp0VWpKV1dGUldSbWxqVjNCWVpXdEtZVlJWU1hkU01FVjRWbGRTUzFWV1JsaFV\
3185 WVXBTVWpCT1JHTXdaRUpWVmxaSFVXNWtUbEZyU201YU0wcERXakJXUjFGc1JtcFNSV2h\
3186 GVVZVNVExb3dOVmRUUmtVMFVXdEdiVTlGVmtOUlZURkVVV3BTUW1Rd2RFSlhWVkpYVld\
3187 wQ1UxRnJUa1prTUdjd1UxZFNhVmRIZURaWlZtaFRZa2RPZEZadE5XaFhSVFIzV1RJeFI\
3188 yVlZlSFJOVkZaYVRXcHNNRmt3WkVka1YxWlVUbGR3YVUxcVFqTlJNbVJhVTFWMGRsZHJ\
3189 iRFpoYWtKR1VWaGtTbEpHVGtKUldHUlRWVlZzYjFGV1FqVlBXRnBOVTFkR01WVnJWbEp\
3190 qYlhnMVlteGtNRlI2VmxOaVZYQXdZVmhTVW1GNlpFOVhSRkpMVlVoV2RWVklRazlVYXp\
3191 BeFZWUnNRbUZWUm5sa1JVNTBWRVprWVZSVmJFMVdiRTEyVFZWc1JWbFhjR2xqTVU1Sll\
3192 tNXdkbUpYYjNkV1F6a3paVmhKY21Nd2RFdGpRM1IxVFhwU1VsQlVNR2xNUTBwb1dqSld\
3193 kV1JETVhwaFYyUjFXbGRSZEZwSFJqQlpVMGsyU1cxV05WTnVaRnBYUjNoNldXcEtSMkV\
3194 3YkhGaU1teGhWMGQ0VEZrd1duZFhWbFowVFZVeFdGSnVRWGxYYTFwclZESkplR05HYkZ\
3195 SWFJrcHhXV3hhWVU1R2NFZGFSbVJzWWxaS1JWUldhR3RoYlVwVlVWUktXRlp0VW5KWmE\
3196 yUkxaRlpXV1ZWdGNFNWlXR2d4VjFjd2VGWXlSWGRsUm1oV1lsZG9jbFZxUWxkalJsRjV\
3197 UbGh3YUZadGREWlZNakUwVjJ4a1IxTnVUbGhoTURFMFdrY3hTMk5HVGxWWGEzQm9ZVEo\
3198 zZWxaR1pIZFNiVkpHVFZaV1UxZEdTazlXYTFwM1ZteFNWbFZyY0U5aGVrVXlWVlpTWVZ\
3199 Sc1NrWlNha1pWVmxaS1ExcEVSbXRqUms1WlZHdHdhV0Y2Vm5wWFZFbDRZekpHU0ZOclV\
3200 rNVhSbHB5Vm01d1IyTkdaSE5oUlhCb1ZsUnNkMVV5TVhkWGJGbDRZMGhTV0dKRk1UTlV\
3201 iRlUxVWxac05sRnJPVlpOUnpneFYyMTRSbUZWZUVSVGJuQm9WakpTTVZkV2FGTk5WMDU\
3202 wVm01d1NtRnVRbWxhV0d4TFpESk9kRTlVUW1GV01EUjNWMnhrVW1GVk9YQlRiWGhzVmx\
3203 oQ2RsZFhkR3RoYlVaV1QxaENWR0V4Y0ZkYVYzUnlaVVpTZEdKRmNHcE5SM2d3V2tWb1E\
3204 xbFdSWGRoZWtwVVZqTm9kbFZ0ZEhwbFZsWlpVMnhTYVdKclNrcFdhMVpUVVcxV2MxSnV\
3205 VbFJpVlZwVlZXdGFjbVZzVFhwalJ6bFhUVlpHTmxkWWNFTmhiRWw1V1ROa1ZVMUdSak5\
3206 aVm1SaFZXdHNjR1F5YkdwTmJYaDFXVzB4UjAxSFVsbFRiWGhLWVcwNWNGZEVRazlsYXp\
3207 sV1QxWm9VMkpyY0dGWmJHTTFaV3hOZDA5WVZsSlhSMUpUVjFSR1YyRXhiM2RqUlZaWVV\
3208 qRndUVmxzVWt0WFZUbFhVMnhXVjFJd05URlVSazE0WXpGUmQwNVdRbWxTZWxaMlZqSjB\
3209 SazFGT1VaWGJYUlhZa2hCZDFReFVrOWhNbEY0Vld0d1YxWlVWbGRYUkVwaFYyczVWMWR\
3210 1UWxkaVJHdzFWWHBPVDFaV1JuSmhSa3BRVmpOQ2Vsa3haSHBsVjBsNldUSnNiVlpxUlR\
3211 WSmFYZHBXVmRrYkdKdVVYUmpNbXh1WW1reGFscFlTakJKYW5CaVNXc3hTbE5WVGt0U1J\
3212 VNUVVVmRPZUZvd1JqTlRWVXBDV2pCc1JsZEhlSEZSTURGRlVWVjBRMW95WkhoaFIzUnh\
3213 WREZDVWxWVlVrSmhhMHB6VkZaR2VtUXdUbEpYVlZKWFZWWkdTRkpZWkV0UmJGWlZVbFp\
3214 PVGxGclJraFJWRVpXVWxWT2JtUXdjRlZYUjNoRldXcEplR1F4YkZoT1ZGWk9WV3hXTTF\
3215 KWVpGcFNSbHBTVlZWNFJWRllhRTlhVmxwUFRWWnNkVlJ1UW1GU01uaHZXVEkxY21WRlV\
3216 qWlJWVFZEV2pBMVYxRnJSbXBVVlVweVRWUldWazF0ZDNkWGJGSkdXVlV4UTFvd1pFSk5\
3217 WbFpHVVZoa00xVnNVbGxpUmxKb1YwWktjMVpWYUZkbGJVWkdUVmhhWVZJeFducFZWRUp\
3218 HWkRCb2Ixa3dOVTVoYTBZelZGZHdTazVGTVVWWk0zQk9aV3RGZDFZeWFHcFVhekUyVVZ\
3219 oa1RtRnJhekJVVlZKcVpXc3hObEZVUWxoaGEwcDBWRlpHZW1Rd1RsSlhWVkpYVlZaR1N\
3220 GSllaRXRSYkZaVlVsWk9UbEZyUmtoUlZFWldVbFZPYm1Rd2NGVlhSM2hGV1dwSmVHUXh\
3221 iRmhPVkZaT1ZXeFdNMUpZWkZwU1JscFNWVlY0UlZGWWFFOWFWbHBQVFZac2RWUnVRbUZ\
3222 TTW5odldUSTFjbVZGVWpaUlZUVkRXakExVjFGclJtcFVWVXB5VFZSV1ZrMXRkM2RYYkZ\
3223 KR1dXc3hRMkV3WkVKTlZsWkdVVmhrTTFVeFVsbGlSbEpvVjBaS2MxWlZhRmRsYlVaR1R\
3224 WaGFZVkl4V25wVlZtaERaREF4UjJFelpFWmtNV3hKVXpJNVlWTlljSEZOUlU1Q1ZWWnN\
3225 TbE15T1dGVFdIQnhUVVZTUWxWWFRrVlZWMlJDVWxSWmQwMVZPSEppTW5CRVlUTktSVlZ\
3226 1WXpOYU1Hd3lWMnRWTUdGVVRUQmFSMHB2VVROR2NGSjZaSEZpTWprelYyNUJNR1ZJV2p\
3227 aU2JsSk5XbnBhVlZaNlFtOVViVkpKWkd4Q1JWVXhVbnBrVm1oVVpWWmpOV1JJU1hwUld\
3228 HUkVZa2RhUkdJd1VsZFVia1pRWkhwc05WUldaekpVYlRWT1VqRldNMUpIWkZwU1JscFR\
3229 UVVpDUWxWVlozWlJhMFpTVWtWR2JscFZSazVSYW1oSVVWUkdWbHBGYkROVlZteE9VVzF\
3230 HUWxKcmJ6TlRTRkpVWkROQ1RWUklWbEJYYW1ScVlUQkdjMVZWYUZaTk1tUkNWRmRqZGx\
3231 Ock1VTk5SV1JDVFZaV2ExSkhaRkpXTUVwRFZXMU9WVTVVVFRCaWF6RmFaR3hTYWxKdVV\
3232 uSmFia295VGpOb1ZrNHdVbkJpVldoeFpXdEdWVkZ0WkU5V2EyaFVWbFZXUlZKRlJreFJ\
3233 iV1J1WTJ0S2JsSlZXa05WVjA1RlVWZHdRbE13U201YU0wWnZZVEp3VUZWR1JsSlNSVVp\
3234 1Vkd0c1FsSkZTa2RSVjJ4R1VWaENTMDR6YUhkVWJGWXlWVlZ3U0UxRk5XOVVSMGwyV2x\
3235 oU2FVMXFRazFTUmxWNFRtMTRkMVV3YUZCT01rWnNZbnBDVjFkWVozZGxTR1JFVTFWRmN\
3236 sUjZWWFpYVkZwRllVTjBhVkZxU1RSTmFsSXhZVmRHVUZWWFJsWlNSRnB1VVZVMWIxZFV\
3237 iRmRTYlZGeVlXNUtlVmt3VmpKVGJsRnBURU5LVGxOVmJFUlNNVkpFVVRCR2FVc3laRUp\
3238 rTUd4RFVWZGtTbEpXYUhOaGEwVjJaV3RHVEZGdFpHNWpWMmh5WVdzNVVWVldSa1ZSVjN\
3239 CRFdUQXhVbU16WkVSVlZteEZWbXhHVWxJd1ZqTlRhMHBXVmtWV1ZGUlZTa0pTTUVWNFZ\
3240 sVldSRm96WkV0V1JtaHpVa2RKZVUxWVpGcFdlbFV4VkZaS1ZtUXdWak5YVlZKWFZWWkd\
3241 UVkpGUmpSVWJWWlhWR3BHV21Kck5YZFhhMlJ6WVVkT2RXRXphRVZsYTBaUFVXMWtUMVp\
3242 yU2tKWk1ERkRZWHBGTVZaVVNuTk5SbkJWVWxaS1RsRlVhRWhSVkVaV1VsVkdNMlF3YkZ\
3243 WWFIzaFZXVlpvVTJKR1JYZFNXR1JKWVVkT1QxUlhjRUprTURGeFUxUlNUbEpIVGpWVWJ\
3244 uQldUbFprYjFrd05VNWxhMFl6VkZkd1NrNUZNVVZaTTJ4UFpXeFZNVll5Y0VOaVJURlN\
3245 Zek5rUkZWV2JFVldiRVpTVWpCV00xTnJTbFpXUlZaVVZGVktRbEl3UlhoV1ZWWkVXak5\
3246 rUzFaR2FITlNSMGw1VFZoa1dsWjZWVEZVVmtwV1pEQldNMWRWVWxkVlZrWk5Va1ZHTkZ\
3247 SdFZsZFVha1phWW1zMWQxZHJaSE5oUjA1MVlUTm9SV1ZyUms5UmJXUlBWbXRLUWxrd01\
3248 VTmhla1V4VmxSS2MwMUdjRlZTVjBaT1VXMWtTRkZVUmxaU1ZVWXpaREZLVlZkSGVGVlp\
3249 WbWhUWWtaV1NWWnVjR2hTVkVZeVYydGtWMk14UlhkU1dHUllWa1ZHVlZGdFpHcGpWMmh\
3250 5WVdzNVVWVlZiRU5SYldSdVkxZG9jbUZyT1ZGVlZURkRVVzVrVDFFd1JrSlZhM0JEVm0\
3251 wNWVscEZkRE5YVlRVMFlWWkNORk5JV25CU2JrWk1aV3RTYzA5WFdqQlVTRlpPV1ZjeGQ\
3252 xSnNSbXBYU0dONFRXcGthRlJ0T1ZOWmJrNUpUREJhVG1OdE1UWlJNRVpKVFhwak0wMTZ\
3253 UbXBOYlRscFZVZE9jMlJzVG5sWFZVb3lUVVZPTUZZeFJqQlpWRnBvU3pKT2RrMXNiRE5\
3254 YYTFKQ1ZUQktibFJzV2tsVmF6RkRVVmRaTkZKVlRrVlJWV1JDVlZWbmRsRlhaRVpSVlR\
3255 GQ1RrVmtRazFXVm10U1NHUkdVV2s1TTFWVlZrSmtNR3hFVVd0U1FscHJTbTVVYkZwSlZ\
3256 UQXhSbEl3VWtKV01tUkRWVmh3TkdWdVpIZFZia0pOWlZNNWVWUldWbHBsYlVadlRXNU5\
3257 lRTB5VmxaUFYyUkhaV3RHYTFGdFpFOVdhMmhTVGtWV1Ixb3hSbFppYms1c1RWVjRSR0V\
3258 6VGpGT1JGWjFaRWhzVWxFeFdrSmFSbEpzVVZWR05WSkVhSEprTUU1dVYxVnNUR0l4Y0V\
3259 wbGJXOTNVbFZHTTFOVlVsUlJWVVl6Vld4R1NtRkZSa3BqTVd4eldsWndUR015Y0VkVWE\
3260 wNTZVMnQwYkZWSGVFaFVWVVpOV2xoQ1YxcFViRVpVUkdSUFlqTlJNVTFVVmpObFJ6Rlh\
3261 aRlZ3UTFGWGJFSlpNRlpPVmxaV2IxSldUbnBVUm1SUlRsaG9WRlZXVlhkWFNFWTJWbTV\
3262 GTkZkWVduQlNha1pwVm0wNU5sSXpjRFJPV0hCUFdqSk9lbVI2TURsSmJERTVabEVpTEN\
3263 KemFXZHVZWFIxY21WeklqcGJleUp3Y205MFpXTjBaV1FpT2lKbGVVbzBUbGROYVU5c2M\
3264 ybFVWV3hLVVRCb2NWRXdUa0paTVU1dVVWaGtTbEZyUm01VFZXUkNWMGRvTUUxVVVucGl\
3265 NREZDWWpCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U1ZtdzBVVE53UWxOclNtNVViRnB\
3266 EVVZac1ZWRlhkRTlUVlRGVFZGaGtSbFZXYkVWV2JFWlNVekJTUW1OR1VtaFdNVm93VjJ\
3267 4ak1XVnJiRVpTYTJoT1ZWUm9NMUpHUmxwU1JscFNWVlY0UlZGV2NFUldhMDVEVWtaV1I\
3268 xUllhRVpXUlVaUlVXMWtUMVpyU2tKVVZURkVVbXh3YzFsdE1WTmtiVTV5Vkd0S1RsRXd\
3269 SbGxTUmxKS1pVVXhSVlJZYkU5aGEwVXhWRmR3U21WVk5WZGlNV3hGWlcxek1WUXhVbkp\
3270 sUlRGeFZGaG9UbUZyTUhoVU1WSldUbFprY1ZGdGFFNVZXRTR6VVRGR1dsSkdXbEpWVld\
3271 SR1pEQndSVlV3VWtaV1JURkRVbFZrUWsxV1ZrWlJNbVF6VXpGVmVXSkhlR2xXTVZveFd\
3272 UTnNRMUZzU2paU1ZrSk9VVlJDU0ZGVVJsWlNWVTR6WkRCa1VtSkdSbTVWVkVaRFZrVXh\
3273 VMVZZWkVaYU1XeEZWbXhHVWxKclZqTmtSM0JhVmpGd2RGZHNUWGRPVlRsRldYcENUMVp\
3274 GVmxoVVZVcFNVakJGZUZaVlZrSmtNMlJQVmxWYWIxSkZNVFZPVlZwUFpXeFdNRlJXVWt\
3275 Ka01VWlZVV3h3VGxGck1VaFJibXg0VWpGT1RrNUViRUphTUZaSVVUQk9lRkl4VGs1T1J\
3276 HeENaREJXU1ZGVVFrcFJWVXBQVFVSb2NWWXdlSHBOUjBadlV6Qm9XbGR1Vm05aVZ6Rmp\
3277 UREpqTkdScVVsaFRNR2d5VVZoU2FGcHNSazFSVTNSS1pGVXhUMkZITVc1aFZ6RllUakJ\
3278 HVG1OdVJtOWlWMHBWVFRCc2FGVkZUalZoUnpGaFUxWk9kMVI2V20xaVUzTXlVMWhhWTB\
3279 3eldrcGphM1J2VlZaU01WWnRPVXhoYldSYVVWaGtiV0ZyUm5aUmJXUnVZMnRLYmxKVld\
3280 rTlZWMDVEVTFWR1Vsa3dVa05qU0ZKYVYwVTFiMVJHYUZOaVIwMTZWVmhXYWsxdGVITlp\
3281 iR1JYWkZkT05VNVhjR2xOYWtFeVZERlNVazFGTVRaUlZsSkRXakExVjFOR1RsWlNWVkp\
3282 GVVZWMFExb3laSGxSYldSR1VtdEtVbGt3VWtKV1JVWlFVVzFrVDFacmFGSlBSVXBDV21\
3283 wb1JsRnJSazVSTUVrd1VWaGtUVlZXYkVWV2JFbDNWV3RLUkZkWVpFdFRWV3h3V2tWa2I\
3284 ySkZlSFZYYlhocFlsWktNbGt5YXpGaGJHeFlUa2hXYVdKVWEzZFVSekV3WkZkSmVsa3p\
3285 WbXRTTW1oM1dUTnJNVTFzYkZobFJFWmhWa1ZHVEZGdFpHNWpWMmh5WVdzNVVWVldSa1Z\
3286 SVjJSUFUxVkdSVkZyV2tKaFZVazFVVzB4ZUZRemNIRlZWR2hzV1ZkamVWTnVVblprVmx\
3287 KdlVsWm9lVm93T1VOWFZsRjNVWHBvWVdSRGREVlBWemxKVWtad1JWbHNVbEpUVjJoQ1Z\
3288 HMXpNbVJIT1ZOaU1sWkVXVmMxYUZSWGNFNVdSWGgwWWxaV2RXSlhTbkphYWtKNldsaGF\
3289 jbEV3YnpSTmJXc3hWbGhHY1ZWcldsZFZVMHBrVEVOS2FHSkhZMmxQYVVwR1ZYcEpNVTV\
3290 wU2praUxDSnphV2R1WVhSMWNtVWlPaUphWTFwa1dYbzBiMUl3UjJKc09UWnFNWGxZWm5\
3291 kdlRYZGxVVGt6VGpCdFNVUmxjVFkyVTBacWRFdG9lR1pSWjNJMGRUWkpOVEJKWldNMmE\
3292 xWTJhSEV3YVcxdlptTlBhVGs0VW1OSVpXUmpNVzFuZHpCWVp5SjlYWDA9IiwiY3JlYXR\
3293 lZC1vbiI6IjIwMjItMDItMjJUMDc6MzM6MjUuMDIwWiIsImFnZW50LXNpZ24tY2VydCI\
3294 6WyJNSUlDSkRDQ0FjcWdBd0lCQWdJRVhsakNNREFLQmdncWhrak9QUVFEQWpCbE1Rc3d\
3295 DUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUVDZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVF\
3296 MREF4TmVWTjFZbk5wWkdsaGNua3hEekFOQmdOVkJBY01CazE1VTJsMFpURWFNQmdHQTF\
3297 VRUF3d1JUWGxUYVhSbFVIVnphRTF2WkdWc1EwRXdIaGNOTWpBd01qSTRNRGN6TXpBMFd\
3298 oY05NekF3TWpJNE1EY3pNekEwV2pCbU1Rc3dDUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUV\
3299 DZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVFMREF4TmVWTjFZbk5wWkdsaGNua3hEekF\
3300 OQmdOVkJBY01CazE1VTJsMFpURWJNQmtHQTFVRUF3d1NUWGxUYVhSbFVIVnphRTF2Wkd\
3301 Wc1FYQndNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUU2MDFPK29qQ2t\
3302 yRFJ3N2dJdlpFNGkzNGRiaENxaUc3am9vd1pwNHh2ekZ0TGc2VFcwaE5kSHZQRFNUc3V\
3303 YU3lXOXRyM0F3Q2xmQ29EVk5xT3c5eU1YNk5uTUdVd0RnWURWUjBQQVFIL0JBUURBZ2V\
3304 BTUI4R0ExVWRJd1FZTUJhQUZKN0h0U3dwTEx1T1o3Y2tBbFFIVTNnQU1nL0pNQjBHQTF\
3305 VZERnUVdCQlJjVDUzNG5NWXZUY0Z0a2Zydjd4VTdEaW1IanpBVEJnTlZIU1VFRERBS0J\
3306 nZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05JQURCRkFpRUFwSjd4cE5VdlFKRzB\
3307 OaExiL2V0YjIwTERVMTZscFNITzdhZW8wVll4MHh3Q0lBK081L1k2RGgrYkIyODI0dWl\
3308 hT1FhVUQ2Z0FOaFk5VkZkK2pycmNFdkp0IiwiTUlJQ0dUQ0NBYitnQXdJQkFnSUVYbGp\
3309 BL3pBS0JnZ3Foa2pPUFFRREFqQmNNUXN3Q1FZRFZRUUdFd0pCVVRFU01CQUdBMVVFQ2d\
3310 3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5OcFpHbGhjbmt4RHpBTkJ\
3311 nTlZCQWNNQmsxNVUybDBaVEVSTUE4R0ExVUVBd3dJVFhsVGFYUmxRMEV3SGhjTk1qQXd\
3312 Nakk0TURjeU56VTVXaGNOTXpBd01qSTRNRGN5TnpVNVdqQmxNUXN3Q1FZRFZRUUdFd0p\
3313 CVVRFU01CQUdBMVVFQ2d3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5\
3314 OcFpHbGhjbmt4RHpBTkJnTlZCQWNNQmsxNVUybDBaVEVhTUJnR0ExVUVBd3dSVFhsVGF\
3315 YUmxVSFZ6YUUxdlpHVnNRMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkN\
3316 BQVJKQlZvc2RLd1lOeGlQeEh2aUZxS3pEbDlmdEx1TWFtcEZRY1h3MTI3YU5vUmJzSC9\
3317 GTXJtekNBSDM3NzMzYzJvYlBjbHZTcllCdjBDdFdRdGE2YStjbzJZd1pEQVNCZ05WSFJ\
3318 NQkFmOEVDREFHQVFIL0FnRUFNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUd\
3319 EQVdnQlF6eHp3cFJwTHkvck1VWXphaDJzMTNlVTlnRnpBZEJnTlZIUTRFRmdRVW5zZTF\
3320 MQ2tzdTQ1bnR5UUNWQWRUZUFBeUQ4a3dDZ1lJS29aSXpqMEVBd0lEU0FBd1JRSWhBSXN\
3321 ZbGVaS3NqRk5Dc0pLZVBsR01BTGVwVmU5RUw3Tm90NTE1d3htVnVKQkFpQWNFTVVVaEV\
3322 Tc0xXUDV4U1FVMFhxelZxOFl2aUYxYlZvekd6eDV6Tmdjc3c9PSJdfX0",
3323 "signatures":[{
3324 "protected":"eyJ4NWMiOlsiTUlJQjhEQ0NBWmFnQXdJQkFnSUdBWEJoTUtZSU1\
3325 Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5\
3326 lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVV\
3327 FQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHlNREF5TWp\
3328 Bd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNSGt4Q3pBSkJnTlZCQVlUQWtGUk1\
3329 SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGt\
3330 hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVM0d0xBWURWUVFERENWU1pXZHBjM1J\
3331 5WVhJZ1ZtOTFZMmhsY2lCU1pYRjFaWE4wSUZOcFoyNXBibWNnUzJWNU1Ga3dFd1lIS29\
3332 aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRUJUVFwvc1JmTDlsSnVGbVwvY24zU2pHcWp\
3333 QXC9xdnBrNytoSTIwOE5oVkRvR2hcLzdLUCt2TXpYeVFRQStqUjZrNnJhTTI4ZlwvbHV\
3334 FK1h1aHVwN1Vmem05Q3FNbk1DVXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBeHd3RGd\
3335 ZRFZSMFBBUUhcL0JBUURBZ2VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSUhOK3VBbUp\
3336 ldVhlc1wveWQxd1M0Mlo0RFhKNEptMWErZzNYa1pnZjhUaGxuQWlFQXBVdTZzZnljRWt\
3337 veDdSWlhtZitLOHc0cDZzUldyamExUVJwWTAyNjQxSFk9IiwiTUlJQjhEQ0NBWmVnQXd\
3338 JQkFnSUdBWEJoTUtZQk1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1\
3339 SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGt\
3340 hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1Z\
3341 EUVRBZUZ3MHlNREF5TWpBd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNRnd4Q3p\
3342 BSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJ\
3343 Bc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WUR\
3344 WUVFEREFoTmVWTnBkR1ZEUVRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000OUF3RUhBMEl\
3345 BQkluQ3VoV1ZzZ2NONzFvWmVzMUZHXC9xZFZnTVBva01wZlMyNzFcL2V5SWNcL29EVmJ\
3346 NRkhDYmV2SjVMTTgxOTVOYVpLTlNvSFAzS3dMeXVCaDh2MncwOVp1alJUQkRNQklHQTF\
3347 VZEV3RUJcL3dRSU1BWUJBZjhDQVFFd0RnWURWUjBQQVFIXC9CQVFEQWdJRU1CMEdBMVV\
3348 kRGdRV0JCUXp4endwUnBMeVwvck1VWXphaDJzMTNlVTlnRnpBS0JnZ3Foa2pPUFFRREF\
3349 nTkhBREJFQWlCZGJIU212YW9qaDBpZWtaSUtOVzhRMGxTbGI1K0RLTlFcL05LY1I3dWx\
3350 6dGdJZ2RwejZiUkYyREZtcGlKb3JCMkd5VmE4YVdkd2xIc0RvRVdZY0k0UEdKYmc9Il0\
3351 sImFsZyI6IkVTMjU2In0",
3352 "signature":"67t3n8zyEek4IM2Ko3Y_UvE1hzp794QFNTqG-HzTrBQtE4_4-yS\
3353 yyFd3kP6YCn35YYJ7yK35d3styo_yoiPfKA"
3354 }]
3355 }

3357 Figure 24: Example Registrar Voucher Request - RVR

3359 A.3. Example Voucher Response (from MASA to Pledge, via Registrar and
3360 Registrar-agent)

3362 The following is an example voucher response from MASA to Pledge via
3363 Registrar and Registrar-agent, in "General JWS JSON Serialization".
3364 The message size of this Voucher is: 1916 bytes
3365 =============== NOTE: '\' line wrapping per RFC 8792 ================

3367 {
3368 "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
3369 udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
3370 iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
3371 UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
3372 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
3373 RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
3374 EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
3375 BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
3376 nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
3377 CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
3378 ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
3379 FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
3380 CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
3381 BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
3382 HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
3383 "signatures":[{
3384 "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
3385 Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
3386 hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
3387 YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
3388 VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
3389 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
3390 CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
3391 wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
3392 CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
3393 qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
3394 FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
3395 FS2JzVkRpVT0iXSwiYWxnIjoiRVMyNTYifQ",
3396 "signature":"0TB5lr-cs1jqka2vNbQm3bBYWfLJd8zdVKIoV53eo2YgSITnKKY\
3397 TvHMUw0wx9wdyuNVjNoAgLysNIgEvlcltBw"
3398 }]
3399 }

3401 Figure 25: Example Voucher Response from MASA

3403 A.4. Example Voucher Response, MASA issued Voucher with additional
3404 Registrar signature (from MASA to Pledge, via Registrar and
3405 Registrar-agent)

3407 The following is an example voucher response from MASA to Pledge via
3408 Registrar and Registrar-agent, in "General JWS JSON Serialization".
3409 The message size of this Voucher is: 3006 bytes
3410 =============== NOTE: '\' line wrapping per RFC 8792 ================

3412 {
3413 "payload":"eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6eyJhc3NlcnRpb24iOiJhZ2V\
3414 udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbmNlIjo\
3415 iUUJiSXMxNTJzbkFvVzdSeVFMWENvZz09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDktMjl\
3416 UMDM6Mzc6MjYuMzgyWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQVVtZ0F\
3417 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTV\
3418 RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1J\
3419 EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016SmFNRFV4RXp\
3420 BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4RHpBTkJ\
3421 nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUF\
3422 CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4MDYvU2N\
3423 ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdBMVVkRXd\
3424 FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVkRGdRV0J\
3425 CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWdOSkFEQkd\
3426 BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0NJUUR\
3427 HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0ifX0",
3428 "signatures":[{
3429 "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
3430 Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS0RBeEt\
3431 hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJNQjR\
3432 YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQWtHQTF\
3433 VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NHQTFVRUF\
3434 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd1dUQVR\
3435 CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRclJzOFI\
3436 wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdOaXZPS0d\
3437 CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS29aSXp\
3438 qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwzMERRSU5\
3439 FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC9cL1pLT2F\
3440 FS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0\
3441 ",
3442 "signature":"ShqW8uFRkuAXIzjAhB4bolMMndcY7GYq3Kbo94yvGtjCaxEX3Hp\
3443 6QXZUTEJ_kulQ1G7DnaU4igDPdUGtcV9Lkw"},{
3444 "protected":"eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk1\
3445 Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUx\
3446 CZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ERXlNRGN\
3447 3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01DazE1UW5\
3448 WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EMFJ2YldGcGJ\
3449 sSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJCazE\
3450 2S1wvaTc5b1JrSzVZYmVQZzhVU1I4XC91czFkUFVpWkhNdG9rU2RxS1c1Zm5Xc0JkK3F\
3451 STDdXUmZmZVdreWdlYm9KZklsbHVyY2kyNXduaGlPVkNHamV6QjVNQjBHQTFVZEpRUVd\
3452 NQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNESERBT0JnTlZIUThCQWY4RUJBTUNCNEF\
3453 3U0FZRFZSMFJCRUV3UDRJZGNtVm5hWE4wY21GeUxYUmxjM1F1YzJsbGJXVnVjeTFpZEM\
3454 1dVpYU0NIbkpsWjJsemRISmhjaTEwWlhOME5pNXphV1Z0Wlc1ekxXSjBMbTVsZERBS0J\
3455 nZ3Foa2pPUFFRREFnTklBREJGQWlCeGxkQmhacTBFdjVKTDJQcldDdHlTNmhEWVcxeUN\
3456 PXC9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm9cL2dHTjBcL2p3ekp\
3457 aMFNsMmg0eElYazEiXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU\
3458 2In0",
3459 "signature":"N4oXV48V6umsHMKkhdSSmJYFtVb6agjD32uXpIlGx6qVE7Dh0-b\
3460 qhRRyjnxp80IV_Fy1RAOXIIzs3Q8CnMgBgg"
3461 }]
3462 }

3464 Figure 26: Example Voucher Response from MASA, with additional
3465 Registrar signature

3467 Appendix B. History of Changes [RFC Editor: please delete]

3469 Proof of Concept Code available

3471 From IETF draft 05 -> IETF draft 06:

3473 * Update of list of reviewers

3475 * Issue #67, shortened the pledge endpoints to prepare for
3476 constraint deployments

3478 * Included table for new endpoints on the registrar in the overview
3479 of the registrar-agent

3481 * addressed review comments from SECDIR early review

3483 * addressed review comments from IOTDIR early review

3485 From IETF draft 04 -> IETF draft 05:

3487 * Restructured document to have a distinct section for the object
3488 flow and handling and shortened introduction, issue #72

3490 * Added security considerations for using mDNS without a specific
3491 product-serial-number, issue #75

3493 * Clarified pledge-status responses are cumulative, issue #73

3495 * Removed agent-sign-cert from trigger data to save bandwidth and
3496 remove complexity through options, issue #70

3498 * Changed terminology for LDevID(Reg) certificate to registrar EE
3499 certificate, as it does not need to be an LDevID, issue #66

3501 * Added new protected header parameter (created-on) in PER to
3502 support freshness validation, issue #63

3504 * Removed reference to CAB Forum as not needed for BRSKI-PRM
3505 specifically, issue #65

3507 * Enhanced error codes in section 5.5.1, issue #39, #64

3509 * Enhanced security considerations and privacy considerations, issue
3510 #59

3512 * Issue #50 addressed by referring to the utilized enrollment
3513 protocol

3515 * Issue #47 MASA verification of LDevID(RegAgt) to the same
3516 registrar EE certificate domain CA

3518 * Reworked terminology of "enrollment object", "certification
3519 object", "enrollment request object", etc., issue #27

3521 * Reworked all message representations to align with encoding

3523 * Added explanation of MASA requiring domain CA cert in section
3524 5.5.1 and section 5.5.2, issue #36

3526 * Defined new endpoint for pledge bootstrapping status inquiry,
3527 issue #35 in section Section 6.4, IANA considerations and section
3528 Section 5.3

3530 * Included examples for several objects in section Appendix A
3531 including message example sizes, issue #33

3533 * PoP for private key to registrar certificate included as
3534 mandatory, issues #32 and #49

3536 * Issue #31, clarified that combined pledge may act as client/server
3537 for further (re)enrollment

3539 * Issue #42, clarified that Registrar needs to verify the status
3540 responses with and ensure that they match the audit log response
3541 from the MASA, otherwise it needs drop the pledge and revoke the
3542 certificate

3544 * Issue #43, clarified that the pledge shall use the create time
3545 from the trigger message if the time has not been synchronized,
3546 yet.

3548 * Several editorial changes and enhancements to increasing
3549 readability.

3551 From IETF draft 03 -> IETF draft 04:

3553 * In deep Review by Esko Dijk lead to issues #22-#61, which are bein
3554 stepwise integrated

3556 * Simplified YANG definition by augmenting the voucher request from
3557 RFC 8995 instead of redefining it.

3559 * Added explanation for terminology "endpoint" used in this
3560 document, issue #16

3562 * Added clarification that registrar-agent may collect PVR or PER or
3563 both in one run, issue #17

3565 * Added a statement that nonceless voucher may be accepted, issue
3566 #18

3568 * Simplified structure in section Section 3.1, issue #19

3570 * Removed join proxy in Figure 1 and added explanatory text, issue
3571 #20

3573 * Added description of pledge-CAcerts endpoint plus further handling
3574 of providing a wrapped CA certs response to the pledge in section
3575 Section 6.3; also added new required registrar endpoint (section
3576 Section 6.2 and IANA considerations) for the registrar to provide
3577 a wrapped CA certs response, issue #21

3579 * utilized defined abbreviations in the document consistently, issue
3580 #22

3582 * Reworked text on discovery according to issue #23 to clarify scope
3583 and handling

3585 * Added several clarifications based on review comments

3587 From IETF draft 02 -> IETF draft 03:

3589 * Updated examples to state "base64encodedvalue==" for x5c
3590 occurrences

3592 * Include link to SVG graphic as general overview

3594 * Restructuring of section 5 to flatten hierarchy

3596 * Enhanced requirements and motivation in Section 4

3598 * Several editorial improvements based on review comments

3600 From IETF draft 01 -> IETF draft 02:

3602 * Issue #15 included additional signature on voucher from registrar
3603 in section Section 6.2 and section Section 5.2 The verification of
3604 multiple signatures is described in section Section 6.3

3606 * Included representation for General JWS JSON Serialization for
3607 examples

3609 * Included error responses from pledge if it is not able to create a
3610 pledge-voucher request or an enrollment request in section
3611 Section 6.1

3613 * Removed open issue regarding handling of multiple CSRs and
3614 enrollment responses during the bootstrapping as the initial
3615 target it the provisioning of a generic LDevID certificate. The
3616 defined endpoint on the pledge may also be used for management of
3617 further certificates.

3619 From IETF draft 00 -> IETF draft 01:

3621 * Issue #15 lead to the inclusion of an option for an additional
3622 signature of the registrar on the voucher received from the MASA
3623 before forwarding to the registrar-agent to support verification
3624 of POP of the registrars private key in section Section 6.2 and
3625 Section 6.3.

3627 * Based on issue #11, a new endpoint was defined for the registrar
3628 to enable delivery of the wrapped enrollment request from the
3629 pledge (in contrast to plain PKCS#10 in simple enroll).

3631 * Decision on issue #8 to not provide an additional signature on the
3632 enrollment-response object by the registrar. As the enrollment
3633 response will only contain the generic LDevID certificate. This
3634 credential builds the base for further configuration outside the
3635 initial enrollment.

3637 * Decision on issue #7 to not support multiple CSRs during the
3638 bootstrapping, as based on the generic LDevID certificate the
3639 pledge may enroll for further certificates.

3641 * Closed open issue #5 regarding verification of ietf-ztp-types
3642 usage as verified via a proof-of-concept in section
3643 {#exchanges_uc2_1}.

3645 * Housekeeping: Removed already addressed open issues stated in the
3646 draft directly.

3648 * Reworked text in from introduction to section pledge-responder-
3649 mode

3651 * Fixed "serial-number" encoding in PVR/RVR

3653 * Added prior-signed-voucher-request in the parameter description of
3654 the registrar-voucher-request in Section 6.2.

3656 * Note added in Section 6.2 if sub-CAs are used, that the
3657 corresponding information is to be provided to the MASA.

3659 * Inclusion of limitation section (pledge sleeps and needs to be
3660 waked up. Pledge is awake but registrar-agent is not available)
3661 (Issue #10).

3663 * Assertion-type aligned with voucher in RFC8366bis, deleted related
3664 open issues. (Issue #4)

3666 * Included table for endpoints in Section 5.3 for better
3667 readability.

3669 * Included registrar authorization check for registrar-agent during
3670 TLS handshake in section Section 6.2. Also enhanced figure
3671 Figure 9 with the authorization step on TLS level.

3673 * Enhanced description of registrar authorization check for
3674 registrar-agent based on the agent-signed-data in section
3675 Section 6.2. Also enhanced figure Figure 9 with the authorization
3676 step on pledge-voucher-request level.

3678 * Changed agent-signed-cert to an array to allow for providing
3679 further certificate information like the issuing CA cert for the
3680 LDevID(RegAgt) certificate in case the registrar and the
3681 registrar-agent have different issuing CAs in Figure 9 (issue
3682 #12). This also required changes in the YANG module in
3683 Section 7.1.2

3685 * Addressed YANG warning (issue #1)

3687 * Inclusion of examples for a trigger to create a pledge-voucher-
3688 request and an enrollment-request.

3690 From IETF draft-ietf-anima-brski-async-enroll-03 -> IETF anima-brski-
3691 prm-00:

3693 * Moved UC2 related parts defining the pledge in responder mode from
3694 draft-ietf-anima-brski-async-enroll-03 to this document This
3695 required changes and adaptations in several sections to remove the
3696 description and references to UC1.

3698 * Addressed feedback for voucher-request enhancements from YANG
3699 doctor early review in Section 7.1 as well as in the security
3700 considerations (formerly named ietf-async-voucher-request).

3702 * Renamed ietf-async-voucher-request to IETF-voucher-request-prm to
3703 to allow better listing of voucher related extensions; aligned
3704 with constraint voucher (#20)

3706 * Utilized ietf-voucher-request-async instead of ietf-voucher-
3707 request in voucher exchanges to utilize the enhanced voucher-
3708 request.

3710 * Included changes from draft-ietf-netconf-sztp-csr-06 regarding the
3711 YANG definition of csr-types into the enrollment request exchange.

3713 From IETF draft 02 -> IETF draft 03:

3715 * Housekeeping, deleted open issue regarding YANG voucher-request in
3716 Section 6.1 as voucher-request was enhanced with additional leaf.

3718 * Included open issues in YANG model in Section 5.1 regarding
3719 assertion value agent-proximity and csr encapsulation using SZTP
3720 sub module).

3722 From IETF draft 01 -> IETF draft 02:

3724 * Defined call flow and objects for interactions in UC2. Object
3725 format based on draft for JOSE signed voucher artifacts and
3726 aligned the remaining objects with this approach in Section 6 .

3728 * Terminology change: issue #2 pledge-agent -> registrar-agent to
3729 better underline agent relation.

3731 * Terminology change: issue #3 PULL/PUSH -> pledge-initiator-mode
3732 and pledge-responder-mode to better address the pledge operation.

3734 * Communication approach between pledge and registrar-agent changed
3735 by removing TLS-PSK (former section TLS establishment) and
3736 associated references to other drafts in favor of relying on
3737 higher layer exchange of signed data objects. These data objects
3738 are included also in the pledge-voucher-request and lead to an
3739 extension of the YANG module for the voucher-request (issue #12).

3741 * Details on trust relationship between registrar-agent and
3742 registrar (issue #4, #5, #9) included in Section 5.1.

3744 * Recommendation regarding short-lived certificates for registrar-
3745 agent authentication towards registrar (issue #7) in the security
3746 considerations.

3748 * Introduction of reference to agent signing certificate using SKID
3749 in agent signed data (issue #37).

3751 * Enhanced objects in exchanges between pledge and registrar-agent
3752 to allow the registrar to verify agent-proximity to the pledge
3753 (issue #1) in Section 6.

3755 * Details on trust relationship between registrar-agent and pledge
3756 (issue #5) included in Section 5.1.

3758 * Split of use case 2 call flow into sub sections in Section 6.

3760 From IETF draft 00 -> IETF draft 01:

3762 * Update of scope in Section 3.1 to include in which the pledge acts
3763 as a server. This is one main motivation for use case 2.

3765 * Rework of use case 2 in Section 5.1 to consider the transport
3766 between the pledge and the pledge-agent. Addressed is the TLS
3767 channel establishment between the pledge-agent and the pledge as
3768 well as the endpoint definition on the pledge.

3770 * First description of exchanged object types (needs more work)

3772 * Clarification in discovery options for enrollment endpoints at the
3773 domain registrar based on well-known endpoints do not result in
3774 additional /.well-known URIs. Update of the illustrative example.
3775 Note that the change to /brski for the voucher related endpoints
3776 has been taken over in the BRSKI main document.

3778 * Updated references.

3780 * Included Thomas Werner as additional author for the document.

3782 From individual version 03 -> IETF draft 00:

3784 * Inclusion of discovery options of enrollment endpoints at the
3785 domain registrar based on well-known endpoints in new section as
3786 replacement of section 5.1.3 in the individual draft. This is
3787 intended to support both use cases in the document. An
3788 illustrative example is provided.

3790 * Missing details provided for the description and call flow in
3791 pledge-agent use case Section 5.1, e.g. to accommodate
3792 distribution of CA certificates.

3794 * Updated CMP example in to use lightweight CMP instead of CMP, as
3795 the draft already provides the necessary /.well-known endpoints.

3797 * Requirements discussion moved to separate section in Section 4.
3798 Shortened description of proof of identity binding and mapping to
3799 existing protocols.

3801 * Removal of copied call flows for voucher exchange and registrar
3802 discovery flow from [RFC8995] in UC1 to avoid doubling or text or
3803 inconsistencies.

3805 * Reworked abstract and introduction to be more crisp regarding the
3806 targeted solution. Several structural changes in the document to
3807 have a better distinction between requirements, use case
3808 description, and solution description as separate sections.
3809 History moved to appendix.

3811 From individual version 02 -> 03:

3813 * Update of terminology from self-contained to authenticated self-
3814 contained object to be consistent in the wording and to underline
3815 the protection of the object with an existing credential. Note
3816 that the naming of this object may be discussed. An alternative
3817 name may be attestation object.

3819 * Simplification of the architecture approach for the initial use
3820 case having an offsite PKI.

3822 * Introduction of a new use case utilizing authenticated self-
3823 contain objects to onboard a pledge using a commissioning tool
3824 containing a pledge-agent. This requires additional changes in
3825 the BRSKI call flow sequence and led to changes in the
3826 introduction, the application example,and also in the related
3827 BRSKI-PRM call flow.

3829 From individual version 01 -> 02:

3831 * Update of introduction text to clearly relate to the usage of
3832 IDevID and LDevID.

3834 * Update of description of architecture elements and changes to
3835 BRSKI in Section 5.

3837 * Enhanced consideration of existing enrollment protocols in the
3838 context of mapping the requirements to existing solutions in
3839 Section 4.

3841 From individual version 00 -> 01:

3843 * Update of examples, specifically for building automation as well
3844 as two new application use cases in Section 3.1.

3846 * Deletion of asynchronous interaction with MASA to not complicate
3847 the use case. Note that the voucher exchange can already be
3848 handled in an asynchronous manner and is therefore not considered
3849 further. This resulted in removal of the alternative path the
3850 MASA in Figure 1 and the associated description in Section 5.

3852 * Enhancement of description of architecture elements and changes to
3853 BRSKI in Section 5.

3855 * Consideration of existing enrollment protocols in the context of
3856 mapping the requirements to existing solutions in Section 4.

3858 * New section starting with the mapping to existing enrollment
3859 protocols by collecting boundary conditions.

3861 Contributors

3863 Esko Dijk
3864 IoTconsultancy.nl
3865 Email: esko.dijk@iotconsultancy.nl

3867 Authors' Addresses

3869 Steffen Fries
3870 Siemens AG
3871 Otto-Hahn-Ring 6
3872 81739 Munich
3873 Germany
3874 Email: steffen.fries@siemens.com
3875 URI: https://www.siemens.com/

3877 Thomas Werner
3878 Siemens AG
3879 Otto-Hahn-Ring 6
3880 81739 Munich
3881 Germany
3882 Email: thomas-werner@siemens.com
3883 URI: https://www.siemens.com/

3885 Eliot Lear
3886 Cisco Systems
3887 Richtistrasse 7
3888 CH-8304 Wallisellen
3889 Switzerland
3890 Phone: +41 44 878 9200
3891 Email: lear@cisco.com

3893 Michael C. Richardson
3894 Sandelman Software Works
3895 Email: mcr+ietf@sandelman.ca
3896 URI: http://www.sandelman.ca/

[Anima] WGLC for draft-ietf-anima-brski-prm-06, e… Sheng Jiang
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Michael Richardson
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Sheng Jiang
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Fries, Steffen
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Sheng Jiang
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Fries, Steffen
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Michael Richardson
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Michael Richardson
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Michael Richardson
Re: [Anima] WGLC for draft-ietf-anima-brski-prm-0… Sheng Jiang
[Anima] Result//Re: WGLC for draft-ietf-anima-brs… Sheng Jiang
[Anima] Result//RE: WGLC for draft-ietf-anima-brs… Fries, Steffen
[Anima] Sheng/Robert/*: Re: Result//Re: WGLC for … Toerless Eckert
Re: [Anima] Sheng/Robert/*: Re: Result//Re: WGLC … Toerless Eckert
Re: [Anima] Sheng/Robert/*: Re: Result//Re: WGLC … Fries, Steffen
[Anima] Reply1, was RE: Sheng/Robert/*: Re: Resul… Fries, Steffen
[Anima] Reply2, was RE: Sheng/Robert/*: Re: Resul… Fries, Steffen
[Anima] Reply3, Was: Re: Sheng/Robert/*: Re: Resu… Werner, Thomas