Subject: RE: Initial comments on SCVP

From: [email-masked]
Date: Tue, 6 Jul 1999 16:24:04 +1000

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? 

It would also help other people, from the non-directly PKI-related problem
areas, to realize where we are and to start contributing to the group.

MichaelZ

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Tuesday, July 06, 1999 4:01 PM
To: [email-masked]
Subject: RE: Initial comments on SCVP

Hi Mike,
    Thanks for taking the time to read the draft and compose these
comments. Since I am on both the OCSP and SCVP drafts, I think I
need to address them.

I actually see OCSP and SCVP addressing pretty different needs and
most probably pretty different communities of users.

OCSP essentially deals with the status of a certificate (and
potentially, other attributes of the holder/account associated with
that certificate). It is a mechanism for a client to ask for
information about a particular cert.

SCVP is mainly directed at making it easier for applications to use
PKI. Yes, it does deal with cert status, but it also deals with
issues like chain building, policy management etc. The main goals
are:
1. To make it easier for an application to use PKI
2. To make it easier for an organization to deploy PKI (by allowing
them to control policy etc.)

I think of OCSP as being an infrastructure protocol, to help provide
up-to-date status information - something that is run as an underlying
mechanism. I see SCVP as something that is used between a low end client
and a server it trusts, to offload the complicated parts of PKIX.

Hope this clarifies the issue.

More comments inline:

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, July 02, 1999 6:28 PM
> To: [email-masked]
> Subject: Initial comments on SCVP
> 
> 
> Ambarish, Paul:
> 
> A very timely draft.

Thank you.

> 
> I've got to wonder though if we need yet another online 
> protocol or if we'd
> be doing our job better by building on our prior work. Both 
> OCSP or DCS have
> achieved a fairly stable level of maturity in the IETF.  In 
> fact, OCSP is
> now RFC 2560.  Upon reviewing the proposal, it seems to me that either
> provide a more stable platform for addressing these requirements.
> 
> OCSP was in its inception aimed at solving the more general 
> certificate
> validation problem. At the request of several very large 
> stakeholders who
> intended to rely on OCSP for Internet-based financial 
> transactions, we chose
> to first deal with the revocation problem, recognizing that via
> extensibility we were architecting a more general certificate 
> validation
> framework.

Mike, I thought it was reasonably clear from previous OCSP debates
that OCSP just returns the status of the certificate(s) asked for -
it doesn't do any additional chain building or chain validation (I
think I remember some explicit comments about that not being part
of OCSP).

> 
> Let's build on that, especially since it was the original 
> intent of OCSP to
> do so.  With the investment people are today making in 
> extensible OCSP, that
> only makes sense.

A lot of SCVP was designed after seeing how people were trying to
use OCSP - there are applications where OCSP makes sense. There
are others where SCVP works better.

> 
> It would relatively straightforward to publish an extensions 
> document. Doing
> so, we would have the advantage of incrementally building on 
> a existing RFC
> specifically intended to be extended in this fashion, for 
> specifically this
> need, rather that totally revinent what that RFC has already 
> established.

Not at all - OCSP fundamentally assumes that you as a client
will to do all validation yourself and are only using OCSP to
query the status of a certificate. It was never meant to work
in an environment where you had no idea of the chain being used
to validate the certificate - remember we use the issuer and
serial number to identify the certificate - not the certificate
itself.

> 
> Otherwise, what's the advantage of replacing a protocol that 
> has already
> been ratified by the working group and promoted to proposed 
> standard status?
> Especially since the requirements being met by the proposed 
> protocol are
> already met or are intended to be met by extensions to 
> RFC2560?  I just
> don't see a compelling case being made for so radical a revision.
> 
> I'm compelled to ask the group at large if others share these 
> sentiments.
> Perhaps I missed something.
> 
> Mike
> 
> 

Regards,
Ambarish

---

From: Al Arsenault <[email-masked]>
Date: Tue, 06 Jul 1999 10:09:17 -0400

> 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

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 6 Jul 1999 08:40:57 -0700

Hi all, I apologize upfront for this commentary and it bears no one person
any personal ill. It is likely to seriously piss some people off, and a
number more will just say "There is Todd popping off again..." but the
reality of this commentary is very true and important for the bigger picture
of the Group, it's deliverables and the continued respect and allegiance it
has.

Al was right in his commentary about the larger issue looming here, that of
a understandable and cohesive roadmap. That is what is specifically trying
to be accomplished, and how we can eliminate the corporate "We did it first"
mentality that permeates the group now...

You as intelligent people must understand that the key uses of the
management of the PKIX world is to provide structure for the working group's
efforts and part of that structure is involved in promulgating the standards
to other organizations.

What we really need is a plan for how the IETF and it's management intend to
promulgate our efforts into other standards organizations and what the scope
of our activities should be., THESE ARE KEY RESPONSIBILITIES of the WG
Chairs and in my mind are undone to date in the PKI WG. My feeling is that
the IETF's requirements and efforts have changed and the organization is
trying not to, and that this is introducing a lot of Entropy into the mix
and slowing down our progress.

