[Anima] Reply2, 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



I just realized that I had not send the proceeding with the reaction on comments starting from where I left in my last reply.

Note that some of the issues have also been addressed by the Shepherd review and are currently being addressed. Specifically a restructuring of section 5 and 6 is planned to increase readability and to simplify the description and increase readability.



As before, I created issues on gitlab for the major issues for better tracking and commented inline.

And again, thank you for the thorough review



Best regards

Steffen





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

[stf] good point, changed



>

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

>

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

[stf] done



>

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

[stf] yes, it makes sense to use the definition from RFC 5272 and not redefine it. I would add this to the terminology section and used the abbreviations in the remaining part.





>

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

[stf]: changed to

Pledge-Voucher-Request is a request for a voucher sent to the Registrar.

The PVR is signed by the Pledge.

>

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

done

>

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

[stf] Great. Included as suggested,





>

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

Not necessarily. But the sentence was not really describing that. Changed to

BRSKI-PRM is applicable to environments where pledges are in pledge-responder-mode and may have no continuous connection to a domain registrar.





>

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

>

> direct and/or continuous connection ?

See above





>

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

As discussed in the design Team meeting, it may be a different registrar-agent but as the pledge is assigned to a specific domain, the expectation is it would always be the same registrar. If that registrar supports both, BRSKI and BRSKI-PRM is left out of scope on purpose.





>

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

Good point took define

>

> 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

Okay, reworded to be non-normative text and wording:



A pledge in pledge-initiator-mode should listen for announcement messages as described in {{RFC8995, Section 4.1}}.  Upon discovery of a potential Registrar, it initiates the bootstrapping to that Registrar.



>

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

Reworded as stated in the previous comment.





>

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

Well, that must have been the influence of " simpleenroll" and "simplereenroll" from EST.

Changed to:

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







>

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

>

> BRSKI-PRM defined <qualifier> enpoints ?

Changed to :

If it still acts as server, the defined BRSKI-PRM endpoints to trigger a Pledge-Enrollment-Request (PER) or to provide a enrollment response can be used for further certificates.



>

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

Done



>

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

Good point, added:

The registrar-agent, defined in this document, may be run on the technician's laptop to interact with pledges.



>

>

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

