Subject: Comments on TSA Draft v7

From: [email-masked]
Date: Fri, 5 May 2000 12:34:52 -0400

Salut Denis,

Here are few other comments on this draft:

a.  Under Section 2.3 you indicate that "The TSA MUST sign all time stamp
messages with one or more keys reserved specifically for that purpose".  You
should indicate that the reason a TSA would have more than one key reserved
specifically for that purpose would be to accommodate different policies,
different algorithms and/or different private key sizes.

b.  Also under Section 2.3 you indicate that the following object identifier
identifies the KeyPurposeID having value id-kp-timeStamping:

   id-kp-timeStamping OBJECT IDENTIFIER ::= {iso(1) 
                      identified-organization(3) dod(6) 
                      internet(1) security(5) mechanisms(5) pkix(7) 
                      kp (3) timestamping (3)}

However, according to Section 4.2.1.13 of RFC 2459, its object identifier
is:

   id-kp-timeStamping    OBJECT IDENTIFIER ::= { id-kp 8 }

c.  Also under Section 2.3, must not a TSA's certificate contain the
Certificate Policies extension defined in Section 4.2.1.5 of [RFC2459]?

d.  Section 2.4.2, it is not clear what would be the circumstance under
which the error "addInfoNotAvailable (17)" for the failInfo field would be
needed since the "tdas" field was removed;

e.  Also under Section 2.4.2, should not the error "unsupportedVersion (22)"
for the failInfo field also be supported? and

f.  Also under Section 2.4.2, for the policy field of the TSTInfo, should
not the error "unacceptedPolicy (15)" be return instead of the error
"badRequest" when the TSA can not produce a response with a the same policy
as requested by the requester in the TimeStampReq?

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