Subject: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 3 Aug 2020 05:52:58 +0000

> From: Toerless Eckert <[email-masked]>
> Sent: Donnerstag, 30. Juli 2020 18:32
 
> Right. So the question is keep it in the document or put it into a separate
> small one. The small one would allow other derivative work not to have to
> have BRSKI-AE as a normative reference, which may be better if its got
> nothing to do with BRSKI-AE.
> 
> I guess we can delay the decision up to the point when we do see such other
> derivative work coming up, and then decide whether to separate out the
> new /brski naming from the doc. As long as there is no such additional doc,
> we keep things in BRSKI-AE as they are right now.

>From my perspective the endpoint naming is independent from BRSKI-AE and we basically came to the discussion based on the illustrative example for the discovery option in BRSKI-AE.  So keeping it in BRSKI-AE and making it independent upon further need also works. We may reuse the text then for a separate document if necessary.
I conclude that the WG is in favor of this way.

Best regards
Steffen

> 
> Cheers
>     Toerless
> 
> > Eliot
> >
> > > On 30 Jul 2020, at 17:46, Fries, Steffen <[email-masked]>
> wrote:
> > >
> > > Hi,
> > >
> > > Based on the discussion of splitting up the voucher handling endpoint
> naming issues from BRSKI-AE today, I just wanted to ensure I got the way
> forward right.
> > > From the Etherpad discussion I understood Michael that he would not be
> too happy with having a BRSKI update right after BRSKI publication as RFC. I
> think finalizing the discussion on the list was advised.
> > >
> > > What we discussed in the WG meeting was to have a separate short
> document, basically defining a renaming or alternatively an alias for the
> current endpoints, which allows to keep the current implementations as is.
> > > Hence, the draft would relate to all of the endpoints defined in section 5
> of BRSKI for the domain registrar facing the pledge (and potentially also the
> MASA), which are:
> > > /.well-known/est/requestvoucher	used by pledge to registrar but also
> from registrar to MASA
> > > /.well-known/est/voucher_status	used by pledge to registrar
> > > /.well-known/est/requestauditlog	used by registrar to MASA
> > > /.well-known/est/enrollstatus		used by pledge to registrar
> > >
> > > From Toerless I understood that he would like to not change the current
> draft as it is already in the final state and rather provide an update as
> separate document.
> > > From Michael I understood he would not be keen on having a fast update
> for the BRSKI document. At least not for a renaming of the defined
> endpoints. Also the IESG may view this as too fast.
> > > Eliot stated that there are already implementations out there that utilize
> the /est approach. So having aliases could be one way of dealing with it, but
> this would double the endpoints at least for the four stated ones above.
> > >
> > > Both approaches have there merits. Having the endpoints distinct from
> the beginning allows a clearer separation of the functionalities, for the
> pledge and for server side handling. Specifically if we later on allow for
> alternative enrollment protocols in BRSKI-AE and define the discovery
> approach, it will lead to less confusion to align the naming with the
> corresponding functionality. From that perspective, my gut feeling would be
> that an integration into base BRSKI may be more appropriate. On the
> contrary, it will slow down the process, but somebody stated that there are
> examples that these changes have been also done in the past and could be
> done fast.
> > >
> > > What do you suggest as way forward?
> > >
> > > Best regards
> > > Steffen
> > >
> > >
> > > --
> > > Steffen Fries
> > > Siemens AG, Corporate Technology
> > > mailto:[email-masked]
> > >
> 
> --
> ---
> [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Aug 2020 07:46:03 -0400

Toerless Eckert <[email-masked]> wrote:
    > Maybe here is a good logic:

    > The short document would not need to be an Update as long as we do not
    > want to eliminate the old /est URLs.

okay, then let's not make the change at all, it's mostly cosmetic.

    > Aliasing should be easy enough.

Aliasing on the server sides (MASA, Registrar) is trivial.
But, the alias will have to remain for all time.

Aliasing on the client, which has to make a decision and possibly a discovery
is non-trivial.  This is why I want to do this *NOW*, or not at all.

In addition, it's clear that we need a registry here!

There are four questions:

1) do we really need to rename anything?
2) do we really need to Link Discovery for the HTTP version? (CoAP version
   already does it in ace-coaps-est)
3) is this a rename or an alias?
4) do we want to do this in (a) BRSKI base document, (b) short document, (c)
   BRSKI-AE document.

