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

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

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:Peter.Sylvester@edelweb.fr]
> Sent:	Tuesday, 5 January 1999 3:06
> To:	ietf-pkix@imc.org
> 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