Re: [IETF-PKIX] OCSP Questions

[mmyers@xxxxxxxxxxxx]

Bob--

We need to come to terms with the OCSP drivers, from which come the
requirements:

We began this work early this year with OCSP as one variation within the
PKIX Part 2 scope.  Mechanisms toward Timestamping, Digital Notary,
Transaction-Based Services and Attribute Authorization are clearly beyond
the scope of the former Part 2.  If not, then the current discussion should
redirect other Part 2 mechanisms to equitably address reliance limits, the
effects of contractual privity and generally the means by which liability
is apportioned in both open and closed PKI models.  With respect to LDAP,
for example, one may require reliance limit attribute per certificate prior
to claiming the LDAP server (or service) is PKIX-compliant.

OCSP's top-level requirement is one of timely access to certificate state.
That is, it is CRLs put online.  Here too there exists a one-to-one
relationship between OCSP and a well-defined scope.  OCSP is no more
broadly scoped than CRLs.  To put it another way, OCSP should not be seen
as a means to arrive at information that is not generally representable as
CRL content.

Attribute Certificates, attribute validation and attribute authority
delegation is a major work area.  After years of debate and standards
drafting, there still does not exist a broadly-based implementation nor
usage of the concept.  I believe we have fairly well concluded however that
the most effective working model is one that provides a reliable identity
independant of attributes that may be associated with that identity.  Thus
mechanisms necessary to confirm the validity of a claimed identity should
be distinct from those which ascertain the validity of claimed attributes.

Lastly, a reality check: my customers need OCSP today.  They have a simple
problem and are looking for a simple solution (notice I did not say "low
assurance" or "weakly secured").  Timestamping, Digital Notary,
Transaction-Based services and Attribute Management, while highly
desirable, are further downline. This too is a reality check, not a
deprecation of their fundamental value in completing the PKI picture. Not
only are they ripe with complexity, but the first three fundamentally
depend upon trusted time--a non-existent quantity.

OCSP solves a simple problem.  True, it's not the whole problem no more
than CRLs are, but it's standard practice to break a complex problem into
manageable pieces.  Timestamping, Digital Notary, Transaction Based
Services and Attribute Management should have separate work items that
identify and define the technology, infrastructure and practices required
to implement them.  A layering of architectural elements, established over
time and in synchronicity with PKI marketplace reality, will move us all
towards these common objectives.

--Mike