RE: ERS comments

["Carl Wallace" <cwallace@xxxxxxxxxxxx>]

<snip>
> > The syntax has no extensibility mechanism.  For a spec with 
> long-term 
> > goals, lack of extensibility could be problem.  One 
> possible approach 
> > would be to replace the reduced hashtree with a CMS attribute bucket
> and
> > refactor reduced hashtree as an attribute.
> 
> Maybe I am not seeing the point: I don't see a real advantage of that.
> In fact I believe that a strict specification is better. (the 
> less room for (mis)interpretation and individual 
> modifications the better)

I'll defer to other comments during the last call.  Generally I agree
with the idea that a strict spec is preferable.  However, with the
timestamp flexibility already there and given the need to accommodate
change over a long period of time, leaving wiggle room for things we
haven't thought of is probably a good idea.

> > What came of the policy discussions during the Paris 
> meeting?  Should 
> > policy be an output of verification?  Does the structure need to 
> > accommodate expression of policy?
> 
> Policy should not be an output of the verification but an 
> input for the storage system and an input fort he 
> verification (for only the system and the auditor can know 
> which algs are acceptable for them.)
>
> > What are the inputs to the verification algorithm?  How does a 
> > verification implementation know a crypto algorithm was secure at a 
> > particular time?  Where digital signatures are used, must all 
> > certificates in the path to the TSA be valid at the time the
> subsequent
> > timestamp was generated?  Verification for at least one timestamp
> option
> > should be described in detail in this doc (RFC3161?) with other 
> > timestamp types addressed in this spec or in related docs.
> 
> A system should be provided with a policy (it can also be 
> only one policy that is configured for the system globally) 
> that will define which alg has been recognized as secure 
> until which date.) This will have to be an implicit part of 
> the verification but not a necessary part of the 
> specification for these criteria can be configured 
> individually for each system based on local restrictions and 
> parameters.

I think we should define a validation algorithm a la 3280, with a
required minimal set of inputs and expected outputs.  This would also
help sort out the policy question.
 
> > Should the hash of preceding Archive Time-Stamp be incorporated into
> the
> > structure to allow each Archive Time-Stamp to stand alone?  Perhaps
> this
> > could be included as an attribute and checked only when 
> validation of 
> > ancestors is desired.
> 
> The verification of the ERS can be split into several parts: 
> one can already verify every ArchiveTimeStamp, 
> ArchiveTimeStampChain and ArchiveTimeStampSequence on its own 
> and puzzle together the results in the end by simply closing 
> the gaps/links of the chain by comparing hash-values of the 
> top and the bottom of each ArchiveTimeStamp.

Unless I am misreading bullets 4 and 5 in section 4.2, you must have the
chain in order to calculate the hash when verifying an evidence record
that has been renewed.  The hash in the first SEQ OF OCTET STRINGs is
not the hash of the original document using a new hash alg but is a hash
of the document + hash of the chain.  Each chain in a sequence does not
stand alone.  If the chain hash were included as an attribute one could
perform a shallow verification, or (possibly) could discard the older
portions of the chain at some point, by concatenating the value from the
attribute with the document hash.