Subject: RE: DPV vs SCVP

From: "Covey, Carlin" <[email-masked]>
Date: Tue, 21 Nov 2000 13:49:08 -0800

What is the incompatibility that is at issue here?  I've done a character by
character
comparison of OCSP v1 and OCSP v2, and I don't see a problem.

I'm no ASN.1 whiz, but it looks like an OCSP v1 server would have no trouble
processing a basic v1 request from an OCSP v2 client, which in turn could
process an 
OCSP v1 response perfectly well.  (If the v2 client didn't know if the
server was
v1 or v2, it might make a v2 request first, get a "malformedRequest"
response and
then try a v1 request.) Likewise, an OCSP v2 server would have no problem
with a 
request from an OCSP v1 client, and would simply return an OCSP v1 response.

Am I missing something?

Regards,

Carlin Covey
Cylink corp.

> -----Original Message-----
> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, November 17, 2000 12:59 PM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: RE: DPV vs SCVP
> 
> 
> Denis,
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Friday, November 17, 2000 12:36 AM
> > To: Michael Myers
> > Cc: Paul Hoffman / IMC; [email-masked]
> > Subject: Re: DPV vs SCVP
> > 
> > 
> > Michael,
> > 
> > > Paul,
> > > 
> > > The OCSPv2 draft does not propose a new protocol; it's an 
> > improvement to an
> > > existing protocol.  
> > 
> > Obviously wrong.
> 
> This is what I was afraid of.  I don't think it's productive 
> to argue this
> point.  What's important is determining if the proposals are 
> technically
> correct and responsive to requirements.
> 
> > In the current proposal, there is no backward
> > compatibility: OCSPv2 is a new protocol. The only big 
> > advantage for OSCPv2
> > against SCVP would be some kind of backward compatibility 
> with OCSPv1.
> > Otherwise, since SCVP is also a new protocol, why not 
> > consider it (I mean
> > its ASN.1 version, not its XML version) ?
> 
> I'm quite sure we're describing the same elephant.
> 
> > Before going to this extreme
> > position, I would like to try to "save" OCSP, hence why I am 
> > spending (too
> > much ?) energy on that topic.
> 
> The question is, do we wish to address these issues and briefly cycle
> RFC2560 at proposed or simply address incremental corrections 
> and move it
> forward?  Rough consensus appears to favor the former.
> 
> > 
> > > At its core it proposes alternative means of identifying
> > > a certificate that are more in line with well-known needs.
> > 
> > "Alternative", in this case, means different and thus 
> > non-compatible means.
> 
> The original v1 certID syntax is preserved in a backwards 
> interoperable
> fashion.  But this discussion has yielded the correct effect. 
>  It's clear I
> need to improve the draft more or less as follows as a 
> proposal to the WG.
> 
> v1 servers SHALL support certID to ensure interoperability 
> with v1 clients.
> 
> v2 clients SHOULD (SHALL?) be capable of supporting the 
> original certID
> structure.
> 
> > 
> > > It could be argued that the DPV and DPD drafts define a new 
> > protocol.  But
> > > since (and especially in the case of DPV) we're talking 
> > about little more
> > > than extension OIDs, I fear that we'll get so wrapped up 
> > debating what is a
> > > protocol vs. a protocol extension that we'll lose sight of 
> > the problem we're
> > > trying to solve.
> > 
> > DPV and DPD can only be considered as extensions, if you 
> > agree with the
> > meaning of the status I explained in two E-mails sent to you. 
> > I am still
> > awaiting a detailed response from you on this matter, and 
> > globally on my
> > previous E-mail.
> 
> I had hoped that you considered my prior emails as 
> responsive.  Some of your
> comments I didn't take to be actionable in the absence of a broader
> consensus.  I'll take another look at them today to see if I missed
> something obvious.
> 
> > 
> > > BTW, all 2560 authors were asked if they wished to 
> > contribute at that same
> > > level of cycle time committment on OCSPv2.  The authorship 
> > list on the
> > > OCSPv2 draft reflects the outcome of those invitations.
> > 
> > Not open to invitations for others ? Is it a closed user group ?
> 
> Of course it's an open WG and as an IETF WG the technical 
> contributions of
> its participating members are key to the quality of the 
> solutions that we
> produce.
> 
> > 
> > > My response to Denis is simply me thinking that once we've 
> > achieved rough
> > > consensus, running code and an RFC that the IETF has 
> > spoken.  Else when is a
> > > last call not a last call?  When is rough consensus not 
> > rough consensus?
> > > When is running code not running code?  I look to the 
> > chairs to provide us
> > > guidance on these points.  Until then, that's my story and 
> > I'm sticking to
> > > it.
> > 
> > We are far from rough consensus at the time being.
> 
> Actually, I believe we are.
> 
> If what you're saying is, Denis' text wasn't recorded 
> verbatim as proposed,
> well, that's probably true.  Much of the text I propose isn't recorded
> verbatim either.  But your comments nonetheless have yeilded 
> positive impact
> on this technical improvement to an Internet standard.  And 
> after all, isn't
> that why we do what we do?
> 
> > If you 
> > continue to stick
> > on your positions, I will be inclined to agree with Paul: " 
> > If the author of
> > a document is not willing to work within the IETF framework, 
> > maybe it is
> > time for a different author or additional co-authors". We 
> > need to move up.
> 
> As I tried to say, I am doing all I can to fully enable the 
> IETF process on
> this issue.  This includes a healthy respect for the 
> consensus development
> process.  That in turn leads me to conclude that once a WG 
> has gone through
> the pain of developing a consensus-based position, those 
> efforts should be
> respected in the interests of maintaining our forward progress.
> 
> And as I tried to say, I'm happy to be guided towards an alternative
> understanding. But it's my sense that once the IETF makes a 
> decision that
> leads to an RFC, we should be very cautious in recanting on those
> recommendations.  For example, some of my earliest OCSP 
> drafts advocated for
> a non-ASN.1 syntax because doing so benefits development, 
> debugging and
> deployment, as Khaja recently and so well put it.  The WG 
> decided that it
> wanted an ASN.1-based solution.  We made that decision and moved on.
> 
> It's my opinion that we must think through a reset of the "good" and
> "unknown" status responses very carefully because of what it 
> implies upon
> the IETF process.  It's possible however that my opinion is 
> unique among
> IETF members.  If so and knowning that, I look to the chairs 
> for guidance to
> help me ensure that the IETF process is fully respected as we 
> go forward on
> this obviously vital issue.
> 
> > 
> > Denis
>