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

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 20 May 1999 09:43:54 +0200

Please let me add some further comments upon yours,

>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.
>
As a matter of fact, it pleases me that someone addresses this issue. The
same structure is being used to support every response from the TSA
regardless whether it is a valid time stamp token (with or without transient
info) or some other semantic token (i.e. "signed time", error report...).
This rises problems not addressed in this draft, namely:

    -since tstTime is mandatory, and messageImprint must match the similar
field in the request, problems not related to the time source (non-existing
TDAs) lead to ambiguous tokens; the time is correct, the messageImprint is
there, despite the status field states that TDAs were not available, bearing
in mind that the TST is signed by the TSA anyway, does not this prove that a
given document existed at a given point in time (Time Stamping!) regardless
other circumstances (charging for the service is a good example)?

This can be countered by:
    - Making the tstTime OPTIONAL => it is funny that a TST is defined
regarding time as optional but it should not appear when reporting errors.
    - Different structures for TST and errors => more complex clients.
    - Further specification of TSA's behaviour in error cases (i.e. not
including message digests)
    - Using authenticated attributes to specify error status and transient
information so that the TST itself would be optional (if status is erroneous
the content of SignedData will not be present)

Regarding transient information, I agree that it should not be there, but
nested signatures seems a bit of an excess to me, I believe that using Auth.
Att. would do or yet better, since we are dealing with transient
information, using transient ligthweight authentication (v.g. SSL) perfectly
suits its security requirements (what about specifying this within transport
section?).

>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.
>

I agree with the former but not with the later. In case of error,  an
"error-signed" message would be issued. Otherwise a "TST-signed" would do.
There is no nesting here.

kind regards,

Juan.

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 20 May 1999 15:38:28 +0200

Denis Pinkas wrote:
>
>Let us separate the two birds:
>
>1) as said before the status should be separated from the token,
>2) the nonce is there to allow a requester that has no local time to make
>sure that he got a timely reponse from the TSA. So it has to be part of the
>signed structure.
>
>
Denis,

    Even admitting that no trusted local clock were available (not even
auth. NTP), the messageImprint field takes account of the problem of
responses timeliness (use a time variant parameter within the messageImprint
field if you do not have data to stamp). If this is still considered not
elegant, a nonce field may be used but that doesn't mean that it has to be
"part of the signed structure", I would say that in that is has to be
"authenticated", this could be done as proposed by Sarbari at other layer or
even including the nonce as an authenticated attribute of the SignedData
construct.

bye,

Juan.

---

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

>the content of SignedData will not be present)

Making tstTime OPTIONAL seems to be counter-intuitive. Either the second
or the third approach sounds fine.  

>suits its security requirements (what about specifying this within
transport

Using transport level security is acceptable to me.

>There is no nesting here.

Sounds good, too! Are the same credentials used to sign the
"error-signed" message as well as the "TST-signed" message? 

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

-----Original Message-----
From: Juan G. de la Vega [mailto:[email-masked]]
Sent: Thursday, May 20, 1999 3:44 AM
To: Sarbari Gupta; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-time-stamp-01.txt 

>approach to overload it with transient information such as a nonce.
As a matter of fact, it pleases me that someone addresses this issue.
The
same structure is being used to support every response from the TSA
regardless whether it is a valid time stamp token (with or without
transient
info) or some other semantic token (i.e. "signed time", error
report...).
This rises problems not addressed in this draft, namely:

    -since tstTime is mandatory, and messageImprint must match the
similar
field in the request, problems not related to the time source
(non-existing
TDAs) lead to ambiguous tokens; the time is correct, the messageImprint
is
there, despite the status field states that TDAs were not available,
bearing
in mind that the TST is signed by the TSA anyway, does not this prove
that a
given document existed at a given point in time (Time Stamping!)
regardless
other circumstances (charging for the service is a good example)?

This can be countered by:
    - Making the tstTime OPTIONAL => it is funny that a TST is defined
regarding time as optional but it should not appear when reporting
errors.
    - Different structures for TST and errors => more complex clients.
    - Further specification of TSA's behaviour in error cases (i.e. not
including message digests)
    - Using authenticated attributes to specify error status and
transient
information so that the TST itself would be optional (if status is
erroneous
the content of SignedData will not be present)

