Subject: Time-stamp server. Extra field for MessageImpring

From: Michael Zolotarev <[email-masked]>
Date: Mon, 29 Mar 1999 12:35:47 +1000

We'd like to propose adding an extra field to the messageImprint structure:

Currently, there is no easy way to link the message hash included in the time-stamp-request to the original message. 
However, most systems will have an [obvious] requirement to associate a time stamp with the original message. Most 
simply, this could be done by incorporating the original message's filename (or some other internal reference 
information) into the time stamp. 

This could be done by adding a messageInfo field to the MessageImprint:
 
MessageImprint ::= SEQUENCE  {
     hashAlgorithm                AlgorithmIdentifier,
     hashedMessage             [0]	IMPLICIT 	OCTET STRING,
     messageInfo                   [1] 	IMPLICIT 	OCTET STRING 	OPTIONAL
          -- a user-defined tag for a pointer to the original message.
}

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 29 Mar 1999 15:44:14 +0200

I would prefer not to have such a field messageInfo inside the MessageImprint but rather 
elsewhere. Given this, it could also be used in DCS inside either

ReqData ::= SEQUENCE  {
     reqInfo                ReqInfo,
     data                   Data
     messageInfo OCTET STRING OPTIONAL
}

and 
Info ::= SEQUENCE  {
     reqInfo                ReqInfo,
     messageImprint       MessageImprint,
     messageInfo          [0] OCTET STRING OPTIONAL
     reqSignature         [1]    SignerInfo OPTIONAL,
...

}
or simply as an optional field inside ReqInfo.

Peter Sylvester
EdelWeb SA
Paris France

---

From: Michael Zolotarev <[email-masked]>
Date: Tue, 30 Mar 1999 12:04:53 +1000

Agree.
In fact, there is yet another point in favor of taking the MessageInfo out 
of the MessageImprint - the TSS draft defines the messageImprint as 
OPTIONAL. This caters for the situations when only a trusted time value is 
required, without linking it to any specific message. However, the client 
may still want to externally associate the obtained 'no messageImprint' 
time stamp with some data/event/entity. In this case the messageInfo will 
be even more useful, serving as an external tag value.

The TimeStamp request would become:

TimeStampReq ::= SEQUENCE  {
     version                      Integer  { v1(0) },
     reqPolicy                    PolicyInformation OPTIONAL,
     tdas                         SEQUENCE OF GeneralName OPTIONAL,
     nonce                        Integer,
    messageInfo          		        OCTET STRING OPTIONAL
     messageImprint               MessageImprint OPTIONAL
}

and the TSTInfo (in the TimeStampToken) would become:

TSTInfo ::= SEQUENCE  {
 	.........
     tstTime                      TSTTime,
     tdaTokens                    SEQUENCE OF TemporalDataToken
     nonce                        Integer OPTIONAL,
    messageInfo          		        OCTET STRING OPTIONAL
       --must be present if the similar field in TimeStampReq is
       --present
       --this field must have the same value as the similar field
       --in TimeStampReq
     messageImprint               MessageImprint OPTIONAL,
	...............
}

As for the DCS, I reckon it is more logical to add MessageInfo as an 
optional field to the ReqInfo structure.
Relying on a similar field in the OPTIONAL(!) ReqTime structure would force 
us to add the ReqInfo to the message, even if we did not want to. And it 
seems like a long way down for just attaching a label to the whole request. 

-----Original Message-----
From:	Peter Sylvester [SMTP:[email-masked]]
Sent:	Monday, March 29, 1999 11:44 PM
To:	[email-masked]; [email-masked]
Cc:	SECURITY/SDPL/[email-masked]; 
SECURITY/SDPL/[email-masked]
Subject:	Re: Time-stamp server. Extra field for MessageImpring

I would prefer not to have such a field messageInfo inside the 
MessageImprint but rather
elsewhere. Given this, it could also be used in DCS inside either

ReqData ::= SEQUENCE  {
     reqInfo                ReqInfo,
     data                   Data

and
Info ::= SEQUENCE  {
     reqInfo                ReqInfo,

}

Peter Sylvester
EdelWeb SA
Paris France

> Currently, there is no easy way to link the message hash included in the 
time-stamp-request to the original message.
> However, most systems will have an [obvious] requirement to associate a 
time stamp with the original message. Most
> simply, this could be done by incorporating the original message's 
filename (or some other internal reference

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 30 Mar 1999 08:29:10 -0500

I have no problem with adding this optional field into both the Time Stamp
and DCS drafts.  I think that it could be useful for clients when trying to
link their tokens with the corresponding data.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, March 29, 1999 9:04 PM
> To: 	'Peter Sylvester'; [email-masked]
> Cc: 	[email-masked]'; [email-masked]'
> Subject: 	RE: Time-stamp server. Extra field for MessageImpring
> 
> Agree.

---

From: "Todd S. Glassey" <[email-masked]>
Date: Tue, 30 Mar 1999 20:06:09 -0800

SNIP ---

>Currently, there is no easy way to link the message hash included in the
time-stamp-request to the original >message. However, most systems will have
an [obvious] requirement to associate a time stamp with the >original
message. Most  simply, this could be done by incorporating the original
message's filename (or >some other >internal >reference information) into
the time stamp.

As far as the evidentiary processes is concerned, I would think that making
this extension a pointer to an external structure is not the best way to
accomplish an archival process, rather the better method is encapsulating
the whole timestamp into a complex token structure. Which brings us to the
next requirement of timestamping, the creation and standardization of basic
time tokens...

Todd