RE: AW: self-signed TSA [Was Re: Private Key Cloning]

[Frank Balluffi <frankb@xxxxxxxxxxxx>]

According to RFC 2459 and draft-ietf-pkix-time-stamp-08.txt, the decision of
how to terminate the most-significant end of a certificate path and obtain
the most-trusted public key is up to you (i.e., is a matter of policy).

I recommend that section 2.4.1 of draft-ietf-pkix-time-stamp-08.txt point to
section 6.1 of RFC 2459 with something like:

For more information about validating the certificates in the certificates
field of the SignedData structure and obtaining the most-trusted public key,
see RFC 2459, section 6.1.

The relevant text follows.

Frank

<relevant-text>
RFC 2459, section 6:

This text assumes that all valid paths begin with certificates issued by a
single "most-trusted CA". ... The "most-trusted CA" is a matter of policy:
it could be a root CA in a hierarchical PKI; the CA that issued the
verifier's own certificate(s); or any other CA in a network PKI.

RFC 2459, section 6.1:

The text assumes that the trusted public key (and related information) is
contained in a "self-signed" certificate. This simplifies the description of
the path processing procedure.  Note that the signature on the self-signed
certificate does not provide any security services.  The trusted public key
(and related information) may be obtained in other formats; the information
is trusted because of other procedures used to obtain and protect it.

draft-ietf-pkix-time-stamp-08.txt, section 2.4.1

If the certReq field is present and set to true, the TSA's public key
certificate that is referenced by the ESSCertID attribute in the response
must be provided by the TSA in the certificates field from the SignedData
structure in that response. That field may also contain other certificates.
</relevant-text>

> -----Original Message-----
> From: Michael Zolotarev [mailto:mzolotarev@baltimore.com]
> Sent: Thursday, June 22, 2000 10:02 PM
> To: Peter Lipp; ietf-pkix@imc.org
> Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> I guess the problem is a common misconception that a TSA is always a
> subsidiary/sub-service of a CA. Not necessary. TSA is/can_be 
> a service on
> its own, with no inherited relationship to any CA at all.
> 
> So when NIST starts offering TSA services, it would have to get a
> certificate from some CA? Why? Why wouldn't you trust their 
> TSA certificate
> directly?
> 
> 
> > -----Original Message-----
> > From: Peter Lipp [mailto:Peter.Lipp@iaik.at]
> > Sent: Thursday, June 22, 2000 7:24 PM
> > To: ietf-pkix@imc.org
> > Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> > 
> > 
> > > I'm not convinced it's bad to issue self-signed TSA certificate.
> > > I'm just saying it might not be a great idea.
> > Agree. I don't see the big advantage. For one, if I want to 
> > trust a CA I
> > need to go through whatever steps are appropriate. If the CA
> > offers/recommends/uses a TSA, it can give me a certificate 
> > for the TSA and -
> > having already decided to trust the CA - it is simple to verify the
> > certificate and decide to trust the TSA too. So what does the 
> > self-signed
> > TSA cert buy me besides the need to go through the trust 
> > decisions again?
> > Now consider revocation - do you really suggest to set up a separate
> > revocation-scheme for the TSA? I simply don't see any 
> > advantage here...
> > 
> > Peter
> > 
>