Subject: some comments on OCSP vs 7

From: Alan Lloyd <[email-masked]>
Date: Tue, 17 Nov 1998 16:28:37 +1100

A quick review - and some operational issues.

Also agree with discussion re Explicit tags. I am not concerned re bytes
on the wire - but they are not consistenly used and make the ASN.1
"clunky".

General comments - from a system perspective is the usual Hows and When
issues.

3.2 
1) an OCSP responder can have the same (private) key as the CA who
issues the certs being validated.
There may be more than one OCSP responder and there may be many CAs who
want to use them so that a client can be simplified in a multi cert
domain environment. This just requiresprivate key distribution and
management. Not good IMHO.

2) CA designated responder - this means that the clients requesting
validation by an OCSP responder must also validate the responder - in
the same way they would have validated the CA if the OCSP responder was
not there.

3) The "good" state para is a worry re "a good state does not
necessarily indicate that the certficate was ever issued" ???! All this
engineering and no trust.

4) The "Unknown" state - I suppose that means that the client goes back
to directory based validation or gives up.

3.3
1) Internal Error - OCSP responder in an inconsistent state - try
another server.
If the extensions in the certs contain AuthorityInfoAccess - with a
sequence of entries, then by defintion the client could go through a
sequence of responders - This does mean however, that a system's fault
tolerant strategy and its system configuration is cryptographically tied
to a cert. This is not good as it means a very inflexible system and a
lot of pre knowledge.
If on the other hand this extension is not used - then the fault
management strategy is a client configuration issue. My concern is that
this scenario is a bit like a telephone being configured with all the
PABXs it can talk to. ie. lots of hand configs and not generally
applied.

2) Try Later - Hmmm
left for a long time will cause a failure in the transaction being
verified.
tried rapidly and frequently will cause protocols and servers to burn
out.

How is "try later" applied to make it operationally useful. I get
concerned that timers and counters (as used in lower layer protocols) to
stop looping for ever, are not included in the spec. ie. these things
also need common configuration definition.

3.4
Updates - 
What does the client do if next update is set to an hour or so infront
of the current time.
Should all client software have a "window" in which requests can be
fired off to the OCSP server and valid responses seen - AND that if the
next update is greater than nnnn it does something about it? What is the
process here under these conditions?

3.6. 
1) The client must check that if the OCSP server signature is not that
of the cert issuer, then it must check the OCSP server cert to see if
the extended key usage is set and the the fact that the OCSP server
cert's Issuer CA is a valid signature for the OCSP server's cert. HMMM

3.7
1) This must be corrected as its very bad to have a trusted function?
that "knows" a CA key has been compromised and the MAY mention the fact
to the supported clients.
a) Does the spec need to say how this key knowledge is provided and it
MUST invalidate all.
Otherwise the text has no substance.

4.1
Issue re crypto binding of system config knowledge is IMHO not a good
idea - or otherwise configure the client software - for any server that
will be used by many CAs/originiators of signed transactions. This does
represent a scaling issue in the making.

Thoughts are welcome. But the concerns are of scaling and the multitude
of conditions that need to be dealt with and  at the end of the day, the
client will probably still have to validate the OCSP's sig  cert path
and other certs via the normal method... via directories.

regards alan

---

From: Andrew Probert <[email-masked]>
Date: Fri, 27 Nov 1998 16:47:00 +1100

If the purpose of this RFP is to quickly find / identify a specific
certificate and its status, rather than trawl through CRLs, then it
seems to me that that rather than adding additional protocol and trust
management to validate certificates, that some of this could be moved
back into the CA and directories, as follows: -

*  When a certificate is revoked, put a CRL style wrapper around the
individual certificate (rather than just its Issuer & Serial), with
Revocation DateTime, Reason Codes etc and the CA signs it, to create a
RevokedCertificateObject
 
*  This RevokedCertificateObject can be stored into a nominated arc of a
DIT along with all other revokedcertificatesobjects

*  I would tend to add additional attributes into the directory's
representation of this object, to improve searchability i.e. SubjectDn,
Validity Date / Time,    MD5 Hash Fingerprint), KeyUsage periods etc as
this is a simpler alternative than implementing certificate matching
rules on the server and helps with reporting / summarisation.

The benefits of the approach are as follows: -

* Existing LDAP / DAP protocols can be used for queries

* Existing directory functions are used to quickly retrieve an object.
If its not found, its not revoked, if its   found the reason codes and
CA signature are readily accessible as part of the object.  Matching on
the client side is easy because you retrieve a copy of the certficate
and can do a compare, as well as all validations.

* Backend DISP / DSP are available for shadowing and distributed queries
is possible, respectively, although I would probably use something with
more guaranteed service than DISP.

* The CA's private key does not need to be available to a Responder
task.  Signing of revoked certificates is a behind the scenes / trusted
function.

* The complexity of Designated Responder key management is avoided

* Online real-time certificate validity checking is available through
online real-time directory support, without needing to invent a new
protocol.

* The user receives an object of real value, because they could archive
/ keep it for proof of revocation, without requiring the whole list.

CRLs have their place as a list of revoked certs and are good for the
process of batch distrubution, but I have always felt that they do not
make for
good online / realtime retrieval purposes.

Directories are pretty fast and reliable now, so we should leverage
their capabilities by adding to information models over existing
protocols.

Andew Probert
Rotek Consulting 
a Division of Secure Network Services
+61 3 9690 8877