OK here is a suggested alternative wording which I think makes things a
little more explicit. I think the remaining cases (i.e. if all is valid
it SHOULD be accepted) are sufficiently obvious that no clarification is
needed.
- If the signature of the signed attributes is invalid or the value of
the signing time lies far in the future (that is, a
greater discrepancy than any reasonable clock skew) then the
list of capabilities MUST NOT be accepted.
- If the timestamp and the signature of the signed attributes is
valid but the messageDigest value is not valid then the receiving
agent SHOULD accept the list of capabilities.
- If the receiving agent has not yet created a list of capabilities
for the sender's public key, then, the receiving agent SHOULD
create a new list containing at least the signing time and the
symmetric capabilities.
- If such a list already exists, the receiving agent SHOULD verify
that the signing time in the incoming message is greater than
the signing time stored in the list. If so, the receiving agent
SHOULD update both the signing time and capabilities in the list.
Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)bigfoot(_dot_)com
PGP key: via homepage.