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

From: Peter Sylvester <[email-masked]>
Date: Mon, 4 Jan 1999 17:05:31 +0100

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: Peter Sylvester <[email-masked]>
Date: Mon, 11 Jan 1999 13:41:54 +0100

> 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 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. 

I am not talking about any protocol that tells you how to get from 
an end user cert to whatever service provider. 

Certificates for OCSP signing or DCS services are rather special
things. They are really end user certificates but closely related to
CAs. 

> 
> 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.

I fully agree with you that filling end user certificates with such
information would not be a very good idea.

---

From: "Linn, John" <[email-masked]>
Date: Mon, 11 Jan 1999 13:09:01 -0500

> 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: Peter Sylvester <[email-masked]>
Date: Mon, 11 Jan 1999 19:41:17 +0100

Actually, the second and third paragraph of 4.1 seem to describe
what I have been asking for if one changes the following text.

   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 
+  or in in certificates for CAs or Authorised Responders.
   Alternatively, the accessLocation for the OCSP provider may be
   configured locally at the OCSP client.

Two scenarios:

- A end-user client has some knowledge about one single local provider
  (kind of local proxy/broker).

- An end user-client (which may be the proxy/broker) knows about CAs
  and the OCSP providers. 

The first case can be covered by 'a local configuration'. if one
wants OCSP requests to be signed, then this local configuration
would contain a public key of the local proxy, probably in a
certificate, and it makes sense to me to have the indicated
extension in this certificate.  

In the second case, I would see the extension in a certificate
describing an issuer's service for ALL certificates issued
by the issuer. 

Similar remarks for DCS etc. are left as an exercise

---

From: Alan Lloyd <[email-masked]>
Date: Mon, 1 Feb 1999 09:11:37 +1100

> -----Original Message-----
> From:	Stephen Kent 
> Sent:	Sunday, January 31, 1999 7:16 AM
> To:	Alan Lloyd
> Cc:	'Stephen Kent'; [email-masked]
> Subject:	RE: finding services : DCS, OCSP, Timestamping, ..
> 
> Alan,
> 
> < much text deleted>
> 
> >	One can cite if one attacks a directory entry but I would expect
> >that a CA entry with its cert and CRL DP, etc is well protected from
> >casual writes - protected via authentication mechanisms and access
> >controls for CA modification only. The same issue would be with an
> >unprotected DB .
> 
> Certs and CRLs are signed and thus we rely less on the directiry
> system to
> protect them, since tampering is evident to the user.  As soon as we
> talk
> about relying on unsigned data items in a directory, the security
> situation
> is quite different.
> 
	After N years with military X.500 and PKIs I think I do
understand this. But in addition to signing data, we can also place
"some" trust on the distributed authentication and access controls of
the directory system. Particularly when the user or certficate reader
has been requested to do strong authentication on the directory service
itself to read the CA entry. We do deal with trusted directory systems
you know.
> >
> >	At least the directory provides a distributed, profileable -
> >authentication and ACI regime which will be designed and deployed
> >according to a cost/trust and service model.
> 
> Yes, but that regime should not be relied upon for cert processing,
> exccept
> to mitigate denial of service concerns, i.e., one shoud rely on a
> directory
> in a cert processing context only to the extent that one needs some
> repository for signed objects.  To extend that reliance to unsigned
> objects, in a fashion that could undermine the security of cert
> processing,
> would be negligent.
> 
	And in the case where this extra strengh is needed we can do
strong auth and signed ops on the directory service.. with DAP - you
know the protocol thats half the size of LDAP with twicw as many feature
including trusted signed operations :-))).

> <lots more text delted>
> 
> >	However, with a robust - distributed directory service - that is
> >designed to be robust - some of those concerns should dissipate.
> After
> >all the phone system is a very big infrastructure that in general
> >supports a service and one tends to think that any failure in any
> >component does not bring the whole system down. Infrastructure design
> >always makes sure that their is no single point of failure for the
> whole
> >service and that any failure only criples a componenet of area of the
> >service.
> >	All I am saying that directory system designs should parallel
> >the phone system re replicated/distributed paths and redundancy
> >features. Thus a "trust" can be placed on them - like any
> infrastructure
> >- water, gas, roads, etc. Otherwise what is the alternative to the
> >design of large scale systems?
> 
> Well, I now work for a phone company, and I do not believe the analogy
> is a
> good one.  Directories in the phone system have very simple access
> models
> and (legitimate) subscribers have very restricted access capabilities.
> When phone phreaks have gone after the phone system, they are often
> successful. The fundamental issue here is that one should rely on any
> infrastructure ONLY to the extent that is intrinsic in that
> infrastructure.
> When we rely on infrastructures in ways beyond their design intent, we
> get
> into trouble.  the OCSP server ID example does that, in my opinion.
> 
	We need to talk re the two paradigms. Many people find the phone
