Subject: TSP Draft - hash enforcement &c

From: J Adrian Pickering <[email-masked]>
Date: Sat, 02 Sep 2000 17:37:43 +0100

The following refers to draft-ietf-pkix-time-stamp-09.txt, dated June 2000, 
and is in response to the Final Call posted on 28 August.

My motivation for the use of TSP is for IPR protection support for the 
academic community at large (an extention to the original motivations of 
Haber and Stornetta in their 1991 paper). I recognise that this is not the 
core motivation for the PKIX TSP endeavours, but I am concerned that the 
emerging standard is as generally applicable to Internet users as possible 
(as the Introduction suggests).

Apologies to some who have already heard some of my views directly on this. 
Uniquely, the Draft does not invite comments to this forum in its Abstract 
- the Final Call now does!

1. I rather take the view that a TSA has no business knowing the meaning of 
what it stamps just as it has no business knowing who it is doing its 
stamping for - it must be a truly disinterested automaton.

Thus, my main concern is the implied and mandatory use of a hash in the 
message imprint. This clearly stems from the PKIX motivation. From the 
point of view of the TSA, this is unenforcible. A client can put anything 
they like in this field provided (at the moment) it has the right length. 
Therefore, I would suggest that if a server cannot verify something it 
should not be stipulated as REQUIRED. This affects paras 6, 7, 8 of 2.1 and 
also 'messageImpring field SHALL...' in 2.4.1 - SHOULD could be used.

My ideal would be that the TSA be given a octet string to stamp and that 
the Draft make very strong recommendations on how this should be used by 
the client - but not to MUST or REQUIRE it. Good candidates for the string 
are the imprint, containing a hash, and the nonce. Further, this approach 
would dilute the security problem highlighted in Section 4 para 5.

However, at this late stage, a 'quick fix' would be to allow clients to put 
something of meaning to *them* in the imprint field (e.g. RIPEMD256 hash) 
and that the algorithm identifier allow this. When the server does its 
check then, provided the OID specifies 'algorithm not known', then the 
length will always conform. This will require adjustments to the algorithm 
OIDs. As far as I can tell this will not undermine PKIX intentions.

As far as I can tell, the AlgorithmIdentifier is actually that of the full 
signing algorithm and *not* that of the hash algorithm(s) alone. I would 
recommend that there be a separately defined hashAlgorithm OID. 
Cryptographers have devised many hash algorithms and variants and there 
should be room for their use, even if this just means using the 'algorithm 
not known' opt-out suggested above.

2. If the TSA policy means a log is kept then a client may wish to 
explicitly indicate whether this request be recorded or not. There are 
other ways of communicating this, but a good way might be to have 'logReq 
BOOLEAN DEFAULT FALSE' in TimeStampReq. This may be something left to 
extensions, though.

3. I presume there is no limit to the length of the nonce, though 64 bits 
is given as an example. Bearing in mind what clients might do in the light 
of my comments in 1, they may wish to use very large nonce's. This may 
affect the practicality of logging.

4. (drafting) Page 8, para starting 'gentime is...'. I think the middle 
sentence should read: 'Such syntax, .... to represent time *within* one 
second, may be used here' (omit 'to').

5. Bearing in mind Christian Vogel's experiences, and the format of other 
Drafts, some examples in the appendix would be very helpful.

6. I have made the authors aware of some IPR matters in addition to those 
in Section 5.

Adrian Pickering/
Lecturer, Electronics and Computer Science,
University of Southampton
Southampton, UK