RE: New Lightweight OCSP I-D

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Alex,

Thanks for your comments.  See my responses in-line using [SC:]

-----Original Message-----
From: Deacon, Alex [mailto:alex@xxxxxxxxxxxx] 
Sent: Tuesday, October 05, 2004 3:00 PM
To: 'Santosh Chokhani'; ietf-pkix@xxxxxxx
Subject: RE: New Lightweight OCSP I-D



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.  

[SC: I am aware of this.  Most of my comments are related to client behavior
and not to the bits on the wire.  The possible exception being the mandatory
caching of the responses.  There, I felt the client simplicity should
drive.]

> 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. 

[SC: 2560 does not limit the signing algorithm.  It imports these.  3280
also is not dependent.  They bring in the algorithm identifiers from 3279 or
successor.  I think this I-D should follow the same modular approach.
Otherwise, we will need to revise it in another year] 

> 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.

[SC: The above text is not a security argument.  Actually, there is no
security issue in this topic or a security reason to envelop the validity
period in a revocation entry with that of the Responder certificate.  One
could try to say that producedAt should fall within the certificate validity
period.  But, even that is not necessary.  Furthermore, since you recommend
short validity period for Responder, this may pose a problem.  Imagine a CA
issuing weekly or daily CRL and Responder renewing it certificate monthly.
You do not want to change thisUpdate or nextUpdate.  You may not be able to
use old or the new certificate.  Aside from being useless from security
viewpoint, you could be in a deadlock at worst and adding the complexity to
the Responder and the client that is not needed and 2560 does not advocate
it.]

>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.  

[SC: If we defined PKI mantra using some of the widely deployed products, we
would have security holes the size of pacific ocean.  We do not change the
security principles and standards because commercial products do it one way.
As to informational RFC, may be you or some one can explain to me what the
term MUST means for informational.  My comments are oriented towards
enhancing interoperability.]

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.  
    
[SC: See previous response]

> 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. 

[SC: Thanks] 

> 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. 

[SC: I am ok with AIA as MUST for an informational RFC]

> 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. 

[SC: I think we should change it]

> 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. 

[SC: My comments are based on giving the leeway to the clients since these
things do not impact interoperability or security.  That is why this should
be RECOMMENDED.]

> 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.

[SC: Thanks]

> 
> 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?

[SC: Again, I do not see why lightweight high volume relates to thus.  The
client should be able to use any of the three mechanisms and local policy to
determine if a response is fresh enough.  This is another case of having a
more stringent requirement and creating extra bits on the wire, when local
policy or other two dates will help accept a response.]

>
> 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?  

[SC: May be qualifying here is the best compromise in the interest of
bandwidth.]

> 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.  

[SC: Thanks.]

Thanks
Alex