RE: Major comments on OCSP (and LDAP Sec

[Alan Lloyd <Alan.Lloyd@xxxxxxxxxxxxxxxxxxxx>]

 Graham I do disagree with many of your statements - because they do not
seem to be grounded on practical configurations.. eg. OSI was too big
and too slow.. DAP = 130kb, LDAP = 230kb. LDAP is because X.500 is to
big and the protocols too slow... DSA = 12mb , sub second responses
across 20 DSAs with millions of entries. 

One can always see a case where something wont work. Eg 747s do not
carry 4000 people. But what has to be considered is that operational
system design should put directories in the right place, put CRLs in the
right place and manage those CRLs -  and the necessay trust of cert path
processing to the best advantage of cost, scaleability, trust and
availability of client software.

The document as it stands pre supposees a problem which may not in
reality exist, proposes a weak solution, does not say what the
information management issues are  and in a multi CA domain env, provide
a reality model as to how CRLs are managed and distributed - The
proposal therfore puts fwd a solution (which complicates large scale
system design matters) to something we may not have - if the system is
designed correctly. Pre processing and cashing results may be good idea,
but it has to be examined in the light of operational reality.

words like "time lag in getting a CRL issued". This could occur by the
human procedure taking 2 years and the generation of the crl in seconds
-  does your proposal mean we can shave a second of the 2?

words like: "to authenticate a high value transaction this delay is
unacceptable." what is this delay - are we taking 2400 lines or OC3 ..
what is acceptable- an OCSP server on morse code can be a lot worse than
good directories... 

words like "An OCSP Responder may be closely coupled to a CA and trusted
to access the CA database" is this a distributed X.500 service? If this
is a fast one the client can be coupled to. And in any case the client
MUST fall back to directory based working anyway.

words like: 
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." I am not sure how this actually works - X.509 certs that are not
in a directory - but if this is a local system design issue - why do we
want a standard to optimise it.

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

Do you have any system designs with high revocation rates and the
policies and algorithms used for CRL and Cert processing with
distributed directory systems and then OCSP servers - and also
cost/trust/operational overhead reports?

please supply - I believe in proof of the issue before we create yet
more system scaling and information management problems..



Alans words:
>
>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.

Alan: No but X.500 solves the directory problems and OCSP without a
directory seems a bit unscaleable and certainly complicates the client
software - does'nt it?

regards alan 
--