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

From: Sarbari Gupta <[email-masked]>
Date: Wed, 19 May 1999 13:56:49 -0400

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. 

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

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. 

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

---

From: "Michael Zolotarev" <[email-masked]>
Date: Thu, 20 May 1999 11:19:16 +1000

Sarbari wrote:
---------------------------------------------

-------------------------------------------------

This is yet another voice in support of the idea we have been tossing around
for a few days (in both private and public mails). The reasons for splitting
the message into data and status were the same as you have come up with.
In fact, a similar approach has been proposed by the AC draft.

For your reference:

> The whole structure turns into the following:
>   TSResponseMessage ::= SEQUENCE {
>        statusInfo   PKIStatusInfo -- from [CMP]
>        tsoken       SignedData  OPTIONAL -- TSTInfo with NO statusInfo
inside there
>   }

and another one

> >  TSResponseMessage ::= CHOICE {
> >       tsoken    [0]  SignedData, -- TSTInfo with NO statusInfo inside
there
> >       errorInfo [1]  ErrorMsgContent -- from [CMP]
> >  }

Sarbari actually went further, suggesting an extra signed layer around the
whole lot. Well, this may answer the argument that sending a non-signed
status is a bad thing. Making it optional (leave it to the transport?, using
ContentType? )...

Do you (the Group) think that the subject MAY deserve a broader discussion?

MichaelZ

---

From: "Jose A. Manas" <[email-masked]>
Date: Thu, 20 May 1999 08:41:22 +0200

> of specific models should be weighed by the TSA before it makes its

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

> messages with one or more keys reserved ..."

I think that quite neat!

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

> 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

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: Denis Pinkas <[email-masked]>
Date: Thu, 20 May 1999 13:09:15 +0200

Sarbari,

My comments are along your text.

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

> For example, the TSA may be owned

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

> changing the MUST to a SHOULD or a MAY?

I have no strong opinion on that topic. I could live with a MAY.

>         - other information related to the response such as status,

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.

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

This means that nesting is not needed.

Please let us keep things simple!

Regards,

Denis

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