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

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 12:08:38 -0400

Sarbari;

I would not be opposed to changing the model and allowing the data to be
included within the time stamp token if there was a clear need for it.
However, I don't see that need.  It may provide for more elegant storage of
the token and message in some special circumstances, but it also makes the
server end more complex since it would then have to be concerned about the
length of messages it time stamps.  Note that appendix A does provide a
method to store the data and token together.

If the Extended Key Usage Extension was not critical two things may happen.
Some clients may not check for it and therefore allow any entity to act as a
TSA.  Also, clients may ignore the extension and accept the signature as any
other signature.  However, it is not just a signature, it is meant to
provide certain assurances.  The semantics of this signature are very
important and I don't want those semantics to be lost.

No, I wouldn't include nonces and status information within a certificate.
But this isn't a certificate.

	Robert.

> ----------
> From: 	Sarbari Gupta[SMTP:[email-masked]]
> Sent: 	Thursday, May 20, 1999 10:44 AM
> To: 	'Robert Zuccherato'; [email-masked]
> Subject: 	RE: Comments on draft-ietf-pkix-time-stamp-01.txt 
> 
> 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: [email-masked] (Terry Hayes)
Date: Fri, 21 May 1999 18:54:08 -0700

> important and I don't want those semantics to be lost.

I think the first case is just a bug in the client application.  A client
implementing time-stamping according to this protocol should check the keyusage
bit as required by the standard.  There isn't much a CA can do to force software
to do the right thing (except publish a list of certified software).  Setting
the extension to critical isn't going to force broken software to do the check.

The second case has more merit.  The CA is preventing the TSA from fooling older
clients into believing it's certified for more than it is.  Given that the TSA
is supposed to use the key ONLY for time-stamping operations, requiring the
extension to be critical makes sense.  However, if the CA wanted to certify the
key for both time-stamping and SSL operations (say), then marking it critical
could be a problem, since older SSL clients might be unable to use the
certificate.

Another example of the second case is the "delta" extension for CRLs.  Older
CRL-using applications would not work correctly if there wasn't a strong
indication that the CRL was unusable for them.  Marking the extension critical
does that very well.

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Sat, 22 May 1999 08:15:12 -0700

Robert, I think what we need is a state/event diagram describing the
transaction of using the DCS and the Client to TSA relational model. I think
this is an important missing piece of the puzzle.

Todd