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

From: Philip Hallam-Baker <[email-masked]>
Date: Tue, 1 Feb 2000 07:31:27 -0800

This attack can be corrected by using the 'exposed MAC' I proposed
in the HTTP security working group in '93 (yahh boo sucks to patent
squaters).

Essentially what one does is to use a MAC to digest the document (I
referred to it as a keyed digest in the prior art). Then one publishes
the key to the MAC along with the digest.

The advantage of this particular scheme is that you can use it to 
harden a system against even exhaustive search (brute force) attacks
with a little ingenuity.

		Phill

-----Original Message-----
From: Linn, John [mailto:[email-masked]]
Sent: Monday, January 31, 2000 4:05 PM
To: [email-masked]'
Subject: RE: LAST CALL:draft-ietf-pkix-time-stamp-05.txt

I've a few comments on this specification.

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. 

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? 

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? 

In References, [ESS] is now RFC-2634.

Editorially, there's an odd character which seems to recur instead of
the
apostrophe in the phrase "TSA's", and in other places where an
apostrophe or
closing single quote is intended; on my display, it appears as a
ligature
"AE".

Other, minor editorial points:

p. 8, 1st line, "may to be used" -> "may be used".

Later on p. 8, "subtracting the accuracy to" -> "subtracting the
accuracy
from". 

Appendix A, 4th line, "allows to know" -> "allows a verifier to know".

--jl

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 04 Feb 2000 11:31:57 +0100

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.

---

From: Roland Mueller <[email-masked]>
Date: Fri, 04 Feb 2000 15:47:57 -0600

Denis,

let me clarify our position:

It is NOT the intention of the ISO working group to introduce patented
mechanisms, our approach is to allow for MULTIPLE mechanism to be used
for time stamping. That's why we introced a mechanism identifier. This
ISO draft does NOT suggest the IETF use or endorse any other mechanism,
it is just for interoperability reasons.

We are also trying to have common data structures to achieve a common
base that allows for further extensions (for the IETF and the ISO
protocols) of time stamping protocols but may be used for schemes as
already introduced in part 2 of our working draft.

I hope that this clarifies our requested changes.

Roland

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 07 Feb 2000 09:13:43 +0100

> for time stamping. 

Roland,

Since you said that you want multiple mechanisms to be used and that
it is NOT the intention of the ISO working group to introduce
patented mechanisms, would you be able to provide at least one
useful example of such a binding mechanism that is not patented ?

Denis

> That's why we introced a mechanism identifier. This
>   --------------------------------------------------------------------
> 
>   Mueller, Roland <[email-masked]>
>   TUVIT Inc.
> 
>   Mueller, Roland
>   TUVIT Inc.                                            <[email-masked]>
>   8716 North MoPac Suite 220;Austin;Texas;78759;U.S.A.  Télécopie: (512) 795-0495
>                                                         Bureau: (512) 795-0494