Regarding transient information, I agree that it should not be there,
but
nested signatures seems a bit of an excess to me, I believe that using
Auth.
Att. would do or yet better, since we are dealing with transient
information, using transient ligthweight authentication (v.g. SSL)
perfectly
suits its security requirements (what about specifying this within
transport
section?).

I agree with the former but not with the later. In case of error,  an
"error-signed" message would be issued. Otherwise a "TST-signed" would
do.
There is no nesting here.

kind regards,

Juan.

---

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

Comments embedded below (preceded by ==>)

- Sarbari

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Thursday, May 20, 1999 7:09 AM
To: Sarbari Gupta
Cc: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-time-stamp-01.txt

Sarbari,

My comments are along your text.

> 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.

So you have the answer to your question.   :-)
This topic has already been extensively debated and I do not want to
reopen
this thread again.

==> I am still missing the answer that you are alluding to. I seem to
remember that in a previous note on a similar thread, Russ Housley
wrote:
	"I suggest that a one-way hash value of the document or the
document itself
	be used." 
Since nobody countered Russ's note, I was expecting to see the
suggestion implemented in the current draft.  

> 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.
>
> 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 am advocating instead *unsigned errors* as other protocols are doing.
This
means that the status error code has to be separated from the signed
token.
I have debated this point with the other editors which are favoring to
sign
everything and thus why this is included in the current draft. There are
many arguments for *not* signing errors, including performances and the
no
response case when the TSA is unable to sign. I prefer to get back an
unsigned error code rather than no response (as mandated today) in such
a
situation.

In that situation there is no need for multiple signing keys and that
makes
life (and implementations) easier. :-)

==> Unsigned errors may not be acceptable in certain usage domains. The
provision for authenticated error messages (whether through an explicit
protocol or secure transport) should be made in this I-D. 

> 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 have no strong opinion on that topic. I could live with a MAY.

1) as said before the status should be separated from the token,
2) the nonce is there to allow a requester that has no local time to
make
sure that he got a timely reponse from the TSA. So it has to be part of
the
signed structure.

> each of which can be signed by a different key.

This means that nesting is not needed.
==> Logically speaking you are right that the TSA response will either
be an error message or the TST. Depending on the syntax specified for
the response message, a successful response may comprise a signed
message that carries a SUCCESS status, a nonce, and the signed TST (in
which case there is nesting).  

Please let us keep things simple!

==> Agreed.

Regards,

Denis

PS: Do not expect any response from me soon: I will be away from my
office
during a week (without with PC).

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 10:06:22 -0400

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 
> 
> 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
> message within the TST itself instead of using the hash of the reminder
> message. 
> 
> service which allows actual data to be sent as part of the request. The
> all known usage models - the legal implications and network efficiencies
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
> Is there anything to prevent a TSA from using multiple signing keys for
I don't think that I meant that the TSA should only have one key.  I will
change the wording.
> only those clients that are able to parse this extension will be able to
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.

> 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.)

> 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: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 20 May 1999 16:21:06 +0200

>or the third approach sounds fine.

_____________________________________________________
I don´t like the first either ;-) but auth. attrib is also a clean solution.
why don´t you like it? do you regard them as the TST structure?
_____________________________________________________

>"error-signed" message as well as the "TST-signed" message?
_____________________________________________________
Good question. My first impulse is to answer "yes" but if you think in
what you are protecting I would say that the "service key" should be
replaced much more often and the "error-signing" or notificatión key
should be valid for a much larger period of time. Policies I guess...

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 10:49:35 -0400

Juan;

Again, my comments are below.

> ----------
> From: 	Juan G. de la Vega[SMTP:[email-masked]]
> Sent: 	Thursday, May 20, 1999 3:43 AM
I don't see this as a problem.  If the TDAs are not available, the TSA can
still produce a structure that has the time and message imprint included.
The status field would correctly indicate that an error occurred.  If a
token that does not contain all of the TDAs is acceptable to the
application, then it can use it, otherwise it doesn't.

> regarding time as optional but it should not appear when reporting errors.
No.  This creates too many problems

>     - Different structures for TST and errors => more complex clients.
I really don't see a need for this.

> including message digests)
Like I said above, I don't see this as a problem.

