Subject: OCSP Agility

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 2 Jul 2008 13:04:07 -0700

I would like to propose OCSP algorithm agility as a WG item.

I have updated the draft circulated earlier. Essentially the argument for this draft is the same as that I made for Steven Farell's: If we want systems to interoperate reliably we should have defined standards for providing the necessary information and not rely on heuristic kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 2 Jul 2008 17:27:51 -0400

The URL does not work.

Unless there is something new, I do not see a need for this.

The algorithms are dictated by the subject certificate.

But, I will be happy to review a newer draft to see if offers any value.

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Wednesday, July 02, 2008 4:04 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: OCSP Agility

I have updated the draft circulated earlier. Essentially the argument
for this draft is the same as that I made for Steven Farell's: If we
want systems to interoperate reliably we should have defined standards
for providing the necessary information and not rely on heuristic
kludges.

http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01
.txt

---

From: Tom Gindin <[email-masked]>
Date: Thu, 3 Jul 2008 19:09:46 -0400

http://www.ietf.org/internet-drafts/draft-hallambaker-ocspagility-01.txt 
does work.  However, I have some actual comments on the draft as well.
        First, the second case in section 4 is not properly worded.  The 
CertID is never signed, although the full request (actually the tbsRequest 
field) may be.  Is the intention of this case to use the algorithm used to 
sign the OCSP request (if it was signed) or to use the algorithm used to 
sign one of the certificates?  Furthermore, my understanding is that there 
may be more than one CertID in the request.
        Second, if the intention of the case is to use the signature of 
the OCSP request when signed, why should the CRL signing algorithm be 
preferred over one of the certificates as the third case?  If the 
certificate was issued with an OCSP AIA and no CRL Distribution Point 
Name, the RP may well never have looked at a CRL for it, while the RP is 
far less likely to have never verified the issuer's signature on the 
certificate.  My assumption is that the upper part of the list is defined 
by the assumption that the next choice after an algorithm which the client 
has explicitly requested is something close to "an algorithm which the 
client has already used for signature or verification".  Is the difficulty 
that some responders may look at CRL's and never actually see the 
certificates?
        Last, the MAY in the second paragraph of section 4 should be at 
the same level as the SHOULD in the last paragraph.

                Tom Gindin

"Santosh Chokhani" <[email-masked]> 
Sent by: [email-masked]
07/02/2008 05:27 PM

To
"Hallam-Baker, Phillip" <[email-masked]>, <[email-masked]>, 
<[email-masked]>
cc
<[email-masked]>
Subject
RE: OCSP Agility

The URL does not work.

 

I would like to propose OCSP algorithm agility as a WG item.
I have updated the draft circulated earlier. Essentially the argument for 
this draft is the same as that I made for Steven Farell's: If we want 
systems to interoperate reliably we should have defined standards for 
providing the necessary information and not rely on heuristic kludges.
http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.txt

---

From: Rob Stradling <[email-masked]>
Date: Fri, 4 Jul 2008 08:31:56 +0100

This draft is entitled "OCSP Algorithm Agility", but I think that "OCSP 
Response Signature Algorithm Agility" would better reflect the current scope 
of the document.

I suggest that we extend the draft so that it also covers:
  1. Recommendations for how an OCSP client should select the signature 
algorithm with which to sign an OCSP request (when OCSP request signing is 
desired).
  2. Recommendations for how an OCSP client should select the hash algorithm 
for each CertID in an OCSP request.

For 1, could we say that an OCSP client MUST either:
  i) not sign an OCSP request, or...
  ii) sign an OCSP request using the same algorithm as the signature on the 
certificate for which it wishes to know the status?
Also, if/when an OCSP responder encounters a signed OCSP request with an 
unknown signature algorithm, could we say that the OCSP responder MUST treat 
that signed OCSP request as if it were an unsigned OCSP request?

For 2, could we simply say that SHA-1 MUST be used?
Are there any real-world applications that don't use SHA-1 for CertID Hash 
Algorithms in OCSP requests?

-- 
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com

Comodo CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

---

From: Rob Stradling <[email-masked]>
Date: Fri, 4 Jul 2008 08:56:25 +0100

On Friday 04 July 2008 08:31:56 Rob Stradling wrote:
> Response Signature Algorithm Agility" would better reflect the current
> scope of the document.
>
>   2. Recommendations for how an OCSP client should select the hash
> algorithm for each CertID in an OCSP request.
>

Change "on the certificate" to "on one of the certificates".  A single OCSP 
request can enquire about multiple certificates.

> unknown signature algorithm, could we say that the OCSP responder MUST
> treat that signed OCSP request as if it were an unsigned OCSP request?
>
> > CertID is never signed, although the full request (actually the
> > tbsRequest field) may be.  Is the intention of this case to use the
> > algorithm used to sign the OCSP request (if it was signed) or to use the
> > algorithm used to sign one of the certificates?  Furthermore, my
> > understanding is that there may be more than one CertID in the request.
> > by the assumption that the next choice after an algorithm which the
> > client has explicitly requested is something close to "an algorithm which
> > the client has already used for signature or verification".  Is the
> > difficulty that some responders may look at CRL's and never actually see
> > the certificates?
> > http://www.ietf.org/proceedings/staging/draft-hallambaker-ocspagility-01.
> >tx t

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 8 Jul 2008 13:34:08 +0100

This has been a topic for discussion for a long time and I think it would be great if we finally could get momentum in moving this forward and into conclusion.
I have reviewed the draft and I think it is a good start, reflecting earlier discussions of the issue.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: Hallam-Baker, Phillip [mailto:[email-masked]]
Sent: den 2 juli 2008 22:04
To: [email-masked]; Stefan Santesson
Cc: [email-masked]
Subject: OCSP Agility

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 8 Jul 2008 15:30:54 +0200

