Re: [ltans] Fwd: Re: I-D ACTION:draft-ietf-ltans-xmlers-06.txt

["Aljosa Jerman Blazic" <[e-mail]>]

Tobias

Answers are inline.
  
> -------- Original Message --------
> Subject: 	Re: [ltans] I-D ACTION:draft-ietf-ltans-xmlers-06.txt
> Date: 	Mon, 07 Jun 2010 19:06:38 +0100
> From: 	Tobias Gondrom <[e-mail]>
> <mailto:[e-mail]>
> To: 	[e-mail]
> 
> 
> Dear Aljosa,
> 
> thanks a lot for the great update version 06!
> I sent a few more purely editorial comments to you directly and have
> identified the following questions we should resolve on the mailing-
> list as other might have them as well:
> 
> 1. Some more general questions about consistency of used terminology:
> - There is some inconsistency in the spelling (start with capital or
> small letter) of Evidence record?
> Shall we use "Evidence Record" or "evidence record"
> - same applies for Archive Time-Stamp/Archive Time Stamp/Archive
> Timestamp
> - same for in-sentence use of "type" and "Type"
>
> I have no preference, just think we should use consistent terms
> throughout the draft.
> In case you like, in RFC4998 when referring to a data structure we
> started with the capital letter and otherwise we used timestamp /
> evidence reocrd using the small letters. Maybe not the best solution
> either.
> As I said I have no personal preference for this.

Thanks for the comment.

> Questions:
> 2. section 3.1.1. paragraph 2:
> old: concatenated and a new hash value is generated from that string
> (there is exception when the first list is having one hash value, then
> this value is added to the next list).
> new: concatenated and a new hash value is generated from that string.
> There is an exception when the first list has only one hash value, in
> which case this value is the root hash value).
> comment: at least that's how I would understand it, otherwise it seems
> to trigger an endless recursive circle.
> The current wording seemed incorrect, but maybe I misunderstood s.th
> here?

One has to read the whole paragraph. "hashes of the first list are
ordered in binary ascending order, concatenated and a new hash value is
generated from that string (there is exception when the first list has
one hash value, then this value is added to the next list). This hash
value is added to the next list of hashes and the previous step is
repeated. When there are no hash lists left, the last generated hash
value is the root hash value..." The last sentence defines termination
point of the process, i.e. when there are no hash lists left, then the
last value generated is the root value (this way it is not possible to
end up with endless recursive circle). If we change the wording as you
have proposed then in case when the initial list has only a single value
this automatically becomes the root value (to be time-stamped), which is
incorrect. A list with a single value my become part of the next list
which has several values and the process is repeated. Only when there
are no (hash) values to order in a list then this value becomes the root
value. For better understanding I suggest the following definition:
"hashes of the first list are ordered in binary ascending order,
concatenated and a new hash value is generated from that string (there
is exception when the first list has one hash value, then this value is
added to the next list). Newly generated hash value is added to the next
list of hashes and the previous step is repeated until there is only one
hash value left, i.e. when there are no hash lists left, the last
generated hash value is the root hash value..."

> 3. section 3.2. item #2
> Question: where is "canonicalization method C" defined or
referenced???

I am not sure I understand this question. You may want to check the
structure in section 2.1. Canonicalization Method is a child element of
Archive time stamp chain and references to canonicalization method
algorithm.

> 4. section 3.3. item#4:
> "If an archive object is having more data objects and the hash tree is
> omitted, also exit with result."
> Question: I am not sure why we have to exit in this case with (you
> probably mean negative) result???
> Do we? And if yes, why?

You are right. It should state "...also exit with negative result." This
definition applies to the rule from section 3.1.1., which states: "When
an archive object is composed of more than one data object, the first
hash list MUST contain hash values of all its data objects." In case
when archive object has more than one data object then hash tree HAS TO
BE composed form hash values of each data object. In case ERS records
fails to demonstrate this, then the result is negative.

> 5. section 4.2.1
> Question about "the complete content of the last ATS MUST be time-
> stamped"
> Why is that? I thought only the old time-stamp has to be
> protected/renewed with a new timestamp?
> So we would not need to do this to the whole ATS structure.(btw. see
> also RFC4998, section 5 does it only on the timestamp) Or do I
> misunderstand s.th.?

This is where XMLERS differs from ERS. Please pay attention to the XML
structure proposed, which includes cryptographic information element
used for collecting cryptomaterial related to the actual time stamp.
Such material may come in a form as time stamp authority digital
certificate, digital certificate revocation list, etc. When renewal
occurs, cryptographic material has to be "protected" with the succeeding
time stamp, hence the requirement to time-stamp the complete ATS.
However, ATS may be empty, i.e. may include only time stamp token and in
this case XMLERS performs analogue to the ERS syntax and processing
rules. But IMO, this is wrong. Time-stamp renewal occurs for various
reasons. The most common reason is revoked or expired digital
certificate or decomposing time stamp authority, although hash
algorithms used are still stable. ERS ASN.1 syntax fails to demonstrate
that previous time stamp was valid at the time of time stamp renewal. It
would need to collect cryptographic material of preceding time stamp
separately and perform additional ERSing for cryptographic material
collected. XMLERS simplifies this process by collecting cryptomaterial
within the Archive Time-Stamp. The redundancy here is only hash tree
which is re-time-stamped although hash algorithm is still stable. Hash
tree element could still be moved out and put as child element to
archive time stamp chain element...

I am updating the draft now but will wait with publishing until the
LTANS meeting.

Regards

Aljosa