> the content of SignedData will not be present)
I don't quite understand this.  Are you arguing for unsigned error messages?
I will respond to that in another email.

> suits its security requirements (what about specifying this within
As I said in an earlier message, I am uncomfortable with changing some of
the underlying assumptions.  I don't want to assume that this protocol will
be run over SSL.

	Robert.

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 20 May 1999 17:18:47 +0200

Robert;

similar
is
>> in mind that the TST is signed by the TSA anyway, does not this prove
that
>application, then it can use it, otherwise it doesn't.

I think I do not get you right. Are you advocating that a structure with a
PKIStatus set to error as  valid and usable?. If this is so, I disagree with
you. I regard that as an error and I would not pay for that, but what I am
saying is that it is still a "proof" and a TSA cannot charge for that
"proof". If you regard the scenario depicted above as acceptable (which
seems reasonable) I recommend to set the PKIStatus to "granted with mods"
instead of  erroneous and I would remove the sentence "A valid time stamp
token will always have value 0 (granted)..." from the I-D.
By the way, I will write other mail regarding the interest for a TDA in TS
protocols.

errors.
>No.  This creates too many problems

I do not like it either, was just thinking aloud.

transient
>I will respond to that in another email.

No. Authenticated attributes are also signed and must be present since the
ContentType to be signed is not PKCS#9 Data, so it is not costly to add
attributes regarding status, and taking advantage of the OPTIONAL nature of
content field whitin SignedData; if an error ocurred then no content would
be present (i.e. TSTInfo).

>the underlying assumptions.  I don't want to assume that this protocol will

There is no need to assume that, you have a transport section in the I-D for
specification.
> Robert.

regards,

Juan.

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 11:34:37 -0400

There is certainly no advantage to including the nonce as an authenticated
attribute.  Doing so would add complexity and the nonce would still have to
be included with the token in order to validate the signature.

> Sent: 	Thursday, May 20, 1999 9:38 AM
> To: 	Denis Pinkas; Sarbari Gupta
> Cc: 	[email-masked]

---

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 20 May 1999 17:53:31 +0200

Robert,

>be included with the token in order to validate the signature.

No, there is not. That was offered as an example of "authenticating" the
nonce whithout being "part of the structure" (TSTInfo) as well as it could
be done at transport layer.

C you,

Juan.

make

---

From: Robert Zuccherato <[email-masked]>
Date: Thu, 20 May 1999 13:04:33 -0400

Juan;

> Sent: 	Thursday, May 20, 1999 11:18 AM
> To: 	Robert Zuccherato; [email-masked]
I am not saying that an error message is a valid token and I am not saying
that it is necessarily usable.  I am just saying that if a TSA wants to
include the valid time and message imprint in all error messages (that it is
feasible for it to do) and this service is explicitly stated in its policy,
I have no problem with that.  In such situations the error message may have
some value as a method to prove the information it contains (but it is still
not a valid time stamp token).  Whether or not you are willing to pay for
it, or any TSA is willing to charge for such a service is beyond the scope
of this document.  

	Robert.

---

From: Sarbari Gupta <[email-masked]>
Date: Thu, 20 May 1999 13:28:06 -0400

Robert,

> > 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.
> > 
> No, but as soon as the TSA is allowed to examine the data and 
> must change
> it's actions based on that data, it is doing more than just 
> providing a
> "proof-of-existence".

I don't agree that the TSA has to examine the "data" to determine if it
dealing with raw data or a hash. One simple way to do this would be to
use your existing structure for MessageImprint (I renamed the subfields
to make it more understandable):

***
MessageImprint ::= SEQUENCE {
	imprintAlgorithm	AlgorithmIdentifier,
	imprintOfMessage	OCTET STRING}

Let us say we designate an OID (let's say XYZ)that represents the
"identity transform" meaning that it does nothing to the input data.
Then your TSA Server code would do the following:

IF (MessageImprint.imprintAlgorithm == XYZ) 
	IF (length of imprintOfMessage > MAXSIZE)
		return FAILURE;
	
ELSEIF ((MessageImprint.imprintAlgorithm == SHA-1)
	IF (length of imprintOfMessage > 20)
		return FAILURE;	
... (for other acceptable imprint algorithms)

USE imprintOfMessage to generate TST
***

Thus, as you can see, when "data" comes in instead of a "hash" the TSA
does nothing substantially different in the realm of "inspecting the
data". What am I missing here?

> 
> > >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.
> > 
> How can we do this (separate transient data from long-lived 
> data) and still
> maintain simplicity and security?

While simplicity is a goal, cleanliness of design is a more important
goal. In other words, we should not sacrifice on architectural elegance
just to make coding easier. I very strongly feel that transient data
should not be included (by design) into long-term objects. 

You ask, "How can we do this ..." - one way to do this would be as
follows:

Define TSAResponse as the response from a TSA:

TSAResponse ::= CHOICE {
	errorInfo		SignedData,  
	tokenInfo		TokenInformation}

For an error information message (of type SignedData) the eContentType
is defined as:
id-ct-TSTerrorInfo	OBJECT IDENTIFIER	 ::= {id-ct 5}

and the eContent shall be of the ASN.1 type TSTErrorInfo.

TSTErrorInfo ::= SEQUENCE {
	status 	PKIStatusInfo,
	nonce 	Integer OPTIONAL}

TokenInformation is an unsigned data structure as follows.

TokenInformation ::= SEQUENCE {
	status	PKIStatusInfo,
	nonce 	Integer OPTIONAL,
	token 	SignedData }

NOTE: When a valid TST is being returned, the status and nonce need not
be signed. The only attack I can envision is possible denial-of-service
but that can't be prevented anyway. 
 	
For a token (SignedData) structure the eContentType would be as in the
I-D, namely id-ct-TSTInfo, and the eContent shall have the ASN.1 type,
TSTInfo.

TSTInfo would be the same as in the I-D except that the nonce and status
fields would be removed. 

The ASN.1 above might need some work, but this is just to give you a
flavor for how the transient info can be separated from the long-term
info without multiple signatures. 

- Sarbari

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 20 May 1999 19:13:11 +0200

> be included with the token in order to validate the signature.
Right. If one wants to remove the nonce, then you would need at least
two signatures. If one has a messageImprint, and the requestor
does not include a nonce, the time stamp token still indicates the
existence of the data, i.e. the hash at that date.

---

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

Rick;

> ----------
> From: 	Rick Wessman[SMTP:[email-masked]]
> Sent: 	Thursday, May 20, 1999 12:16 PM
> To: 	Robert Zuccherato
> Cc: 	Sarbari Gupta; 'Denis Pinkas'; [email-masked]
> How about "splitting the difference" and sending back a signed error
> when possible. If that is not feasible, then an unsigned error would be
> sent back. I agree with Denis that it's better to get something back
> than nothing.
> 
This would still allow TSAs to return unsigned error messages and everyone
would still have to deal with them.  Thus, the potential security problem
remains.  If I get one of these messages how do I know that it actually came
from the TSA?  

> Otherwise, users may get very confused by the lack of response.
> 
Users will still have to handle the case where no response is returned since
sometimes devices do lose their connectivity.  At least when I don't receive
any response, I know that a problem exists.  If I get an unsigned error
message, somebody may be impersonating the TSA, or I might have formatted my
request wrong.

	Robert.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 20 May 1999 20:15:03 +0200

>                                     Rick
I agree, BUT you do not necessarily need a special data element
to carry that information.

First, the ACTUAL protocol, there is NO provision at all to
use any lower layer error signaling . In case of an inability of
signing, the TSA does not try to use any mecanism (sending an http
error, or whetever) to signal that error. the ONLY means for
a requestor is to wait, to retry, and to give up.

Or, a response from the tsa front end http server telling 403,
500 or whatever can by NO means interpreted as a possible signal
of a REAL problem. A TSA based service cannot react with an
http error, the current abstract protocol simply indicates that
there is no way that a client can obtain information to stop retrying.

It seems not unwise to provide such a means in the ABSTRACT layer.
One can say thar for example the tsa would create a specific
lower layer error code.  This does NOT mean that a client
should believe unconditionally that this is true.

A reason to have an optional unsigned response like in LAAP
is to avoid to define for each lower layer transport the
mapping to some error message. In some transport layers this
might even be a little bit difficult. 

The proposition to have some sequence or choice with some status
code around the token, is one way of doing this WITHOUT a need
to map this to lower services. 

In fact having a SEQUENCE does
not make sense to me. As soon as there is a signed response,
whatever status needs to be included in the signature. The
signature validation needs to follow pkcs7 rules, thus you
either make a copy of the status that is already inide the data
or in an attribute. 

The usage for catastrophic errors has nothing to do
with the usage of a signed response. It seems that there is
a confusion because one used the same data structure. 

At least: If the status is granted, there is no need to indicate
this at all in a PKIStatus field (unless you want to add a
free text containing some publicity) ==> PKIStatus optional. 
If it is missing, the status is granted. 

It is a matter of taste to use an authenticated attribute or not.
You can put all and everything into an authenticated attribute. The
DATA provided by a time stamping authority are not arbitrarily long
data where several signers want to add different attributes, or
where you want to communicate the signatures without the data.

There is one intermediate solution that might be worth to be
considered: The data portion of the signed data would just be
the request, and all other information would be in some
authenticated attribute. In this case the TSA can even correctly
signal an error condition that the request had an invalid
encoding for exemple.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 20 May 1999 20:22:45 +0200

> 
> 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.
> 
Right.

A client may be configured to trust all tsa certificates issued by
some trustworthy CA. Since the CA can also certify other entities,
a clear distinction is necessary.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 20 May 1999 20:31:07 +0200

> > 
> > 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
> No, but as soon as the TSA is allowed to examine the data and must change
> it's actions based on that data, it is doing more than just providing a
> "proof-of-existence".
Doesn't the current text already asks for that; what means validation
of a hash function? 

> > somewhat complex, but there are other ways of separating the transient
> How can we do this (separate transient data from long-lived data) and still
Agree, seems difficult with ONE single signature. 

The status is NOT a transient element here. The nonce is such an element,
but you do not need it.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 26 May 1999 18:29:49 +0200

> 
> My response may have been less-than-clear on two points.  First, the modified
> protocol does NOT contain an error value in the TimestampToken.  Errors are
> limited to the second type of response.  This is very different from the current
> draft, which produces data that "looks" like a token, but is not valid since an
> error value is set within it.
> 
> Second, I intended to describe the changes to the current draft in two phases -
> a protocol that returns tokens or UNauthenticated errors, and then a better
> protocol that provides authentication for the error values (to prevent
> spoofing).  The bullet you refer to is meant to describe the first phase, and is
> what I intended.
> 
> To expand:  this first phase of changes to the current draft protocol could also
> allow the server to quietly discard requests that generate an error.  This might
> be an appropriate response when the service is provided over email, or UDP
> channels.  This possibility also falls in to the realm of unauthenticated
> responses, since there is no verifiable response from the server to indicate the
> request was denied.
Why does the first phase allow to QUIETLY DISCARD a request? It seems to me
that the contrary is the case:

The actual text requires that all responses need to be signed, thus in order
to signal an error condition where no signing is possible, the TSA just does
NOTHING, i.e., quietly discard the request.

The proposed unauthenticated answer provides a mecanism to signal this condition
to the requestor, thus the requesting client MAY stop immediately and call the
support center of the TSA or whatever.

The question is: Is this a desirable service? 

> 
> Also, when the second phase of changes is applied (to add authenticity to the
> errors), you can choose to allow (or require) a different certificate to be used
> to sign the error values.  This is also different than the current proposal.
> I'm not convinced it is necessary since the content-type OID in the SignedData
> will clearly indicate the response is not a real time-stamp token, but some
> people may feel more comfortable signing with a different key (and certificate)
> in this case.
Signing with a different certificate has nothing to do with the format of
the signed message. 

It is a matter of taste how to encode the data. Whether this is done using
a separate content OID (TSTInfo and TSTError), or using a choice inside
the data, is really not that important. 

But there is ONE error situation cannnot be handled nicely with the current
text: If the request is incorrectly encoded, the TSTInfo cannot be created
at all. Since the data of the request are the only way to idenify the
request in an error message (sent via mail for example), it seems to
make sense to have a different structure for signaling errors, something
like a sequence of a pkistatus and an octet string that encapsulates the
request or part of it. 

The question here is what kind of service must be provided by the TSA? 

Summary: The proposed changes seem worth to be discussed, but not 
from a pure standpoint of asn1 encoding. This is a service definition
question (IMHO).

Peter