RE: New Lightweight OCSP I-D

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

Thanks again Santosh,

This gives me a better idea as to your concerns so I will go back and work
on a -01 version with your comments in mind.  Look for a new version
sometime next week.

Alex


> -----Original Message-----
> From: Santosh Chokhani [mailto:chokhani@xxxxxxxxxxxx] 
> Sent: Tuesday, October 05, 2004 3:01 PM
> To: ietf-pkix@xxxxxxx
> Subject: RE: New Lightweight OCSP I-D
> 
> 
> 
> 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
> 
>