On 25-Aug-22 08:57, Michael Richardson wrote:
Carsten Bormann <[email protected]> wrote:
> That is getting closer to my question “what does it mean for
> (something) to be signed”?
> Apparently, this is a statement from an initiator, valid within the
> session-id, optionally scoped to the locator option, and expressed in
> the objective. These four are picked out of the message. The
> mechanism is specific to M_FLOOD and needs to be re—done for any other
> message type.
> The signed-data is missing a freshness component, which is either an
> absolute timestamp (like CWT exp, possibly enhanced with nbf/iat info)
> or an epoch marker.
Yes. Toerless thinks it might be contained in the session-id, but I've been
sitting on the fence about that.
Well (as you can see in Toerless's proposal) the tuple {session-id, initiator}
needs to be included, because theoretically two initiators could generate
the same pseudo-random session-id.
I need to understand epochs a bit better. I wonder whether an epoch boundary
should define when session-id repetition becomes OK (even if highly improbable).
There's a practical argument for that: a good implementation will cache
obsolete session-ids to detect repetition, but needs to age out that cache
somehow. My code does that with a simple LRU but that isn't ideal.
Brian
> We want the objective to stand alone for forward compatibility; hence
> the signature would have a detached payload.
> What I don’t understand is why the signature then needs to be encoded
> as part of the objective. Why can’t I sign a combination of objectives
> that are only valid as that combination?
I think it could go somewhere else, but I'd like to first understand an
example of this combination.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
