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

From: "David A. Cooper" <[email-masked]>
Date: Wed, 1 Aug 2012 09:56:03 -0400

Martin,

Please read 
http://www.ietf.org/mail-archive/web/pkix/current/msg27687.html for an 
example of the confusion that the text in RFC 2560 is causing.  This is 
not about making changes to the protocol and then trying to achieve 
greater adoption of those changes, it is about making the document 
sufficiently clear and unambiguous that problems like the one described 
in that message can be avoided in the future.

In this message, you are again asking for changes to be made.  For 
example you said:
> 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).

I was given a very strict mandate to not make any changes to OCSP.  Can 
you show me where this "MUST" requirement appears in RFC 2560?  If not, 
then how could I include such a "MUST" requirement in 2560bis without 
breaking my promise not to make any changes to the protocol.  This 
proposed change may be a good idea, but that doesn't mean it's not a change.

You also say that "There really ought to be a requirement that 
implementations (of CA and OCSP software) MUST support short-lived OCSP 
signer certs...."  Again, that may be a good idea, but can you find that 
requirement in RFC 2560?  If not, then wouldn't including such a 
requirement in 2560bis be a change?

The final paragraph in your message proposes reordering the checks in 
Section 2.3.6.  However, the checks in Section 2.3.6 are listed in the 
same order as they appear in Section 3.2 of RFC 2560. While one could 
certainly reorder them without changing the protocol since the text does 
not specify that the checks need to be performed in the order they are 
listed, it would seem that reordering them would be inconsistent with 
the approach that you are advocating of "doing minimal changes to the 
original document."

You also misrepresent RFC 5280 in your message.  RFC 5280 very clearly 
allows CAs to sign CRLs with a different key than was used to sign the 
certificates covered by the CRL, and notes that it may be necessary for 
a relying party to build a separate certification path for the 
certificate needed to verify the signature on the CRL.  As for OCSP, 
contrary to your assertion, relying parties are *NOT* required to be 
able to validate responses if the response (or the responder's 
certificate) was signed with a different key than the target 
certificate.  I cannot find a single statement in RFC 2560 that states 
that conforming applications MUST be able to validate such responses, 
and so there is no such statement in 2560bis either.

On 07/31/2012 09:53 PM, Martin Rex wrote:
> 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
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Wed, 1 Aug 2012 23:20:09 +0200 (CEST)

> in that message can be avoided in the future.

I haven't fully read through this, but it appears to be quite related
to my complaint about Appendix E of the -04 document to be lacking
requirements on inclusion of which particular certs in the OCSP response
in order to provide a basis for interop.  Without such requirements
about which certs must be present in the OCSP response, interop will
remain a lucky coincidence rather than a result of conscious design
decisions.

And as an implementor, I would limit my OCSP to exactly two cases:
(1) certificate signer key also signed the OCSP response
(2) certificate signer key also signed an OCSP responder cert,
    and this OCSP responder cert MUST be included in the OCSP response. 

> proposed change may be a good idea, but that doesn't mean it's not a change.

First, the rest of my reply was under the stated premise:

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

and secondly, I'm against requiring OCSP clients to support fancy PKI
models.  However the complete lack of details what needs to be included
in an OCSP response in order to provide a basis for interop is a
DEFECT of rfc2560. 

I would be perfectly OK with augmenting the existing spec with
something like