My answers:
1) No, I don't want to rename anything.  Let BRSKI-AE establish a new registry.

2) I don't want to Link Discovery, and I think it's harmful if BRSKI-AE
   proposes this rather than it being in the base document.

3) I see an alias as a waste of time. It's either a rename, or don't do it.

4) If we want to do this, then do it in the base document.
   Yes, with *ALL* the delay risk that Brian Carpenter mention.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Aug 2020 08:07:51 -0400

Hi Mark, this concerns some desired changes to /.well-known/est.

Specifically, to move the things we did in anima-bootstrapping-keyinfra out
of /.well-known/est into a new /.well-known/brski.
The WG has not concluded to do this as yet, as the above document has passed
IESG review and is in MISREF at the RFC-EDITOR.

The thread starts at:
   https://mailarchive.ietf.org/arch/msg/anima/jjusQdqzS3G4WbczolCxF0_YmQQ/

I have prepared sample changes which I'd like your opinion on.

1) I am now registering /.well-known/brski
2) I no longer need /.well-known/est to point to the new document.  Should I
   say this?
3) Am I creating the /.well-known/brski Registry correctly?
   I didn't see any other WK that have sub-registries.

This URL works:
  https://ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-41&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/brski-est-rename/dtbootstrap-anima-keyinfra.txt

But, includes a few small typos which were sent to the RFC-editor.

This should be the better DIFF:
  https://ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-42&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/brski-est-rename/dtbootstrap-anima-keyinfra.txt

but the DT/cache refuses to believe -42 exists yet, but maybe in 30 minutes
it will be okay.

---

From: "Fries, Steffen" <[email-masked]>
Date: Tue, 4 Aug 2020 17:08:05 +0000

Hi Michael,

Thank you for your view on the discussion and the proposals. 
 
> But, the alias will have to remain for all time.
Yes, that was the burden connected. 

> Aliasing on the client, which has to make a decision and possibly a discovery is
> non-trivial.  This is why I want to do this *NOW*, or not at all.
Agreed 

>    proposes this rather than it being in the base document.
Just to be sure I understand it right, the discovery of enrollment endpoints would still be part of BRSKI-AE? 
So what we added in section 5.3 of the latest BRSKI-AE is still necessary to my understanding?

> 3) I see an alias as a waste of time. It's either a rename, or don't do it.
Renaming would be the much clearer way forward in the light of multiple (different) enrollment endpoints supported at the registrar and the connected processing as discussed.

>    Yes, with *ALL* the delay risk that Brian Carpenter mention.
My take from the discussion so far regarding that point was rather reluctance regarding changes in the base document due to the connected delay, but as you stated, it would be the clean way. 

Best regards
Steffen

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 5 Aug 2020 09:25:04 +1000

> On 4 Aug 2020, at 10:07 pm, Michael Richardson <[email-masked]> wrote:
> 
> 

Sure, we have a process for that ;)  Easiest thing to do is to create an issue here:
  https://github.com/protocol-registries/well-known-uris

> 2) I no longer need /.well-known/est to point to the new document.  Should I

Yes. Best thing to do is to include it in the request above.

>   I didn't see any other WK that have sub-registries.

How you manage the namespace under your well-known URI is totally up to you. That looks reasonable to me, although if you don't think it's likely there will be additions for a while, you could just say 'update this document to register additional paths'.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2020 13:04:37 -0400

Thank you for the comments.

    > How you manage the namespace under your well-known URI is totally up to
    > you. That looks reasonable to me, although if you don't think it's
    > likely there will be additions for a while, you could just say 'update
    > this document to register additional paths'.

We have new drafts that we are considering adopting now.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Aug 2020 13:12:39 -0400

> Just to be sure I understand it right, the discovery of enrollment
    > endpoints would still be part of BRSKI-AE?

I frankly don't see the point of the discovery at all.

I understand the use case with CoAP, where one wants to be able to multicast
a request to /.well-known/core to find out which devices support a particular
service.
HTTP does not have the same thing, so I don't see the point of agility in the
end points if they are all in /.well-known anyway.

    > Renaming would be the much clearer way forward in the light of multiple
    > (different) enrollment endpoints supported at the registrar and the
    > connected processing as discussed.

If there is value in renaming, then lets do it RIGHT NOW.
I DO NOT WANT to confuse the market by having an RFC come out, followed by
another one 'correcting' it six months later.
I CAN NOT live with that situation.

    > My take from the discussion so far regarding that point was rather
    > reluctance regarding changes in the base document due to the connected
    > delay, but as you stated, it would be the clean way.

