Subject: Timestamp: confidential content

From: "Manger, James" <[email-masked]>
Date: Wed, 9 Jun 1999 12:58:15 +1000

You should be able to timestamp a message without compromising its
confidentiality.  Including a digest instead of the actual message in the
timestamp is not quite enough.  Revealing a digest allows anyone who can
guess the message (exhaustively search the potentially small message space)
to confirm that their guess is right.  A salt is needed.

Instead of submitting a digest of the message, the requestor submits a
digest of a combination of a salt and the message.  The requestor does not
submit the salt.  The following syntax could be used by the requestor to
store the returned timestamp:

TimestampedData ::= SEQUENCE {
	source		SEQUENCE {
				random	OCTET STRING,
				content	OCTET STRING  OPTIONAL
			},
	timestamp	TSTInfo -- "messageImprint" is the digest of the
DER-encoded "source" field with the "content" present
}

This makes the "nonce" field in TSTInfo unnecessary.  By chosing a fresh
value for the "random" field the requestor ensures the "messageImprint" is
fresh and, hence, that the timestamp is fresh.

Two attribute definitions might be useful.
The timestampedContent attribute is suitable as an authenticated or
unauthenticated attribute in a {PKCS #7|CMS} SignedData value.  The content
is the content of the SignedData value (i.e. the same octets that are used
to calculate the messageDigest authenticated attribute).  The
timestampedSignature is suitable as an unauthenticated attribute in a {PKCS
#7|CMS} SignedData value.  The content is the encryptedDigest value (i.e.
the signature).

timestampedContent	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID
id-at-??? 1 }
timestampedSignature	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID
id-at-??? 2 }

---

From: "Michael Zolotarev" <[email-masked]>
Date: Wed, 9 Jun 1999 19:29:09 +1000

James,
The draft says that the "hashedMessage field SHOULD contain the hash of the
datum to be time stamped". That definition (SHOULD, not MUST) leaves room
for having any type of data as the hashedMessage. So the client can pass a
hash, a salted hash, or even a message in the clear, or whatever else with
the messageImprint.

I do not see how optional 'salting' the hash eliminates requirement for
having the nonce field. The nonce is used to verify that the received
response is indeed for the request that has been sent, to prevent a replay
attack. Please, explain.

By the way, sending clear data should be made possible, if the client wants
to. To do that, TSA should not assert the strength of the hashAlgorithm, and
accept mesageImprint with no hashAlgorithm at all. Which requires making the
field optional. But please (please) do not start another discussion on
this - we had enough of it already :).

I'm not sure that defining extra attributes is a good idea. Unless we make
using the attributes mandatory and the only possible option, it adds
unnecessary complexity to the client, which now has extra options where to
look for the time stamp data.

Regards
MichaelZ

-----Original Message-----
From:	[email-masked] [mailto:[email-masked]] On Behalf Of
Manger, James
Sent:	Wednesday, June 09, 1999 12:58 PM
To:	[email-masked]'
Subject:	Timestamp: confidential content

TimestampedData ::= SEQUENCE {
	source		SEQUENCE {
				random	OCTET STRING,
				content	OCTET STRING  OPTIONAL
			},
	timestamp	TSTInfo -- "messageImprint" is the digest of the DER-encoded
"source" field with the "content" present
}

timestampedContent	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID id-at-???
1 }
timestampedSignature	ATTRIBUTE ::= { WITH SYNTAX TimestampedData  ID
id-at-??? 2 }