Major comments on OCSP (and LDAP Security architectures)

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Comments on:

                Online Certificate Status Protocol - OCSP
                        <draft-ietf-pkix-ocsp-05.txt>


All, I wish to raise some issues with the document. In recognising that
considerable effort has gone into it, and it is well presented it has
many issues.

I have copied this to the ldap ext list - and no doubt I will get told
off for that by some.

Reason for this: This affects in a major way LDAP clients, the security
model for LDAP and directories  which is under review at the moment and
the issues of how one supports the OCSP server from a CA and LDAP server
perspective.




From the conceptual level it seems from "this solution" there are
perceived problems with natural client to "directory enabled"
certificate path processing and CRL checking with a client attached to a
scaleable , reliable and distributed directory system (X.500). The
rationale in the document for developing OSCP is not quite clear on this
though. 

And to correct these perceived problems - a protocol (namely OCSP) is
added to an overall commercial system design and this has the effect of
adding many more trust (loss) and reliability issues  - AND  more
operational and protocol over heads - and naturally cost. 
There seems to be no real advantage to OCSP - simply because the problem
is not clearly defined - but have I defined it?.



General Points and Points in line follow.


1. Directories and Certs/CRLs and CAs. In X.500, these are represented
as objects in an X.500 directory - (which is in fact an object oriented,
distributed, name based transaction system on which authentication and
access controls apply). The protocols used for access (LDAP for limited
operations, or DAP) (and DSP - distribution) support this object
oriented information paradigm.
In total this directory environment is engineered as a distributed OO
information system and must not be seen as " just a set of "message"
protocols". 

Cert path processing and the processing of CRLs is a natural OO process
for a client to follow in a distributed system based on certificate
(object)naming properties. The client must be implemented to trust
itself in this act. Otherwise who can it trust.


2. The point raised above is that for certificate paths to be processed
in a wider distributed EC community, it is necessary for the directory
system to be X.500 as that is truly "distributed". This is because LDAP
servers (not LDAP accessed X.500 ones) are not distributed by design (no
DSP) and therefore have the massive restrictions that:

a) Where users need to be authenticated on to many servers, then each
server's DIT must be replicated to every other server. This as we all
know in a very big system, is operationally unworkable and from a system
trust point of view - totally weak.

b) Cert paths are a chain of referenced objects that normally exist in a
distributed system. Therefore LDAP severs (non X.500/LDAP servers)
cannot - repeat CANNOT, process named objects such as certs and crls
over a multi server, multi domain system. Unless massive replication and
hand configuration of knowledge is performed.

Has the proposal been presented to deal with this major flaw and
weakness in LDAP servers to GET ROUND the problem of dealing with
distributed objects (cert paths) in a non distributed LDAP server
environment?
Ie we add to the system YET another server process and yet another set
of non OO protocols. But as shown in the following comments, OCSP does
not cure the problem, -  simply because the problem of dealing with cert
paths DEMANDS a distributed directory system.


3. In a normal client and directory system relationship, the onus is on
the client to verify signatures through repeated accesses to follow the
cert path through the directory system (this may require the tracking of
cross certs to other domains). The OO name based transaction process
that follows these paths is natural and scaleable in a distributed
directory system.
With OCSP, the problem is complicated because the client has deal with
its natural cert path processing in a directory system AND with one or
more non-directory OCSP servers "via messages", which in turn has to
deal with the cert path processing in the directory system. ie. OSCP
really solves nothing - but certainly adds to the cert path process
timing, complexity and cost overheads. 
Do LDAP clients now have to Know the SCOPE of directory technology they
interface to. If they connect to an X.500 distributed system then use
natural cert path processing via LDAP or DAP. However, if connected to
lots of replicated LDAP servers (non distributed) - try OSCP, and if no
luck,  seek out the X.500 working option.