Do we agree that this rename is cosmetic?
It appeals to humans, computer code does not care in any way.
If the WG can tolerate the process risk, then it shouldn't be a problem.
If we can agree by the end of the week to do this, then the changes could be
approved in less than a week, if the ADs agree that this does not require a
new IETF LC.

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 6 Aug 2020 07:51:51 +0000

> From: Anima <[email-masked]> On Behalf Of Michael Richardson
> I understand the use case with CoAP, where one wants to be able to multicast a
> request to /.well-known/core to find out which devices support a particular
> service.
> HTTP does not have the same thing, so I don't see the point of agility in the end
> points if they are all in /.well-known anyway.
Agreed. As BRSKI-AE is intended to extend BRSKI and therefore uses HTTP, there is no need for a specific enhancement. The discovery using /.well-known will provide all available endpoints to the pledge, which then can evaluate the response. From an application perspective I would expect that the pledge may not support multiple enrollment approaches and simply try whatever he supports. The domain registrar would be the more capable component to support multiple options. 
For the constraint case (not contained in BRSKI), the discovery of specific endpoints is more important to not overload the pledge.   
Based on that, I would propose to update the example in section 5.3 of BRSKI-AE to list only /.well-know instead of the currently stated /.well-know/brski. 

> I CAN NOT live with that situation.
As stated before, the value from my understanding is more clarity (distinct naming) regarding the provided services/endpoints.

> approved in less than a week, if the ADs agree that this does not require a new
> IETF LC.
As this is essentially a name change and does not change the functionality of BRSKI I would assume that there is no need for an new IETF LC, which would slow down publication. With that assumption in mind, I would be in favor. 

Best regards
Steffen
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Aug 2020 08:53:47 -0400

> Agreed. As BRSKI-AE is intended to extend BRSKI and therefore uses
    > HTTP, there is no need for a specific enhancement. The discovery using
    > /.well-known will provide all available endpoints to the pledge, which
    > then can evaluate the response. From an application perspective I would
    > expect that the pledge may not support multiple enrollment approaches
    > and simply try whatever he supports. The domain registrar would be the
    > more capable component to support multiple options.

Can you explain to me why the discovery via /.well-known/brski is useful?
This is on the *REGISTRAR*.

In reading BRSKI-AE, I seem to be missing any place where the PUSH mechanism
is described.  In a PUSH use case, what protocol would the pledge expose to
the pledge-agent and/or commissioner?
As far as I can tell, in the PULL case, when CMP (or another mechanism) will
be used, there is still a voucher exchange first.  The Registrar can express
it's preference in the (parboiled) voucher-request from Registrar to MASA.

The MASA, if the pledge supports the desired enrollment protocol, could
include the hint.  In fact, the MASA could include an entire URL with
meta-data about the protocol to use.

This would jive very nicely with the brski-cloud mechanism!!!

    > For the constraint case (not contained in BRSKI), the discovery of
    > specific endpoints is more important to not overload the pledge.

I don't understand this at all.  What do you mean, overload the pledge?
Are you talking about network or code space or what?

    > As stated before, the value from my understanding is more clarity
    > (distinct naming) regarding the provided services/endpoints.

yes, but that's a cosmetic issue.
it appeals to humans, but it makes no technical difference.
Nevertheless, if we can do this quickly, then let's do it.
I've provided proposed text in the form of a diff, the ADs have agreed to a
process, the chairs , just need to run it.

I hope that your(Siemens) Thomas Werner will comment.

---

From: "Fries, Steffen" <[email-masked]>
Date: Wed, 19 Aug 2020 13:29:04 +0000

> From: Michael Richardson <[email-masked]>
The intention was to let the pledge or the pledge-agent know in advance what enrollment options are available at the registrar side allowing the pledge to fail fast if it does not have a matching enrollment protocol. For the original BRSKI, this is not the case, as both sides support the same feature set. In BRSKI-AE allowing alternative enrollment protocols, the registrar may support multiple different ways. To avoid make support for specific protocols mandatory on the registrar side, discovery of supported options was intended. Based on the discussion we had after the last meeting I think the discovery of /.well-known/ would be sufficient.

