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

From: "Polk, William T." <[email-masked]>
Date: Tue, 31 Jul 2012 20:21:37 -0400

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

---

From: [email-masked] (Martin Rex)
Date: Wed, 1 Aug 2012 03:53:10 +0200 (CEST)

Polk, William T. wrote:
>  
> 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.

I do.  Documenting only the differences and pointing out its values
has caused much greater adoption in the installed base of TLS for
changes such as secure renegotiation (rfc5746) or the SSL Beast
countermeasure through 1/(n-1) initial record splitting than
what you can see about adoption of TLSv1.1 over the last 6 years.

>
> 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.

This sounds like you're asking for _changing_ the existing protocol
by publishing a new spec with different or additional requirements.

On quick glance, the most significant "improvement" of -04 over rfc2560
seems to be the examples in Appendix E.  Carrying them over into -05
should be simple and straightforward.

What seems to be badly lacking in Appendix E of -04 is the requirements
of which certs MUST be included in the OCSP response for each of the
example CA/OCSP architecture/hierarchy, except for Figure 1 (where
no cert is necessary).

What should be spelled out explicitly is that some of the depicted
architectures require an RP to be able to (a) build a certification
path (something that is *NOT* required for PKIX/rfc5280), and
in some cases (b) being able to distinguish certs with different
public keys from the same CA (=same issuer name) based on other
characteristics than issuer name (probably SubjectKeyIdentifier).
The latter is also *NOT* required for RPs by rfc5280 (the certificate
path validation algorithm in rfc5280 6.1 is entirely ignorant of
SubjectKeyIdentifiers).

Revocation checking of the OCSP signer sounds like a very bad idea,
because it implies recursion.  There really ought to be a requirement
that implementations (of CA and OCSP software) MUST support short-lived
OCSP signer certs that obviate cert revocation checking of a _seperate_
OCSP signer cert entirely for the RP so that consumers of the technology
can configure&obtain interop with RPs that do not support such recursion.

Looking at 2.3.6 Response Verification of -04,
the ordering of checks should IMHO rather be (1), (4), (5), (3), (2)
based on the current numbering of the items, i.e. one should only
perform public key crypto operation with a key that has
been verified as being trustworthy, similar to how the certificate
path validation in rfc5280 6.1 works.

-Martin