Evidence Record Syntax (ERS)
RFC 4998

Note: This ballot was opened for revision 15 and is now closed.

(Jari Arkko) Yes

(Russ Housley) (was Discuss) Yes

Comment (2007-05-22)
No email
send info
  From the Gen-ART Review by Brian Carpenter:

  At the end of section 4.2:
  >
  > The data (e.g. certificates, CRLs or OCSP-Responses) needed to verify
  > the timestamp SHOULD be stored in the timestamp itself or MUST be
  > preserved otherwise.
  >
  I find this insufficiently clear. When would it be acceptable not to
  store these data in the timestamp, and if not done so, how would the
  retriever know where to look?

  Just before section 5.1:
  >
  > After the renewal, always only the last, i.e. most recent
  > ArchiveTimeStamp and the algorithms and timestamps used by it must
  > be watched regarding expiration and loss of security.
  >
  This raises a general question - maybe this is well understood in LTANS,
  but RFC 4810 didn't clarify it for me. When a hash or crypto algorithm
  becomes "insecure" is not a well-defined moment. What is the triggering
  event for a Time Stamping Authority to decide to switch to a new
  algorithm, for example? What is the significance of the rather
  under-defined data stored in cryptoInfos (section 3.1)? If it says
  "SHA1 valid until 2010" does that means it is or isn't OK to use SHA1
  to generate timestamps in December 2009? Maybe all this is documented
  elswehere?

  I'm surprised that the redundancy mentioned in the Security 
  Considerations is only a recommendation. To my taste, it would
  be a MUST, since we are discussing the *really* long term here.

(Tim Polk) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Sam Hartman) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection