Hi Michael, > -----Original Message----- > From: Michael Richardson <[email protected]> > 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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
