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

From: Sarbari Gupta <[email-masked]>
Date: Thu, 20 May 1999 10:44:31 -0400

Robert:

You write:

This issue has actually been discussed quite a bit both on the list and
at
PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
examine or verify the data being time stamped in any way.  If it did so,
it
would be doing more than just providing a "proof-of-existence" for the
data
at a particular point in time and would become more like a "notary"
service.
(Although the term "notary" is not a good term to use.  Everyone has a
different definition what an electronic notary should do.)  We also
decided
that it was desirable to only have a message imprint within the time
stamp
token and not to include the entire data.  In most circumstances this is
what is desired, and it would prevent people from forcing the TSA to
produce
HUGE time stamp tokens.  If we allowed tokens to be produced using the
actual data instead of the message imprint, the TSA would, in most
cases,
need to examine the data to determine, for example, if the data is too
big
for it to support.  As I stated, this is not allowed in this model. 
 
==> I did not attend the PKIX meetings that you are referring to. If the
majority of folks feel that data SHOULD NOT be timestamped, I am willing
to accept that. 

==> However, your argument sounds somewhat circular. First, you create a
"model" where data cannot be inspected, then you come from the other
direction and say that data cannot be allowed on the incoming request
since the "model" does not allow it. Any "models" that are created
should be based on business/usage requirements. First, we need to
evaluate whether it makes sense for a "business model" where TSTs
contain data (of maximum length to be determined by the TSA) instead of
hashes. If so, I would argue that your "model" needs to be expanded to
accommodate the "business model".

==> I agree that allowing data to be fed in to the TSA implies that the
TSA has to (at the very least) inspect the data length. I don't
understand why this is such a big problem - doesn't the TSA inspect the
hash OID today? Why does inspecting the data length negate the "just
providing a "proof-of-existence" for the data" maxim?    

==> You also write:
Why don't we allow the actual data in the request, but just a message
imprint in the token?  Because then the TSA would have to examine the
request to determine if it contains the actual data (which then must be
hashed) or a message imprint (which doesn't).  Thus, we have the message
imprint in both the request and response.

==> I am not advocating that you support a mode where data is sent in
but the TST contains the imprint. I am proposing that there are business
cases where the TST itself contains small amounts of data (of length TBD
by TSA).

==> You also write:
No, this isn't too restrictive.  Client's must know what entities are
entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.
==> Setting the Extended Key Usage extension to not be critical can also
have the effect you desire. Clients that care will check that the TSA's
certificate is allowed for timestamping (even though it is
non-critical). However, all clients can verify a TST. 

==> You also write:
I really don't see the advantage of adding this extra layer of
complication.
==> I feel that nonces and status codes SHOULD NOT appear within a TST.
Would you include status codes (related to the cert request) and nonces
within a certificate?

- Sarbari

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

-----Original Message-----
From: Robert Zuccherato [mailto:[email-masked]]
Sent: Thursday, May 20, 1999 10:06 AM
To: [email-masked]; 'Sarbari Gupta'
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 

Sarbari;

My responses are below.

> ----------
> From: 	Sarbari Gupta[SMTP:[email-masked]]
> Sent: 	Wednesday, May 19, 1999 1:56 PM
> To: 	[email-masked]
> Subject: 	Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> 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. 
> 
This issue has actually been discussed quite a bit both on the list and
at
PKIX meetings.  A Time Stamp Authority, as we have defined it, does not
examine or verify the data being time stamped in any way.  If it did so,
it
would be doing more than just providing a "proof-of-existence" for the
data
at a particular point in time and would become more like a "notary"
service.
(Although the term "notary" is not a good term to use.  Everyone has a
different definition what an electronic notary should do.)  We also
decided
that it was desirable to only have a message imprint within the time
stamp
token and not to include the entire data.  In most circumstances this is
what is desired, and it would prevent people from forcing the TSA to
produce
HUGE time stamp tokens.  If we allowed tokens to be produced using the
actual data instead of the message imprint, the TSA would, in most
cases,
need to examine the data to determine, for example, if the data is too
big
for it to support.  As I stated, this is not allowed in this model. 

Why don't we allow the actual data in the request, but just a message
imprint in the token?  Because then the TSA would have to examine the
request to determine if it contains the actual data (which then must be
hashed) or a message imprint (which doesn't).  Thus, we have the message
imprint in both the request and response.

> 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 don't think that I meant that the TSA should only have one key.  I
will
change the wording.
>  
> 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?
> 
No, this isn't too restrictive.  Client's must know what entities are
entitled to act as TSAs.  Otherwise, anyone could act as a valid TSA.

> 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. 
> 
I really don't see the advantage of adding this extra layer of
complication.
(Although I will admit that I haven't read carefully the flood of emails
that I have received from you and others the past 24 hours about this
topic.)

> 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. 
> 
In security requirement number 9, the word "token" should be changed to
"message" to be consistent with Section 2.3.  An error message is a time
stamp message, so there is no reason to use a different key for error
messages than for tokens.  I don't see the problem here.

	Robert.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 May 1999 17:54:34 -0400

Sarbari,

PKIX has distinguished between time stamping, where only a hash is sent and
a proof of existance is the goal, vs. data certification, where one might
want the authority to make additional attestations about what is being
certified.  Som on that basis, I think Roberto's comments are in keeping
with the discussions that have transpired at PKIX meetings.

Steve