Subject: RE: finding services : DCS, OCSP, Timestamping, ..

From: Alan Lloyd <[email-masked]>
Date: Tue, 12 Jan 1999 13:26:48 +1100

Thanks for that John. My comments on OCSP also mentioned the use of this
extension in that in a domain agile and global wanderer envrionment -
and to deal with errors or failures in OCSP servers - it would be better
if the certificate did not cryptographically tie its validation server
to the users details. ie. if a "named" OCSP server failed the cert
cannot be validated however, if a fault tollerant and replicated
directory backbone service - that supported many OCSP validation
processes failed, then an alternative validation process can be dealt
with in the system. Its a question that OCSP seems to want to fix the
OCSP server details in the cert, whereas a directory enabled OCSP
approach with-distributed and replicated OCSP server funtions offers
better utility and scaleability without the need to crypto-bind config
info into certs.

just thoughts 
regards alan
> -----Original Message-----
> From:	Linn, John [SMTP:[email-masked]]
> Sent:	Tuesday, 12 January 1999 5:09
> To:	[email-masked]; 'Peter Sylvester'
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Peter, all, re:
> 
> > > IMHO  would be simpler to build a DN based directory service with
> > > logical issuer objects which support many cert based services than
> to
> > > hand configure references of many services in every cert.
> > I guess you missed one point here: The extensions are not in the
> > end user certs but in a cert that describes the service, for exemple
> > in the public key certificate of some OCSP or DCS service. 
> > 
> This isn't how I read ocsp-07, section 4.1, 1st paragraph, which
> states, "In
> order to convey to OCSP clients a well-known point of information
> access,
> CAs SHALL provide the capability to include the AuthorityInfoAccess
> extension (defined in [PKIX1], section 4.2.2.1) in certificates that
> can be
> checked using OCSP".  Absent restatement or rescoping, this seems to
> include
> end users as well as OCSP services themselves within the set of
> certified
> entities for which OCSP-conformant CAs are expected to be able to
> include
> certificate-resident AIA extensions for use in locating an appropriate
> OCSP
> responder.  The remainder of the paragraph notes that locally
> configured
> client data can be used as an alternative to inclusion of AIA
> extensions,
> suggesting that this required capability may not be used in all cases,
> but I
> don't see discussion suggesting that intended use is confined to
> certificates above the end-user level.
> 
> --jl
>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jan 1999 10:51:50 -0500

Alan & John,

>better utility and scaleability without the need to crypto-bind config

I think we have to pay close attention to the specific services in deciding
what constitutes a good way to find appropriate servers.  For revocation, I
think the CA has an obligation to state how/where is makes revocation data
available, because the CA is the ultimate authority for this data.  Thus,
for example, we can bind into each cert one or more CRL distribution
pointers. If a CA chooses to delegate that authority to some 3rd party, it
needs to do so in a highly secure fashion. One could include a set of OCSP
server pointers, which would permit a more robust mechanism, though at the
cost of cert size growth.

For a directory system to provide a highly secure way to discover such
delegation, I think we must have some way for a CA to post a signed, dated,
attestation that provides the equivalent info.  We currently have no
structure for such data.  Also, there is a potential performance tradeoff
here as well, i.e., use of a directory server seems to add another level of
indirection to the process, thus requiring more network accesses, ...

In contrast, use of a timestamping service doesn't seem to be so closely
tied to a specific cert and so it is not clear that a pointer needs to be
included in a cert for such services.

Steve