Brian E Carpenter <[email protected]> wrote: > We would prefer that this doesn't invalidate existing (unsigned) GRASP > code. That could be done by appending an optional signature to the > existing M_FLOOD message format. An alternative is to add a new flood > format that is signed, but would not be understood by existing code.
A third option is that we make what might be a breaking change.
A subject of some debate has been whether some of the proposed changes are in
fact breaking changes to the spec, or just to how some code (mis)-intrepreted
the spec.
At this point, my opinion is that we do not have enough GRASP deployment for
this to matter. I think that having signed M_FLOOD messages, even if they
are inside a protected ACP, is a sufficiently useful thing that we should
just do that.
I have one use case that involves Information Centric Networking (ICN) inside
of an ACP.
> 3. It seems fairly obvious that we should use COSE, most likely with a
> detached payload, so that the M_FLOOD message appears unsigned for
> nodes that don't support signing and verification.
One possible breaking change would be to use COSE in non-detached payload mode.
> 4. We don't claim to have solved the general problem of key
> distribution for multicast destinations, but in the ACP context it
> seems likely that we can flood out the necessary public keys.
I feel confident that for a number of use cases that this won't be an issue,
and that we can leverage the BRSKI enrollment process to get any application
specific keys that we need.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
