At Sat, 9 Oct 2010 00:16:22 +1100, Geoff Huston wrote: > > I assume that in addition to the CMS requirement that: > > "The signing-time attribute MUST be present"
Yes. > there is an additional requirement that reads (approximately) > > "Each party MUST ensure that the signing-time attribute value is > strictly greater than the signing-time attribute value of the > previous message sent to the same recipient. Messages received with > a signing-time value less than that of the most recently received > and accepted message from the same sender MUST be rejected." Close. I think the proposal was that the signing time attribute must be greater than or equal to the signing-time attribute of previous messages sent by the same originator to the same recipient. "Greater than or equal to" vs "strictly greater than" is important, and is a tradeoff. The advantage is that it removes the problem of unintended rate limiting to one message per second (don't really know if that's a real issue, but in theory it might be). Disadvantage is that it leaves one open to replay of the latest message, but with the protocol as currently written, I haven't been able to think of anything evil an attacker could do by replaying the most recent message, and it's easy for the sender to add one-second delays (if neede) to the middle of a command stream that really should not be inverted. So greater-than-or-equal-to seems right to me. There probably should also to be a note somewhere stating that there must be -some- way (even if only manually typing SQL commands, that's an implementation detail) for an operator to reset this value, to handle the case where a sender accidently signs with a time far in the future (read: "wait two years and call me in the morning" is not the preferred answer from the help desk in such cases). _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
