Subject: draft-ietf-ltans-ers-02 comments

From: "Carl Wallace" <[email-masked]>
Date: Fri, 20 May 2005 11:44:36 -0400

Below are some questions and comments on the -02 draft of ERS.

Administrative
	- EVS in section 1.1, section 1.2 should be ERS
	- EV should be ER in "EV as file format" and "EV as part of another
syntax specification".
	- ETS in section 1.2 should be ERS
	- "Reduce hash-tree" should be "Reduced hash-tree" in Terminology
	- "Trusted archiving" is not referenced in the body of the
specification.  Suggest removing it from the Terminology section.  Same
applies to "archived data object group" and "trusted archive authority".
	- In section 2.1, remove comma from "contains data, necessary".
	- In section 2.1, change "if necessary" to "as necessary" or "when
necessary" in bullet 3.
	- In section 3, change "to verify" to "verification of".
	- In section 3.1, change "not existent" to "not present, "
	- In section 3.1, change "identically" to "identical"
	- Throughout section 4, change "first Initial" to "first
ArchiveTimeStamp in the first ArchiveTimeStampChain".
	- In section 4.1, change "must be ordered" to "MUST be ordered"
	- Suggest renaming ArchiveTimeStampSequence to
ArchiveTimeStampChainSequence
	- In section 4.2, "ASN.1 encoded" to "DER encoded".
	- In figure 4 and associated text, h123, h12 and h2abc should be
h123', h12' and h2abc'.
	- In 5.2, update the CMS reference and omit requirement for RSA
algorithm.
	- Section 5.2 requires encrypted data to be encapsulated but
Appendix A permits detached data.
	- id-ATS is not defined in the ASN.1 module.
	- In section 3.2, SEQ{h12, h1} should be SEQ{h2abc, h1}

Non-administrative
	- In section 2.1, how would a partial document be archived, i.e. how
can the structures be used to archive the "essential parts" of a document?
	- The verification algorithm needs a sorting step before
concatenation (section 3.3, bullet 3).  
	- In 4.1, why must all ArchiveTimestamps in an ArchiveTimestampChain
use the same hash algorithm?  Seems like this should refer to the algorithm
used within the hash tree not the hash algorithm used for the timestamp.
	- For timestamp renewal, why not obtain a timestamp for the entire
previous ArchiveTimeStamp (i.e. complete sequence including hash alg,
reduced hashtree and timestamp) instead of the timestamp field only?  This
would simplify processing (and would facilitate covering verification data -
see below).  Also, it's not clear in the current text if the entire
ContentInfo is timestamped or the content field of the timestamp object (in
section 4.2).
	- In section 4.2, bullet 3, is the hash calculated over a
concatenation or over the encoded ArchiveTimeStampChainSequence?  	
	- In Appendix A, given a detached set of signatures, what
constitutes the first signature?  
	- In Appendix A, why define two OIDs for the attribute?  One could
do with context determining how the attribute is processed.
	- Appendix A should also account for ContentWithAttributes structure
(see RFC4073).  This may be the cleanest way to associate an EvidenceRecord
attribute with any type of CMS object and avoid the need to strip out
attributes and reencode at verification time.
	- Suggest pushing cryptoInfos down a level.  This would allow
cryptoInfos to be protected by subsequent timestamps.  
	- Need to define some cryptoInfo types.
	- Suggest adding SIZE (1.MAX)  to each SEQUENCE OF in the
reducedHashtree definition.  Also on Chain object definitions.