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

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

Hi Michael,

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: Freitag, 28. August 2020 20:32
>     > 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.
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'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.
> 
>     > 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 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. 

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

> 
>     > 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.
That sounds great. Your support is greatly appreciated here.. 
> 
>     > 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.
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. 

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


> 
> --
> Michael Richardson <[e-mail]>ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>