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.
> 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
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
