RE: TSA draft V7.0

[Carlisle Adams <carlisle.adams@xxxxxxxxxxx>]

Hi Michael,

My interpretation is more along the following lines.  If a CA explicitly
puts an extension in a certificate designating the subject to be a TSA then,
in some sense at least, the time stamp authority function becomes a CA
service.  Thus, I see no conflict with such use of the AIA extension.

On the other hand, if a time stamper independently sets itself up as a TSA,
without any explicit "endorsement" from a CA, then this time stamp authority
function is not a CA service.  EEs will need to discover in some other way
that this is a TSA and will need to install the TSA public key in a secure
(out-of-band) fashion, independent of any contact with any CA.  Use of AIA
in this instance would indeed be contrary to the spirit of RFC 2459, but
that's not a problem since this instance is defined by the assumption that
AIA is not used.

So, I think the text is fine as-is, but I'd be interested in other
opinions/interpretations on this.

Carlisle.


> ----------
> From: 	Michael Zolotarev[SMTP:mzolotarev@baltimore.com]
> Sent: 	Thursday, April 27, 2000 9:35 PM
> To: 	Denis.Pinkas@bull.net
> Cc: 	PKIX mailing group
> Subject: 	TSA draft V7.0
> 
> Denis,
>  
> Something I've just noticed in the draft, which skipped my attention
> before:
>  
> The TSA draft defines how the AIA extension can be used in the TSA
> certificate. 
> ***
> A TSA's certificate MAY contain an Authority Information Access extension
> [RFC2459] in order to convey the method of contacting the TSA. The
> accessMethod field in this extension MUST contain the OID
> id-ad-timestamping:
> ***
>  
> The definition actually contradicts to the 2459 profile which says:
>  
> ***
> The authority information access extension indicates how to access CA
> information and services FOR THE ISSUER OF THE CERTIFICATE in which the
> extension appears. Information and services may include on-line validation
> services and CA policy data. 
> ****
> 
> Note the "FOR THE ISSUER OF THE CERTIFICATE" bit.
> 
> The content of the AIA extension does not depend on who the subject is. It
> only depends on what information access services the CA has to offer. In
> other words, a CA would most probably use the same AIA for a TSA cert and
> for any other entity's certificate it generates .
> 
> The only possible situation I can think of when the definition given by
> the
> TSA draft makes a tiny bit of sense is for self-signed TSA certificates.
> If
> this is the case, the AIA would be presenting a set of protocols that can
> be
> used to obtain timestamps. But then it must be clearly stated by the
> document that only self-signed TSA certs can have that information in the
> AIA extension. Still, it contradicts to the spirit of the 2459, which
> defines the AIA as providing information about how to access the
> certificate-issuing authority, but not the services offered by the subject
> of the certificate.
> 
> The current definition in the TSA draft goes back to the very early
> version
> of the draft. Probably, it is just me who is wrong, and there is something
> I
> simply do not understand. Would like my concerns to be explained.
> 
> BTW, an alternative and in my opinion a better way of specifying the set
> of
> URIs to obtain timestamps would probably be defining a proprietary
> extension
> in TSA certificates. TsaAccessDescription ::= SEQUENCE SIZE (1..MAX) OF
> GeneralName. Non-critical, with the id-ad-timestamping OID.
> 
> Best regards
> 
> M
> 
>  
> 
>  
>