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

From: Alan Lloyd <[email-masked]>
Date: Mon, 11 Jan 1999 10:15:48 +1100

Some thoughts:
terms like "issuer" in the cert should be used - via a directory
service. - these are logical names of objects in the real world that
provide cert based services such a travel cards, etc. In addition a cert
can be used for authentication in many services so it (the cert) should
be as simple as possible re references to the services on which it is
used. In addition services may change by name/location and physical
properties due to error, compromise or failure - so in that case (where
references to services are tied to a cert) - all the certs would have to
be re issued.

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 do not think adding references in certs beyond that of issuer DN is
the way to go. The danger is that each cert will end up like a web
document and all PKIs will be like the WEB in terms of their management
resources and overheads.

regards alan 

> -----Original Message-----
> From:	Peter Sylvester [SMTP:[email-masked]]
> Sent:	Tuesday, 5 January 1999 3:06
> To:	[email-masked]
> Subject:	finding services : DCS, OCSP, Timestamping, ..
> 
> happy new year
> 
> The current texts of DCS, OCSP, Timestaping do not specify how one can
> find the actual service. It seems useful to me to use some
> certificate extension.
> 
> The service operate (or can operate) in 'signed' environments, thus
> a client has some knowledge of the public key of the service;
> there are some chances that this knowledge comes from a certificate. 
> On the other hand the actual method of getting the service, 
> http, ftp, xyz, and the addresses is not known. It seems 
> logical to me to put extensions conforming to
> 
> pkix part 1: 4.2.2.1  Authority Information Access
> 
> into the certificate that describes the access point and method to
> that service. 
> 
> 
> 
> Peter Sylvester

---

From: Stephen Kent <[email-masked]>
Date: Mon, 11 Jan 1999 17:58:04 -0500

Alan,

>references to services are tied to a cert) - all the certs would have to

I am not a believer in the one-size-fits-all certificate, so I am less
concerned about the possible complexity that you suggest above.  A
reasonable model of cert issuance suggests that users acquire multiple
certs, each of which has limited scope, just like the many forms of ID,
membership, and charge cards we carry today.  This simplifies many aspects
of cert management, especially revocation, and avoids the complexities due
to trying to "trust" one CA for many different credential forms.

>hand configure references of many services in every cert.

Unfortunately, we don't have a global directory service of the sort
envisioned by X.500, so finding a service based on the DN of the cert
issuer is not easy.
PKIX recommends use of an extension that we developed specifically so that
the issuer of a cert can point users to the locations where anciliary
services can be accessed.  If one has suitable directory support, e.g., due
to limited scope or as a result of config data, then it might be a fine
alternative.  However, in an effort to not hold up deployment of such
services while waiting for ubiquitous directory service, ...

>document and all PKIs will be like the WEB in terms of their management

One could easily overdo it, but I don't think we're in danger of that yet.

Steve