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

[FRousseau@xxxxxxxxxxxxxxxxx]

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
frousseau@chrysalis-its.com      Tel. (613) 723-5077 Ext. 419
http://www.chrysalis-its.com       Fax. (613) 723-5078