"In order to provide reliable interoperability on
this protocol options, the following additional requirements are
necessary, that are not part of rfc2560 (but might have been
obvious implications for some implementors anyhow".

If you approach rfc2560 from the viewpoint of formal correctness proofing,
you will immediately notice which protocol options are underspecified
and where you will encounter interop problems with implementers who
do not read a spec and create an implementation with any kind of formal
correctness in mind (i.e. planned and predictable behaviour
in unknown future usage scenarios).

> requirement in 2560bis be a change?

Same as above.

> the approach that you are advocating of "doing minimal changes to the 

rfcdiff visualizes this as newly added text:

http://tools.ietf.org/rfcdiff?url1=rfc2560.txt&url2=draft-ietf-pkix-rfc2560bis-04.txt

...which is one of the reasons that I'm violently opposed to
completely rearrange the document structure in the fasion of -04

Concerning the same info in section of rfc2560 section 3.2
a clarifying text that the ordering in the enumeration is not normative,
and it might be sensible to perform the public key signature verification
at the end, rather than as 2nd check, because it is likely the most
"expensive" operation and one should avoid making public key crypto
operations with public keys before it has been established that these
keys are trustworthy.

> certificate needed to verify the signature on the CRL.

Quoting from rfc5280, section 5.1.1.3

   http://tools.ietf.org/html/rfc5280#section-5.1.1.3

                     The use of separate CA certificates for validation
   of certificate signatures and CRL signatures can offer improved
   security characteristics; however, it imposes a burden on
   applications, and it might limit interoperability.  Many applications
   construct a certification path, and then validate the certification
   path (Section 6).  CRL checking in turn requires a separate
   certification path to be constructed and validated for the CA's CRL
*> signature validation certificate.  Applications that perform CRL
*> checking MUST support certification path validation when certificates
*> and CRLs are digitally signed with the same CA private key.  These
   applications SHOULD support certification path validation when
   certificates and CRLs are digitally signed with different CA private
   keys.

rfc5280 is pretty explicit that support for CRLs that are not signed
by the same CA key that signed the certificate is OPTIONAL, because
MINIMUM REQUIREMENT RPs will likely not support it.

Keep in mind that CRLs, in contrast to OCSP, lack a standardized
carry-on container for CRL signer certificates.

Keep also in mind, that construction(!) of a certificate path is
explicitly outside of the scope of rfc5280.  Which more-or-less
means that all options described in rfc5280 that require certificate
path construction are implicitly outside the scope of rfc5280 as well
(and very likely missing in minimum requirement RPs):

   http://tools.ietf.org/html/rfc5280#page-73

   The primary goal of path validation is to verify the binding between
   a subject distinguished name or a subject alternative name and
   subject public key, as represented in the target certificate, based
   on the public key of the trust anchor.  In most cases, the target
   certificate will be an end entity certificate, but the target
   certificate may be a CA certificate as long as the subject public key
   is to be used for a purpose other than verifying the signature on a
   public key certificate.  Verifying the binding between the name and
   subject public key requires obtaining a sequence of certificates that
*> support that binding.  The procedure performed to obtain this
*> sequence of certificates is outside the scope of this specification.

>
> As for OCSP, contrary to your assertion, relying parties are *NOT*
> required to be able to validate responses if the response
> (or the responder's certificate) was signed with a different key
> than the target certificate.

That is a misunderstanding.  I'm perfectly aware and OK with this.

>
> I cannot find a single statement in RFC 2560 that states 

What is lacking in RFC2560, and should be added in rfc2560bis is
that when using a different OCSP signer cert, then the OCSP server
MUST include all certs that will be necessary for processing this
OCSP response *within* the OCSP response.

In general, this also means that the examples in
Figure 7, Figure 8 and Figure 9 of -04 are incorrect, because
in general a cross-cert between the cert-signing CA cert and the
OCSP-responder signing CA cert will be necessary, unless the
OCSP request contains an unambiguous proof that the OCSP client
is in posession of the rootCA cert from Figures 7, 8, 9

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 2 Aug 2012 08:30:05 +0200 (CEST)

> proposed change may be a good idea, but that doesn't mean it's not a change.

What could be done in order to minimize the changes to the original
protocol is adding one or more appendixes that specify "interop profiles",
showing which additional requirements will result in what kind of
interop improvements.  Any new/additional requirement may imply
a patch/change/update of at least parts of the installed base, of course.

The focus should be, what minimum set of additional/new requirements
will provide reliable interop on which exact protocol option.

And new requirements(=changes) for the OCSP responder or the PKI/CA will
often be easier to deploy than changes to the unwashed masses of
OCSP clients (RPs).  That does not necessarily mean that it will be
easier to get a software for the OCSP server or CA than for the
OCSP client from the respecitive software suppliers...

> requirement in 2560bis be a change?

That is sort-of a prerequisite for making OCSP processing work reliably.

Think of the new TLS extension for stapling OCSP responses.  The objective
is that a client can connect to a server, obtain the server certificate
along with **ALL** OCSP responses necessary to verify the server certificate
from the TLS handshake and not having to do _any_ third party communication
at all.  The algorithm for the server to obtain the necessary OCSP responses
allowing this should be simple and straight-forward.  If verification
of OCSP signer certs would need additional OCSP responsed or CRLs, then
it would no longer be simple and straightforward.

-Martin

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 2 Aug 2012 11:30:52 -0400

Martin,

As you voted for option A in the straw poll, please provide Stefan with 
this formal correctness proof so that he can address any aspects of the 
protocol that are underspecified, in case future development of 2560bis 
is based on option A.

Dave

---

From: [email-masked]
Date: Mon, 6 Aug 2012 14:37:21 +0200

Martin,

I agree with you that only two cases (besides a local configuration which 
is OPTIONAL) SHALL be supported.
However, I would rephrase it slightly differently:

The key that is able to verify a SingleResponse (within a 
BasicOCSPResponse) MUST be :
(1) either the certificate signer key,
(2) or the key from an OCSP responder signed by the certificate signer 
key,
    and in this case the OCSP responder cert MUST be included in the OCSP 
response. 

Denis

De :    [email-masked] (Martin Rex)
A :     "David A. Cooper" <[email-masked]>
Cc :    pkix <[email-masked]>
Date :  01/08/2012 23:20
Objet : Re: [pkix] 2560bis (essay version)
Envoyé par :    [email-masked]

=

Same as above.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 7 Aug 2012 07:58:50 +0200 (CEST)

> protocol that are underspecified, in case future development of 2560bis 

Myself, I don't do formal correctness proofs (I do not have such huge
amounts of time at my disposition) [*].

But once you understand how formal correctness proofing works in principle,
you can use the underlying methods to check some specification
feature/protocol option for "obvious" defects (contradictions or
ambiguities).  Defects in a spec often cause interop problems.
Sometimes defects will require a disambiguation before being
implementable, but not all implementors ask for disambiguation,
(ab)use a misspecified protocol option in the fashion they see fit
and ship their implementation of it.

And sometimes defects can be recognized and overcome by redundant
information in the spec, but not all implementors are equally gifted
in deducting what the spec should have correctly said.

X.509 and PKIX contain so many inconsistencies and ambiguities
that one will probably have to change or drop at least half of X.509 spec
in order to obtain correctness.  Considering the size and complexity
of these specs, it looks like a multi-man-year effort to me.

So what I'm doing about OCSP is looking at the "minimum requirements"
OCSP client & responder, and which parts of the more complex options
will cause interop problems with a high probability.

-Martin

 [*] In 1996 a student from the University of Karlsruhe was doing his
     master thesis at my company, a tool-based formal correctness proof
     of a specific subset of our authorziation scheme.  He was helping
     the developers to create the detailed specification, while he
     was doing the translation into predicate logic and updating the
     specification to accomodate for ambiguities and inconsistencies
     that the tool encountered.  It took him 4 months.
     The tool that he used was "Karlsruhe Interactive Verifier (KIV)"

     Personally, I'm _not_ intimate with all the theory behind it,
     and was disappointed by the ROI, but I really liked the underlying
     principles and adopted them for spec-reviewing and programming and
     used them in 1996-1998 for reviewing the subset of GSS-API v2
     (rfc2743/2744) that we use in our software.

     When I applied this methods in Nov 2009 to during discussion
     of TLS channel bindings on the TLS mailing list, after I had
     understood what Nico&Larry were trying to accomplish, I tried
     describing to them why their desired behaviour was incompatible
     with the existing TLS renegotiation as specified:

       http://www.ietf.org/mail-archive/web/tls/current/msg03922.html

     On my way home, it dawned on me that certain application designs
     might be blindly relying on a TLS protocol characteristic that
     really did not exist, and would likely be susceptible to MitM:

       http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

     The TLS renegotiation MitM problem (and the full scope of the
     vulnerability) had been independently discovered 2 months earlier
     and resulted in a closed group secretly working on a fix:

       http://www.ietf.org/mail-archive/web/tls/current/msg03942.html

     And some 1500 messages later in the discussion, I gave a very
     rough sketch how to apply semi-formal logic to compare two different
     approaches to specify a protocol feature with each other:

       http://www.ietf.org/mail-archive/web/tls/current/msg05466.html

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 07 Aug 2012 10:16:30 +0200

> of these specs, it looks like a multi-man-year effort to me.

This thread is about OCSP, not about X.509 or PKIX (aka 5280) isn't it?

---

From: [email-masked] (Martin Rex)
Date: Tue, 7 Aug 2012 21:58:00 +0200 (CEST)

Peter Sylvester wrote:
> Martin Rex wrote:

While this specific thread is about OCSP, OCSP is not an isolated
piece of technology, but based on PKIX/rfc5280.  You can not review
the facier options of OCSP without including rfc5280&X.509 in the review.

The carry-on container in OCSP for the OCSP signer certificate is
a sequence of certificates, not a singular cert.  So for the
fancy options where the CA key/cert that signed the certificate
under examination is neither the signer of the OCSP response,
nor the signer of the OCSP signer cert, more than one cert
may be required for the purpose of checking the OCSP signer
cert for revocation.  How to obtain the certs is *not* specified
in rfc2560.  Chasing AIA of a cert that hasn't been verified yet
would be a serious vulnerability.

At the moment I do not see any reasonable alternative to requiring
the inclusion of all necessary certs in the the OCSP response.
But rfc2560 does not mandate a particular ordering of the certs
in the OCSP response, and how to build a certification path
is explicitly outside of the scope of PKIX/rfc5280.

  "You are in a maze of twisty little passages, all alike" 

Reviewing a specification prior to implementing it means recognizing
protocol options that are well-defined and where interop can reasonably
be expected (when implemented by the peer), and distinguishing them
from protocol options that are ambiguous/underspecified and/or partially
out-of-scope is important, or you might see your expectations (about
interop) differ from reality.

I would appreciate when early adopters, who are pushing for a spec
would do a careful review of the spec before it is finalized/published,
so that the spec can be fixed/clarified before there is a huge installed
base.  Often they're primarily focused on specific usage scenarios
on their minds, and whether the spec contains sufficient "slack" for
their purposes & "creativity".

-Martin