RE: New Lightweight OCSP I-D

["Deacon, Alex" <alex@xxxxxxxxxxxx>]

Santosh,

Thanks for taking the time to review the draft.  Comments in line....

> -----Original Message-----
> From: Santosh Chokhani [mailto:chokhani@xxxxxxxxxxxx] 
> Sent: Monday, October 04, 2004 6:54 AM
> To: ietf-pkix@xxxxxxx
> Subject: New Lightweight OCSP I-D
>
> I have some concerns regarding the new RFC.  There are several items 
> in the I-D that are good engineering advice, but they go far beyond
> what should be within the scope of the RFC and should be up to the
> application and relying party.  These are listed as MUST in the RFC 
> and should be changed to SHOULD or RECOMMENDED.  These items are 
> included in the comments below.

Remember that the main motivation of this draft is to define a profile
of OCSP that ensures OCSP scalability (including bandwidth issues and
client/server processing) when used in large PKI environments.  Moving
some of the MUSTs to SHOULDs seems to water down what we are
trying to accomplish.   Also, our goal is to not make current client
implementations non-conformant, but to define behavior when these
clients find themselves in high volume environments.   We will make
this clearer in the introduction for -01.  

> 1.  Section 1.2.2, sha256WithRSAEncryption should be added to the
> signature algorithms.

Although I understand the reasoning behind adding this requirement, I
think doing so is a little premature and would create a situation
Where this draft is no longer a strict profile of RFC2560.   I think
2560 has to move first on this point.  

> 2.  Section 1.2.2, The term "validity window" for the response is 
> not clear or defined.  I suspect it is thisUpdate and nextUpdate for
> the response.  It should be defined.  Furthermore, there is no 
> reason for the Responder certificate validity period to envelope 
> the response window.  For example, the Responder may have been 
> issued a new certificate since thisUpdate or may get a new 
> certificate before nextUpdate.  Thus, this requirement is excessive.
> Also, it is not clear why this requirement is imposed from security 
> viewpoint.

Well, from a security point of view its my opinion that a properly
behaved OCSP responder would always ensure that responses it creates
are enveloped within the validity period of the certificate it uses to
sign the responses.  If one assumes that the OCSP responder
certificate is a license to issue responses a responder should not be
entitled to issue a response that exceeds his license to make such
statements.

>From a more practical point of view, there exist many widely deployed
clients that will fail OCSP response validation if this nesting does
not occur.  Thus we were hoping to increase interop with the existing
client base with this requirement.  You will note that this draft is
currently specified as informational due in some part to the fact that
it defines existing and deployed implementations.  

Having said that, I agree clarification would be helpful.  Here is a
proposed update to the 3rd paragraph of section 1.2.2 -      

1.2.2 Signed OCSPResponses 

[...]

    The response validity period is the time interval during 
    which the responder warrants that the response is accurate, 
    it is represented as two dates: the date in which the 
    response validity period begins (thisUpdate) and the date
    in which the response validity period ends (nextUpdate). The 
    response validity period SHOULD NOT exceed the validity period
    of the responders certificate.  
    

> 3.  Section 1.2.3, It is not clear if the certificate has expired
> and the Responder does not maintain revocation status of expired 
> certificates, what the response should be.  May be "unauthorized" is
> meant.  If so, this should be made clearer.

OK.  We will update the last paragraph of Section 1.2.3 as follows:

    The responder will return an OCSPResponseStatus of "unauthorized" 
    when processing requests for which it is not capable of responding 
    authoritatively. This includes the scenario where a responder has 
    removed the records of expired certificate from its database.  

> 4.  Section 2.1, The recognition of AIA should be changed from MUST 
> to RECOMMENDED.  Using MUST means that clients and implementations 
> that use OCSP Responder as trust anchor, will have an added 
> requirement.

I think its important that if a CA includes an OCSP AIA extension in
the cert that all clients have the ability to recognize this extension. The
requirement does not mandate a client communicate with
the responder on the other side of the AIA URI...just that it has the
option of doing so (or not doing so) based on local policy. 

> 5.  Section 2.1, The requirement to check OCSP before CRL as a MUST
> is excessive.  This should be recommended.  It should be left up to
> the implementation to determine whether to use CRL or OCSP.

Well...I think asking for a CRL that may be many megabytes when a
simple/small OCSP request/response would do the trick is also excessive :)
If others feel the MUST here is excessive I'll change
to a SHOULD. 

> 6.  Section 2.2, The order in which path is validated and when the
> OCSP response is requested, should be changed from MUST to
> RECOMMENDED.  This should be an application decision.

If a client is unable to validate a signature on a cert, why would it
bother to hit the wire to determine the certs status?Remember that one
goal of this ID is to limit clients hits to the server and thus we are
suggesting that applications using OCSP clients in these scenarios
(not all scenarios mind you) validate the cert first, before it hits
the wire to ask for its revocation status.  What if we qualified this
MUST as follows: 

2.2 Sending an OCSP Request 
     
    To avoid needless network traffic, when applications are operating 
    as a lightweight OCSP client they MUST verify the signature of 
    signed data before asking an OCSP client to check the status of 
    certificates used to verify the data. If the signature is invalid 
    or the application is not able to verify it, an OCSP check MUST
    NOT be requested. 


> 7. Section 3, When nonce is not included in the request or response,
> another way to check freshness are producedAt and thisUpdate.  
> These should be described in this section.

Agreed.  We mention this in section 3, but don't elaborate.

> 
> 8.Section 3, The checks for nextUpdate that are MUST should be
> changed to RECOMMENDED.  Basically, freshness check should be based
> on the local policy and this I-D should RECOMMEND items based on a
> combination of the three dates asserted in the response.

We are saying that when a client is configured (via local policy or
otherwise) to work in a highvolume/lightweight mode it must make these
checks.  We are not mandating that clients always operate in this
mode.  Would qualifying this MUST such that it applies to OCSP clients
operating in a lightweight/highvolume environment (as suggested for #6
above) do the trick?

>
> 9.Section 5.1, Caching should be RECOMMEND and not MUST.

I disagree...especially when clients are operating in a
lightweight/highvolume environment.  Caching on the client is key to
ensuring server load and network bandwidth is kept to a minimum.
Again, would qualifying this MUST address your issue?  

> 10.  The I-D should explicitly require the Responders to have access
> to accurate source of time in order to assert producedAt and
> possibly thisUpdate and nextUpdate, depending on how the Responder
> asserts these two values.

Will add to section 3.  

Thanks
Alex