Subject: RE: DPV vs SCVP

From: Michael Myers <[email-masked]>
Date: Thu, 16 Nov 2000 14:22:15 -0800

Paul,

The OCSPv2 draft does not propose a new protocol; it's an improvement to an
existing protocol.  At its core it proposes alternative means of identifying
a certificate that are more in line with well-known needs.

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.

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.

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.

Mike

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Thursday, November 16, 2000 8:46 AM
> To: [email-masked]
> Subject: RE: DPV vs SCVP
> 
> 
> At 10:08 AM -0800 11/15/00, Michael Myers wrote:
> >Replace "good" with "not revoked"
> >---------------------------------
> >The last call for comments on the I-D that led to RFC2560 
> occurred roughly
> >two years ago.
> >
> >
> >Replace "unknown" with "revocation status unknown"
> >--------------------------------------------------
> >See above.
> 
> OCSPv2 is a new protocol, which means that bugs in the old protocol 
> can be fixed. I'm not saying that I agree with Denis' requests, but 
> it is inappropriate to give an out of hand rejection to them simply 
> because they had been discussed before, at the same time as the othe 
> flaws in OCSP were being considered.
> 
> 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, such as the ones who helped craft OCSPv1.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 17 Nov 2000 09:36:04 +0100

Michael,

> existing protocol.  

Obviously wrong. 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) ? 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.

> At its core it proposes alternative means of identifying

"Alternative", in this case, means different and thus non-compatible means.

> protocol vs. a protocol extension that we'll lose sight of the problem we're

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.

> OCSPv2 draft reflects the outcome of those invitations.

Not open to invitations for others ? Is it a closed user group ?

> guidance on these points.  Until then, that's my story and I'm sticking to

We are far from rough consensus at the time being. 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.

Denis