RE: Who can be a Time Stamping Authority?

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

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

> -----Original Message-----
> From: FRousseau@chrysalis-its.com [mailto:FRousseau@chrysalis-its.com]
> Sent: Wednesday, May 10, 2000 4:04 AM
> To: Denis.Pinkas@bull.net
> Cc: ietf-pkix@imc.org
> 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