Subject: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt

From: [email-masked]
Date: Tue, 11 May 1999 09:31:16 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Time Stamp Protocols
	Author(s)	: C. Adams, B. Pinkas, P. Cain, R. Zuccherato
	Filename	: draft-ietf-pkix-time-stamp-01.txt
	Pages		: 18
	Date		: 10-May-99
	
This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]).  In order to reduce the amount of trust required of a TSA we
introduce (in Appendix C) the optional Temporal Data Authority (TDA)
whose function is to provide further corroborating evidence of the time
contained in the token.  We also give an example of how to place a
signature at a particular point in time, from which the appropriate
certificate status information (e.g. CRLs) may be checked.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-time-stamp-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-time-stamp-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Wed, 12 May 1999 13:06:15 +0200

Hi there,

    I would like to make use of this new draft announcement to recall an old discussion on the messageImprint field which seems not to have been solved at sigth of this new draft:

    The question of using a SEQUENCE OF MessageImprint instead of the single MessageImprint arised on the basis of strenghtening the relation beetwen the digital object to be stamped and the representation of that object (i.e. message digests) in a way that beared possible weaknesses in one of the hash functions used to obtain that representation.
    In order to address this without modifying the syntax, the use of "composite" OIDs was proposed (i.e. valid OID could be "SHA1++MD5"), besides this is not specified in the draft, it doesn´t seem to be a very good idea and this is my personal opinion; a structure "SEQUENCE OF" would be more appropriate there, not just because the number of OIDs grows exponentially (assuming an agreed method for sorting the hashes) with the number of hash functions, but for some other reasons:

    On one hand, the use of a "SEQUENCE OF" would replace the presently optional field "messageImprint". There is no need for this new field to be declared optional since an "empty sequence" may be used. Therefore this becomes a wherewithal to reduce optional fields (I can remember someone complained about that).

    On the other hand this new structure preserves interoperability; TST verification software may not understand an agreed "composite OID" in which agreement it did not take part (i.e. a verifier trying to validate a token issued by some other TSA that agreed a new OID with ITS clients).Not understanding the OID it would be unable to process the associated value. It seems more natural to me that a client software "scans" a sequence of hashes looking for those it knows and trusts...

bye,

Juan.
____________________________________________
Juan González-de-la-Vega
Software Engineer
e-mail: <[email-masked]>
FNMT - Fábrica Nacional de Moneda y Timbre
Phone: +34 (91) 506 48 40.
Fax: +34 (91) 506 48 59

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 13 May 1999 11:50:01 +0200

Hi,

Just some comments on your response,

-----Mensaje original-----
De: Robert Zuccherato <[email-masked]>
Para: [email-masked] <[email-masked]>; 'Juan G. de la Vega'
<[email-masked]>
Fecha: miércoles 12 de mayo de 1999 21:01
Asunto: RE: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt

R:

Juan;

As I stated at the time, since this protocol relies on signatures to
preserve the integrity of the time stamp token, and signing algorithms make
use of hashes, if SHA-1 is broken, for example, then no time stamp token
will be trusted.  Thus, adding more hashes will not improve the security of
the protocol.

J: I was thinking in something a step forward; regarding TST as a signed
receipt not as the only time certificate itself (it is difficult to imagine
a TSA just signing without keeping any record), in this case multiple hashes
do improve the security of the protocol since the TSA keeps multiple
representation of the data item stamped and may reissue (without requiring
the user) a TST using a non-broken hash algorithm when the formerly used is
no longer to be trusted. Anyway, since the protocol just considers TSTs as
valid time stamping proofs then the inclusion of multiple hash would make no
effect as far as the signature algorithm wouldn't regard these.

R:
I am also concerned that TSA's will begin demanding that 3 (or 4 or 5)
different message imprints be included within the request, in order to make
it more "secure".  Or that verifiers will begin to be required to verify
every message imprint (even though you only really need to verify one
imprint).  This will make client tools much more complex.

J: I do not agree with you. The verifier is not required or forced to, the
verifier herself decides which policies fit
her security/trust requirements. In this sense your proposal of using
"composite" OIDs limits the configuration of those requirements and also
backward compatibility. If my client application just computes SHA-1 and a
TST comes with the OID "SHA-1++NEWHASH" it would reject that Token, while
this should not happen if my application could scan several OIDs looking for
SHA-1...
If you use "composite" OIDs and willing to support 4 different hash
algorithms, then you go up to 15 OIDs and the associated computing of the
messageImprint field, I think that is more complex that having 4 OIDs and
following a sequence. Anyway, this does not apply if the signature is the
only support for time certificates...

R:
Since the benefits of including a SEQUENCE OF Message Imprint are dubious,
there are possibly negative consequences, and there doesn't appear to be a
great deal of support for including it, I left it out.

Robert.

regards,

    Juan.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 16 May 1999 11:35:24 (NZST)

>My concern is that composite hashes do not scale:
>
>1. There are currently about 7 hash algorithms to play with (md2, md4, md5,
>sha1, rimemd128, ripemd160, ripemd256). That implies 7 single oids, plus 7x6
>combinations with two of them, plus 7x6x5 combinations of three, and so on. I
>feel much more confortable with 7 oids rather than with such a collection.

Scalability of xWithY algorithms is always a problem.  Why not use an algorithm
identifier instead of an OID?  OID = { ... }, parameters =
SEQUENCE { hash_oid1, hash_oid2 }?  That way you introduce a single new OID,
and can reuse all the existing OIDs for hash algorithms.

Peter.

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 18 May 1999 15:09:53 -0400

Agreed, this is a simple way to include multiple message imprints for those
applications that really must.  I therefore see no reason to include a
SEQUENCE OF MessageImprint within the time stamp request and tokens.

	Robert.

> ----------
> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Sunday, May 16, 1999 7:35 AM
> To: 	[email-masked]; [email-masked]
> Subject: 	Re: I-D ACTION:draft-ietf-pkix-time-stamp-01.txt
>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 19 May 1999 14:17:41 +0200

> SEQUENCE OF MessageImprint within the time stamp request and tokens.
IMHO the proposed solution is a dirty hack.

It assumes that you can always determine the length of a hash either by
looking at the OID, or by inspection the CONTENT of some data.  

You can never include a hash function that requires a parameter
in it algorithmIdentifier. 

Well, if you want to be general, you can always fix that by defining all
this in a more complex parameters section. (instead of a sequence of
oid, you would need at sequence of sequence {algorithmidentifier, length}

Or, this second algoritm one can include the other Peter's proposed algorithm
as a value, but not the other way around. 

A somewhat complex solution for a simple problem. 

Peter