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

From: Alan Lloyd <[email-masked]>
Date: Tue, 12 Jan 1999 15:20:31 +1100

Agree with most you say and I am a realist you know. However, may I make
the point, as below.

> -----Original Message-----
> From:	Stephen Kent [SMTP:[email-masked]]
> Sent:	Tuesday, 12 January 1999 9:58
> To:	Alan Lloyd
> Cc:	'Peter Sylvester'; [email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> >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.
> 
> 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.
> 
> >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.
> 
> 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.
	[Alan Lloyd]  
	This comment is common in that we (the planet) does not have a
global directory service, therefore we wont use it.
	In terms of engineering systems, a directory service is a
function - and should be seen as just that ie. it is a distributed
object oriented function - with auth and access control properties - and
regardless of scale and operational deployment - if directory services
are considered as a supporting information infrastructure that will be
applied in many vertical markets and organisations for many operational,
information management, security and service delivery reasons, then why
not incorporate such functions into such things as PKI.

	Its like that when OCSP or LDAP or HTTP were invented they all
assumed and relied on the fact that TCP/IP and the Internet existed and
was serviceable and they used that. When X.500 was designed it assumed
underlying comms/Internet were there to support inter directory
operations. When X.509 and CAs and the X.500 distributed authentication
model was put together it assumed a distributed directory service with
DSP, DAP (and LDAP) were available. 
	By putting and crypto binding system config/directory references
into certs and mapping subjects and issuers to the URLs of servers - all
we are doing is operationally placing single directory entries all over
the place in a fragmented and possibly uncordinated way - ie
operationally if a directory service is not used. The certficate by
definition becomes a directory entry (ie it related names to server
addresses) and the humans that manage (the millions of these cert/dir
information things) - become the directory infrastructure.

	Not good for operational approaches re cost, reliability and
scaling.
	 I think directory supported OCSP servers will be the way to go.

	just thoughts and regards alan

> 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, ...
> 
> >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.
> 
> One could easily overdo it, but I don't think we're in danger of that
> yet.
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Jan 1999 11:02:47 -0500

Alan,

>Agree with most you say and I am a realist you know. However, may I make

<deleted text>

>not incorporate such functions into such things as PKI.

I'm not sopposed to directory services, but from a security perspective I
don't want to make PKIs too dependent on them.  For some range of
PKI-enabled applications, e.g., IPsec, we don't strictly require
directories, and to introduce a dependency would result in a less secure
system, e.g., in terms of availability, and may also degrade performance.
In other cases, e.g., S/MIME, we clearly benefit greatly from directories.

>DSP, DAP (and LDAP) were available.

Yes, but not all of these examples are equally true.  TCP/IP does exist,
and the Internet does exist, but DSP/DAP and global X.500 directories do
not, in general.  Thus, the PKIX WG has worked to minimize this dependence,
to make use of X.509 technology more useful in the Internet.

>information things) - become the directory infrastructure.

I think this is an overstatement of the current situation, but agree that
one could head this way.  I've have long argued against putting directory
entry data into certs (especially when it is not verified!), for the same
reason.  However, I think we have to look at each data item and asses the
security and performance implications of putting it into a cert or relying
on its availability and integrity in a directory.  For different data
ietems we should expect to come to different conclusions.

>	 I think directory supported OCSP servers will be the way to go.

OCSP servers may use directories, or may use private databases, depending
on scope.  For example, if I, as a CA, decide to offer OCSP service for the
certs I issue, I don't need to use a full fledged directory for that
purpose.  However, if I operate a third party OCSP service, I may want to
collect revocation data from directories, if available.  Alternatively, I
may simply have CAs e-mail me their CRLs.

Steve