Subject: Who can be a Time Stamping Authority?

From: [email-masked]
Date: Tue, 9 May 2000 14:04:14 -0400

Salut Denis,

At paragraph 10 of Section 2.1 of the TSA Draft, it is mentioned that "a TSA
is REQUIRED to sign each time stamp token using a key generated exclusively
for this purpose and have this property of the key indicated on the
corresponding certificate".

This specific requirement explicitly excludes CAs that would want to offer a
time stamping service using the same key that they commonly used to sign
certificates and/or certificate status information (i.e. CRL or OCSP), which
is fine with me.

This then leave two cases that I think you should describe in the TSA draft:

a.  a TSA with a self signed certificate whose public key is trusted by the
requester; or

b.  a CA designated TSA who holds a specially marked certificate issued
directly by the CA, indicating that the TSA may be trusted to issue time
stamping tokens.

In the first case, each requester must obtain the TSA self signed
certificate by some (out-of-band) authenticated process, which would be
outside the scope of this TSA document.  Because it is mentioned in Section
2.2 of the TSA Draft that the requesting entity SHALL verify the validity of
the digital signature of the TimeStampToken, it is not clear how the
requester could verify the validity of the TSA self signed certificate as
part of validating the digital signature of the TimeStampToken.  This would
probably be a good reason for a TSA self signed certificate to contain an
Authority Information Access extension [RFC2459] as suggested by Michael
Zolotarev, which could indicate how to access the on-line validation
services for the TSA certificate.  Otherwise, the TSA self signed
certificate should probably contain a CRL distribution points extension to
indicate where to find the status of the TSA certificate.

In the second case, the TSA certificate should contain an extension, which
would indicate that this TSA may issue time stamping tokens within that CA
realm.  Since RFC2459 is currently being revised and as suggested by Michael
Zolotarev, the Authority Information Access extension does not seem
appropriate for this particular purpose, I would suggest that a new private
Internet extension should probably be added in RFC2459 to achieve this
requirement.

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: Wed, 10 May 2000 16:43:32 +1000

I guess a need to clarify a few points here, to avoid possible
misunderstanding about my opinion.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 10, 2000 4:04 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Who can be a Time Stamping Authority?
> 

> it is not clear how the requester could verify the validity of the TSA
self signed 
> certificate as part of validating the digital signature of the
TimeStampToken.  This would probably be a good reason for a
> TSA self signed certificate to contain an Authority Information Access
extension [RFC2459] as suggested 
> by Michael Zolotarev, which could indicate how to access the on-line
validation services for the TSA certificate. 
> Otherwise, the TSA self signed certificate should probably contain a CRL
distribution points extension to indicate where to
> find the status of the TSA certificate.
>
This is not what I was saying, actually. I was saying that the only reason
for AIA to be present in self-signed TSA certificates is to specify the
access mechanism to the TSA. In addition, AIA in CA-issued TSA certs CAN NOT
be used for that purpose (specifying the access mechanism to the TSA).
What you are proposing - using the AIA for checking the status of a
self-signed TSA cert - is not going to work, I'd say. This is a problem with
self-issued certificates - you can not trust its own claim about its
revocation status.

So, coming back to my original point, the only reason I can see for a
self-signed TSA cert to have the AIA extension is to specify the access
mechanism for obtaining timestamps. Leaving aside the practicality of it,
and the point that probably AIA is not the best candidate for it. In either
case, the draft should be more explicit about using AIA.

> In the second case, the TSA certificate should contain an extension, which
would indicate that this TSA may issue time
> stamping tokens within that CA realm.  Since RFC2459 is currently being
revised and as suggested by Michael Zolotarev, the
> Authority Information Access extension does not seem appropriate for this
particular purpose, I would suggest that a new
> private Internet extension should probably be added in RFC2459 to achieve
this requirement.
It did not occur to me that a CA may want to designate a TSA as a "Domain
TSA", by placing a special mark into the TSA's certificate. My first
impression is that by doing that the CA would embark on a slippery path of
taking responsibility of TSA operations. Unless this is really the case, and
the CA fully owns/operates the TSA. 
Yet, considering that this can be a real situation, I do not see why the AIA
extension can not be used for that (which is different from your point,
Francois :). It does not contradict to the definition of AIA. The extension
is used by the CA to announce to the world: This is my OCSP. This is my
policy data. <<This is my recommended TS provider for the domain>>. Why not?

To explain all that, the only thing the current draft would have to say is 
***
"If a TSA certificate is NOT a self-signed certificate, and it contains the
AIA extension, the extension MAY be used to indicate that the TSA is closely
associated with the issuing CA's domain.  That is, the CA MAY designate the
TSA to be the 'domain TSA'. In this case, the accessMethod field in this
extension MUST contain the OID id-ad-timestamping, and the accessLocation
field defining the protocol. Note that it is different from just defining
the extKeyUsage=id-kp-timeStamping".

Best regards
Michael

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 10 May 2000 13:10:11 +0200 (MET DST)

> realm.  Since RFC2459 is currently being revised and as suggested by Michael
What does mean 'issue time stamping tokens withing that CA realm'?

> Internet extension should probably be added in RFC2459 to achieve this
It seems to me that what is required is a kind of 'Subject Information Access'
extension as it was available in earlier drafts. The definition is similar
to the AIA by replacing 'issuer' by 'subject'.

Another possibility is to change in 2459:

   The authority information access extension indicates how to access CA
   information and services for the issuer of the certificate in which
   the extension appears. 

to

   The aia extension indicates how to access services related to the certificate
   in which the extension appears. 

The definition of accessMethod must describe anyway how the extension has to be
interpreted.