Fries, Steffen <[email protected]> wrote: >> > 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.
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.
>> 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 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.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
