Re: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

On January the 25 th Warwick Ford, co-chair of the PKIX WG, issued a
14-days WG Last Call on the document
draft-ietf-pkix-time-stamp-05.txt.

The last call period will thus end on February the 8 th.

Up to now, several comments and responses have been posted to the
mailing list by Roland Mueller, Michael Zolotarev, Magnus Nystrom,
Peter Gutmann, Paul Koning, John Linn and Philip Hallam-Baker.

As lead editor of the document I will attempt to summarize the
comments that have been received so far.

Roland, as editor of an ISO document on time stamping (WD 18014) is
asking for an extremely late and major change in the document. The
rational advocated for that change request is to accommodate
particular mechanisms that do not use digital signatures.

Paul asked for an example to justify added stuff and Roland produced
a 5 pages text, ... which did not convinced Paul for making the
change. Roland did not replied up to now.

John raised three technical comments (I will answer to them later
below) and pointed a few editorial errors (thanks John !).

Philip discussed on the first technical points raised by John.

Peter asked for the removal of some ASN1 tags. Magnus supported this
position.

Let us address the three technical points raised by John first:

JL1: "If different entities obtain timestamps on the same data
object using the same hash algorithm, or a single entity obtains
multiple timestamps on the same object, the generated timestamp
tokens will include identical message imprints; as a result, an
observer could determine that the timestamps refer to the same
underlying data.  It might be worth a note in Security
Considerations stating that, in contexts where this potential
exposure is a concern, some unique value could be generated by the
requester and combined with a data object before hashing the
combination in order to produce MessageImprint's hashedMessage."

An observer could indeed determine that the timestamps refer to the
same underlying data. However, this is not a big concern since the
observer will neither know the actual content nor the intended
usage. The way that is proposed to address this issue might lead to
the definition of another standardized binding technique so that the
receiver of the TSP can know how to verify the linkage. I am not in
favor of defining such a new linkage structure under the reason that
I do not find the problem sufficiently important to be corrected. I
would rather prefer to address the concern in a different way: if
the requester really cares about this problem, he should rather use
a protected channel with data confidentiality to access the TSA. If
you wish to provide some text along these lines, I would be willing
to consider it for inclusion in the security consideration section.


JL2: "The second paragraph of Sec. 2.2 bears a number of SHALLs for
verification steps which are to be performed by the requesting
entity once the TimeStampToken is received.  What's the recommended
or required action if any of these verifications fail? "

Here is the text:

Upon receiving the response (which is or includes a TimeStampResp,
as defined below), the requesting entity SHALL verify the status
error 
returned in the response and if no error is present it SHALL verify
the
various fields contained in the TimeStampToken and the validity of
the 
digital signature of the TimeStampToken. In particular, it SHALL
verify
that what was time stamped corresponds to what was requested to be 
time stamped.  The requester SHALL verify that the TimeStampToken
contains the correct certificate identifier of the TSA, the correct 
data imprint and the correct hash algorithm OID.  It SHALL then
verify 
the timeliness of the response by verifying either the time included 
in the response against a local trusted time reference, if one is 
available, and/or the value of the nonce (large random number with a 
high probability that it is generated by the client only once) 
included in the response against the value included in the request.

I propose to add: "If any of the verifications above fails, the
TimeStampToken SHALL be rejected."

JL3: "In the Accuracy structure, is no more than one of the seconds,
millis, or micros OPTIONALs to occur, or may more than one of these
elements occur in combination? "

If you want to express, e.g. 1,5 s you have to use two of them in
combination. However, I suspect that in practice this case will be
quite seldom, but in theory any value must be able to be expressed.

Now let us come back to the main issue raised by Roland. Since, I
have shown up in an ISO ad-hoc meeting on Time Stamping that was
held on the last day of the RSA conference in San Jose, I know a
little bit more than what has been exposed.

I will wear two hats in sequence:

1) to express my own opinion,
2) to act as a moderator in the discussion.

My own opinion first: 

I cannot agree more with Roland when he says: " It is understood
that this proposal reaches the IETF working group at an extremely
late stage in its standardisation cycle." 

The main idea seems to open the door to "binding schemes" that do
not use digital signatures. The single one that I know is the
patented scheme from Surety. It has been advocated that other
schemes could also fall under that umbrella, but, up to now, no one
has yet advertised an unpatented scheme. It would thus seem that the
motivation of the change is to allow similar ASN1 structures to be
used for content of the Time Stamp Token, whatever binding scheme is
being used; in practice, the (unpatended) scheme from the PKIX WG
and at least one patented scheme from Surety.

My position as a moderator:

I am awaiting for other comments or opinions on that topic before
trying to see where the WG concensus is.

Denis.