4. Having yet another server in the system adds more network trafic and
delays. And this server still should have to go to the directory service
(LDAP servers/ CAs or otherwise) to determine what certs and CRLs do
exist.
Ie.  I am not sure how these OCSP servers are "FED" with their
certificate information. One can only assume they go to the directory
system (as well as the client) to do the same job - the client software
should have done in the first place.
It is likely that some will say that each OSCP server for performance
reasons is pre configured CRLs and CA certs and these are replicated all
over the place - but this approach does lose trust and does not scale
either - see LDAP server issues - replicate all things to all servers in
all places :(((.


5. The text implies in fact states that the OCSP server can give vague
results ie, A cert can be Valid when it isnt, and Invalid when it is.
This is hardly a reason to complicate a system with more parts, more
overhead, more cost and at the same time less trust. Again scaling such
systems up with these factors engineered in, is bad news for all.


6. The text requires that the client may have to use both directory
tracking Cert path processing in some cases and OCSP in others or in the
case of OSCP rejects, return to natural directory system based
processing. Software maintenace, reliability?

7. The signed ops - trust paths between the client and the server and
the server and the supporting directory system require key management
and no doubt support of yet more certs. What happens about validity and
to compromise issues with these certs/keys.

8. CA design, cross certs, cert management, crl management, and
CPS/security policies are all implicated if this is used.



Detailed comments in line with text.


Snip
Text:
The Online Certificate Status Protocol (OCSP) enables applications to
determine the revocation state of an identified certificate. OCSP maybe
used to satisfy some of the operational requirements of providing more
timely revocation information than is possible with CRLs. An OCSP client
issues a status request to an OCSP responder and suspends acceptance of
the certificate in question until the responder provides a response.

Comment:
It is unlikely that this is more timely: Reading a directory system is
quicker than creating messages to servers, that may not know the answer.
The "satisfy some" words mean what? - This area of the system must be
definitive or it has no trust.

Snip
Text:
An OCSP response consists of a response type and the bytes of the
actual response. All definitive response messages SHALL be digitally
signed. The key used to sign the response MUST belong to one of the
following:

- the CA who issued the certificate in question
- a Trusted Responder whose public key is trusted by the requester
- a CA Designated Responder (Authorized Responder) who holds a special 
  certificate issued by the CA indicating that it may issue OCSP 
  responses for that CA

Comment:
How does the client know to direct any specific name or certificate item
to any specific OCSP server, is this a directory function? That needs
more configuration, more schema and more processing.

Snip
Text:
This specification defines the following definitive response indicators 
for use in the certificate status value:

- notRevoked
- revoked
- unknown 

The notRevoked state indicates that the certificate is not revoked. It
does not necessarily mean that the certificate was ever issued. Nor does
it mean that the certificate is in its validity interval.

Comment:
This has no value - ie a not revoked status when the certficate might
not exist....????? What TRUST does one place in that?

 Text: 
A notRevoked state by an OCSP responder DOES NOT absolve the application
of the responsibility of checking that the certificate is in its
validity period and has been correctly signed. For example, it is quite
possible that an OCSP responder returns the notRevoked state if a
certificate was revoked, but has since expired (equivalent to a serial
number being dropped from the CRL). 

Comment:
This has no value - ie a not revoked status when the certificate is
invalid? What TRUST does one place in that?
 

The revoked state indicates that the certificate has been revoked.

The unknown state indicates that the responder doesn't know about the
certificate being requested.

Comment - in this case the client must do the right thing and go to a
distributed directory service.


Snip.

Text:
2.4 Semantics of thisUpdate, nextUpdate and producedAt

Responses can contain three times in them - thisUpdate, nextUpdate and
producedAt. The semantics of these fields are:

- thisUpdate: The time at which the status being indicated is
              known to be correct
- nextUpdate: The time at or before which newer information will
              be available about the status of the certificate
- producedAt: The time at which the OCSP responder signed this
              response.

Comment: Does this mean that the client software also keeps timing state
and synchronism with the OSCP server(s) - different time zones,
different servers? How?

snip
Text:
2.6 OCSP Signature Authority Delegation

The key that signs a certificate's revocation information need not be
the same key that signed the certificate. A certificate's issuer
explicitly delegates OCSP signing authority by issuing a certificate
containing a unique value for extendedKeyUsage in the OCSP signer's
certificate.

Comment: 
how is uniqueness achieved - globally?


Snip
Text:

3.1 Certificate Content

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 PKIX Part 1, section
4.2.2.1) in certificates that can be checked using OCSP.
Alternatively, the accessLocation for the OCSP provider may be
configured locally at the OCSP client.

Comment:
For all those designing CAs - putting URLs, etc in certs that relate
domains is downgrading the real life OO name based model of distributed
directories. Ie my cert and my name in this URL approach ties my cert/
CA to a physical computer system domain instead a real life logically
named domain. Lke amex, visa, etc.

Text:
CAs that support an OCSP service, either hosted locally or provided by
an Authorized Responder, MAY provide a value for a
uniformResourceIndicator (URI) accessLocation and the OID value
id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

Comment:
Scaleability issues apply and lots of configuration management
overheads.

snip
Text
4.1.2 Notes on the Request Syntax

The primary reason to use both the name and the public key to identify
the issuer is that it is possible that two CAs may choose to use the
same Name (uniqueness in the Name is a recommendation that cannot be
enforced).

Comment:
Well it is in a distributed interconnected directory system such as
X.500 - but it is impossible to prove/get unique names with detached non
distributed LDAP servers.


Text:
Two CAs will never, however, have the same public key
unless the CAs either explicitly decided to share their private key, or
the key of one of the CAs was compromised.

While it is possible to identify a certificate by sending over either
the entire certificate or just a CertID, it is recommended that clients
use just the CertID to reduce the size of the request.
However, certain OCSP responders MAY require the entire certificate
whose status is to be determined.

Comment:
 This is questionable. Do we have to implement Options in the clients
(ie to select cert Ids or certs) and servers that, depending on the
relationship between the local client, its OCSP server(s) and those OCSP
servers with their Cas, and their Cas with other Cas that have the
relationship with clients that used the private part of the key to form
the original message to the local client - And that all such
relationships could be different on a case by case or connection by
connection or key management basis???

Unworkable, or Unworkable or it could be unworkable!!



 I skipped the rest I am afraid.

I have assumed that this proposal has been developed because of the
fundamental issue with non distributed LDAP servers in that they cannot
do mutual authentication between servers (no distributed User trust) and
they cannot do distributed cert path or crl processing.

The fundamental principle of directories is that they are named based OO
distributed systems where objects such as certs, see also, role
occupants, etc can be "followed" through a number of directory domains.
The concept is simple, it works. But LDAP and LDAP servers have missed
this fundamental concept out. To resolve this the solution seems to "add
another protocol and server" to the system, complicate the client, add
to the cost risks and operational overheads..

The real solution to this problem is to use X.500 distributed
directories with LDAP or DAP access.




Perhaps the situation is: It is unlikely that OCSP is required where a
distributed X.500 directory system is used. In this case the system has
less software in the client, and is less complex, less costly and from
an operational perspective many times easier to support and scale. In
addition CA design, CPS's, security policies and trust/cost models are
simpler.

IF however, non X.500 LDAP servers are used and because cert path
processing is impossible with these, this OCSP server could be added.
However, again, this adds considerable complexity to the system, its key
management, etc, etc and costs in dollars, reliability, scaleability,
performance and human configuration effort AND the development of CA
trust / information models and CPSs to support these new devices... .
And the way in which OCSP servers get their information is left to the
deployer.

Regards alan