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

["Fries, Steffen" <[e-mail]>]

Hi Toerless,

Thank you for the review. 
I think it is good to receive further feedback on the approach although it re-opens some of the discussions we already had in the design team. But that also provides the option to rethink certain approaches. 

I managed to go through the major comments listed below and also the further inline comments up to section 2. I will continue with reacting on the comments. I created issues in https://github.com/anima-wg/anima-brski-prm/ to be better able to track the identified points. Please have a look in case I missed some points. I was concentrating on the major issues and may have combined some of them. Please add further issues if you feel necessary.

As we have normative dependencies on two other documents, the time pressure may be not too high. 

I made further comments inline

Best regards
Steffen

> From: Toerless Eckert <[e-mail]>
> Sent: Donnerstag, 23. Februar 2023 23:41
> 
> [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).
[stf] yes, this is something we can probably address by enhancing the approach in RFC 8995 in section 8.6 by specifying a DNS service name like " brski-prm-registrar" to signal the availability of the additional endpoints and the connected functionality.
Crated Issue #79: https://github.com/anima-wg/anima-brski-prm/issues/79

> 
> 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.
[stf] currently we have mDNS in the draft, but if you could provide text for  a GRASP based approach would be welcomed 
Created issue #80: https://github.com/anima-wg/anima-brski-prm/issues/80

> 
> [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:
[stf] not really the opposite but tries to utilize the same approach with exchanged client and server roles. This has been outlined in the introduction and also section 3 

> 
> 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.
[stf] the proximity assertion provide the information with which entity a pledge was in contact: the registrar for the TLS connection in case of BRSKI and the registrar-agent in case of BRSKI-PRM


> 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. 
[stf] not quite. We had the necessity discussed to identify the registrar-agent to ensure it can be identified, who resp. which component performed the actual onboarding. See also issue #1 for the discussion on agent-proximity (instead of proximity). Note that the issue was on BRSKI-AE before the actual split: https://github.com/anima-wg/anima-brski-ae/issues/1 ,  


> 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 ?
[stf] We discussed the requirement to identify the device that actually performed the bootstrapping/onboarding and that it acts as agent of the registrar. 
See: https://github.com/anima-wg/anima-brski-ae/issues/1. The approach using agent-signed data resembles the determination of registrar proximity in BRSKI. As we do not have a direct connection between the pledge and the registrar, a distinction was requested to underline that the security may be different as there is no 1:1 connection protected by TLS. In BRSKI-PRM he voucher contains a registrar certificate, which was provided by the registrar-agent and not by the registrar directly. Also, the binding of the Voucher request and the enrollment request as in BRSKI via the TLS connection is not provided in that way by PRM. The binding can be shown by using the same credentials on the pledge site for signing the PVR and the PER. 
BTW, the requirement is also included in the requirements discussion in section 4 and in the security considerations in section 10.2


> 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):
[stf] thanks for providing the additional text as justification, I included it as issue #81: https://github.com/anima-wg/anima-brski-prm/issues/81 and already proposed changes in a comment.


> ---
> 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. 
[stf] we should discuss this as the TLS connection also serves as binding between the PVR, PER, in a timely fashion. So there may be some further tweaks necessary in the formulation. 


> 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.
[stf] As BRSKI does not have the concept of the registrar-agent this statement may be misleading. As stated above, I tried to come up with an updated description. https://github.com/anima-wg/anima-brski-prm/issues/81

> 
> 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.
[stf] note that this is already addressed in the security consideration section 10.2

> 
> 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.
[stf] the motivation for BRSKI-PRM was not necessarily nomadic network connectivity.  It is addressed by using the registrar-agent  with an installer in contrast to co-location with a registrar. Nomadic network connectivity was one of the reasonings for BRSKI-AE. 
> ---
> 
> 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.
[stf] as stated above, I took the proposal and justification as issue #81: https://github.com/anima-wg/anima-brski-prm/issues/81 and already proposed changes in a comment..

