Subject: RE: DPV vs SCVP

From: Michael Myers <[email-masked]>
Date: Fri, 17 Nov 2000 11:58:59 -0800

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