Subject: Re: roadmap

From: "Sean P. Turner" <[email-masked]>
Date: Mon, 22 Apr 2002 09:47:15 -0400

Peter,

I'll make the changes noted below.

To put the "is SCVP THE protocol" issue to bed.  Can we say that that was the plan
before we heard that "OCSPv2 will not be pushed to informational and hence we are not in
the situation to have a defined set of requirements that enables selection of one from
among potentially several technical approaches." (words from Mike Myers)?

spt

Peter Sylvester wrote:

> >>
> > Peter,
> >
> >     (Sorry for the delay in responding.  I work for a fairly small company,
> > and when the boss wants the next version of the product shipped, he's not
> > overly fond of hearing things like "but I gotta keep up on PKIX stuff.)
> Thanks for the fast answer. I am well aware of such a situation
> of highly volunteer work. (which just happened to change for me since
> the beginning of April). :-)
>
> >
> > AWA:  That was put in there after the London meeting last August. At that
> > time Michael Myers, the "leader" of the OCSP faction, indicated that his
> > approach to solving the DPV/DPD - SCVP vs. OCSP battles was to let SCVP
> > continue along the standards track, and make the next OCSP version (that
> > handled the full DPD/DPV functions) go to experimental status.  (This would
> > be similar to the PKIX vs SPKI situation.)  So, it seemed like SCVP had
> > "won".  Since then, however, the WG has dropped back to going through the
> > entire DPD/DPV requirements discussions; AND Michael has been told (by Steve
> > Bellovin) that the IESG will not support pushing OCSPv2 to experimental with
> > SCVP being standards track.  I guess you're right; this makes the London
> > "conclusions" no longer valid and the wording will have to be changed.
>
> Ok. Just to inform you, as far as I remember there has not been any discussion
> in London about *the* protocol. I was there and would have certainly made a comment.
> of course, there might have been the usual 'corridor' and 'bar' meetings. :-)
>
> > >
> > > ?   specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating
> > > ?   (though in [TSP] request for a time stamp are not required to use
> > > ?   [CMS]).
> > >
> > > encapsulating what?
> > >
> >
> > AWA:  Oops - editing error.  That should say "... as an encapsulating
> > protocol ..." (or maybe encapsulating mechanism, if you don't consider CMS
> > to be a full protocol).
>
> Indeed, I consider CMS as a 'document format', but that was not
> really the point: There is one word missing,  'mechanism' would be fine.
> But my proposal 'unfolds' the combined statement into
> two independant sentences concenrning the two "protocols" and
> clarifies one (because in DVCS everything is optional).
>
> > >    Both [DVCS] and [TSP] define CMS contenttypes to transport protocol
> > >    information. [TSP] optionally uses CMS SignedData and an encapsulatin
> > >    security envelope as an option for the requests, and mandatory for
> > >    the resulting tokens. [DVCS] allow the optional usage of CMS security
> > >    envelopes permitting to authenticate requests and responses.
> > >
>
> > > I have the feeling that something is wrong in the following:
> > >
> > >      - PKC holders that are issued certificates and can sign digital
> > >        documents and encrypt documents;
> > >
> > >      - Clients that validate digital signatures and their certification
> > >        paths from a known public key of a trusted CA;
>
> Here some idea to clarify: feel free to change this.
>
> PKC holders are issued certificates and can sign
> digital documents and decrypt documents using private keys.
>
> Clients that validate digital signatures and their certification
> paths from a known public key of a trusted CA and that encrypt
> document using public key from certificates of PKC holders.
> (or should one call them 'relying parties').
>
> Regards and thanks again for the response.
>
> Peter

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Apr 2002 19:59:30 -0400

>among potentially several technical approaches." (words from Mike Myers)?

Sean,

SCVP and OCSPv2 were both put forth as candidates for providing 
DPV/DVD services, but before we developed suitable requirements for 
these services. So, the WG elected to first develop a requirements 
document, and then choose a protocol to satisfy those agreed-upon 
requirements. I laid out a plan for this process last year, but the 
requirements development took longer than expected. This is probably 
not so bad, as it has allowed us to focus more on getting agreement 
on the requirements, without the added confusion of arguing over a 
specific protocol. Nonetheless, I agree with Peter that it is 
inappropriate to label SCVP as the protocol at this time. We agreed 
to allow competing protocol submissions which would be evaluated 
against the requirements. Even if OCSPv2 were not a competitor, there 
is no prohibition from another protocol being considered relative to 
the requirements doc.

Steve

---

From: "Sean P. Turner" <[email-masked]>
Date: Tue, 23 Apr 2002 19:38:01 -0400

> is no prohibition from another protocol being considered relative to

Steve,

Thanks for the input.  I'll make sure to change the phrasing so that it
doesn't say the SCVP was "the" protocol and positively spin the situation
we're in now.  This is the problem with the draft that is documenting a moving
target - it's just about always wrong.

Cheers,

spt

P.S. Nice job on CNN.