So then this new updated ROADMAP plan needs to address

    1)     What we are trying to do - What are the goals of the effort and
the subsystem efforts, in no uncertain terms
    2)    The Scope of the efforts and responsibilities of the
players/protocols
    3)    What types of systems and transaction processing infrastructure
that we need to put in place and WHY!
    4)    What other standards agencies we are making alliances with and who
from the WG is the representative to handle the relationship
    5)    What the goals and deliverables for our standards are, that is
what Standards these efforts are built to address.

    6)    Regular reports on the a) Status of the management efforts, b)
relations to other efforts within the Group and their state, and c)
cooperative (cross standards group) efforts.

 From my standpoint the operating of the PKIX WG, as a passive pit that
people just come to  swirl their designs through is bogus. What we really
need is a better definition of the evolutionary process and the interface
points and these fall directly on the WG Chair's.

BTW, my feeling  is that with everything that is going on today, that PKI
may need to be split into a number of other WG's to support this since
mindset the PKI roadmap is getting too large for one group to handle without
some additional structure.

Me specific response to Al's commentary are included below.

----- Original Message -----
From: Al Arsenault <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 06, 1999 7:09 AM
Subject: Re: Initial comments on SCVP

> > to outline the distinction of one protocol from the others.

> > Writing a [rough

AMEN!!!!!

> having to explain what all the alphabet soup in PKIX was in the first
place.

This is a bigger issue in PKIX that what people think since there clearly
are a limited amount of commercial apps for a number of the efforts underway
in PKIX right now.

The reality of the situation is that we spend a tremendous amount of time
and collective focus working on what is clearly "Art for Art Sake" and this
must end as our predominent activity  or it is my feeling that PKIX is
ultimately doomed.

> approach.

AMEN!!! - The issue herre is that the 'problems' haven't changed, it's just
that with no end use statement everytime a new rock in the road pops up, the
protocol is morphed instead of just addressing the end use goal to begin
with.

> That is:

This is so true it is ridiculous and the mindset that "I'll just morph this
existing effort" to fill that need becuase I didn't work my use models out
from the beginning is also negligent of the group. If you are trying to
solve a problem and the problem morphs on you, one of two things happened.
1 - you didn't do the upfront work to understand what you were trying to do,
or 2, you tried to fix a movig target style problem. Either way the efforts
wind up dilluting the focus and causing enough noise in the machine that the
organization looks like a bumch of arrogent geeks trying to tell the world
how they are going to do what it is they do.

> new overhead, much of which is going to be redundant.

AMEN

> I implement Timestamp and ignore DCS.  et cetera, et cetera.

You could, if the end use models would be satisfied with those services. How
many applications for these literal unbundled protocols are there though?

> protocols in a "heavyweight" PKI, there's a lot of redundancy.

> If I have DCS,
> handled by a slight modification to DCS?

No... (what I mean is that), it buys you a limited proofing model, because
TTP models are in themselves flawed and costly to scale. The reality about
timestamping from a commercial standpoint is that the value is in embedding
the timestamping infrastructure as a proof model *INSIDE* the transaction
engine(s). This way if you need a TTP they connet to their embedded system
through a simple protocol, maybe like an SSL transport.

The real issue is that the people driving the current proposal still haven't
addressed that the underlying inability to deliver and reference relaible
time has been fixed for sometime now.

To support this assertion, and that I am wrong and TTP models work so well
then explain to me why NetDox's failure and Surety's position now are so
powerful. The bottomline is that any self-respecting IT person wants to own
and operate their infrastructure and that's that.

> Similarly, if I do SCVP, what does
> the PKIX arena altogether.

No we are not. Becuase they wont. It's purely a financial thing.

> The advantage is that my gut feeling tells me we've
> protocols that everybody implements.

ABSOLUTELY!

>  (It's bad enough now listening to vendors

I agree with you 100%

> say it correctly.

So far I suggest that we have done this only for a  few of our systems and
technologies.

The reality is that the management and players involved in steering these
efforts have not done their homework properly. I suggest that the key issues
to advancing this technology to the RFC state would involve the standard RFC
rules and two implementations
I further suggest that the most valuable thing that the IETF and in
particular the PKI team management can do is to create a road map of what
protocols it has on the board and what their intended usese are and how they
effect one and other.

I also suggest that these protocols be modled in how they interact and what
they provide,so people know what they are getting at the commerical
black-box level. That way the commercial world knows what this might set of
tools can do and what it cannot and we regain our credibility. These should
be amended into the PKI Roadmap or included as an appendix.

The problem with this is that most of the efforts currently underway,
especially the timestamping one does not have a specific clearly stated end
use model. It is more the thing of "Well we created it, now you use it" and
this make us look foolish and unkempt. All in all, the real issue is that
this inability to control these issues says to me that PKIX is way out of
hand.

> Sean did an outstanding job putting together draft -02 of the

I suggest that without a statement of use that NO PROTOCOL or draft should
be advanced beyond a I-D. The day's for doing art-for-art's-sake are not
over yet, it's just we need to understand what is intended and what we can
depend on. So if there is no specific use model, then say that upfront.

Todd

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 07 Jul 1999 13:48:02 -0700

>Right now, it seems like we're adopting a "got a problem, get a protocol"

To be more accurate, the approach is closer to "got a problem, get one or 
two protocols".

>     - if you want to do that using CMS formats, use CMC

That's one problem with two solutions. The "want to do" is not a problem, 
it is a preference.

>possessed certain qualities, use DCS

That's one problem (and a subproblem) with two solutions. Clearly, DCS can 
emit an answer that says "I didn't look at the qualities of the bits you 
gave me".

>clients" just ask servers for the answers, use SCVP

That's one problem (and a subproblem) with two solutions. The only 
difference in this pair is that OCSP is already a standard.

>     - ad infinitum, ad nauseum

Nausea is in the stomach of the beholder. :-)

>new overhead, much of which is going to be redundant.

Or, worse, slightly different from the other solutions (can you say "key 
identifier"?) which leads to having to be much more careful when 
implementing more than one.

>I implement Timestamp and ignore DCS.  et cetera, et cetera.

That's not really an advantage if (b) is designed correctly. Yes, I know 
the "design" word doesn't come up much in this working group: we mostly use 
the stuff that someone else already gave us and we try to salvage what we 
can and make it Internet-friendly (or at least less Internet-scary). If we 
design (b) correctly, implementors still have the flexibility because they 
just turn on or off the parts of the single protocol they want or don't want.

>the PKIX arena altogether.

Two comments here: we can be careful, and we're already forcing out many 
people.

>protocols that everybody implements.

Absolutely right. We'll do even better if we design carefully so that 
implementors without the advantage of the years that many folks have spent 
on these protocols can still do it right and do it well.

>to grow exponentially very soon, with all the additional protocols we keep

And it will grow as everyone who thinks they have to do PKI says "we do 
PKIX" and then starts to cobble together the bits they need.

>decide),

...not an auspicious beginning for design cleanliness...

>and to an extent for OCSP (its scope was tightly constrained to be
>certificate status, rightly or wrongly).

We could stop there and say "no more piecemeal protocols".

>   But, I don't think we're that far

I for one would be happy to not move SCVP forwards if we were sure we could 
get a more inclusive protocol that covers all the things desired for 
timestamp, DCS, and OCSP. I'm wary of doing certificate enrollment over the 
new protocol, because three choices are worse than two, but if folks want 
One True Protocol, it could be done there cleanly as well (with work).

>CMC has advanced to Proposed Standard).