system/directory system paradigm very useful.
	As for infrastructures. They tend to be in fact very big systems
- by definition. If OCSP wants to be big - it will become an
infrastructure - but if it wants to be big it will have to be supported
by a big distributed information base... some thing like a directory
service. Otherwise its hand carved...

> <still more text deleted>
> 
> >>
> >	Thats the CA theory view that may not serve an operational
> >world. The transaction with a cert has a business/policy component
> also
> >and that must be tied to the cost/trust/business models that apply
> >certificates. ie. the theoretical CA model need not rule in all
> cases.
> 
> Of course PKI designs are driven by many factors, but that doesn't
> mean we
> have to be sloppy about security, and you have not provided any models
> that
> quantitatively compare the tow models we are debating.  This is the
> PKIX
> mailing list in the IETF; we worry about real CA concerns, not just
> theoretical ones. Your directory-centric perspective on these issues
> strikes me as much more theoretical :-).
> 
	Theory ! Oh really. How many OCSP servers will be needed for 100
m users. What is the information system that supports this?
> <yet more text deleted>
> 
> >	As said, when one designs a distributed directory service
> >infrastructure with directory enabled processes attached to the
> service
> >for such things like org chart generation, subject matter context
> >clumping  and possibly cert validation and... specialised seach/data
> >engines for fingerprint validation, etc , then these processes by
> nature
> >are context sensitive (or insesnitive) - mult path, distributed
> >processes . ie with directory enabled distributed processing, the
> whole
> >system, service and processing paradigms change - including the
> >configuration and single point of failure models.
> >
> >
> >	The telephone network is very similar to the PKI validation
> >model that is needed for global services. Multi domains, multi
> services,
> >global roaming and distributed-fast authentication. As directories
> make
> >the phone system work, so will directories make big PKIs work.
> 
> As I noted above, I work for a large phone company and I dispute the
> validity of the analogy.  What it seems to boil down to is an
> assertion by
> you that directories will be ubiquitous, very fast, ultra reliable,
> and
> sufficiently secure so that we should abandon the crypto-integrity
> model
> upon which X.509 is based.  
> 
	Thats it. Got it in one. 

> Clearly this is not the case today, so let's
> just see if the directory model you envision comes to pass.  if so,
> I'll
> withdraw my objections.  
> 
	Its coming to pass. Simply bnecause all those "servers" being
promoted need ... wait for it...
	Information and for that information to be applied in a
distributed and common way.

> However, in the mean time, I suggest that we not
> degrade the security of PKIs based on these projections.
> 
	No infact we are enhancing the PKI with the reality of deployed
directory systems.
	A PKI without a business purpose and information and service
deployment scaleability will be an orphan technology.
	regards alan

> Steve

---

From: Andrew Probert <[email-masked]>
Date: Mon, 1 Feb 1999 11:23:04 +1100

I have watched this dialogue with interest.

I must admit to being a fan of directories of any sort and can't but help
comment on some real-world recent things I have seen, in favour of the
approach..

The internet is build upon DNS (Domain Name Servers), DHCP (Distributed Host
Control Protocol) et al.  Serious vendors such as CISCO have bought
companies like American Internet Corporation to get a hold of infrastructure
technologies to help them scale and lo and behold we see things like Radius
Servers being bolted up to directories to give them the sorts of backends
that can scale and perform.  

How many ISPs can you name that have woeful performance on initial
connections, whilst I assume they grovel around in poorly designed backend
database to find billing and profile information?  A directory should be
considered to publish customer details internally to a service provider as
well as a restricted profile of information to the outside world!

Sure systems can get pretty large upon lightweight technologies such as DNS
etc, but they are definately creaking at the seams, especially when some
maniacs are suggesting the next step of extending DNS servers with
Certificate storage capabilities.

Andew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions
Tel  +61 3 9690 8877
Fax +61 3 9690 8171

> From:	Alan Lloyd [SMTP:[email-masked]]
> Sent:	Monday, February 01, 1999 9:12 AM
> To:	'Stephen Kent'
> Cc:	[email-masked]