I tried to address this point by including the following (kept it as limitation as there are other challenges that the draft addresses more directly. Also it was addressing https://github.com/anima-wg/anima-brski-prm/issues/10):

Added:

To overcome this situation, the pledges may need to be powered on, either manually or by sending a trigger signal.



>

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

Simplification is ongoing, also, some issues have been addressed through the Shepherds review





>

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

Will be taken into account



>

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

Well, the verification would be done based on the agent-signed data, which is an object provided by the registrar-agent, forwarded by the pledge. So the registrar can verify which component triggered that action. This was required based on the discussion we had in the Design Team





>

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

Good point. Taken.



>

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

Proposal to change it to "the MASA issues"  with a reference to RFC 8995



>

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

Already addressed in current version





>

>

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

What the paragraph tries to get across is that a signed object such as a PKCS#10 request alone is not sufficient, if there is no POI. BRSKI achieves this by using the authentication in TLS while BRSKI-PRM does it with an additional signature invoking the IDevID



>

>

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

No, the main point is that a pledge behaves as a server and waits for being triggered to do something. This reverses a lot of communication and requires a different approach. In addition we wanted to not rely on communication security as provided by TLS to be able to apply the same approach over other media like BTLE.



>

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

Based on the Shepherd review, we will have a discussion and restructuring to better distinguish into sections for the requirements, the communication and the data objects. This should ease the understanding.

>

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

Done



>

> 512        constrained environments it may provided based on COSE

> [RFC9052] and

>

> s/may/may be/

Done



>

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

In the latest updated we already addressed that point by stating that in BRSKI-PRM the join proxy is neglected but may be used to help the registrar-agent finding the registrar.



>

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

>From an architecture point of view we did not make this distinction. The domain components are intended to reflect the "static" components already belonging to the domain that help the pledge to connect or be connected to the domain. We deliberately aligned with the BRSKI picture to show the similarities. The difference is provided by the registrar-agent, which allows this on-site/off-site functionality by reversing the communication direction to the pledge.



>

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

Okay, will take this into account in the next revision



>

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

Hm, as the security is bound to the objects, is it helpful to provide this information here again? We already a similar statement that we do not rely on transport security in the requirements and also in the introduction.





>

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

Basd on the Shepherd review we changed it to MUST, with a reference to the specifying section

>

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

If the pledge issues a PER and never receives a certificate it may not communicate in the target domain. When the PER is used for an attack, it still has the signature of the pledge with the IDevID and the signature with the private key corresponding to the public key contained in the PER. To leverage this, an attacker would need at least the corresponding private key.

Also, when the registrar-agent returns with the voucher and the enrollment response (certificate), there is a specific order of steps before the domain certificate in the voucher, the registrar certificate and the own certificate is verified and accepted.





>

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

As stated before, meanwhile we also head the Shepherd review pointing to the structural issue. That said, we will have a discussion and restructuring to better distinguish into sections for the requirements, the communication and the data objects.





>

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

Not sure I get the point here. BRSKI-PRM between the registrar-agent and the registrar is intended to transport the signed objects using BRSKI means but via different endpoint to cope with the additional signature.



>

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

Has been done already



>

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

The requirement to know which registrar-agent actually did the onboarding was a very early requirement raised in the Design Team (https://github.com/anima-wg/anima-brski-ae/issues/1). Note that this was at the time before the split of the BRSKI-AE draft.



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

The registrar-agent is not required to have specific attribute in its certificate. It needs to be recognized as authorized entity by the registrar. This could be done in different ways like an attribute but also by using a specific subCA issuing only certificates for registrar-agents or similar. So it depends on the actual deployment. We described the subCA part in the verification section 6.2.3

>

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

For the discovery of the registrar by the registrar- agent we already have an issue in the ANIMA github: https://github.com/anima-wg/anima-brski-prm/issues/79

Also, The join proxy is stated to be not sed between the pledge and the registrar-agent but may be used between the registrar-agent and the registrar as outlined in #79



>

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

It is not stated, that a join proxy is not used. A registrar-agent may use it to connect to the right registrar.



>

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

It was intended to describe a domain registrar supporting both, BRSKI and BRSKI-PRM.  Proposal to change it to

A registrar with combined functionality of BRSKI and BRSKI-PRM detects if the bootstrapping is performed by the pledge directly (BRSKI case) or by the registrar-agent (BRSKI-PRM case) based on the utilized credential for authentication (either pledge's IDevID or LDevID from registrar-agent) .





>

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

Will be included in the next revision



>

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

Yes will include that it is in the PVR and the voucher

>

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

>

> "proximity registrar certificate" ???

Proposal to change to just "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 ???

The intention was to provide a statement, that the registrar certificate was received indirectly by the pledge. As the MASA is able to verify the chain: pledge -> registrar-agent -> registrar by the RVR the MASA has evidence that the pledge at least was in that domain.





>

>

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

This could be addressed by the restructuring. The approach you are referring to is exactly what is described in section 6. We will keep track of it.





>

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

Yes, this is as in BRSKI, the registrar should possess information which pledges to onboard either by serial number or by vendor.

This is described in section 6.2.2 with a reference to RFC8995.





>

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

Yes, this may be again a point for the restructuring, as the handling of the agent-proximity assertion is addressed in section 6.2.3 and 6.2.4





>

>

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

Okay, to be handled during restructuring,´. As the note in which this text occurs does not really contribute to the explanation of agent-proximity, we may move it to a better place in the document. Section 6.1.1 actually handles it.







>

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

Okay, will be included.



>

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

Okay, noted. It was done in this way to explain the changes first and then relate them to the existing BRSKI approach.





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

PoP is done by the pledge, based on the received registrar certificate and later the voucher, which has an additional signature



>

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

Text adapted and to be included:

In BRSKI, the pledge verifies POP of the LDevID by the registrar via the TLS handshake and 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. Until the pledge receives the voucher, the registrar certificate is accepted provisionally.

In contrast, in BRSKI-PRM, the pledge has no direct connection to the registrar and takes the LDevID provided by the registrar-agent from the Trigger PVR message and include it into his PVR. This allows not only the MASA, but also the registrar to decide whether or how to proceed with the BRSKI-PRM PVR. In a similar fashion, the pledge accepts the registrar certificate provisionally until it receives the voucher as described in Section 6.3. See also [RFC8995] "PROVISIONAL accept of server cert".



>

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

We utilized EE certificate to underline that it is an end entity certificate, but this can also be underlined by using LDevID as suggested.



>

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

Thanks for the background. Yes, the assumption would be that pledges can mutually authenticate later on when bootstrapped and onboarded.



>

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

Yes, this is why we use "authenticated self-contained object". The additional signature with the IDevID credential provides that.

It is explained in the terminology.



>

> 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

> ??

Yes. Will change to

The pledge is triggered by the registrar-agent to generate the PVR and PER. It will also be triggered for processing of the responses and the generation of status information one the registrar-agent has received the responses from the registrar later in the process.







>

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

correct

>

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

Was designed as in BRSKI to have the same "approach"



>

> 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

> .example.com%2F.well-

> known%2Fbrski&data=05%7C01%7Csteffen.fries%40siemens.com%7Ce9764f

> 49c7fb4b59efdd08db15ef1519%7C38ae3bcd95794fd4addab42e1495d55a%7C

> 1%7C0%7C638127888888179293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM

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

The problem with https here is that the pledge needs a TLS server certificate, which is does not possess at this point in time. The inability to do this, is explained in the section afterwards.





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

The plaintext connection between the pledge and the registrar-agent is addressed in the privacy consideration section.





>

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

As stated above, this is the problem, that the pledge does not possess a usable certificate for TLS server authentication. It would require to change the TLS processing to not perform the name to domain mapping.



>

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

Okay, will take suggested endpoint names.



>

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

okay

>

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

This mapping should be clear by naming but may be included



>

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

Okay





>

> 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

This was only to make "registrar" appear italics in html. Will be removed.





>

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

Was aligned with BRSKI. But we could use endpoint here.







>

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

We aligned in the first place with BRSKI and did not use shorter names. This is left to constraint BRSKI for now.





>

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

Yes



>

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

It is used to identify the registrar-agent involved in the bootstrapping.





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

Yes, the LDevID(RegAgt) is usd to authenticate towards the registrar. If the registrar-agent breaks as in your example, the original provided responses can still be used. BTW, the ability to use other certificates for the registrar-agent is also considered by the remark on using short-lived certificates just below.



>

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

The reason for using the SKID here was to avoid the provisioning of the LDevID(RegAgt) to the pledge, specifically for the constraint case.

Proposal to enhance justification to

" In BRSKI-PRM, the SKID is used in favor of providing the complete LDEVID(RegAgt) certificate to accommodate also constraint environments and reduce bandwidth needed for communication with the pledge. In addition, it follows the recommendation from BRSK to use SKID in favor of a certificate fingerprint to avoid additional computations."



>

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

This is to be seen in connection to the PVR processing, not for the PER processing. We already have an own endpoint for providing the wrapped PER on the registrar . Opened issue https://github.com/anima-wg/anima-brski-prm/issues/86





>

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

This also relates to Issue #86 stated above. BRSKI and BRSKI-PRM use different certificates for the authentication to the registrar.



>

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

Addressed in version 08





>

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

This is a configuration precondition for the registrar-agent. It may get a list of serial numbers or expected IDevIDs.



>

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

It is described two sentences later, that it is provided by administration or via scanning





>

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

It is needed to identify that the registrar-agent is in contact with expected pledges (it is addressed further in section 5.3.2 on discovery)



>

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

It helps the registrar-agent and at the end the registrar, if he wants to authorize only dedicated pledges and not every pledge





>

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

Will be considered in the restructuring





>

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



815-817 were intended to underline the handling in BRSKI. Will be enhanced for clarification to

According to [RFC8995] section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the pledge voucher-request object. This behavior is retained also in BRSKI-PRM.



Proposal to rewrite 819 in the following way as we also allow discovery without a serial number:

The following information MUST be available at the registrar-agent before interaction with the pledge:

·        LDevID(RegAgt): own operational key pair (to sign agent-signed-data).

·        Registrar EE certificate: certificate of the domain registrar (to be provided to the pledge) .

The following information MAY be available at the registrar-agent before interaction with the pledge:

·        Serial-number(s): product-serial-number(s) of pledge(s) to be bootstrapped (to query discover specific pledges based on the serial number)





>

> 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

Refers to section 4, included.





>

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

Yes, considered in Issue #79

>

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

Hm, the extension "id-kp-cmcRA" actually is not evaluated by the registrar-agent. It acts in a similar way as the pledge in BRSKI. This extension is from interest for the next hop in the infrastructure as it shows the registrar is authoritive.



>

> This is inline with what we wrote in RFC8994/RFC8995 to authenticate

> registrar i think.

Yes, but on the infrastructure side of the registrar.

So no need for the hop to the registrar-agent. At the end the registrar/RA decides upon acceptance for the domain.

>

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

There is an ongoing discussion in https://github.com/anima-wg/anima-brski-prm/issues/80 which discusses the DNS-SD approach and if we have sub parameters or text parameters to describe further functionality.





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

Replaced with "The manufacturer may support this functionality as outlined in Section 10.4."





>

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

Considered in next update





>

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

I think going beyond the two short examples is too much for this document. I propose to reference EAP onboarding ()https://datatracker.ietf.org/doc/draft-richardson-emu-eap-onboarding/) here .



>

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

Okay, will delete the reference to RC8995 here



>

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

Will be included in next version







>

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

Hm, I'm a bit hesitant to add this as the first exchange involves data from the registrar-agent. So at least this step is not store and forward

>

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

No, the pledge cant this at this point in time. It was intended to allow the registrar to verify that an authorized registrar-agent has done the bootstrapping. This was the result of Issue #1 (https://github.com/anima-wg/anima-brski-ae/issues/1)

>

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

We tried to be open here as this is an implementation issue of the registrar-agent.







>

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

Okay, forward pointer is good. Will include reference to section 6.1 as it contains the preconditions.





>

>

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

It is the other way around, the registrar-agent signs the serial number of the pledge -> results in agent-signed-data -> send to the pledge -> signed by the IDevID -> send via registrar-agent to registrar. Registrar validates that pledge is the intended one and was in contact with authorized registrar-agent.







>

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

> the

>

> fetch from where ?

Changed to  " The registrar MUST provide the LDevID(RegAgt) certificate identified by the SubjectKeyIdentifier (SKID) in the header of the agent-signed-data from the PVR in its RVR (see also section 6.2.2)."

The important point is that the registrar needs to ensure that the corresponding registrar-agent is allowed for bootstrapping.





>

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

Good point, the certificate may be available via the TLS handshake already. In that case the registrar needs some means to ensure the certificated is trusted for a registrar agent. Alternatively, it may be provided via a repository. Is outlined in section 6.2.2





>

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

Yes, we stated that in section 6.1. But this leads to a simplification as covered by the new text proposed above: "The registrar MUST provide the LDevID(RegAgt) certificate identified by the SubjectKeyIdentifier (SKID) in the header of the agent-signed-data from the PVR in its RVR (see also section 6.2.2)."



>

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

No, the PVR is contained in the "prior-signed-voucher-request" field of the RVR added this in the parenthesis "(contained in the "prior-signed-voucher-request" field of RVR)"





>

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

Good point, will delete "instead of "proximity", as there is no direct connection between the pledge and the registrar."



>

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

Will be included in next version



>

> 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

Okay



>

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

Okay



>

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

Good idea, will be included



>

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

Good observation. The registrar-agent may possess the IDevID CA certificate. This was intended optional. If it has the IDevID CA certificate it could already verify the PVR. But the registrar will do the verification in any case. Opened new issue for tracking: https://github.com/anima-wg/anima-brski-prm/issues/87



>

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

Okay





>

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

Editorial thing, the registrar-agent SHOULD have synchronized time.





>

>

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

Will be considered in the restructuring





>

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

We did not include the verification of the registrar-agent by the pledge. The trust establishment is done with the registrar, therefore only the registrar certificate is verified, not the agent-signed-data.





>

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

Proposal to remove "excluding the ASN.1 encoding of "OCTET STRING" as the intention was to use only the value, but this is already state in the parenthesis.



>

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

The registrar is the one verifying the signature. We included the time here mainly for logging  on the infrastructure site as part of the signature created.



>

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

The serial number is included to support the verification on the registrar that a specific registrar-agent was in contact with the pledge. We than have the chain serial number -> agent-signed data -> PVR (signed with IDevID(Pledge) is be verified by the registrar. What was needed for that was some piece of data to be signed. As the registrar-agent in most cases is expected to know which pledges to bootstrap (hence the list for the discovery), we took the serial number. Using the serial-number seemed the natural approach as this would be the information the registrar-agent used for mDNS.



>

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

We tried to avoid sending the certificate chain to already address the constraint case. The registrar is expected to possess the information to validate the IDevID certificate. Made this an issue: https://github.com/anima-wg/anima-brski-prm/issues/88



>

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

Okay





>

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

Okay



>

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

>

Okay





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

> Media-type

>

> 1240      application/voucher-jws+json.

>

>

> 1242   replace ""

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

True, will be included



>

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

True, will be deleted



>

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

As we wanted to minimize the roundtrips between the pledge, registrar-agent, and the registrar we started with the generic cert.

The RA/CA may also include further attributes into the certificate as discussed on the LAMPS mailing list based on our question https://mailarchive.ietf.org/arch/msg/spasm/Cq8OdZrkFZSv_bNc3HQzxRfdIFA/



Proposal to include the following:

This document specifies the request of a generic certificate with no CSR attributes provided to the pledge. If specific attributes in the certificate are required, they have to be inserted by the issuing RA/CA. How the HTTP POST can be used to provide CSR attributes is out of scope for this specification.









>

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

Okay





>

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

okay

>

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

Yes, it is a MUST statement here.





>

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

Okay







>

> 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

Okay





>

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

It is included as note and should inform the reader only about the possibility that other formats provide the signature wrapping. As we utilize [I-D.ietf-netconf-sztp-csr] and only use the P10cr, the intention was to at least point to that difference



>

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

Yes, addressed in https://github.com/anima-wg/anima-brski-prm/issues/88



>

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

We avoided comments to make it parseable using standard tools. The second base64 indicates the optional certificate chain

>

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

>

Good point. It is a security policy decision of the registrar. Will include from your suggested text:

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



>

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

As stated above, will make this optional. https://github.com/anima-wg/anima-brski-prm/issues/87



>

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

Yes, will add "Same as in BRSKI" to the statement

>

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

Will include "(voucher signing key and certificate, TLS server certificate and private key)"



>

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

No. It was intended to point to the issuing CA certificate of the registrar. This enables the MASA to verify the registrar certificate





>

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

Good point, there is nothing different to BRSKI, will delete that part

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







>

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

Yes, see also https://github.com/anima-wg/anima-brski-prm/issues/86



>

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

Yes, it is a 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.

That text was initially intended for a registrar supporting both BRSKI and BRSKI-PRM.

Included your suggestion









>

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

Okay, good point





>

>

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

Yes, true





>

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

>

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

>

> remove SHALL.

Why not as SHALL statement? This is a mandatory step to perform

>

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

Will be addressed in the context of https://github.com/anima-wg/anima-brski-prm/issues/81



>

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

>

Thanks for sharing your thoughts. We included the SHOULD be used here to indicate that an application may also provide further or more fine grained responses.



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

Okay, agreed





>

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

>

Will take the proposal. Simplifies explanation.





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

Very important point. We will add the proposed text.



>

> (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').

Proposal to extend  "SHALL contain the following parameters as defined in [RFC7515]:"

To "SHALL contain the following parameters as defined in [RFC7515] to support JWS signing of the object:"







> 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

Would be section 5.5





>

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

We only had a statement that the serial number of the product corresponds with the X520SerialNumber in the IDevID.

The part here describes the required handling by the registrar





>

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

Will include proposed text. It better describes the action.



>

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

> the

>

> s/enhanced/extended/

Okay





>

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

Yes, corrected







>

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

Is it just the naming "agent-proximity" which makes you believe that there is a TLS connection? We took "proximity" here to underline that it is the same concept as in BRSKI, the pledge gets an artifact (the LDevID(RegAgt)) that it cn verify later on. As it was not provided directly but via an agent we picked the name agent-proximity.



>

>

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

Okay



>

> 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

> ^           ^^

Okay





>

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

Okay, created several issues around this (#81, #89)

>

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

Okay, thank you for the suggestion, will be included



>

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

Okay



>

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

Open a new issue for it: https://github.com/anima-wg/anima-brski-prm/issues/90

The additional signature was already motivated and included in Issue #15, here as optional but we made it mandatory later on based on the discussion of the provisional accept state.



>

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

Yes, up for discussion in https://github.com/anima-wg/anima-brski-prm/issues/90



>

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

This is an interesting case.

The intention was that the registrar-agent behaves like a pledge for the interaction with the registrar, with the exception, that he already has both request objects in place.  i.e.:

  *   Opens a TLS connection to the registrar
  *   sends the PVR
  *   waits for the voucher
  *   sends the PER in the same connection
  *   waits for the certificate

So it is intended to be handled all via the same https connection. The registrar-agent would wait until he receives all responses.



Proposal to enhance the first paragraph to:

After receiving the voucher, the registrar-agent sends the PER to the registrar in the same HTTPS connection similar as described for the PER processing in Section 5.2 of BRSKI.

Addressed in https://github.com/anima-wg/anima-brski-prm/issues/91







>

> 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

Okay, referred to Section 6.1.4



>

> 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

>