RE: TSA draft V7.0

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

Carlisle,

Let me explain my point once again:

The 2459 defines the AIA extension as containing information about the
ISSUER of a certificate. Be it a TSA, or any other certificate. Therefore,
the AIA extension in a TSA certificate is expected to provide details about
the CA that issued that certificate, but not about the TSA itself.

Assuming that a CA generates a certificate for TSA so that the AIA somehow
contains the TSA's details - how would you know if the extension really
contains information about issuing CA, or the TSA? The freedom if
interpretation would be dangerously confusing.


This is why it would be only reasonable to have the AIA in self-signed TSA
certificates.

Regards
Michael


> -----Original Message-----
> From: Carlisle Adams [mailto:carlisle.adams@entrust.com]
> Sent: Saturday, April 29, 2000 12:14 AM
> To: Denis.Pinkas@bull.net; 'Michael Zolotarev'
> Cc: PKIX mailing group
> Subject: RE: TSA draft V7.0
> 
> 
> 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
> > 
> >  
> > 
> >  
> > 
>