Roadmap issues

["Bob Jueneman" <BJUENEMAN@xxxxxxxxxx>]

Well said, Al.  I can't even keep up with reading all of the various drafts, 
many of which seem like the minor differences between various religious
sects, rather than being something really substantial.  

I'm not trying to stop progress, but I'd like to see some of the existing protocols
widely implemented, and their pros and cons clearly evaluated, prior to 
launching into the YAP ( Yet Another Protocol).

For example,  am still far from convinced of the utility of OCSP, when compared to
multiple CRL distribution points and delta CRLs. Based on the problems
we've had trying to improve the performance of SSL, I don't
relish the overhead of having to sign every individual validation request, 
when the information may not have changed since the last time it was 
requested.

And so far, I haven't seen the legal community come to any kind of 
agreement with respect to the need for, or value of "non-repudiation",
even though I still think it is important.  But that being the case, I can't get
too excited about rushing to support timestamping, etc.

It seems to me that a lot of the recent activity has ben a solution in search of 
a problem, or someone trying to invent and get buy-in to a protocol that will
give them a niche advantage.

To date, the only wide-spread use of PKI is for SSL to authenticate Amazon.com, etc.
Even SSL mutual authentication is not at all wide spread, and S/MIME is 
just beginning to attract some use. 

Various pilots are underway, but real conclusions are still a long way away.

I'd like to propose about a one year moratorium on new protocol developments in this
space, until we can figure out what works, what is interoperable (novel concept!),
and what is actually going to be used.  Then we can address some of the gaps.

"If it ain't broke, don't fix it."

"If it ain't even being used yet, it ain't broke."

Bob






>>> Al Arsenault <awa1@netmail.home.com> 07/06/99 08:09AM >>>


mzolotarev@baltimore.com wrote:

> OCSP, SCVP, and now DCS. It appears that there is more commonality between
> the various protocol's goals, then there is difference. Even the authors of
> the drafts are apparently perplexed when trying to substantiate the work and
> to outline the distinction of one protocol from the others. Writing a [rough
> cut of a] road map would be a nightmare, I'm imagining. Or could it be a
> good, probably even a necessary thing to do at this stage, to see for
> ourselves where we are heading?

Actually, stuff like this (CRS/CMC, CMP, etc.) was what led to the initial cut
at a PKIX roadmap in the first place.  Some of us were tired and frustrated at
having to explain what all the alphabet soup in PKIX was in the first place.

Right now, it seems like we're adopting a "got a problem, get a protocol"
approach.  That is:

    - if you want to communicate between an end-entity and a CA/RA, use CMP
    - if you want to do that using CMS formats, use CMC
    - if you want proof that bits existed at a certain time, use Timestamp
    - if you want proof that bits existed at a certain time, AND that they
possessed certain qualities, use DCS
    - if you don't want to process CRLs yourself, but want to know if a
certificate is valid at a given time, use OCSP
    - if you want to have a server do most of the PKI stuff, and let "thin
clients" just ask servers for the answers, use SCVP
    - ad infinitum, ad nauseum

The problem to me is that each time we introduce a new protocol, we introduce
new overhead, much of which is going to be redundant.

So, the question I ask is, does this working group believe that the right
approach should be:

    (a) continue along the current path of building a "large" number of "simple"
protocols; or
    (b) redesign the architecture somewhat so that there is a small number of
protocols, with options and extensions to handle all of the different services.

To me, the advantage to (a) is that it lets designers have lots of flexibility
in putting together their own PKI structures.  If I don't want OCSP, I leave it
out completely.  If I have a lightweight client, SCVP may be the only protocol
it needs; everything else can be off-loaded.  If I just want timestamp services,
I implement Timestamp and ignore DCS.  et cetera, et cetera.

The disadvantage, though, is that for somebody who's going to do a lot of the
protocols in a "heavyweight" PKI, there's a lot of redundancy.  If I have DCS,
what does Timestamp truly buy me - and is this something that couldn't be better
handled by a slight modification to DCS?  Similarly, if I do SCVP, what does
OCSP buy me?  Would I be better served by defining SCVP to have a mandatory part
that's the moral equivalent of OCSP, with extensions to handle the rest of the
stuff?

Similarly, the disadvantage to (b) is that, if we're not careful, we're going to
force somebody with only a small subset of "the PKI problem" to implement a
large protocol with lots of overhead, potentially causing them to drop out of
the PKIX arena altogether.  The advantage is that my gut feeling tells me we've
got a better chance of getting an interoperable PKI with a small number of
protocols that everybody implements.  (It's bad enough now listening to vendors
pitching me "we implement PKIX", and having to go through exactly which parts of
PKIX they mean, and whether that has a snowball's chance in the Sahara of
actually interoperating with the stuff I've already got.  The problem is going
to grow exponentially very soon, with all the additional protocols we keep
defining.)

So - I'm soliciting feedback from the group on  this issue.  The resolution has
already been reached for CMP vs CMC (approve them both and let the market
decide), and to an extent for OCSP (its scope was tightly constrained to be
certificate status, rightly or wrongly).  But, I don't think we're that far
along with any of the other protocols, and I'd really like to get a sense for
the group's views now, while there's still a chance to do something about it.

We'll put whatever the "right" answer is in the Roadmap, and figure out how to
say it correctly.  Sean did an outstanding job putting together draft -02 of the
Roadmap (I'm afraid I haven't been much help lately :-).  However, it's getting
close to time to advance this turkey to informational RFC (most likely, after
CMC has advanced to Proposed Standard).  So, the sooner decisions can be made
about "approach" the better.

                        Al Arsenault

-- this represents my personal opinion, and may or may not represent the
opinions of my employer, or of any other organization with which I have a
relationship