Subject: Re: [pkix] 2560bis (essay version)

From: Stefan Santesson <[email-masked]>
Date: Thu, 02 Aug 2012 10:09:19 -0700

Tim,

You say that "Our experience with implementations of RFC 2560 has been
decidedly mixed"

I have in the past years developed tools for signature validation within
the EU trust framework.
This involves 800+ trust services, many of them providing OCSP.
My experience with interoperating with a vast amount of OCSP responders in
EU is that the practically only technical issue I ever have encountered,
is related to certificate chaining to the OCSP responder. Except from that
I have encountered some OCSP responders (very few though) that don't think
I'm authorized to ask for some reason, but that is not a technical interop
failure.

So in my experience, RFC 2560 does in large work very well in creating
interoperability, except for the chaining issue.

If your experience is different from mine, it would be really helpful to
get a list of recorded interop issues. Even a rough list would be helpful.
It would certainly help knowing what needs fixing and to determine if a
complete re-write is motivated.

/Stefan

On 12-07-31 5:21 PM, "Polk, William T." <[email-masked]> wrote:

>My apologies for the essay, but since I can't be at the session tomorrow
>I wanted to add
>a rationale.  Since Steve asked that we *not* supply an essay, I am
>supplying my rant in a
>separate message.
>
>First, I want to note that I support the chairs effort to bring 2560bis
>to publication ASAP.
>There is a real need.  Experience shows that implementers who weren't in
>the room/on the list
>in 1999 have interpreted some text inconsistently, and have encountered
>problems (e.g.
>key rollover) that were not treated as comprehensively as we believed at
>the time.
> 
>I would gladly support Option A if I thought it would produce a document
>that
>could produce interoperable implementations in a timely manner, but I
>just don't see it.  Our
>experience with implementations of RFC 2560 has been decidedly mixed, and
>those
>implementations weren't particularly agile.  I don't think a minor edit
>of 2560 will meet the
>need, so restarting will from 2560 will either produce a document that
>falls short or will take
>a lot more effort than Stefan believes.
>
>No document is ever perfect, but I think that the -04 needs very little
>work to be publishable.
>I believe that most of the new text in the document is needed to answer
>errors of omission
>in 2560 (which is why I think restarting from 2560 will be less efficient
>than you expect.)
>As I recall, Santosh has some issues that he thinks could be addressed
>efficiently (and has
>offered to help).  Denis has asked for a lot more work, but I think he is
>in the rough (and option
>A won't change that.)  Based on that analysis, I suggest option B as most
>efficent.
>
>The most important thing, though, is not whether we choose A or B.  It is
>getting a document
>published that fills in the gaps in RFC 2560 in a reasonable timeframe.
>One path forward might
>be to double-check the email list and compile the set of problems to be
>addressed.  I would
>start with David's slides for presentation at the meetings since he
>usually listed the
>issues he was addressing.  Modify the list if it is too long or
>incomplete, then compare.  If the list
>has all been addressed in -04 we are done.  If not, consider which will
>take more work.
>
>My 2 cents.
>
>Tim Polk
>
>________________________________________
>From: Polk, William T.
>Sent: Tuesday, July 31, 2012 7:46 PM
>To: Stephen Kent; pkix
>Subject: RE: [pkix] 2560bis
>
>B.
>
>________________________________________
>From: [email-masked] [[email-masked]] On Behalf Of Stephen
>Kent [[email-masked]]
>Sent: Sunday, July 29, 2012 1:13 PM
>To: pkix
>Subject: [pkix] 2560bis
>
>Folks,
>
>Recent messages exchanges point to significant disagreement about the
>future direction
>for this doc. At the March meeting Stefan presented a proposal for how
>to move
>ahead, as outlined in his slides. As noted in the minutes, the audience
>(at the mic)
>included one indication of support for this streamlined approach, and
>one expression
>of concern. Not a lot of interest.
>
>Work on this doc has dragged on for 2 years now. In October of 2011
>Santosh argued that
>version -04 of the doc was, in his opinion, a step backwards, adding
>more confusion to
>RFC 2560 vs. clarifying it. Stefan agreed (in a message in March of
>2012), and
>thus he created the current, stripped-down version of the doc (-05)
>which was published
>recently.
>
>Given the mixed response to this version, it's not clear that the WG
>members who are interested
>in OCSP clarifications are in agreement on how to proceed.
>
>So, let's begin a straw poll on the topic.  Here are the options I am
>offering:
>
>     A - continue to work with the -05 version as the basis for an RFC
>     B - revert to the -04 version as the basis for an RFC
>     C - don't publish a clarifications document for OCSP
>     D - the respondent volunteers to work on a new version of 2560bis
>
>Please send your replies to the list starting now. The straw poll will
>close
>in two weeks, on August 12. While there are many other, legitimate
>comments one could
>offer, I am interested only in replies to this multiple choice straw
>poll (i.e., no
>essay replies :-) )
>
>Thanks,
>
>Steve
>
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix