Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt

From: Sarbari Gupta <[email-masked]>
Date: Thu, 20 May 1999 09:24:41 -0400

Jose,

You write:
>We have identified a business case for this service where the TSA
>does know the contents. The issue is whether it is a time-stamping
>service any longer or you have jumped into a notary service.
>If I were not too purist, I think there are situations
>We have identified a business case for this service where the TSA
>does know the contents. The issue is whether it is a time-stamping
>service any longer or you have jumped into a notary service.
>If I were not too purist, I think there are situations
>where the time certificate is something more than a separate
>appendix, for easiness of storage, transmission, verification,
>and so on.where the time certificate is something more than a separate
>appendix, for easiness of storage, transmission, verification,
>and so on.

I personally don't see why a timestamping standard cares what data is
allowed to be timestamped. As far as I know, a notary not only vouches
for the contents, but also vouches for the identity of the parties that
are signing the document (to be notarized). So, just allowing data to be
timestamped does not promote it to a notary service, I think.

>Packaging things in two levels adds complexity, but does not
>help any practical situation I may foresee. If simplifity
>is an objective, a single layer is simpler.

I agree simplicity should be a goal. The two layer SignedData is
somewhat complex, but there are other ways of separating the transient
data (status, nonce) from the long-lived timestamp token.

- Sarbari
=================================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 (voice)
(703)848-0960(FAX)
[email-masked]
=================================

-----Original Message-----
From: Jose A. Manas [mailto:[email-masked]]
Sent: Thursday, May 20, 1999 2:41 AM
To: Sarbari Gupta
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt

Sarbari Gupta wrote:
> 
> Please accept the following comments on the document:
> 
> 1) Section 2.1 item 6 states that the TSA is required "to only time
> stamp a hash representation of the datum"
> Why is this so? I think in certain circumstances it may be logical to
> allow the "messageImprint" to be the message itself (e.g., for short
> messages), such that the Time Stamp Token could contain a time-stamped
> version of the actual data. I understand this puts the burden of
> liability on the TSA (since it has seen the data) but this may be
> irrelevant based on the usage model. For example, the TSA may be owned
> and operated by a company that sends out Reminder Messages as a
service
> - in this case, it may be very elegant to package a short reminder
> message within the TST itself instead of using the hash of the
reminder
> message.
> 
> The point is that a TSA should be allowed to support a timestamping
> service which allows actual data to be sent as part of the request.
The
> perceived legal liabilities and network inefficiencies should not be
> used to restrict the timestamping standard. The standard should allow
> all known usage models - the legal implications and network
efficiencies
> of specific models should be weighed by the TSA before it makes its
> service available.

We have identified a business case for this service where the TSA
does know the contents. The issue is whether it is a time-stamping
service any longer or you have jumped into a notary service.
If I were not too purist, I think there are situations
where the time certificate is something more than a separate
appendix, for easiness of storage, transmission, verification,
and so on.

Some cases where I find it makes sense are: certificates,
CRLs, notary statements, ...

> 2) Section 2.3 states "The TSA MUST sign all time stamp messages with
a
> key reserved specifically for that purpose"
> Is there anything to prevent a TSA from using multiple signing keys
for
> signing time stamps - selecting a specific key based on properties of
> the incoming request. I would recommend rewording it to say "...
> messages with one or more keys reserved ..."

I think that quite neat!

> 3) Section 2.3 also states that the TSA's certificate MUST have the
> extended key usage field extension set to critical. This implies that
> only those clients that are able to parse this extension will be able
to
> verify the timestamp token. Isn't this too restrictive? How about
> changing the MUST to a SHOULD or a MAY?

I am not sure about this. I foresee a time stamping verification
client to be a very specific piece of software, that may well
take care of this criticality; so I do not see you are excluding
any one. An asking for this extension may enforce TSA role.

> 4) The current definition of the TSTInfo data structure seems to be
> trying to kill two birds with a single stone. It seems that the TSA
> response can potentially contain:
>         - the signed timestamp token
>         - other information related to the response such as status,
> nonce, etc.
> As such, it would seem logical to use a nested SignedData structure to
> signify the response from the TSA. The first level SignedData would
> contain the status, nonce, and (when status = SUCCESS) the timestamp
> token. The timestamp token itself would use another SignedData
structure
> to hold the relevant data of the timestamp token. The actual timestamp
> token is for wider distribution - I don't think it is a good design
> approach to overload it with transient information such as a nonce.
> 
> In fact, to be a purist, a failed timestamp request is not generating
a
> timestamp token, so the error message and the nonce should be signed
by
> a key that is different from the key used to sign a good timestamp
> token. This is further reason to support nested SignedData structures
> each of which can be signed by a different key.

This is right, but too academic for me. If the time-stamping
service goes ok, you get a time certificate that is OK as soon
as it exists. If the service goes wrong, the response is not 
good anyhow.

Packaging things in two levels adds complexity, but does not
help any practical situation I may foresee. If simplifity
is an objective, a single layer is simpler.

> - Sarbari
> =================================
> Sarbari Gupta
> CygnaCom Solutions
> (703)848-0883 (voice)
> (703)848-0960(FAX)
> [email-masked]
> =================================

Best,
pepe

-- --------------------------------------------------------
Prof. Jose A. Manas                     <[email-masked]>
Dpt. Telematica                 http://www.dit.upm.es/~pepe
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid, SPAIN               fax: [+34] 91 336 73 33

---

From: "Jose A. Manas" <[email-masked]>
Date: Thu, 20 May 1999 17:51:38 +0200

> timestamped does not promote it to a notary service, I think.

I am not sure what you mean.
But let me put my point of view in other words.

When a notary makes an statement on whatever,
there are three relevant pieces of information:
  - the statement itself (the message)
  - the authentity of the originator (notary's signature)
  - the time at which the notary makes the statement
    (time-stamp)

If the time-stamp is a signature attached to known data,
there is a unique act of signing, and this may be 
confortable for handling evidence in the future.

I think I mean that it makes sense that a notary 
is (also) a time-stamp authority,
and definitely he knows the contents.

Did I make my point clear?
pp