> -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Mittwoch, 26. August 2020 21:43 > > Fries, Steffen <[email protected]> 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. 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.
> >> 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 > > 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. 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 > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
