Subject: New Lightweight OCSP I-D

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 4 Oct 2004 09:54:08 -0400

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.
 
1.  Section 1.2.2, sha256WithRSAEncryption should be added to the signature
algorithms.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
9.Section 5.1, Caching should be RECOMMEND and not MUST.
 
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.
 
Santosh Chokhani 
Orion Security Solutions, Inc. 
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101 
(703) 917-0060  Ext. 35 (voice) 
(703) 917-0260 (Fax) 
[email-masked] 
Visit our Web site 
http://www.orionsec.com <http://www.orionsec.com/>

---

From: "Deacon, Alex" <[email-masked]>
Date: Fri, 8 Oct 2004 14:08:49 -0700

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:[email-masked]] 
> Sent: Tuesday, October 05, 2004 3:01 PM
> To: [email-masked]
> 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:[email-masked]] 
> Sent: Tuesday, October 05, 2004 3:00 PM
> To: 'Santosh Chokhani'; [email-masked]
> 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:[email-masked]]
> > Sent: Monday, October 04, 2004 6:54 AM
> > To: [email-masked]
> > 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]
> 
> 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.]
> 
> >
> 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
> 
>