RE: ERS comments

["Tobias Gondrom" <tgondrom@xxxxxxxxxxxx>]

Carl,

no problem and thanks fort he review. I will change the spelling and
format issues today right after the meeting. 

- concerning 2119 language: it is intended that some of the musts are
not capital MUST - exactly because of the 2119 language specifications.

The rest of the answers inline....

Tobias



> -----Original Message-----
> From: Carl Wallace [mailto:cwallace@xxxxxxxxxxxx]
> Sent: Monday, March 20, 2006 1:47 PM
> To: ietf-ltans@xxxxxxx
> Cc: Tobias Gondrom
> Subject: ERS comments
> 
> Below are comments for -05 of ERS.  I apologize for the late posting
> relative to the WG meeting.  Most are nits.  My two primary concerns
are
> lack of extensibility and underspecification of the validation
> algorithm.
> 
> NITS
> In the definitions section, change "a Archive..." to "an Archive...".
> 
> Definitions should be alphabetical.
> 
> In section 2.1, change "necesarry" to necessary".
> 
> In section 4.2, "if the Time-Stamp of an Archive Time-Stamp becomes
> invalid" should be "before the Time-Stamp of an Archive Time-Stamp
> becomes invalid".
> 
> In section 4.3, add "at the time verification is performed" to the end
> of the sentence immediately following the three bullets.
> 
> The draft does not consistently use 2119 language.  In particular, the
> verification algorithm in section 4.3 needs to have capitalization
> applied to some of the MUSTs.
> 
> In the definitions section, why were parentheses added to "Archived
data
> object" and "Archived data object group"?
> 
> COMMENTS/QUESTIONS
> What is the IMPORT for AlgorithmIdentifier?  Shouldn't this be
imported
> from RFC3280?  Similarly, id-ERS-1 should be defined in this module,
not
> imported.

I would go with this, other comments from the WG?


> 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)

> 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.

> 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.