> In reading BRSKI-AE, I seem to be missing any place where the PUSH
> mechanism is described.  In a PUSH use case, what protocol would the
> pledge expose to the pledge-agent and/or commissioner?
This is currently left outside in terms of the protocol. The intention was to only specify the necessary (signature wrapped) data objects to be exchanged, to be open regarding the underlying transport between the pledge and the pledge-agent. This also would allow to use an arbitrary pledge-agent, but this is up for discussion. I'm currently thinking about the necessity to be able to authenticate the pledge-agent using an LDevID, if we solely rely on the objects. Authentication could also be done using HTTP authentication merely to authorize the pledge-agent to act as proxy between the pledge and the registrar. 

> be used, there is still a voucher exchange first.  The Registrar can express it's
> preference in the (parboiled) voucher-request from Registrar to MASA.
PULL was meant to describe the behavior of the pledge to start the onboarding while PUSH was more the trigger from the pledge-agent.
As the enrollment is between the pledge, the registrar, and the CA, I would not see a need to include this information in the voucher. This should be done as outlined in BRSKI. 
> include the hint.  In fact, the MASA could include an entire URL with meta-
> data about the protocol to use.
> 
Hm, haven't though about this. In case of standard BRSKI I would not see a need, as it would be handled by the domain registrar, but in case of the cloud registrar, it would provide the option to point to the right domain registrar supporting the enrollment. 

> Are you talking about network or code space or what?
I was referring to the discovery of specific endpoints. In case of /.well-known the registrar would deliver all endpoints including their options supported, while in case of asking for a specific endpoint only delivers the specific options of that endpoint. What I meant to say was that the pledge only gets the necessary information about the endpoints he needs not all. So it would relate to the processing on the pledge. 

> process, the chairs , just need to run it.
It may be cosmetic, but it would be consistent regarding the functionality provided by the specific endpoint if alternative enrollment options are used.  

> I hope that your(Siemens) Thomas Werner will comment.
I will give him a trigger ;-)

Best regards
Steffen

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 20 Aug 2020 06:38:44 +0000

Hi Michael,
> > As far as I can tell, in the PULL case, when CMP (or another
> > mechanism) will be used, there is still a voucher exchange first.  The
> > Registrar can express it's preference in the (parboiled) voucher-request
> from Registrar to MASA.
> PULL was meant to describe the behavior of the pledge to start the
> onboarding while PUSH was more the trigger from the pledge-agent.
> As the enrollment is between the pledge, the registrar, and the CA, I would
> not see a need to include this information in the voucher. This should be
> done as outlined in BRSKI.
> >
> > The MASA, if the pledge supports the desired enrollment protocol,
> > could include the hint.  In fact, the MASA could include an entire URL
> > with meta- data about the protocol to use.
> >
> Hm, haven't though about this. In case of standard BRSKI I would not see a
> need, as it would be handled by the domain registrar, but in case of the cloud
> registrar, it would provide the option to point to the right domain registrar
> supporting the enrollment.
I had some further thought on this. I think it would fit to the cloud registrar to the described option 3 in the current draft. If the voucher definition is enhanced with the local RA info, the enrollment options could be provided as well, allowing the pledge to pick the supported one and perform the enrollment. 

If the hint about the protocol support would be included by the MASA to inform the registrar, it may be limited to the  MASA as defined in BRSKI. I'm not sure how this would work with the delegated voucher approach, as the DASA may not know the device capabilities. 
If the voucher definition would be enhanced in case of the cloud registrar, it may also be possible to enhance the voucher request definition, to allow the registrar to populate the information from the domain registrar to the MASA and repeat all options or suitable enrollment options in the voucher (response) provided to the pledge.  

Best regards
Steffen

---

From: "Werner, Thomas" <[email-masked]>
Date: Wed, 26 Aug 2020 15:40:24 +0000

Hi Michael,

as already stated the renaming of the endpoints is just a cosmetic issue, machines would not care about.
Nevertheless as this came up now, I think the proposed changes are fine and should be included as you already outlined:
- https://ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-42&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/brski-est-rename/dtbootstrap-anima-keyinfra.txt 
- https://ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-41&url2=https://raw.githubusercontent.com/anima-wg/anima-bootstrap/brski-est-rename/dtbootstrap-anima-keyinfra.txt 

Summary for renaming:
1) /.well-known/est/requestvoucher    [used by pledge to registrar but also from registrar to MASA]
    --> /.well-known/brski/requestvoucher
