Subject: STRAWPOLL: ABSTAIN (with explanation)

From: Carlisle Adams <[email-masked]>
Date: Wed, 29 Jan 2003 10:41:43 -0500

Hi,

On a conceptual level, I like the framework that OCSP started with:  a
request/response protocol to ask an authority questions about the status of
a certificate.  "Status" might mean "has this certificate been revoked?"
(most implementations of OCSP today are built to answer precisely this
question).  However, "status" along with a policy can mean "is this
certificate OK with respect to this policy?" and "status" along with a trust
anchor can mean "is this certificate OK with respect to this trust anchor?"
(i.e., is there a valid path connecting the two?).  This is not overloading
the word "status".  This word already means different things in different
contexts; whether something is "OK" or "not OK" depends entirely upon
context.  The goal of the OCSP framework was to choose a default meaning to
solve an immediate need in a simple way (unadorned "status" is equivalent to
"revocation status") and to allow other meanings to be indicated through the
extension mechanism so that future needs can be met relatively easily.  I
think this framework is powerful and conceptually attractive.

DVCS is also a powerful framework.  However, the scope of interactions it is
intended to address is much broader than OCSP, looking more at validating
and certifying arbitrary data (including signatures, certificates,
contracts, etc.).  Thus, although path validation and path discovery are
technically subsets of the interactions that DVCS can handle, I wonder if
developers/users will find the overall breadth too rich or confusing for
their DPD/DPV needs.

My strawpoll vote therefore leans toward OCSP.  However, the last version of
SCVP I read in any detail was several drafts ago, and I must confess that I
have not yet found time to read the CVP draft at all, never mind all the
corresponding compliance matrices.  In good conscience, then, I feel that I
have to abstain on this vote.

Of course, given the requirements spec that PKIX has published, any of the
candidates can be engineered to fit the bill.  So, in this sense, it does
not matter in the least which one we pick (as long as it is only one!).  I
like the idea of a single framework, rather than one protocol for revocation
status and a completely different protocol for other kinds of status, but I
can live with whatever outcome the WG members and chairs choose by rough
consensus.

Carlisle.