That would be nice, but not until more people read it and comment on it. 
You also have a large, unfinished section (5.4) which I think is vitally 
important to get right, given that the press still says  "PKIX uses a 
hierarchical trust model" all the time.

>   So, the sooner decisions can be made

Sounds like we'll have something to talk about in Oslo.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Stephen Kent <[email-masked]>
Date: Wed, 7 Jul 1999 13:55:11 -0400

Todd,

>the subsystem efforts, in no uncertain terms

The function of the WG is to develop protocols and data formats for use of
X.509 certificates and CRLs in the Internet environment.  PKIX does not
address all possible standards activities that are PKI and Internet
related.  Rather, we focus on that which we consider to be generally
applicable, leaving application-specific PKI standards to relevant
application (security) WGs.

>    2)    The Scope of the efforts and responsibilities of the

Protocols, not being people, are not responsible :-).  Scope was addressed
above.

>that we need to put in place and WHY!

Transaction processing infrastructure?  We are providing generic,
X.509-based public key infrastructure standards.  There will probably be
many PKIs in practice and our goal is to provide standards that will serve
as a suitable basis for most of these. Your question seems to suggest a
more narrow focus.  The certs covered by PKIX standards may be used to
support authentication, authorization, and non-repudiation. Not all
PKIX-compliant applications will use all of these capabilities of certs and
thus no single instance of a PKI will be appropriate for all.

>from the WG is the representative to handle the relationship

We try to work closely with the ITU X.500 committee, since much of our work
has been profiling base standards produced by that committee.  We have
informal relationships, via shared membership, with the ANSI X.9 folks.
Several members of the WG act as liasions to other WGs, as reflected in
their contributions and or by their role in the other WGs.  This is not a
formalized relationship. For example, I act as a liasion to IPsec, Russ and
Paul work in S/MIME, Sharron for LDAP, ...

>what Standards these efforts are built to address.

See answer to #1 above.

>cooperative (cross standards group) efforts.

Status reports are distributed via the mailing list. Because of the
informal nature of the liasion realtioships with other groups, these
reports are generated in response to relevant events in the other WGs.
Since our focus is on generic PKI standards, not all PKI activities in
other groups will be of interest to all PKIX members, and thus folks are
encouraged to sign up for mailing lists that match their interests.

>some additional structure.

As noted above, application-specific PKI standards are, by our charter, to
be farmed out to relevant application WGs.  That is happening in S/MIME,
TLS, and IPsec.

Steve