Comments on the draft ltrans-ers-03

["Jim Schaad" <jimsch@xxxxxxxxxx>]

Gentlemen,

Here is a first level review.  I have not gone into the document in any
depth nor have I actually tried to compile the ASN.1 module.

I am not on this mailing list so if you have any questions for me then you
need to respond directly to me.

Jim Schaad
Soaring Hawk Consulting.





Section 1.1 "example are" --> "example is"

Section 1.3: "An evidence record include" --> "includes"

Section 3.2 - consistancy on "hash-tree" "hash tree" "hashtree"

Appendix A   - "In this case the hash value of the CMS Object as well as the
hash value of the     content have --> "has"

Section 2.1: digestAlgorithms - is this just the OIDs of the algorithm
identifiers or does this include all of the parameters as well?

Section 2.1: field encryption in EvidenceRecord is not described in order
and in the same format.

Section 2.1: field encrytion - is this suppose to contain infomration about
re-encryption or about decryption of the fields?  There is some differences
between these.   Suggest a hint about where keys are found is included as
well in this location.

Section 3.1:  Are you restricted to a single set of parameters?  If you are
doing multiple hash operations  might one which to allow for different sets
of parameters for each of the hash operations?

Section 3.2: From my reading of the text, Figure 3 should be (h1), (h2a,
h2b, h2c), (h3) as this is the order items are in the tree above.  

Section 3.2:  There not text or reference for how grouping is done. (step 4
- place in groups and sort)

Section 3.3:  Why search in the first list rather than the entire list of
reducedHashtree?  It seems to me that it could be anyplace in the list and
still be valid.

Section 3.3: In step 3 it says that the value must be a member of the next
higher list --- WHAT LIST????? The reduction removes these from the list of
hash values.  It must be taken on faith that it is correct until you reach
the root.

Section 3.3: How does one re-construct the grouping that was created in the
production step?  Very non-obious

Section 4.1:  What does it mean for a ArchiveTimeStampSequence to be ordered
by time of timestamp?  If I run two parallel ArchiveTimeStampChains with
different hash functions and sign both at the approx the same time -- which
comes first?  Ordered by the first entry or the last entry on the chain?
There is no reason to assume that all of the entries in the second chain
occur after all of the entiries in the first chain.


Section 4.2:  It states that the hash algorithms must be the same -- how
about the hash algorithm parameters?

Section 4.2, 4.3: I have serveral issues with the algorithm that you are
using to replace a hash functions.  They are:

1) I believe that atsc(i) should be a constant for all documents.  A
document should never be deleted and then re-added, nor is a document added
during the process of renewing a timestamp.  Thus either the document has
been deleted (in which case it is not re-hashed) or it is in every
ArchiveTimeStampSequence.  Ergo - atsc(i) is constant for all values of i.

2) Verification requires that an implemenation of all previous hash
algorithms be kept is that what one wants to do?  (I.e. do you want to be
able to have a "fast" proof using just the current data).

3) What happens if only one item is left in a document group (i.e the rest
have been deleted)?  Is it treated as a document group of one or as a single
document?

Section 5.1:  The proper term is detached content rather than external
content.  Suggest "encryptionCover is a CMS content type of EnvelopedData
where the encryptedContent field is absent"

Section 5.1: Putting the private key into a BIT STRING is problematic.  I
would suggest either an OCTET STRING or an ANY DEFINED BY with the OID as
well.

Section 5.1:  I don't understand the set of parameters that you have defined
for re-encryption of the structure.  I would thing that the only thing that
you need is the ContentEncryptionKey in the clear - The rest of the
parameters are kept in the encryptionCover field.  You don't need to the
public key or the KeyEncryptionKey fields unless you are intending to
re-build the EncryptionCover field.

Section 5.1:  If you are using the EncryptedData field you need to make some
additional statements that are not required in CMS.

1) The ContentInfo field to be submitted MUST be DER encoded.
2) The encrypted content MUST be connonicalized PRIOR to being encrypted.
(i.e. ASN.1 is DER encoded, MIME uses S/MIME rules and so forth)
3) The EncryptedData RecipientInfos MUST ALL be kept intact unless the
EncryptedData field was not archived.

Section 6:  Use the correct module for CMS -- 
   CryptographicMessageSyntax2004
     { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

Section 6:  Add a reference comment to each of the IMPORT-ed modules -- From
[RFCXXXX] so that they can be easily found


Section 6:  ASN Errors
   id-EncryptionCMS_encryptedmessage ::= {id-ATS-1}

-- id-ATS-1 not defined

   EncryptionKeyRandom::= SEQUENCE {
      encryptionKey   OCTET STRING,
      randomValue     BIT STRING}}

-- illegal token }


Comment:  Useful to have the list name in the document so I know where to
send mail to.



---- need guidence on what happens if a key is revoked -- need to have a
second signature added before hand?