2) /.well-known/est/voucher_status    [used by pledge to registrar]
  --> /.well-known/brski/voucher_status
3) /.well-known/est/requestauditlog   [used by registrar to MASA]
  --> /.well-known/brski/requestauditlog
4) /.well-known/est/enrollstatus          [used by pledge to registrar]
  --> /.well-known/brski/enrollstatus

Note: 
This changes should be also adopted by: https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-08 
With the result of two more characters "/est/" --> "brski", maybe the draft-ietf-anima-constrained-voucher should shrink this part to something like  "/br/", "/brs/", "bki"?

Best regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Anima <[email-masked]> Im Auftrag von [ext] Fries, Steffen
Gesendet: Mittwoch, 19. August 2020 15:29
An: Michael Richardson <[email-masked]>
Cc: [email-masked]
Betreff: Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

> From: Michael Richardson <[email-masked]> Fries, Steffen 
> <[email-masked]> wrote:

> Registrar can express it's preference in the (parboiled) voucher-request from Registrar to MASA.

> I've provided proposed text in the form of a diff, the ADs have agreed 
> to a process, the chairs , just need to run it.

Best regards
Steffen

_______________________________________________
Anima mailing list
[email-masked]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fanima&amp;data=02%7C01%7Cthomas-werner%40siemens.com%7Cff1afabca2014c1fa20208d84443e0f9%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637334405616918902&amp;sdata=cL0Aa22O9Ef7QYWEEME%2Bvjb5aRTj%2BGxhlCYqfWBuUoY%3D&amp;reserved=0

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Aug 2020 15:39:42 -0400

Werner, Thomas <[email-masked]> wrote:
    > as already stated the renaming of the endpoints is just a cosmetic
    > issue, machines would not care about.  Nevertheless as this came up
    > now, I think the proposed changes are fine and should be included as
    > you already outlined: -

okay.

    > https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-08
    > With the result of two more characters "/est/" --> "brski", maybe the
    > draft-ietf-anima-constrained-voucher should shrink this part to
    > something like "/br/", "/brs/", "bki"?

yes, something like that, I agree.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Aug 2020 15:42:32 -0400

Fries, Steffen <[email-masked]> wrote:
    >> Can you explain to me why the discovery via /.well-known/brski is
    >> useful?  This is on the *REGISTRAR*.

    > The intention was to let the pledge or the pledge-agent know in advance
    > what enrollment options are available at the registrar side allowing
    > the pledge to fail fast if it does not have a matching enrollment
    > protocol.

I understand this need, but it seems that we are making the pledge more
complex in order to keep the registrar simpler.  That makes no sense to me:
the pledge should be minimal, while the registrar can remain complex.

    > This is currently left outside in terms of the protocol. The intention
    > was to only specify the necessary (signature wrapped) data objects to

I'd really like to have the PUSH part in scope.
I thought that it was just not done yet, but it seems to me that without the
PUSH part, that the protocol isn't async at all.  It is just BRSKI-CMP.

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 27 Aug 2020 12:56:35 +0000

> -----Original Message-----
> Sent: Mittwoch, 26. August 2020 21:43
> 
Maybe I phrased it wrong. The intention is not to make the pledge more complex. The goal should be to keep the pledge simple and enhance the registrar to handle also other situations like unavailability of certain connections. The registrar should be the more capable component. The discovery was intended in situations, in which the registrar supports multipole options, but not all may be mandatory supported. In this case the discovery would help. Otherwise the pledge may do trial and error.

> PUSH part, that the protocol isn't async at all.  It is just BRSKI-CMP.
Async was meant that connectivity to certain components is not available at the time of the onboarding. For use case 1 it would be the issuing PKI and in use case 2 the registrar. To handle this signature wrapped objects were introduced. One way of addressing this during enrollment is using protocols supporting signature wrapped objects like CMP or EST with fullcmc as outlined. The goal is to be protocol agnostic. This was also a reason for the discovery option. 
Regarding PUSH. As outlined in BRSKI-AE section 5.2.4 the pledge would be queried by the pledge-agent for certain objects. It was intended to have it in the current document. The current description assumes that it would be sufficient to define just the signature wrapped objects to be exchanged between the pledge-agent and the pledge and not the transport of these objects to be open regarding the underlying media. This would allow to use the functionality of the domain registrar via the pledge-agent, even of the pledge utilizes a different network stack. But maybe this is to far fetched and it is easier to concentrate on the currently assumed pledge capabilities (in BRSKI) to do HTTP as a starting point. I think that this needs further discussion. Do you have a concrete use case in mind, which should be addressed?

