Subject: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 13:15:57 -0500

Hi, folsk.

I have a discuss on the lightweight ocsp profile .

One of the primary purposes of the lightweight OCSP profile is to
allow deployment of responders that do not have private keys and thus
can only return pre-produced responses.
However this document is  informational, not standards track.

I contend that RFC 2560 allows pre-produced responses, but does not
really support responders that can only give pre-produced responses.
That is, I contend that as written, to achieve interoperability, you
need to have an online signing key.

I believe it is inappropriate for an informational document to profile
OCSP in this way.

I'd like to ask the PKIX working group to do one of three things to resolve my discuss:

1) Make a standards-track change/clarification to 2560 indicating that
   responders need not have a key.

2) Remove this major goal from the lightweight-ocsp-profile.

3) Withdraw the document.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 9 Nov 2006 12:00:23 -0800

Sam, all:

I will oppose the following:

> 1) Make a standards-track change/clarification to
>    2560 indicating that responders need not have a key.

Perhaps the subject I-D should clarify the role of a relay.

Mike

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Sam Hartman
Sent: Thursday, November 09, 2006 10:16 AM
To: [email-masked]
Subject: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Hi, folsk.

I'd like to ask the PKIX working group to do one of three things to resolve
my discuss:

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 16:10:13 -0500

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Perhaps the subject I-D should clarify the role of a
    Michael> relay.

I do not understand this sentence.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 9 Nov 2006 13:36:55 -0800

Sam,

For definition (since there has never really been one to date), there are
two forms of OCSP relay.  The first is a cache of previously signed yet
still reliable responses.  I believe this to be the target of the subject
I-D.  The second form is a re-signing of OCSP responses under a key trusted
by the ultimate requestor. Neither of these derivative aspects of OCSP are
discussed in any depth in 2560.  It is my preference that 2560 remain as is,
to define the protocol and its various options.  Other I-Ds may then map
that protocol and those options onto specific instances of need.

Mike

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 18:23:44 -0500

>>>>> "Michael" == Michael Myers <[email-masked]> writes:

    Michael> Sam, For definition (since there has never really been
    Michael> one to date), there are two forms of OCSP relay.  The
    Michael> first is a cache of previously signed yet still reliable
    Michael> responses.  I believe this to be the target of the
    Michael> subject I-D.  The second form is a re-signing of OCSP
    Michael> responses under a key trusted by the ultimate
    Michael> requestor. Neither of these derivative aspects of OCSP
    Michael> are discussed in any depth in 2560.  It is my preference
    Michael> that 2560 remain as is, to define the protocol and its
    Michael> various options.  Other I-Ds may then map that protocol
    Michael> and those options onto specific instances of need.

I don't understand how defining an OCSP relay would be different than
my option 1 to which you object.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 09 Nov 2006 22:21:47 -0500

>>>>> "Dave" == Dave Engberg <[email-masked]> writes:

    Dave> I agree with Mike, and disagree with Sam's original
    Dave> assertion.

    Dave> A keyless responder with pre-signed responses can be fully
    Dave> compliant with the mandatory requirements of RFC 2560.  This
    Dave> is reflected in both the "letter of the law" and in every
    Dave> OCSP relying party app/plug-in I've tested (which can all
    Dave> work with keyless caching responders).

Then please clarify 2560.  Reasonable people including me and other
participants in this WG are confused by it.

---

From: "Dave Engberg" <[email-masked]>
Date: Thu, 9 Nov 2006 22:04:24 -0500

I agree with Mike, and disagree with Sam's original assertion.

A keyless responder with pre-signed responses can be fully compliant with
the mandatory requirements of RFC 2560.  This is reflected in both the
"letter of the law" and in every OCSP relying party app/plug-in I've tested
(which can all work with keyless caching responders).

This approach isn't for everyone, but many issuers prefer to trade off the
hypothetical "replay" risk for the security & scalability advantages of
offline keys.  Drastically lower risk of key compromise, DoS, etc.

I don't believe that a profile of OCSP (like the Lightweight OCSP profile)
that implicitly encourages this type of deployment can be in conflict with
RFC 2560.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Michael Myers
Sent: Thursday, November 09, 2006 4:37 PM
To: Sam Hartman
Cc: [email-masked]
Subject: RE: draft-ietf-pkix-lightweight-ocsp-profile and RFC 2560

Sam,

Mike

---

From: Russ Housley <[email-masked]>
Date: Fri, 10 Nov 2006 22:52:34 -0500

>(which can all work with keyless caching responders).

After a face-to-face discussion with Sam, I think that he is 
correct.  Let me try to explain the case that he discovered.

Assume that the relying party has a certification path to validate, 
and two of the certificates in the path contain AIA extensions that 
point to the same OCSP Responder.

The relying party generates an OCSP request, including both of the 
certificates.  RFC 2560 allows one or more certificate to be named in 
the OCSP Request (SEQUENCE OF Request), and I could not find any text 
to indicate that support for more than one element in this sequence 
is not mandatory.

The OCSP Responder generates an OCSP response for both of the 
certificates (SEQUENCE OF SingleResponse).  This response is covered 
by one signature.

So, there are three cases to consider:

(1) OCSP Responder with a signature key - there is not a concern 
here.  The OCSP Responder builds the response and signs it.

(2) OCSP Responder that can relay to a server with a signature key - 
there is not a concern here.  The OCSP Responder forwards the request 
to the server with a signature key, the server builds the response 
and signs it, and then the signed response is sent back to the 
original responder.

(3) OCSP Responder with a bunch of cached responses - there is a 
concern here.  The responder cannot respond to the multi-certificate 
request unless responses for every possible combination of requested 
certificates is computed and cached.  This would be computationally 
prohibitive for a certificate population of any significant size.

The only way forward that I see is RFC 2560bis.

Russ

---

From: "Michael Myers" <[email-masked]>
Date: Sat, 11 Nov 2006 13:37:23 -0800

Russ,

Thanks for the explanation.  I will coordinate with Steve and Stephan.
Perhaps we can also take care of that pesky hash algorithm agility issue at
the same time.

Mike

-----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, November 10, 2006 7:53 PM
>
> . . .
>

Russ