Subject: RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt

From: [email-masked]
Date: Mon, 1 May 2000 16:32:34 -0400

Denis,

In Section 2.4.1, could there be a way for a requester to indicate what hash
and signature algorithms he/she wants on the TimeStampToken in cases where a
TSA would support multiple algorithms since according to the current
definition of the "policy" field in Section 2.4.2, it does not seem to be
within the scope of this field to address this? How would otherwise a TSA
announce to the world what algorithms it uses to sign Time Stamp Tokens and
also what algorithms it supports in messageImprints.  Could the S/MIME
capabilities attribute be used for this?

In Section 2.4.2, in the time stamping response when the "status" field
contains the value one (1), doesn't this mean that a token is also present,
but its format was modified from what the requester demanded? If so, some
text will need to be modified to also indicate that when the PKIStatus
contains the value one and not just zero, a Time Stamp Token is also
present.  Otherwise, it should be clear what only values for the "status"
field are allowed in a response by a TSA.

In Section 2.4.2, it is mentioned that 'The statusString field of
PKIStatusInfo MAY be used to include reason
text such as "messageImprint field is not correctly formatted"', however the
"statusString" field itself, which is defined as PKIFreeText in RFC 2510, is
missing from the definition of the PKIStatusInfo field specified in this
document.  It would be preferable if the PKIStatusInfo field was defined
consistently in both documents.

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5077 Ext. 419
http://www.chrysalis-its.com       Fax. (613) 723-5078

---

From: Michael Zolotarev <[email-masked]>
Date: Tue, 2 May 2000 10:33:11 +1000

> Denis,
> 
> In Section 2.4.1, could there be a way for a requester to indicate what
hash and signature algorithms he/she wants on the 
> TimeStampToken in cases where a TSA would support multiple algorithms
since according to the current definition of the 
> "policy" field in Section 2.4.2, it does not seem to be within the scope
of this field to address this? How would 
> otherwise a TSA announce to the world what algorithms it uses to sign Time
Stamp Tokens and also what algorithms it 
> supports in messageImprints.  Could the S/MIME capabilities attribute be
used for this?
I'd say that the client should be able to verify all 'common' types of
signatures: [RSA/DSA]:[SHA1/MD5].
The encryption algorithm for the signature is defined by the key type in the
TSA's certificate, so the client can find it out before making the first
transaction with the TSA. I do not think that the hash is really going to be
a hard bit for the client.

The same about hash algorithms supported by the TSA for messageImprints -
the TSA should accept all 'common' types. If it does not understand the
algorithm's OID, the error will be returned to the client. So that the
client will have to try a different algorithm. With makes it nothing but
ugly, making me to believe any static information about TSA's capabilities
should be communicated separately from the actual TSA responses. The client
should discover the capabilities of the TSA before transacting, out-of-band
or from some published TSA practice statement.

Regards
Michael

---

From: [email-masked]
Date: Tue, 9 May 2000 13:55:59 -0400

Michael,

>or from some published TSA practice statement.

However, the problem I see with a published TSA practice statement is that
it would not currently lend itself to automation unless XML was used.  This
is why in the first place I had suggested using the S/MIME capabilities
attribute to indicate any static information about TSA's capabilities.
Checking the S/MIME capabilities attribute should not be a major issue for a
requestor since he/she must be able to use S/MIME to verify the integrity of
a TimeStampToken.

Francois

---

From: Michael Zolotarev <[email-masked]>
Date: Wed, 10 May 2000 11:48:26 +1000

Francois,

> attribute to indicate any static information about TSA's capabilities.

I do not think, really, that a TSA client will need to be 'automated', as
opposing to been statically configured for using a particular TSA(s). You'd
never let a TSA client 'go in the wild and free hunt' for some TSA service
out there. The cost, the legal liabilities, the quality of service and a lot
of other factors contribute to the fact that a decision has to be taken to
which TSA to use. Before the TSA can be first used by the client. You
configure the client, telling it to use THAT TSA, with THAT hash algorithm,
with THAT TSA certificate or some other trust parameters. I see the
configuration of the client to be an essentual part of the whole
timestamping framework. But it is just my opinion.

I agree that having the TSA policy and capabilities structured as XML would
help automating the client configuration task.

> requestor since he/she must be able to use S/MIME to verify 

timeStampToken is defined as basic CMS construct. The requestor does not
have to implement/use/understand full S/MIME in order to parse the token.