Subject: RE: OCSP identifiers

From: Carlisle Adams <[email-masked]>
Date: Tue, 28 Nov 2000 10:14:03 -0500

Hi Denis,

> ----------
> From: 	Denis Pinkas[SMTP:[email-masked]]
> Sent: 	Tuesday, November 28, 2000 8:17 AM
> To: 	Michael Myers
> Cc: 	[email-masked]
> Subject: 	Re: OCSP identifiers
> 
> > I was not claiming a consensus on the fundamental need to amend RFC
> 2560's
> > certificate identification syntax.  But since you brought it up, it
> would be
> > useful to tally across the "Re: OCSP identifiers" thread.  I've done so.
> > Among those who spoke on-list regarding OCSPv2's proposal to amend RFC
> > 2560's certID syntax, PKIX has:
> > 
> > 9  in favor
> > 2  opposed
> > 
> > Below is the précis underlying that count.
> > 
> > Mike
> > 
> > In favor
> > --------
> > Michael Myers
> > Carlisle Adamas
> > Stephen Farrell
> > Rich Ankney
> > Denis Pinkas
> >    (noting that Denis proposes an alternative means
> >     of expanding RFC 2560's certID.)
> 
> !?!?!? Please, Mike, count me on the OPPOSED side.
 
The vote here (as Mike mentions above) was on "the fundamental need to amend
RFC 2560's certificate identification syntax".  Why in the world would you
propose a means to extend the 2560 syntax to accommodate other means of
identification if you are "OPPOSED" to the idea that the syntax needs
amending?  Were you deliberately trying to confuse us all?  :-)

It seemed quite clear to me that you agreed that additional means of
identification would be valuable (i.e., that the current syntax was
insufficient for some environments), but were just trying to ensure that
this was done in a backward compatible way (as much as possible).  Thus, I
was not at all surprised to see Mike put you in the "favor" column, and am
quite surprised to see you asking to be put in the "opposed" column.
Anyway, thanks for the clarification!

> This makes four oppositions, if I count correctly and - maybe - eight in
> favor: this is NOT a rough consensus.
 
Actually, my impression is that in IETF any majority can be considered
"rough consensus" if an issue has dragged on long enough and a specification
needs to progress.  Certainly, a 2/3 majority would be considered "rough
consensus" in many circles (even outside IETF!).  While it is likely the
case that not all the opinions are in yet, at the moment I doubt that many
would claim that this vote was "too close to call".

Carlisle.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 28 Nov 2000 16:32:31 +0100

Carlisle,

> > 2560's  certificate identification syntax.  But since you brought it up, it
> > would be useful to tally across the "Re: OCSP identifiers" thread.  I've
> > done so.

> > Among those who spoke on-list regarding OCSPv2's proposal to amend
> > RFC 2560's certID syntax, PKIX has:
> >
> > 9  in favor
> > 2  opposed
> >
> The vote here (as Mike mentions above) was on "the fundamental need to
> amend RFC 2560's certificate identification syntax".  Why in the world
> would you propose a means to extend the 2560 syntax to accommodate other
> means of identification if you are "OPPOSED" to the idea that the syntax
> needs amending?  Were you deliberately trying to confuse us all?  :-)

Sorry ... I misread the argument. 

> Anyway, thanks for the clarification!

I am clearly opposed to the current OCSP v2 proposal, I am not opposed in
principle to extensions, ... IF a rational is provided for these extensions
AND we care for OCSCP v1 backward compatibility. In an E-mail posted to Mike
this morning (Paris time), I raised a point raised much earlier, which
remains to be answered:

"Besides the ASN.1, explanations would need to be given to tell which
combinations of these parameters make sense. The problem is that for the
basic service (i.e. a simple revocation status request), some combination
may be fine, but not sufficient for additional services (supported through
extensions). So we would have to anticipate the needs for these extensions. 

In order to make sure we do not miss anything, a study should be done, at
least for the three services that we are attempting to support, to explain
and identify which combinations of these parameters are needed and thus make
sense." 

Would you have an answer ?

>> This makes four oppositions, if I count correctly and - maybe - eight
>> in favor: this is NOT a rough consensus.
> 
> "rough consensus" if an issue has dragged on long enough and a
> specification needs to progress.  Certainly, a 2/3 majority would be
> considered "rough consensus" in many circles (even outside IETF!).  While
> it is likely the case that not all the opinions are in yet, at the moment
> I doubt that many would claim that this vote was "too close to call".

The fact is that we have no consensus on any ASN.1 syntax change today.
Simon might be right when saying: "The bottom line is, lets stick with
RFC2560, and move on with it", ... unless arguments are given to explain the
use of every extension and reduce the number of cases of practical
combinations.

Regards,

Denis