RE: Major comments on OCSP (and LDAP Sec

[Graham Bland <gbland@xxxxxxxxx>]

Let me try and define the purposes and use of OCSP from my perspective.

If you feel it appropriate could you please post this on to the  ldap ext 
list.

Over a period of time a CA will receive revocation requests for certificates 
for a variety of reasons from a change in status or name to a compromise of 
the keys.
Periodically it publishes the information on all revoked certificates in 
CRLs.
These CRLs will be fairly large and there is a time lag between the 
revocation of a certificate and its appearance on a CRL.

If I am using a certificate chain to authenticate a high value transaction 
this delay is unacceptable.  For practical reasons of distribution and their 
potential size CRLs are unlikely to be published more than daily at the 
most, Delta CRLs solve some of this problem but even if we postulate 60 
minutes as the generation period this still leaves a potential 60 minute 
gap.

An OCSP Responder may be closely coupled to a CA and trusted to access the 
CA database, it therefore has access to the revocation status of a 
certificate as it stands at this moment in time, there is no distribution 
gap.  So it can return a more timely revocation status of a certificate (Not 
the certificate itself) to a Client.

The other use of an OCSP Responder can be to provide the status information 
for other CAs by accessing the CRLs for those CAs.  This approach removes 
the requirement for every end user to:
Retrieve multiple large CRLs
Verify the CRLs
Store in an accessible form the list of revoked certificates (required to 
prevent having to re read the CRLs for every transaction)

Practically in e-mail systems CRLs cannot be retrieved and processed on 
demand when required by a transaction.

Assume I am sat at my PC and have a certificate of an end user to whom I 
wish to secure an Email.  I must retrieve the CRL to validate the 
certificate path from my CA to their CA, assuming this requires CRLs from 4 
CAs I may need to process well over 1 Mb of data depending on the number of 
certificates issued by the CA and the number of revoked certificates. 
Depending on the bandwidth I have to the LDAP servers this will probably 
take too long to leave the user waiting.  4 OCSP requests will be a lot 
quicker.

Secondly the Directory may not exist. If an organization has its own CA this 
does not imply that they also have a Directory server or access to one.

Your detailed comments follow


>Detailed comments in line with text.
>
>
>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.

The directory will not be local so the messaging aspects remain 
approximately the same for both, The bandwidth requirements for a short 
query and response are a lot lower than transmitting back a large CRL. 
 Especially over for example a dial in line.

"Satisfy some" I agree should be tightened up Suggest
OCSP may be used to remove the delays inherent in the publication and 
distribution of CRLs and therefore provide more timely revocation 
information than is possible with CRLs.


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

Either via the id-pkix-ocsp-service-locator  extension in the certificate or 
by a pre configured OCSP server.

>
>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?
>
Exactly the same trust as works in practice I receive a certificate with a 
message and access a CRL based on the information contained within the 
certificate.  It is not on the CRL therefore I know it has not been revoked. 
 Proof that the certificate was issued is provided by the trust placed in 
the signature of the certificate Not its presence or absence on a CRL.  The 
purpose of OCSP is to provide revocation status nothing else.

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

Exactly the same as can be obtained from a directory service Expired 
certificates may be maintained on a directory I believe that no internal 
checking is done if I retrieve a certificate from a directory as to the 
validity of the certificate.  I must check it myself.

If a certificate is placed on a CRL it remains on the CRL until its expiry 
(probably for a short period after that) After that it is removed from the 
CRL  Therefore its absence from the CRL does not imply that the certificate 
is has not expired, this is determined by checking the validity dates within 
the certificate.  Similarly the fact that I have a certificate with a 
signature means nothing until I have validated the signature just as I would 
have to having retrieved a certificate from a directory.
OCSP provides information as to the revocation status of a certificate, 
nothing else.


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

Quite possibly but where, how, which directory service, etc.

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

A loose time synchronization is assumed, the times are specified as a 
Generalised time just as the corresponding fields in a CRL are specified and 
the start and end dates in a certificate are.  Time is the same problem for 
OCSP as it is in deciding if the next CRL has been issued.

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

Why do we need global uniqueness, I am not sure what you mean.

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

Agreed

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

Basically agreed

>snip
>Text
>4.1.2 Notes on the Request Syntax
>
>The primary reason to use both the name and the public key to identify
t>he 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.

Agreed, however we have to work with what we have got, not always the same 
as what we would like.

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

Draft inconsistency already noted

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

Wrong assumption I am afraid.  Timeliness of revocation information is the 
main driving force.

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

Still doesn't solve the problem OCSP does.


--
Zergo Limited, The Square, Basing View, Basingstoke, Hants. RG21 4EG, UK
Tel: + 44 (0) 1442 342 600    Fax: +44 (0) 1256 812 901
Website:  http://www.zergo.com