> 
> [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.
[stf] during the discussions in the design team the necessity to identify a registrar agent has been discussed from the beginning. We also had the discussion to use a simple "proxy" of any kind and to only rely on the signatures of the utilized objects. At the end it was the goal to strive for something which is close to BRSKI (also with the proximity assertion), which was the reasoning for some decisions in the past. 
This issue of using the registrar-agent certificate in contrast to the registrar-certificate in the PVR has been discussed in the design team meeting on February 28, but was not finalized. 

> 
> [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.
[stf] yes, the registrar-agent needs to be provisioned with this information or discover it. It is seen as trusted component from a registrar perspective. To ease this, a BRSKI run in advanced is recommended as outlined in section 5.1

> 
> - 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.
[stf] I don't see this point. There is no requirement for a 1:1 mapping of registrar-agent and registrar. If the registrar-agent is configured with multiple registrar addresses is left out so far. It may be. And the registrar, based on the authentication of the registrar-agent is also possible to accept multiple registrar-agents. 

> 
> - 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.
[stf] as stated above, from my understanding, this is rather a security policy decision to allow using multiple registrar-agents with a single registrar or one registrar-agent with multiple registrars. I don't see a restriction in BRSKI-PRM.

> 
> - 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.
[stf] not sure I get the naming point. What does " ... sound as if there is some form of cryptographic security involved .." mean?
  - agent-provided-proximity-registrar-cert is a self-contained object used to establish the trust into the new domain.
  - agent-signed-data provides the option to identify and verify the involved registrar-agent on the registrar site and on the MASA site.

> 
> 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.
[stf] It was a design goal to not rely on TLS and to be able to utilize the approach also with other transports. 
Also, this approach would change the provisional accept in TLS to accepting the client authentication of the registrar-agent, while the pledge may not have an IDevID cert usable as TLS server certificate.
In addition, in BRSKI-PRM it was recommended to use short-lived certificates for the registrar-agent (section 5.4)


> 
> 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.
[stf] the registrar-agent may be a temporary component to help the bootstrapping of a pledge. The registrar is rather the component to build permanent trust with. The registrar-agent was intended to facilitate the interaction with the pledge in a way, it is detectable. It was not intended to replace the registrar with its functionality.

> 
> 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:
[stf] this sounds you are proposing to not use agent-proximity at all?

> 
> 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.
[stf] in that case the registrar signed the PVR as you wrote. This is not done by the pledge-agent. Meaning the registrar-agent is only involved in the transport but not in the processing of information exchanged between the pledge and the registrar.

> 
> 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.
[stf] in BRSKI, we have the TLS connection that is provisionally accepted by the pledge as it is not able to validate the registrars certificate completely, until it gets the voucher. In BRSKI-PRM, we do not assume this TLS connection between the pledge and the registrar-agent for different reasons (independence from TLS, pledge does not have an appropriate certificate to authenticate as TLS server). Also, as the registrar-agent certificate may be short-lived (not clear if the same certificate would be used on the way back providing the voucher and the enrollment response). Therefore the trust is to be established to the registrar directly (as in BRSKI).  

> 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.
[stf] BRSKI-PRM focusses on the initial provisioning. If the pledge stays as server or switches to a client mode is not addressed as it is application or use case dependent. 



> [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.
[stf] As discussed in the Design Team Meeting on February 28, for re-enrollment it may be meaningful to add a subsection explaining how the BRSKI-PRM defined endpoint can be utilized. In general it should be possible, and mainly influences the state machines on the pledge, involving the existence of an LDevID, which is to be renewed. The initiation itself is a policy decision of the operator and typically triggered based on the validity period of the existing LDevID cert.
Included this as issue #83: https://github.com/anima-wg/anima-brski-prm/issues/83


> 
> [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.
[stf] created issue #84: https://github.com/anima-wg/anima-brski-prm/issues/84
The media type is defined in JWS-voucher and is not specific to BRSKI-PRM.
BTW, the registrar distinguishes between pledge and registrar-agent is based on the utilized *DevID. If an LDevID is used, the request originates from the registrar-agent. It can then verify the content of the PVR including the agent-signed-data.
If an IDevID is used, the request originates from a pledge. Proposal to leave it like this. 

> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.i
> etf.org%2Flicense-
> info&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59ef
> dd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
> 127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =oqAZiLfE0ni0W6NAi0HKyiHnA5DRp%2BVs6BNk1F9SfjM%3D&reserved=0):
>   ----------------------------------------------------------------------------
> 
>      No issues found here.
> 
>   Checking nits according to
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fid-info%2F1id-
> guidelines.txt&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7
> fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0
> %7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7
> C&sdata=AhyPChi1mi0XLWgS6ficGqe80zekxjGMizNO3if4wMk%3D&reserved=0:
>   ----------------------------------------------------------------------------
> 
>      No issues found here.
> 
>   Checking nits according to
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf
> .org%2Fid-
> info%2Fchecklist&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f4
> 9c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> 7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=XKksJYAg3bzZ2uOLMtobk76Tbqv7%2BrXoJnVISidYgnk%3D&reserve
> d=0 :
>   ----------------------------------------------------------------------------
> 
>      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.
[stf] no idea either 
> 
>   == 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdoc%2Fdraft-ietf-anima-brski-
> prm%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b
> 59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C
> 638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&s
> data=yXi7Wg3odQ5LkEMG9Jzi%2FQ4kUpexZLOyRKd9kgYndbI%3D&reserved=0.
> 
> 40	   Source for this draft and an issue tracker can be found at
> 41
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Fanima-wg%2Fanima-brski-
> prm&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59ef
> dd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
> 127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =C59JYjZtKLgN69o1B2DjvNKd7DrbGam0DQQzDikEskU%3D&reserved=0.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrac
> ker.ietf.org%2Fdrafts%2Fcurrent%2F&data=05%7C01%7Csteffen.fries%40sieme
> ns.com%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab4
> 2e1495d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C3000%7C%7C%7C&sdata=0P9bQG20VCbdPVBubm2wjQxlJwHYi2IGItD0o
> UH7aoY%3D&reserved=0.
> 
> 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
> 
> 62	   Copyright (c) 2023 IETF Trust and the persons identified as the
> 63	   document authors.  All rights reserved.
> 
> 65	   This document is subject to BCP 78 and the IETF Trust's Legal
> 66	   Provisions Relating to IETF Documents
> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.i
> etf.org%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb
> 4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=Lq5z4YNJtIoYYylM4k3rd0wZ4pESDHOtRCAQifhm%2BfQ%3D&reserved=
> 0
> 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"
[stf] done

> 
> 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

[stf] Done

> 
> 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.
[stf] well, the pledge in that case is acting as server in general for the communication as it does not initiate the communication. It ets requests and provides responses. This is true for the BRSKI exchanges, but also for other protocols used by the pledge. Proposal to keep it as "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 ..."
[stf] Done 
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.go
> ogle.com%2Fsearch%3Fq%3Dcomputer%2Bnetworking%2Bwhat%2Bis%2Ban%
> 2Bendpoint&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb
> 4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%
> 7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=%2Fro5LUvJRAa6cyem7IgTXfj95hyRHDJ6AX6sxTD2MH4%3D&reserved=
> 0
> 
> 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.
[stf] we added the definition to make the use of the term in the context of the document clear as result of the discussion on issue # 16
https://github.com/anima-wg/anima-brski-prm/issues/16
Added that explanation to the terminology:    
endpoint:
: Used in the context of this document similar to resources in CoAP {{RFC7252}} and also in HTTP {{RFC9110}}. Endpoints are accessible via .well-known URIs.


> 
> 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.
[stf] okay

> 
> 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.
[stf] as discussed in the Design team meeting on February 28, the motivation to not rely on TLS was provided by these two reasons (IDEVIDs can be used as TLS server certificate and TLS may not be used at all). So we had to look for a different technical approach. Lightweight was not the first target. I'm not sure I understand the part " ... have no automatable provisioning backend option ..." with respect to the BRSKI Registrar. As we had the requirement to identify the registrar-agent, it is not comparable to the join proxy as in BRSKI.


> 
> 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.


[stf] --- to be continued


> 
> 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
> "https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ex
> ample.com%2F.well-
> known%2Fbrski&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49
> c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C
> %7C&sdata=wAjFtvKJKEACxgbdCbfZFlHyyy1WPS8xqqeiqimJ4rw%3D&reserved=0
> " 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 "[e-mail]"
> 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:
> <https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf
> .org%2Fwg%2Fanima%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7
> Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d5
> 5a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300
> 0%7C%7C%7C&sdata=djjcWVydKq86TW3VjIMIhDcTRPLIQoWcMuDEDjv7nSA%3
> D&reserved=0>
> 2591	       WG List:  <mailto:[e-mail]>
> 2592	       Author:   Steffen Fries
> 2593	                 <mailto:[e-mail]>
> 2594	       Author:   Eliot Lear
> 2595	                 <mailto: [e-mail]>
> 2596	       Author:   Thomas Werner
> 2597	                 <mailto: [e-mail]>
> 2598	       Author:   Michael Richardson
> 2599	                 <mailto: [e-mail]>";
> 
> 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.
> 
> 2614	       Copyright (c) 2021 IETF Trust and the persons identified as
> 2615	       authors of the code. All rights reserved.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrustee.i
> etf.org%2Flicense-
> info&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59ef
> dd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638
> 127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC
> JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata
> =oqAZiLfE0ni0W6NAi0HKyiHnA5DRp%2BVs6BNk1F9SfjM%3D&reserved=0).
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59efdd0
> 8db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638127
> 888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P5
> Y%2BjUWvw9BTZ2CabpV5y9X9ejPYqlVsYbbzM026rdE%3D&reserved=0
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-anima-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59efdd0
> 8db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638127
> 888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N
> EpRUBHtjVWCuvRWqrJvKb2NAWsUHlTyo%2BpdCLKtAcU%3D&reserved=0
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59efdd0
> 8db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638127
> 888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P5
> Y%2BjUWvw9BTZ2CabpV5y9X9ejPYqlVsYbbzM026rdE%3D&reserved=0
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc2119&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=N4gwMimlJ0q8mGYeRQ%2Bs1gHb4jHl7nxIcgJyvIILIz
> 8%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc5280&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=5hmLIh%2BKXiGja0qgTy6nOHYzkmxugLWTvmwWky
> VPrAw%3D&reserved=0>.
> 
> 2928	   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
> 2929	              DOI 10.17487/RFC6762, February 2013,
> 2930
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc6762&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=vyxhx6V5QliAh2m6UpwuMzo56hsVL8%2FT2FnxZ1B
> OxkQ%3D&reserved=0>.
> 
> 2932	   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
> 2933	              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
> 2934
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc6763&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=EhLYigtuGYpAgBUBdu3vjDNjBZ2l6VeeTHDevg5tQAk
> %3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc7030&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=bAPbQqnwRf%2FZOETI45%2B78%2B6KR0MBZsAc1N
> haFp41pMg%3D&reserved=0>.
> 
> 2941	   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
> 2942	              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
> 2943	              2015,
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc7515&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=OWdlnsXddxExjUPhRMWYz6qQeiiXHqWtdiG3iEXKzqs
> %3D&reserved=0>.
> 
> 2945	   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
> 2946	              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
> 2947
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8040&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=GhHKGpV3z6bqBq7l8du0m9DbL5rIGe4SIACUwWrHI
> Xo%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8174&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=oa9gez8QvH1MqHd726m%2F3dIhEiB%2FOEa0QwSk
> 6dHF1uY%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8366&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=RcyXYytxy%2BsaV3kpLZcnjND8eqCmrQWo1LlhTdtq
> o9I%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8610&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=vhYi8NLtkzanSHpUJI2M0XdfccqDapQnaReidlJISBY%
> 3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8995&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=w%2BEmlKW6oG3dx3NZ4Jhklf3b7c%2Fg0VHEED1nY
> 0EBbPM%3D&reserved=0>.
> 
> 2969	12.2.  Informative References
> 
> 2971	   [BRSKI-PRM-abstract]
> 2972	              "Abstract BRSKI-PRM Protocol Overview", April 2022,
> 2973
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.git
> hubusercontent.com%2Fanima-wg%2Fanima-brski-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59efdd0
> 8db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638127
> 888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pA
> pPz1kAXTaHyJ9db44Jo02U3ZOBV1IRgf%2F2hYsVsXs%3D&reserved=0
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Farchive%2Fid%2Fdraft-ietf-
> &data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c7fb4b59efdd0
> 8db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638127
> 888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P5
> Y%2BjUWvw9BTZ2CabpV5y9X9ejPYqlVsYbbzM026rdE%3D&reserved=0
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarc
> hive.ietf.org%2Farch%2Fmsg%2Fsaag%2F&data=05%7C01%7Csteffen.fries%40s
> iemens.com%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4ad
> dab42e1495d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpb
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C&sdata=evfF8d8xO8Ix5jgv8n1kZiW2pcz2hMlPNLcII
> CqFP3E%3D&reserved=0
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc2986&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=1Q8%2BPaGOH8oliHbh7%2BiznJQAkLyKIH4PeHUqN
> uThFFE%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc6125&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=4Gi5%2F7PJ25sVLicCqx5LLmJ6ToHJo2hx4Wr57FJng
> Ro%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc6241&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=BelJ6EXzY8%2BfRS0cR7aJX0dmYG7%2BXDwnDmvey
> qyVV%2BA%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc7252&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=uCgNszPeTfmvQmJb8iikYcHP1Guw1nMASdUQQf0uY
> 5I%3D&reserved=0>.
> 
> 3014	   [RFC8340]  Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
> 3015	              BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
> 3016
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8340&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=vajgD%2Ba5dBkEZSqy6%2FNg0U0MNB9GYPyDUqLO
> oJRA4cs%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8407&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=g5Csf%2B5XbN02Z8rW1pnWmNaU7C13UGyPClf6rv
> PHxOw%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc8792&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=8FCWcYt8VSEIPnxUPc5RQhv5qHwYwYk18NBzP8Al6
> SM%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc9052&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=RU0cffIWRZnapyJOceddTydjJ6jwNhBOejEJBKjEkGQ
> %3D&reserved=0>.
> 
> 3033	   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
> 3034	              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
> 3035	              August 2022,
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc9053&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=%2F%2BsyReoOOiIcqOwgk%2FnLSnfprgK6TFUImzD
> H%2B44qNf4%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc9110&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=VZBNvHTOuoCCQ0RSNBpNRAqgB8TI4ku%2BBvqhle
> SyptU%3D&reserved=0>.
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rf
> c-
> editor.org%2Finfo%2Frfc9238&data=05%7C01%7Csteffen.fries%40siemens.co
> m%7Ce9764f49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e14
> 95d55a%7C1%7C0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=Nmm3TtsB5vq9Z0guZ7OCid2mPDqvCkSouygTp%2F
> momT0%3D&reserved=0>.
> 
> 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
> iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsI
> m5\
> 3065
> vbmNlIjoiTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjI\
> 3066
> tMDQtMjZUMDU6MTY6MTcuNzA5WiIsImFnZW50LXByb3ZpZGVkLXByb3hpbWl0
> eS1yZWd\
> 3067
> pc3RyYXItY2VydCI6Ik1JSUI0akNDQVlpZ0F3SUJBZ0lHQVhZNzJiYlpNQW9HQ0NxR
> 1N\
> 3068
> NNDlCQU1DTURVeEV6QVJCZ05WQkFvTUNrMTVRblZ6YVc1bGMzTXhEVEFMQm
> dOVkJBY01\
> 3069
> CRk5wZEdVeER6QU5CZ05WQkFNTUJsUmxjM1JEUVRBZUZ3MHlNREV5TURjd05
> qRTRNVEp\
> 3070
> hRncwek1ERXlNRGN3TmpFNE1USmFNRDR4RXpBUkJnTlZCQW9NQ2sxNVFuVnp
> hVzVsYzN\
> 3071
> NeERUQUxCZ05WQkFjTUJGTnBkR1V4R0RBV0JnTlZCQU1NRDBSdmJXRnBibEps
> WjJsemR\
> 3072
> ISmhjakJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQmsxNksva
> Tc5b1J\
> 3073
> rSzVZYmVQZzhVU1I4L3VzMWRQVWlaSE10b2tTZHFLVzVmbldzQmQrcVJMN1dSZ
> mZlV2t\
> 3074
> 5Z2Vib0pmSWxsdXJjaTI1d25oaU9WQ0dqZXpCNU1CMEdBMVVkSlFRV01CUUdD
> Q3NHQVF\
> 3075
> VRkJ3TUJCZ2dyQmdFRkJRY0RIREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdTQVlEVlI
> wUkJ\
> 3076
> FRXdQNElkY21WbmFYTjBjbUZ5TFhSbGMzUXVjMmxsYldWdWN5MWlkQzV1WlhT
> Q0huSmx\
> 3077
> aMmx6ZEhKaGNpMTBaWE4wTmk1emFXVnRaVzV6TFdKMExtNWxkREFLQmdnc
> Whrak9QUVF\
> 3078
> EQWdOSUFEQkZBaUJ4bGRCaFpxMEV2NUpMMlByV0N0eVM2aERZVzF5Q08vUm
> F1YnBDN01\
> 3079
> hSURnSWhBTFNKYmdMbmdoYmJBZzBkY1dGVVZvL2dHTjAvand6SlowU2wyaDR4
> SVhrMSI\
> 3080
> sImFnZW50LXNpZ25lZC1kYXRhIjoiZXlKd1lYbHNiMkZrSWpvaVpYbEtjRnBZVW0xTV
> d\
> 3081
> GcDJaRmRPYjFwWVNYUmpiVlo0WkZkV2VtUkRNWGRqYlRBMldWZGtiR0p1VVhS
> ak1teHV\
> 3082
> ZbTFXYTB4WFVtaGtSMFZwVDI1emFWa3pTbXhaV0ZKc1drTXhkbUpwU1RaSmFrb
> DNUV3B\
> 3083
> KZEUxRVVYUk5hbHBWVFVSVk5rMUVZelpPUkVWMVRrUlJORmRwU1hOSmJrNX
> NZMjFzYUd\
> 3084
> KRE1YVmtWekZwV2xoSmFVOXBTWGROVkVsNlRrUlZNazU2WnpWSmJqRTVJaXd
> pYzJsbmJ\
> 3085
> tRjBkWEpsY3lJNlczc2ljSEp2ZEdWamRHVmtJam9pWlhsS2NtRlhVV2xQYVVwWlkw
> aHd\
> 3086
> jMVJWZERSaVNFSkNUbXBvYWxaVVZrZFZWVEZaVmxoYWRWTldVVEpWV0dNNV
> NXbDNhVmx\
> 3087
> YZUc1SmFtOXBVbFpOZVU1VVdXbG1VU0lzSW5OcFoyNWhkSFZ5WlNJNklrY3pW
> M2hHU0d\
> 3088
> WMFdGQTRiR3hTVmkwNWRXSnlURmxxU25aUllUWmZlUzFRYWxGWk5FNWhk
> MW81Y0ZKaGI\
> 3089
> yeE9TbTlFTm1SbFpXdHVTVjlGV0daemVWWlRZbmM0VTBONlRWcE1iakJoUVhW
> b2FVZFp\
> 3090
> UakJSSW4xZGZRPT0iLCJhZ2VudC1zaWduLWNlcnQiOlsiTUlJQjFEQ0NBWHFnQXdJ
> QkF\
> 3091
> nSUVZbWQ0T1RBS0JnZ3Foa2pPUFFRREFqQStNUk13RVFZRFZRUUtEQXBOZVVK
> MWMybHV\
> 3092
> aWE56TVEwd0N3WURWUVFIREFSVGFYUmxNUmd3RmdZRFZRUUREQTlVWlhO
> MFVIVnphRTF\
> 3093
> 2WkdWc1EwRXdIaGNOTWpJd05ESTJNRFEwTWpNeldoY05Nekl3TkRJMk1EUTB
> Nak16V2p\
> 3094
> BOU1STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYV
> hSbE1\
> 3095
> SY3dGUVlEVlFRRERBNVNaV2RwYzNSeVlYSkJaMlZ1ZERCWk1CTUdCeXFHU000O
> UFnRUd\
> 3096
> DQ3FHU000OUF3RUhBMElBQkd4bHJOZmozaVJiNy9CUW9kVys1WWlvT3poK2pJ
> dHlxdVJ\
> 3097
> JTy9XejdZb1czaXdEYzNGeGV3TFZmekNyNU52RDEzWmFGYjdmcmFuK3Q5b3RZN
> VdMaEo\
> 3098
> 2alp6QmxNQTRHQTFVZER3RUIvd1FFQXdJSGdEQWZCZ05WSFNNRUdEQVdnQlJ2
> b1QxdWR\
> 3099
> lMmY2TEVRaFU3SEhqK3ZKL2Q3SXpBZEJnTlZIUTRFRmdRVVhwemxNS3hscEE2OG
> NVNUZ\
> 3100
> RTVhVdm5JVDZRd3dFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBd0l3Q2dZSUtvWkl6aj
> B\
> 3101
> FQXdJRFNBQXdSUUlnYzJ5NnhvT3RvUUJsSnNnbE9MMVZ4SEdvc1R5cEVxUmZ6M
> FF2NFp\
> 3102
> FUHY0d0NJUUNWeWIyRjl6VjNuOTUrb2xnZkZKZ1pUV0V6NGRTYUYzaHpSUWIz
> WnVCMjl\
> 3103
> RPT0iLCJNSUlCekRDQ0FYR2dBd0lCQWdJRVhYakhwREFLQmdncWhrak9QUVFEQ
> WpBMU1\
> 3104
> STXdFUVlEVlFRS0RBcE5lVUoxYzJsdVpYTnpNUTB3Q3dZRFZRUUhEQVJUYVhSbE1
> ROHd\
> 3105
> EUVlEVlFRRERBWlVaWE4wUTBFd0hoY05NVGt3T1RFeE1UQXdPRE0yV2hjTk1qa3
> dPVEV\
> 3106
> 4TVRBd09ETTJXakErTVJNd0VRWURWUVFLREFwTmVVSjFjMmx1WlhOek1RMHd
> Dd1lEVlF\
> 3107
> RSERBUlRhWFJsTVJnd0ZnWURWUVFEREE5VVpYTjBVSFZ6YUUxdlpHVnNRMEV3
> V1RBVEJ\
> 3108
> nY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVRsRzBmd1QzM29leloxdmtIUWJ
> ldGV\
> 3109
> ibWorQm9WK1pGc2pjZlF3MlRPa0pQaE9rT2ZBYnU5YlMxcVppOHlhRVY4b2VyS2
> wvNlp\
> 3110
> YYmZ4T21CanJScmNYbzJZd1pEQVNCZ05WSFJNQkFmOEVDREFHQVFIL0FnRUFN
> QTRHQTF\
> 3111
> VZER3RUIvd1FFQXdJQ0JEQWZCZ05WSFNNRUdEQVdnQlRvWklNelFkc0Qvai8rZ1
> gvN2N\
> 3112
> CSnVjSC9YbWpBZEJnTlZIUTRFRmdRVWI2RTliblh0bitpeEVJVk94eDQvcnlmM2V5T
> Xd\
> 3113
> DZ1lJS29aSXpqMEVBd0lEU1FBd1JnSWhBUG5CMHcxTkN1cmhNeEp3d2ZqejdnRG
> lpeGt\
> 3114
> VWUxQU1o5ZU45a29oTlFVakFpRUF3NFk3bHR4V2lQd0t0MUo5bmp5ZkRObDVN
> dUVEQml\
> 3115	   teFIzQ1hvWktHUXJVPSJdfX0",
> 3116	       "signatures":[{
> 3117
> "protected":"eyJ4NWMiOlsiTUlJQitUQ0NBYUNnQXdJQkFnSUdBWG5WanNVN\
> 3118
> U1Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlF
> RS0RBe\
> 3119
> EthVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFT
> kJNQ\
> 3120
> 0FYRFRJeE1EWXdOREExTkRZeE5Gb1lEems1T1RreE1qTXhNak0xT1RVNVdqQlNN
> UXN3Q\
> 3121
> 1FZRFZRUUdFd0pCVVRFVk1CTUdBMVVFQ2d3TVNtbHVaMHBwYm1kRGIzSndNU
> k13RVFZR\
> 3122
> FZRUUZFd293TVRJek5EVTJOemc1TVJjd0ZRWURWUVFEREE1S2FXNW5TbWx1Wj
> BSbGRtb\
> 3123
> GpaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCQzc5bGlhUm
> NCalpjR\
> 3124
> UVYdzdyVWVhdnRHSkF1SDRwazRJNDJ2YUJNc1UxMWlMRENDTGtWaHRVVjIxbX
> ZhS0N2T\
> 3125
> XgyWStTTWdROGZmd0wyM3ozVElWQldqZFRCek1Dc0dDQ3NHQVFVRkJ3RWdC
> QjhXSFcxa\
> 3126
> GMyRXRkR1Z6ZEM1emFXVnRaVzV6TFdKMExtNWxkRG81TkRRek1COEdBMVVkS
> XdRWU1CY\
> 3127
> UFGRlFMak56UFwvU1wva291alF3amc1RTVmdndjWWJNQk1HQTFVZEpRUU1NQ
> W9HQ0NzR\
> 3128
> 0FRVUZCd01DTUE0R0ExVWREd0VCXC93UUVBd0lIZ0RBS0JnZ3Foa2pPUFFRREFn
> TkhBR\
> 3129
> EJFQWlCdTN3UkJMc0pNUDVzTTA3MEgrVUZyeU5VNmdLekxPUmNGeVJST2xxc
> UhpZ0lnW\
> 3130
> ENtSkxUekVsdkQycG9LNmR4NmwxXC91eW1UbmJRRERmSmxhdHVYMlJvT0U9Il
> 0sImFsZ\
> 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
> iOiJhZ2VudC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiY2FmZmUtOTg3NDU
> iLCJ\
> 3159
> ub25jZSI6ImM1VEVPb29NTE5hNEN4L1UrVExoQ3c9PSIsInByaW9yLXNpZ25lZC12
> b3V\
> 3160
> jaGVyLXJlcXVlc3QiOiJleUp3WVhsc2IyRmtJam9pWlhsS2NGcFlVbTFNV0ZwMlpGZE
> 9\
> 3161
> iMXBZU1hSamJWWjRaRmRXZW1SRE1YZGpiVEEyWkcwNU1Wa3lhR3hqYVVrMlp
> YbEthR01\
> 3162
> 6VG14amJsSndZakkwYVU5cFNtaGFNbFoxWkVNeGQyTnRPVFJoVnpGd1pFaHJhV
> XhEU25\
> 3163
> wYVdFcHdXVmQzZEdKdVZuUlpiVlo1U1dwdmFWa3lSbTFhYlZWMFQxUm5NMDVF
> VldsTVE\
> 3164
> wcDFZakkxYWxwVFNUWkpiVTB4VmtWV1VHSXlPVTVVUlRWb1RrVk9ORXd4VlhK
> V1JYaHZ\
> 3165
> VVE5qT1ZCVFNYTkpiVTU1V2xkR01GcFhVWFJpTWpScFQybEplVTFFU1hsTVZFRjV
> URlJ\
> 3166
> KZVZaRVFUTlBhazE2VDJwQk5FeHFSVFZPYkc5cFRFTkthRm95Vm5Wa1F6RjNZMjA
> 1TW1\
> 3167
> GWFVteGFRekYzWTIwNU5HRlhNWEJrU0d0MFkyMVdibUZZVGpCamJVWjVURm
> RPYkdOdVV\
> 3168
> XbFBhVXBPVTFWc1JGSkdVa1JSTUVacFZESmtRbVF3YkVOUlYyUktVakJHV1ZkWVR
> uZFR\
> 3169
> WMVoyVkZWR2RsSXdUa1JqVldSVVZGUlJOVkZyUms1Uk1ERkhaRE5vUkdWclJrdF
> JiV1J\
> 3170
> QVm10S1FsZFdVa0poTUZwVFZGWktTbVF3VmtKWFZWSlhWVlpHVEZKRlJuTlViVlp
> XVkc\
> 3171
> 1YWFWZEZTbTlaYlRWeVpVVmFWVkZXVWtOYU1EVlhVV3RHZWxSVlVrWk5WRlp
> XVFRGYWN\
> 3172
> GbDZTbk5oTWtaWVVtNXNiRlpGVmxGVVZVVjNVakJGZUZaVlZrTmtNMlJJVmtab2
> MxWkh\
> 3173
> SbGxWYlhoT1ZXdFdNMUpJWkZwU1JscFNWVlZTUlZGWGFFOWFWbHBQWTBkU
> 1NGWnJVbEp\
> 3174
> XUlVac1VtNWpkMlZWTVVWU1dHeE9Va1pHTTFSdWNFcE5WVFZGWVVkR1IyUjZ
> RalpVVlZ\
> 3175
> KR1pWVXhSVlZZWkU5bGEydDRWR3RTYjFsVk1VaFRXR2hFWld0R1MxRnRaRTlXY
> TBwQ1Y\
> 3176
> xWlNRbUV3V2xOVVZrcEtaREJXUWxkVlVsZFZWa1pNVWtWR2MxUnRWbFpVYmx
> wcFYwVkt\
> 3177
> iMWx0TlhKbFJWcEZVVlpPUTFvd05WZFJhMFo2VkZWTmQwMVVWbFpOTVZwd1d
> YcEtjMkV\
> 3178
> 4YkZsVGFsWk9WVlJvTTFKR1JscFNSbHBTVlZWb1JWRldjRTlhVmxwUFkwZFNTRlpZ
> YUV\
> 3179
> oU1JVWllVVzFrVDFaclNrSlVWVEZGVFVSRk1WWlVTbk5OUm5CWFUyMTRZVTF0Z
> URaYVJ\
> 3180
> XaExZVWRPY1ZGc2NFNVJhekZJVVc1c2VGSXhUazVPUkd4Q1dqQldTRkV3VG5oU0
> 1VNU9\
> 3181
> Ua1JzUW1Rd1ZrbFJWRUpLVVZWS1NsVklhRmhrVlRGSlVucG9TMVJIV2taVlJVVTF
> UMWh\
> 3182
> hZDAxdVZrbFNWVFZxVlROc2JWa3pWVE5VUjJSYVRraEJlRTVGUmtOT01GSk9XbFJ
> GTkU\
> 3183
> xSVRrWmxSV1J4VkZOME0yTnJOVFJPTURVMVdWaE9lRXQ2Um5CTlJXUlVVVEZKT
> lU1VVV\
> 3184
> UTk5SRVp0VWpKV1dGUldSbWxqVjNCWVpXdEtZVlJWU1hkU01FVjRWbGRTUzFW
> V1JsaFV\
> 3185
> WVXBTVWpCT1JHTXdaRUpWVmxaSFVXNWtUbEZyU201YU0wcERXakJXUjFGc1Jt
> cFNSV2h\
> 3186
> GVVZVNVExb3dOVmRUUmtVMFVXdEdiVTlGVmtOUlZURkVVV3BTUW1Rd2RFSlh
> WVkpYVld\
> 3187
> wQ1UxRnJUa1prTUdjd1UxZFNhVmRIZURaWlZtaFRZa2RPZEZadE5XaFhSVFIzV1RJ
> eFI\
> 3188
> yVlZlSFJOVkZaYVRXcHNNRmt3WkVka1YxWlVUbGR3YVUxcVFqTlJNbVJhVTFWM
> GRsZHJ\
> 3189
> iRFpoYWtKR1VWaGtTbEpHVGtKUldHUlRWVlZzYjFGV1FqVlBXRnBOVTFkR01WVnJ
> WbEp\
> 3190
> qYlhnMVlteGtNRlI2VmxOaVZYQXdZVmhTVW1GNlpFOVhSRkpMVlVoV2RWVklRaz
> lVYXp\
> 3191
> BeFZWUnNRbUZWUm5sa1JVNTBWRVprWVZSVmJFMVdiRTEyVFZWc1JWbFhjR2
> xqTVU1Sll\
> 3192
> tNXdkbUpYYjNkV1F6a3paVmhKY21Nd2RFdGpRM1IxVFhwU1VsQlVNR2xNUTBw
> b1dqSld\
> 3193
> kV1JETVhwaFYyUjFXbGRSZEZwSFJqQlpVMGsyU1cxV05WTnVaRnBYUjNoNldXcEt
> SMkV\
> 3194
> 3YkhGaU1teGhWMGQ0VEZrd1duZFhWbFowVFZVeFdGSnVRWGxYYTFwclZESkplR
> 05HYkZ\
> 3195
> SWFJrcHhXV3hhWVU1R2NFZGFSbVJzWWxaS1JWUldhR3RoYlVwVlVWUktXRlp0V
> W5KWmE\
> 3196
> yUkxaRlpXV1ZWdGNFNWlXR2d4VjFjd2VGWXlSWGRsUm1oV1lsZG9jbFZxUWxkalJ
> sRjV\
> 3197
> UbGh3YUZadGREWlZNakUwVjJ4a1IxTnVUbGhoTURFMFdrY3hTMk5HVGxWWGE
> zQm9ZVEo\
> 3198
> zZWxaR1pIZFNiVkpHVFZaV1UxZEdTazlXYTFwM1ZteFNWbFZyY0U5aGVrVXlWVlp
> TWVZ\
> 3199
> Sc1NrWlNha1pWVmxaS1ExcEVSbXRqUms1WlZHdHdhV0Y2Vm5wWFZFbDRZekp
> HU0ZOclV\
> 3200
> rNVhSbHB5Vm01d1IyTkdaSE5oUlhCb1ZsUnNkMVV5TVhkWGJGbDRZMGhTV0dK
> Rk1UTlV\
> 3201
> iRlUxVWxac05sRnJPVlpOUnpneFYyMTRSbUZWZUVSVGJuQm9WakpTTVZkV2FGT
> k5WMDU\
> 3202
> wVm01d1NtRnVRbWxhV0d4TFpESk9kRTlVUW1GV01EUjNWMnhrVW1GVk9YQlR
> iWGhzVmx\
> 3203
> oQ2RsZFhkR3RoYlVaV1QxaENWR0V4Y0ZkYVYzUnlaVVpTZEdKRmNHcE5SM2d3V
> 2tWb1E\
> 3204
> xbFdSWGRoZWtwVVZqTm9kbFZ0ZEhwbFZsWlpVMnhTYVdKclNrcFdhMVpUVVcxV
> 2MxSnV\
> 3205
> VbFJpVlZwVlZXdGFjbVZzVFhwalJ6bFhUVlpHTmxkWWNFTmhiRWw1V1ROa1ZVM
> UdSak5\
> 3206
> aVm1SaFZXdHNjR1F5YkdwTmJYaDFXVzB4UjAxSFVsbFRiWGhLWVcwNWNGZEVR
> azlsYXp\
> 3207
> sV1QxWm9VMkpyY0dGWmJHTTFaV3hOZDA5WVZsSlhSMUpUVjFSR1YyRXhiM2R
> qUlZaWVV\
> 3208
> qRndUVmxzVWt0WFZUbFhVMnhXVjFJd05URlVSazE0WXpGUmQwNVdRbWxTZW
> xaMlZqSjB\
> 3209
> SazFGT1VaWGJYUlhZa2hCZDFReFVrOWhNbEY0Vld0d1YxWlVWbGRYUkVwaFYyc
> zVWMWR\
> 3210
> 1UWxkaVJHdzFWWHBPVDFaV1JuSmhSa3BRVmpOQ2Vsa3haSHBsVjBsNldUSnNi
> VlpxUlR\
> 3211
> WSmFYZHBXVmRrYkdKdVVYUmpNbXh1WW1reGFscFlTakJKYW5CaVNXc3hTbE5
> WVGt0U1J\
> 3212
> VNUVVVmRPZUZvd1JqTlRWVXBDV2pCc1JsZEhlSEZSTURGRlVWVjBRMW95Wkho
> aFIzUnh\
> 3213
> WREZDVWxWVlVrSmhhMHB6VkZaR2VtUXdUbEpYVlZKWFZWWkdTRkpZWkV0U
> mJGWlZVbFp\
> 3214
> PVGxGclJraFJWRVpXVWxWT2JtUXdjRlZYUjNoRldXcEplR1F4YkZoT1ZGWk9WV3h
> XTTF\
> 3215
> KWVpGcFNSbHBTVlZWNFJWRllhRTlhVmxwUFRWWnNkVlJ1UW1GU01uaHZXVEk
> xY21WRlV\
> 3216
> qWlJWVFZEV2pBMVYxRnJSbXBVVlVweVRWUldWazF0ZDNkWGJGSkdXVlV4UTFv
> d1pFSk5\
> 3217
> WbFpHVVZoa00xVnNVbGxpUmxKb1YwWktjMVpWYUZkbGJVWkdUVmhhWVZJeF
> ducFZWRUp\
> 3218
> HWkRCb2Ixa3dOVTVoYTBZelZGZHdTazVGTVVWWk0zQk9aV3RGZDFZeWFHcFVh
> ekUyVVZ\
> 3219
> oa1RtRnJhekJVVlZKcVpXc3hObEZVUWxoaGEwcDBWRlpHZW1Rd1RsSlhWVkpYVl
> ZaR1N\
> 3220
> GSllaRXRSYkZaVlVsWk9UbEZyUmtoUlZFWldVbFZPYm1Rd2NGVlhSM2hGV1dwSm
> VHUXh\
> 3221
> iRmhPVkZaT1ZXeFdNMUpZWkZwU1JscFNWVlY0UlZGWWFFOWFWbHBQVFZac2
> RWUnVRbUZ\
> 3222
> TTW5odldUSTFjbVZGVWpaUlZUVkRXakExVjFGclJtcFVWVXB5VFZSV1ZrMXRkM2R
> YYkZ\
> 3223
> KR1dXc3hRMkV3WkVKTlZsWkdVVmhrTTFVeFVsbGlSbEpvVjBaS2MxWlZhRmRsYlV
> aR1R\
> 3224
> WaGFZVkl4V25wVlZtaERaREF4UjJFelpFWmtNV3hKVXpJNVlWTlljSEZOUlU1Q1ZW
> WnN\
> 3225
> TbE15T1dGVFdIQnhUVVZTUWxWWFRrVlZWMlJDVWxSWmQwMVZPSEppTW5CR
> VlUTktSVlZ\
> 3226
> 1WXpOYU1Hd3lWMnRWTUdGVVRUQmFSMHB2VVROR2NGSjZaSEZpTWprelYyN
> UJNR1ZJV2p\
> 3227
> aU2JsSk5XbnBhVlZaNlFtOVViVkpKWkd4Q1JWVXhVbnBrVm1oVVpWWmpOV1JJU
> 1hwUld\
> 3228
> HUkVZa2RhUkdJd1VsZFVia1pRWkhwc05WUldaekpVYlRWT1VqRldNMUpIWkZw
> U1JscFR\
> 3229
> UVVpDUWxWVlozWlJhMFpTVWtWR2JscFZSazVSYW1oSVVWUkdWbHBGYkROVl
> ZteE9VVzF\
> 3230
> HUWxKcmJ6TlRTRkpVWkROQ1RWUklWbEJYYW1ScVlUQkdjMVZWYUZaTk1tUkN
> WRmRqZGx\
> 3231
> Ock1VTk5SV1JDVFZaV2ExSkhaRkpXTUVwRFZXMU9WVTVVVFRCaWF6RmFaR3hT
> YWxKdVV\
> 3232
> uSmFia295VGpOb1ZrNHdVbkJpVldoeFpXdEdWVkZ0WkU5V2EyaFVWbFZXUlZKRlJ
> reFJ\
> 3233
> iV1J1WTJ0S2JsSlZXa05WVjA1RlVWZHdRbE13U201YU0wWnZZVEp3VUZWR1JsSl
> NSVVp\
> 3234
> 1Vkd0c1FsSkZTa2RSVjJ4R1VWaENTMDR6YUhkVWJGWXlWVlZ3U0UxRk5XOVVS
> MGwyV2x\
> 3235
> oU2FVMXFRazFTUmxWNFRtMTRkMVV3YUZCT01rWnNZbnBDVjFkWVozZGxTR1J
> FVTFWRmN\
> 3236
> sUjZWWFpYVkZwRllVTjBhVkZxU1RSTmFsSXhZVmRHVUZWWFJsWlNSRnB1VVZV
> MWIxZFV\
> 3237
> iRmRTYlZGeVlXNUtlVmt3VmpKVGJsRnBURU5LVGxOVmJFUlNNVkpFVVRCR2FVc3
> laRUp\
> 3238
> rTUd4RFVWZGtTbEpXYUhOaGEwVjJaV3RHVEZGdFpHNWpWMmh5WVdzNVVWV
> ldSa1ZSVjN\
> 3239
> CRFdUQXhVbU16WkVSVlZteEZWbXhHVWxJd1ZqTlRhMHBXVmtWV1ZGUlZTa0pT
> TUVWNFZ\
> 3240
> sVldSRm96WkV0V1JtaHpVa2RKZVUxWVpGcFdlbFV4VkZaS1ZtUXdWak5YVlZKWF
> ZWWkd\
> 3241
> UVkpGUmpSVWJWWlhWR3BHV21Kck5YZFhhMlJ6WVVkT2RXRXphRVZsYTBaUFV
> XMWtUMVp\
> 3242
> yU2tKWk1ERkRZWHBGTVZaVVNuTk5SbkJWVWxaS1RsRlVhRWhSVkVaV1VsVkdN
> MlF3YkZ\
> 3243
> WWFIzaFZXVlpvVTJKR1JYZFNXR1JKWVVkT1QxUlhjRUprTURGeFUxUlNUbEpIVGp
> WVWJ\
> 3244
> uQldUbFprYjFrd05VNWxhMFl6VkZkd1NrNUZNVVZaTTJ4UFpXeFZNVll5Y0VOaVJU
> RlN\
> 3245
> Zek5rUkZWV2JFVldiRVpTVWpCV00xTnJTbFpXUlZaVVZGVktRbEl3UlhoV1ZWWkV
> Xak5\
> 3246
> rUzFaR2FITlNSMGw1VFZoa1dsWjZWVEZVVmtwV1pEQldNMWRWVWxkVlZrWk5
> Va1ZHTkZ\
> 3247
> SdFZsZFVha1phWW1zMWQxZHJaSE5oUjA1MVlUTm9SV1ZyUms5UmJXUlBWbXR
> LUWxrd01\
> 3248
> VTmhla1V4VmxSS2MwMUdjRlZTVjBaT1VXMWtTRkZVUmxaU1ZVWXpaREZLVlZk
> SGVGVlp\
> 3249
> WbWhUWWtaV1NWWnVjR2hTVkVZeVYydGtWMk14UlhkU1dHUllWa1ZHVlZGdF
> pHcGpWMmh\
> 3250
> 5WVdzNVVWVlZiRU5SYldSdVkxZG9jbUZyT1ZGVlZURkRVVzVrVDFFd1JrSlZhM0JEV
> m0\
> 3251
> wNWVscEZkRE5YVlRVMFlWWkNORk5JV25CU2JrWk1aV3RTYzA5WFdqQlVTRlpP
> V1ZjeGQ\
> 3252
> xSnNSbXBYU0dONFRXcGthRlJ0T1ZOWmJrNUpUREJhVG1OdE1UWlJNRVpKVFhw
> ak0wMTZ\
> 3253
> UbXBOYlRscFZVZE9jMlJzVG5sWFZVb3lUVVZPTUZZeFJqQlpWRnBvU3pKT2RrMXNi
> RE5\
> 3254
> YYTFKQ1ZUQktibFJzV2tsVmF6RkRVVmRaTkZKVlRrVlJWV1JDVlZWbmRsRlhaRVpS
> VlR\
> 3255
> GQ1RrVmtRazFXVm10U1NHUkdVV2s1TTFWVlZrSmtNR3hFVVd0U1FscHJTbTVVY
> kZwSlZ\
> 3256
> UQXhSbEl3VWtKV01tUkRWVmh3TkdWdVpIZFZia0pOWlZNNWVWUldWbHBsYlV
> adlRXNU5\
> 3257
> lRTB5VmxaUFYyUkhaV3RHYTFGdFpFOVdhMmhTVGtWV1Ixb3hSbFppYms1c1RW
> VjRSR0V\
> 3258
> 6VGpGT1JGWjFaRWhzVWxFeFdrSmFSbEpzVVZWR05WSkVhSEprTUU1dVYxVnNU
> R0l4Y0V\
> 3259
> wbGJXOTNVbFZHTTFOVlVsUlJWVVl6Vld4R1NtRkZSa3BqTVd4eldsWndUR015Y0V
> kVWE\
> 3260
> wNTZVMnQwYkZWSGVFaFVWVVpOV2xoQ1YxcFViRVpVUkdSUFlqTlJNVTFVVmp
> ObFJ6Rlh\
> 3261
> aRlZ3UTFGWGJFSlpNRlpPVmxaV2IxSldUbnBVUm1SUlRsaG9WRlZXVlhkWFNFWTJ
> WbTV\
> 3262
> GTkZkWVduQlNha1pwVm0wNU5sSXpjRFJPV0hCUFdqSk9lbVI2TURsSmJERTVabE
> VpTEN\
> 3263
> KemFXZHVZWFIxY21WeklqcGJleUp3Y205MFpXTjBaV1FpT2lKbGVVbzBUbGROYV
> U5c2M\
> 3264
> ybFVWV3hLVVRCb2NWRXdUa0paTVU1dVVWaGtTbEZyUm01VFZXUkNWMGRvT
> UUxVVVucGl\
> 3265
> NREZDWWpCa1JGRXpSa2hWTURBd1QxVktRbFJWVGs1U1ZtdzBVVE53UWxOclN
> tNVViRnB\
> 3266
> EVVZac1ZWRlhkRTlUVlRGVFZGaGtSbFZXYkVWV2JFWlNVekJTUW1OR1VtaFdNV
> m93VjJ\
> 3267
> 4ak1XVnJiRVpTYTJoT1ZWUm9NMUpHUmxwU1JscFNWVlY0UlZGV2NFUldhMDV
> EVWtaV1I\
> 3268
> xUllhRVpXUlVaUlVXMWtUMVpyU2tKVVZURkVVbXh3YzFsdE1WTmtiVTV5Vkd0S1
> RsRXd\
> 3269
> SbGxTUmxKS1pVVXhSVlJZYkU5aGEwVXhWRmR3U21WVk5WZGlNV3hGWlcxek1
> WUXhVbkp\
> 3270
> sUlRGeFZGaG9UbUZyTUhoVU1WSldUbFprY1ZGdGFFNVZXRTR6VVRGR1dsSkdXbE
> pWVld\
> 3271
> SR1pEQndSVlV3VWtaV1JURkRVbFZrUWsxV1ZrWlJNbVF6VXpGVmVXSkhlR2xXTVZ
> veFd\
> 3272
> UTnNRMUZzU2paU1ZrSk9VVlJDU0ZGVVJsWlNWVTR6WkRCa1VtSkdSbTVWVkVa
> RFZrVXh\
> 3273
> VMVZZWkVaYU1XeEZWbXhHVWxKclZqTmtSM0JhVmpGd2RGZHNUWGRPVlRsRld
> YcENUMVp\
> 3274
> GVmxoVVZVcFNVakJGZUZaVlZrSmtNMlJQVmxWYWIxSkZNVFZPVlZwUFpXeFdNRl
> JXVWt\
> 3275
> Ka01VWlZVV3h3VGxGck1VaFJibXg0VWpGT1RrNUViRUphTUZaSVVUQk9lRkl4VGs
> 1T1J\
> 3276
> HeENaREJXU1ZGVVFrcFJWVXBQVFVSb2NWWXdlSHBOUjBadlV6Qm9XbGR1Vm0
> 5aVZ6Rmp\
> 3277
> UREpqTkdScVVsaFRNR2d5VVZoU2FGcHNSazFSVTNSS1pGVXhUMkZITVc1aFZ6Rll
> UakJ\
> 3278
> HVG1OdVJtOWlWMHBWVFRCc2FGVkZUalZoUnpGaFUxWk9kMVI2V20xaVUzTXl
> VMWhhWTB\
> 3279
> 3eldrcGphM1J2VlZaU01WWnRPVXhoYldSYVVWaGtiV0ZyUm5aUmJXUnVZMnRLY
> mxKVld\
> 3280
> rTlZWMDVEVTFWR1Vsa3dVa05qU0ZKYVYwVTFiMVJHYUZOaVIwMTZWVmhXYW
> sxdGVITlp\
> 3281
> iR1JYWkZkT05VNVhjR2xOYWtFeVZERlNVazFGTVRaUlZsSkRXakExVjFOR1RsWlN
> WVkp\
> 3282
> GVVZWMFExb3laSGxSYldSR1VtdEtVbGt3VWtKV1JVWlFVVzFrVDFacmFGSlBSVXB
> DV21\
> 3283
> wb1JsRnJSazVSTUVrd1VWaGtUVlZXYkVWV2JFbDNWV3RLUkZkWVpFdFRWV3h3
> V2tWa2I\
> 3284
> ySkZlSFZYYlhocFlsWktNbGt5YXpGaGJHeFlUa2hXYVdKVWEzZFVSekV3WkZkSmVsa
> 3p\
> 3285
> WbXRTTW1oM1dUTnJNVTFzYkZobFJFWmhWa1ZHVEZGdFpHNWpWMmh5WVdz
> NVVWVldSa1Z\
> 3286
> SVjJSUFUxVkdSVkZyV2tKaFZVazFVVzB4ZUZRemNIRlZWR2hzV1ZkamVWTnVVblpr
> Vmx\
> 3287
> KdlVsWm9lVm93T1VOWFZsRjNVWHBvWVdSRGREVlBWemxKVWtad1JWbHNVbE
> pUVjJoQ1Z\
> 3288
> HMXpNbVJIT1ZOaU1sWkVXVmMxYUZSWGNFNVdSWGgwWWxaV2RXSlhTbkphY
> WtKNldsaGF\
> 3289
> jbEV3YnpSTmJXc3hWbGhHY1ZWcldsZFZVMHBrVEVOS2FHSkhZMmxQYVVwR1ZYc
> EpNVTV\
> 3290
> wU2praUxDSnphV2R1WVhSMWNtVWlPaUphWTFwa1dYbzBiMUl3UjJKc09UWnF
> NWGxZWm5\
> 3291
> kdlRYZGxVVGt6VGpCdFNVUmxjVFkyVTBacWRFdG9lR1pSWjNJMGRUWkpOVEJK
> WldNMmE\
> 3292
> xWTJhSEV3YVcxdlptTlBhVGs0VW1OSVpXUmpNVzFuZHpCWVp5SjlYWDA9IiwiY3Jl
> YXR\
> 3293
> lZC1vbiI6IjIwMjItMDItMjJUMDc6MzM6MjUuMDIwWiIsImFnZW50LXNpZ24tY2Vy
> dCI\
> 3294
> 6WyJNSUlDSkRDQ0FjcWdBd0lCQWdJRVhsakNNREFLQmdncWhrak9QUVFEQWp
> CbE1Rc3d\
> 3295
> DUVlEVlFRR0V3SkJVVEVTTUJBR0ExVUVDZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WU
> RWUVF\
> 3296
> MREF4TmVWTjFZbk5wWkdsaGNua3hEekFOQmdOVkJBY01CazE1VTJsMFpURWF
> NQmdHQTF\
> 3297
> VRUF3d1JUWGxUYVhSbFVIVnphRTF2WkdWc1EwRXdIaGNOTWpBd01qSTRNRG
> N6TXpBMFd\
> 3298
> oY05NekF3TWpJNE1EY3pNekEwV2pCbU1Rc3dDUVlEVlFRR0V3SkJVVEVTTUJBR0
> ExVUV\
> 3299
> DZ3dKVFhsRGIyMXdZVzU1TVJVd0V3WURWUVFMREF4TmVWTjFZbk5wWkdsaG
> Nua3hEekF\
> 3300
> OQmdOVkJBY01CazE1VTJsMFpURWJNQmtHQTFVRUF3d1NUWGxUYVhSbFVIVn
> phRTF2Wkd\
> 3301
> Wc1FYQndNRmt3RXdZSEtvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUU2MDFPK2
> 9qQ2t\
> 3302
> yRFJ3N2dJdlpFNGkzNGRiaENxaUc3am9vd1pwNHh2ekZ0TGc2VFcwaE5kSHZQRF
> NUc3V\
> 3303
> YU3lXOXRyM0F3Q2xmQ29EVk5xT3c5eU1YNk5uTUdVd0RnWURWUjBQQVFIL0J
> BUURBZ2V\
> 3304
> BTUI4R0ExVWRJd1FZTUJhQUZKN0h0U3dwTEx1T1o3Y2tBbFFIVTNnQU1nL0pNQj
> BHQTF\
> 3305
> VZERnUVdCQlJjVDUzNG5NWXZUY0Z0a2Zydjd4VTdEaW1IanpBVEJnTlZIU1VFRER
> BS0J\
> 3306
> nZ3JCZ0VGQlFjREFqQUtCZ2dxaGtqT1BRUURBZ05JQURCRkFpRUFwSjd4cE5VdlFK
> RzB\
> 3307
> OaExiL2V0YjIwTERVMTZscFNITzdhZW8wVll4MHh3Q0lBK081L1k2RGgrYkIyODI0d
> Wl\
> 3308
> hT1FhVUQ2Z0FOaFk5VkZkK2pycmNFdkp0IiwiTUlJQ0dUQ0NBYitnQXdJQkFnSUVY
> bGp\
> 3309
> BL3pBS0JnZ3Foa2pPUFFRREFqQmNNUXN3Q1FZRFZRUUdFd0pCVVRFU01CQUdB
> MVVFQ2d\
> 3310
> 3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk4xWW5OcFpHbGhjbmt4RHp
> BTkJ\
> 3311
> nTlZCQWNNQmsxNVUybDBaVEVSTUE4R0ExVUVBd3dJVFhsVGFYUmxRMEV3SGh
> jTk1qQXd\
> 3312
> Nakk0TURjeU56VTVXaGNOTXpBd01qSTRNRGN5TnpVNVdqQmxNUXN3Q1FZRFZ
> RUUdFd0p\
> 3313
> CVVRFU01CQUdBMVVFQ2d3SlRYbERiMjF3WVc1NU1SVXdFd1lEVlFRTERBeE5lVk
> 4xWW5\
> 3314
> OcFpHbGhjbmt4RHpBTkJnTlZCQWNNQmsxNVUybDBaVEVhTUJnR0ExVUVBd3dS
> VFhsVGF\
> 3315
> YUmxVSFZ6YUUxdlpHVnNRMEV3V1RBVEJnY3Foa2pPUFFJQkJnZ3Foa2pPUFFNQ
> kJ3TkN\
> 3316
> BQVJKQlZvc2RLd1lOeGlQeEh2aUZxS3pEbDlmdEx1TWFtcEZRY1h3MTI3YU5vUmJ
> zSC9\
> 3317
> GTXJtekNBSDM3NzMzYzJvYlBjbHZTcllCdjBDdFdRdGE2YStjbzJZd1pEQVNCZ05WSF
> J\
> 3318
> NQkFmOEVDREFHQVFIL0FnRUFNQTRHQTFVZER3RUIvd1FFQXdJQ0JEQWZCZ05
> WSFNNRUd\
> 3319
> EQVdnQlF6eHp3cFJwTHkvck1VWXphaDJzMTNlVTlnRnpBZEJnTlZIUTRFRmdRVW5
> zZTF\
> 3320
> MQ2tzdTQ1bnR5UUNWQWRUZUFBeUQ4a3dDZ1lJS29aSXpqMEVBd0lEU0FBd1J
> RSWhBSXN\
> 3321
> ZbGVaS3NqRk5Dc0pLZVBsR01BTGVwVmU5RUw3Tm90NTE1d3htVnVKQkFpQW
> NFTVVVaEV\
> 3322	   Tc0xXUDV4U1FVMFhxelZxOFl2aUYxYlZvekd6eDV6Tmdjc3c9PSJdfX0",
> 3323	     "signatures":[{
> 3324
> "protected":"eyJ4NWMiOlsiTUlJQjhEQ0NBWmFnQXdJQkFnSUdBWEJoTUtZSU1\
> 3325
> Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS
> 0RBbE5\
> 3326
> lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1B
> MEdBMVV\
> 3327
> FQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTmVWTnBkR1ZEUVRBZUZ3MHl
> NREF5TWp\
> 3328
> Bd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFNSGt4Q3pBSkJnTlZCQVlUQ
> WtGUk1\
> 3329
> SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaW
> MybGt\
> 3330
> hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVM0d0xBWURWUVFERENWU
> 1pXZHBjM1J\
> 3331
> 5WVhJZ1ZtOTFZMmhsY2lCU1pYRjFaWE4wSUZOcFoyNXBibWNnUzJWNU1Ga3dF
> d1lIS29\
> 3332
> aSXpqMENBUVlJS29aSXpqMERBUWNEUWdBRUJUVFwvc1JmTDlsSnVGbVwvY24
> zU2pHcWp\
> 3333
> QXC9xdnBrNytoSTIwOE5oVkRvR2hcLzdLUCt2TXpYeVFRQStqUjZrNnJhTTI4Zlwvb
> HV\
> 3334
> FK1h1aHVwN1Vmem05Q3FNbk1DVXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUhBeH
> d3RGd\
> 3335
> ZRFZSMFBBUUhcL0JBUURBZ2VBTUFvR0NDcUdTTTQ5QkFNQ0EwZ0FNRVVDSUh
> OK3VBbUp\
> 3336
> ldVhlc1wveWQxd1M0Mlo0RFhKNEptMWErZzNYa1pnZjhUaGxuQWlFQXBVdTZzZ
> nljRWt\
> 3337
> veDdSWlhtZitLOHc0cDZzUldyamExUVJwWTAyNjQxSFk9IiwiTUlJQjhEQ0NBWmV
> nQXd\
> 3338
> JQkFnSUdBWEJoTUtZQk1Bb0dDQ3FHU000OUJBTUNNRnd4Q3pBSkJnTlZCQVlUQ
> WtGUk1\
> 3339
> SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmdOVkJBc01ERTE1VTNWaW
> MybGt\
> 3340
> hV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJFd0R3WURWUVFEREFoTm
> VWTnBkR1Z\
> 3341
> EUVRBZUZ3MHlNREF5TWpBd05qQXlNak5hRncwek1EQXlNakF3TmpBeU1qTmFN
> Rnd4Q3p\
> 3342
> BSkJnTlZCQVlUQWtGUk1SSXdFQVlEVlFRS0RBbE5lVU52YlhCaGJua3hGVEFUQmd
> OVkJ\
> 3343
> Bc01ERTE1VTNWaWMybGthV0Z5ZVRFUE1BMEdBMVVFQnd3R1RYbFRhWFJsTVJ
> Fd0R3WUR\
> 3344
> WUVFEREFoTmVWTnBkR1ZEUVRCWk1CTUdCeXFHU000OUFnRUdDQ3FHU000O
> UF3RUhBMEl\
> 3345
> BQkluQ3VoV1ZzZ2NONzFvWmVzMUZHXC9xZFZnTVBva01wZlMyNzFcL2V5SWNc
> L29EVmJ\
> 3346
> NRkhDYmV2SjVMTTgxOTVOYVpLTlNvSFAzS3dMeXVCaDh2MncwOVp1alJUQkRN
> QklHQTF\
> 3347
> VZEV3RUJcL3dRSU1BWUJBZjhDQVFFd0RnWURWUjBQQVFIXC9CQVFEQWdJRU1
> CMEdBMVV\
> 3348
> kRGdRV0JCUXp4endwUnBMeVwvck1VWXphaDJzMTNlVTlnRnpBS0JnZ3Foa2pPU
> FFRREF\
> 3349
> nTkhBREJFQWlCZGJIU212YW9qaDBpZWtaSUtOVzhRMGxTbGI1K0RLTlFcL05LY1I
> 3dWx\
> 3350
> 6dGdJZ2RwejZiUkYyREZtcGlKb3JCMkd5VmE4YVdkd2xIc0RvRVdZY0k0UEdKYmc9I
> l0\
> 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
> udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbm
> NlIjo\
> 3370
> iTDNJSjZocHRIQ0lRb054YWFiOUhXQT09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDQtMjZ\
> 3371
> UMDU6MTY6MjguNzI2WiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQV
> VtZ0F\
> 3372
> 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQk
> FvTUNrMTV\
> 3373
> RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJs
> UmxjM1J\
> 3374
> EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016S
> mFNRFV4RXp\
> 3375
> BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4
> RHpBTkJ\
> 3376
> nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXd
> FSEEwSUF\
> 3377
> CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4
> MDYvU2N\
> 3378
> ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdB
> MVVkRXd\
> 3379
> FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVk
> RGdRV0J\
> 3380
> CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWd
> OSkFEQkd\
> 3381
> BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0
> NJUUR\
> 3382
> HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0if
> X0",
> 3383	     "signatures":[{
> 3384
> "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
> 3385
> Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS
> 0RBeEt\
> 3386
> hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJ
> NQjR\
> 3387
> YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQ
> WtHQTF\
> 3388
> VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NH
> QTFVRUF\
> 3389
> 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd
> 1dUQVR\
> 3390
> CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRcl
> JzOFI\
> 3391
> wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdO
> aXZPS0d\
> 3392
> CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS2
> 9aSXp\
> 3393
> qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwz
> MERRSU5\
> 3394
> FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC
> 9cL1pLT2F\
> 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
> udC1wcm94aW1pdHkiLCJzZXJpYWwtbnVtYmVyIjoiMDEyMzQ1Njc4OSIsIm5vbm
> NlIjo\
> 3415
> iUUJiSXMxNTJzbkFvVzdSeVFMWENvZz09IiwiY3JlYXRlZC1vbiI6IjIwMjItMDktMjl\
> 3416
> UMDM6Mzc6MjYuMzgyWiIsInBpbm5lZC1kb21haW4tY2VydCI6Ik1JSUJwRENDQ
> VVtZ0F\
> 3417
> 3SUJBZ0lHQVcwZUx1SCtNQW9HQ0NxR1NNNDlCQU1DTURVeEV6QVJCZ05WQk
> FvTUNrMTV\
> 3418
> RblZ6YVc1bGMzTXhEVEFMQmdOVkJBY01CRk5wZEdVeER6QU5CZ05WQkFNTUJs
> UmxjM1J\
> 3419
> EUVRBZUZ3MHhPVEE1TVRFd01qTTNNekphRncweU9UQTVNVEV3TWpNM016S
> mFNRFV4RXp\
> 3420
> BUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNNeERUQUxCZ05WQkFjTUJGTnBkR1V4
> RHpBTkJ\
> 3421
> nTlZCQU1NQmxSbGMzUkRRVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXd
> FSEEwSUF\
> 3422
> CT2t2a1RIdThRbFQzRkhKMVVhSTcrV3NIT2IwVVMzU0FMdEc1d3VLUURqaWV4
> MDYvU2N\
> 3423
> ZNVBKaWJ2Z0hUQitGL1FUamdlbEhHeTFZS3B3Y05NY3NTeWFqUlRCRE1CSUdB
> MVVkRXd\
> 3424
> FQi93UUlNQVlCQWY4Q0FRRXdEZ1lEVlIwUEFRSC9CQVFEQWdJRU1CMEdBMVVk
> RGdRV0J\
> 3425
> CVG9aSU16UWRzRC9qLytnWC83Y0JKdWNIL1htakFLQmdncWhrak9QUVFEQWd
> OSkFEQkd\
> 3426
> BaUVBdHhRMytJTEdCUEl0U2g0YjlXWGhYTnVocVNQNkgrYi9MQy9mVllEalE2b0
> NJUUR\
> 3427
> HMnVSQ0hsVnEzeWhCNThUWE1VYnpIOCtPbGhXVXZPbFJEM1ZFcURkY1F3PT0if
> X0",
> 3428	     "signatures":[{
> 3429
> "protected":"eyJ4NWMiOlsiTUlJQmt6Q0NBVGlnQXdJQkFnSUdBV0ZCakNrWU1\
> 3430
> Bb0dDQ3FHU000OUJBTUNNRDB4Q3pBSkJnTlZCQVlUQWtGUk1SVXdFd1lEVlFRS
> 0RBeEt\
> 3431
> hVzVuU21sdVowTnZjbkF4RnpBVkJnTlZCQU1NRGtwcGJtZEthVzVuVkdWemRFTkJ
> NQjR\
> 3432
> YRFRFNE1ERXlPVEV3TlRJME1Gb1hEVEk0TURFeU9URXdOVEkwTUZvd1R6RUxNQ
> WtHQTF\
> 3433
> VRUJoTUNRVkV4RlRBVEJnTlZCQW9NREVwcGJtZEthVzVuUTI5eWNERXBNQ2NH
> QTFVRUF\
> 3434
> 3d2dTbWx1WjBwcGJtZERiM0p3SUZadmRXTm9aWElnVTJsbmJtbHVaeUJMWlhrd
> 1dUQVR\
> 3435
> CZ2NxaGtqT1BRSUJCZ2dxaGtqT1BRTUJCd05DQUFTQzZiZUxBbWVxMVZ3NmlRcl
> JzOFI\
> 3436
> wWlcrNGIxR1d5ZG1XczJHQU1GV3diaXRmMm5JWEgzT3FIS1Z1OHMyUnZpQkdO
> aXZPS0d\
> 3437
> CSEh0QmRpRkVaWnZiN294SXdFREFPQmdOVkhROEJBZjhFQkFNQ0I0QXdDZ1lJS2
> 9aSXp\
> 3438
> qMEVBd0lEU1FBd1JnSWhBSTRQWWJ4dHNzSFAyVkh4XC90elVvUVwvU3N5ZEwz
> MERRSU5\
> 3439
> FdGNOOW1DVFhQQWlFQXZJYjNvK0ZPM0JUbmNMRnNhSlpSQWtkN3pPdXNuXC
> 9cL1pLT2F\
> 3440
> FS2JzVkRpVT0iXSwidHlwIjoidm91Y2hlci1qd3MranNvbiIsImFsZyI6IkVTMjU2In0\
> 3441	   ",
> 3442
> "signature":"ShqW8uFRkuAXIzjAhB4bolMMndcY7GYq3Kbo94yvGtjCaxEX3Hp\
> 3443	   6QXZUTEJ_kulQ1G7DnaU4igDPdUGtcV9Lkw"},{
> 3444
> "protected":"eyJ4NWMiOlsiTUlJQjRqQ0NBWWlnQXdJQkFnSUdBWFk3MmJiWk1
> \
> 3445
> Bb0dDQ3FHU000OUJBTUNNRFV4RXpBUkJnTlZCQW9NQ2sxNVFuVnphVzVsYzNN
> eERUQUx\
> 3446
> CZ05WQkFjTUJGTnBkR1V4RHpBTkJnTlZCQU1NQmxSbGMzUkRRVEFlRncweU1ER
> XlNRGN\
> 3447
> 3TmpFNE1USmFGdzB6TURFeU1EY3dOakU0TVRKYU1ENHhFekFSQmdOVkJBb01
> DazE1UW5\
> 3448
> WemFXNWxjM014RFRBTEJnTlZCQWNNQkZOcGRHVXhHREFXQmdOVkJBTU1EM
> FJ2YldGcGJ\
> 3449
> sSmxaMmx6ZEhKaGNqQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJ
> QUJCazE\
> 3450
> 2S1wvaTc5b1JrSzVZYmVQZzhVU1I4XC91czFkUFVpWkhNdG9rU2RxS1c1Zm5Xc0J
> kK3F\
> 3451
> STDdXUmZmZVdreWdlYm9KZklsbHVyY2kyNXduaGlPVkNHamV6QjVNQjBHQTFVZ
> EpRUVd\
> 3452
> NQlFHQ0NzR0FRVUZCd01CQmdnckJnRUZCUWNESERBT0JnTlZIUThCQWY4RUJB
> TUNCNEF\
> 3453
> 3U0FZRFZSMFJCRUV3UDRJZGNtVm5hWE4wY21GeUxYUmxjM1F1YzJsbGJXVnVje
> TFpZEM\
> 3454
> 1dVpYU0NIbkpsWjJsemRISmhjaTEwWlhOME5pNXphV1Z0Wlc1ekxXSjBMbTVsZE
> RBS0J\
> 3455
> nZ3Foa2pPUFFRREFnTklBREJGQWlCeGxkQmhacTBFdjVKTDJQcldDdHlTNmhEWV
> cxeUN\
> 3456
> PXC9SYXVicEM3TWFJRGdJaEFMU0piZ0xuZ2hiYkFnMGRjV0ZVVm9cL2dHTjBcL2p3
> ekp\
> 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: [e-mail]
> 
> 3867	Authors' Addresses
> 
> 3869	   Steffen Fries
> 3870	   Siemens AG
> 3871	   Otto-Hahn-Ring 6
> 3872	   81739 Munich
> 3873	   Germany
> 3874	   Email: [e-mail]
> 3875	   URI:   https://www.siemens.com/
> 
> 3877	   Thomas Werner
> 3878	   Siemens AG
> 3879	   Otto-Hahn-Ring 6
> 3880	   81739 Munich
> 3881	   Germany
> 3882	   Email: [e-mail]
> 3883	   URI:   https://www.siemens.com/
> 
> 3885	   Eliot Lear
> 3886	   Cisco Systems
> 3887	   Richtistrasse 7
> 3888	   CH-8304 Wallisellen
> 3889	   Switzerland
> 3890	   Phone: [phone]
> 3891	   Email: [e-mail]
> 
> 3893	   Michael C. Richardson
> 3894	   Sandelman Software Works
> 3895	   Email: [e-mail]
> 3896	   URI:
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.san
> delman.ca%2F&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f49c
> 7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C
> 0%7C638127888888335207%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%
> 7C&sdata=ysm2AjHgU%2BsNKwNcusEb2xj6mTKwXXA6uGJrtFDuAbM%3D&reser
> ved=0
> 
> 
> 
> 
> 
> 
>