Best regards
Steffen

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Aug 2020 14:32:19 -0400

> Maybe I phrased it wrong. The intention is not to make the pledge more
    > complex. The goal should be to keep the pledge simple and enhance the
    > registrar to handle also other situations like unavailability of
    > certain connections. The registrar should be the more capable
    > component. The discovery was intended in situations, in which the
    > registrar supports multipole options, but not all may be mandatory
    > supported. In this case the discovery would help. Otherwise the pledge
    > may do trial and error.

While I appreciate the idea of having the pledge fail faster, and go onto to
the next possible registrar, I think that the pledge should support one and
only one mechanism, and it's up to the registrars to keep up.

If we are doing proper ACP ANIMA, then we can include the enrollment options
for the Registrar into the GRASP DULL announcement, and this can inform the
pledge's decision as to which Registrar to pick.

    > Async was meant that connectivity to certain components is not
    > available at the time of the onboarding. For use case 1 it would be the
    > issuing PKI and in use case 2 the registrar. To handle this signature
    > wrapped objects were introduced. One way of addressing this during
    > enrollment is using protocols supporting signature wrapped objects like
    > CMP or EST with fullcmc as outlined. The goal is to be protocol
    > agnostic.

I don't yet understand how the voucher-request is done in async BRSKI.
I thought that was what we were doing.. I have many ideas about this.

    > This was also a reason for the discovery option.

I don't think it helps.

    > Regarding PUSH. As outlined in BRSKI-AE section 5.2.4 the pledge would
    > be queried by the pledge-agent for certain objects. It was intended to

But, how is it queried?

    > have it in the current document. The current description assumes that
    > it would be sufficient to define just the signature wrapped objects to
    > be exchanged between the pledge-agent and the pledge and not the
    > transport of these objects to be open regarding the underlying
    > media. This would allow to use the functionality of the domain

okay, so I'm very interested in helping define this well enough to be used.

    > registrar via the pledge-agent, even of the pledge utilizes a different
    > network stack. But maybe this is to far fetched and it is easier to
    > concentrate on the currently assumed pledge capabilities (in BRSKI) to
    > do HTTP as a starting point. I think that this needs further
    > discussion. Do you have a concrete use case in mind, which should be
    > addressed?

Well, I thought that the furnace in the basement where there is no
connectivity was a really good use case.
The furnace installer has a smartphone or dedicated comissioning device.

As for HTTP: I would tend to suggest that we should use CoAP.
This works over WIFI as well as other technologies, and convergence here
would be good.

---

From: "Fries, Steffen" <[email-masked]>
Date: Mon, 31 Aug 2020 14:41:11 +0000

Hi Michael,

> Sent: Freitag, 28. August 2020 20:32
Yes, this keeps the pledge simple, but would require the registrar to implement the other options mandatorily.

> 
> If we are doing proper ACP ANIMA, then we can include the enrollment
> options for the Registrar into the GRASP DULL announcement, and this can
> inform the pledge's decision as to which Registrar to pick.
This would also be an option for a  discovery, but I have to dig deeper into GRASP.

> I don't yet understand how the voucher-request is done in async BRSKI.
I realize more an more that a pure "request-object" without considering the transport is probably too abstract. Implementing requires also the transport. 
> I thought that was what we were doing.. I have many ideas about this.
Yes, voucher-request and also certification-request would be collected by the pledge-agent. Good to hear you have ideas here, as we need to define the approach more precisely. 

>     > be queried by the pledge-agent for certain objects. It was intended to
The pledge essentially must be able to listen for the request. In industrial environments the embedded device is most often in a server role waiting for requests. This would have to be leveraged also for the PUSH interaction. 

> okay, so I'm very interested in helping define this well enough to be used.
That sounds great. Your support is greatly appreciated here.. 
> The furnace installer has a smartphone or dedicated comissioning device.
This was one of the point I concluded form the last meeting. The trust assumptions about the pledge and pledge-agent interaction is one of the points to be discussed further. 

> This works over WIFI as well as other technologies, and convergence here
Which may bring it closer to the constraint voucher than BRSKI. I was looking for the latter, hence HTTP as proposal. But this is open for discussion.

Best regards
Steffen