I looked at the draft.

It seems that the main argument is given in section 6:
   In most applications it is sufficient for the signing algorithm to be   at least as secure as the signing algorithm used to sign the original   certificate whose status is being queried.  This criteria may not   hold in long term archival applications however in which the status   of a certificate is being queried for a date in the distant past,   long after the signing algorithm has ceased being considered trustworthy.
The case of long term archival can be addressed by applying a time-stamp on the response, i.e. as specified in RFC 5126 (CAdES). 
Most of the other cases can indeed be addressed by using the signature algorithm used to sign the original certificate.

So I am not fully convinced that there is such a need, since it is always possible to have some servers that only use specific algorithms 
(which is a case that is not mentioned in the draft), like ECDSA.

I noticed that, in the proposal, the client has no clue to know which algorithms the server would be ready to support. 
There might be some kind of negotiation. Should this draft progress, I would then suggest to use 
some of the ideas of SP-NEGO (RFC 2487).

Denis

De : owner-ietf-pkix 
À : kent,stefans 
Date : 2008-07-02, 22:04:07
Sujet : OCSP Agility

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 11 Jul 2008 13:11:57 +0100

Phil,

I have some concerns with your proposal with respect to compatibility with the Lightweight OCSP profile, RFC 5019 (http://tools.ietf.org/html/rfc5019).

In the transport profile of rfc 5019 (section 5) the following is stated:

   When constructing a GET message, OCSP clients MUST base64 encode the
   OCSPRequest structure and append it to the URI specified in the AIA
   extension [PKIX].  Clients MUST NOT include CR or LF characters in
   the base64-encoded string.  Clients MUST properly URL-encode the
   base64 encoded OCSPRequest.  For example:

      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
      %3D%3D

 The reason for this is to enable HTTP cashing by making request URIs unique for any given certificate.

However, if clients starts to include algorithm preferences in the request, this model is broken and status requests for the same certificate may result in different requests URI's. This may negatively affect the cashing model which is a serious problem for certificates with high volume of status checks such as web server certificates.

I think we at-least need to make clear that the proposals of your new draft MUST NOT be used in combination with RFC 5019.
Alternatively this may be a reason to reconsider this proposal altogether.

Stefan Santesson
Senior Program Manager

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jul 2008 08:07:12 -0700

Well, RFC 5019 states that it SHOULD NOT be used with ANY extension:
 
   Clients MUST NOT include the singleRequestExtensions structure.

   Clients SHOULD NOT include the requestExtensions structure.  If a
   requestExtensions structure is included, this profile RECOMMENDS that
   it contain only the nonce extension (id-pkix-ocsp-nonce).  See
   Section 4 <https://webmail.verisign.com/exchange/philip.baker/Drafts/RE:%20OCSP%20Agility.EML/1_text.htm#section-4>  for issues concerning the use of a nonce in high-volume
   OCSP environment
 
Which is clearly something that should be noted in the draft.
 
I don't see that this causes a problem however. Variation in the request structure will reduce the efficiency of caching somewhat but not eliminate the advantage entirely. If caching is worthwhile we should be hoping for ten hits or more per cert that is looked up. One index key per cert is certainly more efficient than two but it is not a deal breaker.
 
Moreover the point of the Simple profile is in my view to state a set of optimum choices for maximizing the performance of the Internet infrastructure that is consistent with the full spec. That is a moving target. What is optimum in 2008 is not going to be optimum when ECC algorithms start to be rolled out. I would imagine that at some stage we will upgrade to mandate the SHA replacement from the competition, etc.

The point of this particular structure is to enable a transition to a new algorithm in a model that involves a local intelligent, OCSP and PKI aware proxy in place of the vanilla HTTP cache.  

From: [email-masked] on behalf of Stefan Santesson
Sent: Fri 7/11/2008 8:11 AM
To: Hallam-Baker, Phillip; [email-masked]
Cc: [email-masked]
Subject: RE: OCSP Agility

Phil,

I have some concerns with your proposal with respect to compatibility with the Lightweight OCSP profile, RFC 5019 (http://tools.ietf.org/html/rfc5019 <http://tools.ietf.org/html/rfc5019> ).

      %3D%3D

 

Stefan Santesson

Senior Program Manager

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jul 2008 10:18:12 -0700

A collegue just pointed out that there are actually two objectives here:
 
1) To provide a transition for new hash algorithms
2) To deprecate unused algorithms
 
The second goal is actually more important than the first. You do not gain any security from enabling the use of a more secure algorithm. You only gain additional security by withdrawing deprecated algorithms from use.
 
Including the agility extension does introduce an additional cache index key, but that is all. Including an extension does not make the response any less cachable:
 
Request
    http:// -lookup-ocsp-status-of-cert-foo-
Response (from server)
    X
 
Request
    http:// -lookup-ocsp-status-of-cert-foo-
Response (from cache)
    X

Request
    http:// -lookup-ocsp-status-of-cert-foo-with-extension
Response (from server)
    Y
 
Request
    http:// -lookup-ocsp-status-of-cert-foo-with-extension
Response (from cache)
    Y

Now it is entirely possible that X=Y in which case a cache might even be able to collapse the two results. But even if they are different the result is still cacheable.

From: Hallam-Baker, Phillip
Sent: Fri 7/11/2008 11:07 AM
To: Stefan Santesson; [email-masked]
Cc: [email-masked]
Subject: RE: OCSP Agility

 

Phil,

      %3D%3D

 

Stefan Santesson

Senior Program Manager