Evidence Record Syntax (ERS)
Note: This ballot was opened for revision 15 and is now closed.
(Jari Arkko) Yes
(Russ Housley) (was Discuss) Yes
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.