Subject: [pkix] Fw: Comments on draft-ietf-pkix-ocspagility-09

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 11 Oct 2010 12:26:37 +0200

Stefan,

Unless I missed an email, I don't believe that I got a response for the two change proposals below.

Denis

--------- 
DE : Denis Pinkas 
À : denis.pinkas 
Date : 2010-09-14, 10:42:57
Sujet : Comments on draft-ietf-pkix-ocspagility-09 (second resent with an ASN.1error corrected)

Dave draw my attention on this draft since some comments made of RFC2560bis was on text imported from ocspagility. 

Let us start by these comments and then, since I reviewed the whole document, I have further comments. 

The security consideration section has two related problems. 
There are two sentences that indicate that an OCSP responder is able to provide status information at a time in the past, which is wrong. 

I provide both the current text (marked OLD) and a proposal replacement to fix the text (marked NEW). See page 7: 

OLD: 

   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. 

NEW: 

   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 used for a date in the distant past, 
   long after the signing algorithm has ceased being considered 
   trustworthy. 

OLD: 

   In archival applications it is quite possible that an OCSP responder 
   might be asked to report the validity of a certificate on a date in 
   the distant past. 

NEW: 

   In archival applications it is quite possible that an OCSP response 
   is used to report the validity of a certificate on a date in 
   the distant past. 

Now, let us come to the other comments and start with an easy one: 
a typo left intentionally by the editor to check whether someone read the draft. 

On page 3, the text is: 

   Since algorithms other than the mandatory to implement algorithms are 
   Allowed, and since a client currently has no mechanism to indicate 
   it's algorithm preferences, there is always a risk that a server 
   choosing a non-mandatory algorithm, will generate a response that the 
   client may not support. 

On the second line the capital A is incorrect. The text should be changed into: 

   Since algorithms other than the mandatory to implement algorithms are 
   allowed, and since a client currently has no mechanism to indicate 
   it's algorithm preferences, there is always a risk that a server 
   choosing a non-mandatory algorithm, will generate a response that the 
   client may not support. 

[The remaining of the email has been deleted]