> Comment 3: > The OCSP responders both include too many certificates, this has a > performance impact for your users; no need to include intermediate and root > certificates in the response. Not a blocker. > [IdenTrust] You are correct that there is some performance impact. > However, this approach is consistent with the RFC 6960 section 4.2.2 - Basic > Response: "The responder MAY include certificates in the certs field of > BasicOCSPResponse that help the OCSP client verify the responder's signature." > In our experience, SSL certificates are used by clients other than browsers; > and, unfortunately, some clients are not able to do proper path construction. > For those cases, and we have had some, we provide those certificates.
How does this fit with Section 4.2.2.2, though? Either the OCSP response has to be signed by the issuing certificate, in which case no certificates need to be included in the OCSP response, or it must be signed with a delegated OCSP responder certificate that is directly issued by the issuing certificate, in which case only one certificate is required. It seems to me like a correct implementation of OCSP response verification should never need more than one certificate in a reasonably-produced OCSP response, at least in the way that such things are used by browsers. [IdenTrust Response] Brian, Thank you for your comment. IdenTrust uses delegated OCSP for the subordinate CA and Root CA, which is contemplated in Section 4.2.2.2. From the perspective of SSL certificates used within the browser context, we concur with your point and any certificate other than the OCSP signer is unnecessary. Our current implementation, however, includes use cases where SSL certificates, or device certificates, are used by legacy applications that need the additional certificates to perform proper validation. With this said, we are evaluating whether separating those offerings make business sense. In the end, we believe the OCSP responses provided by our system are RFC compliant though not as efficient as possible for the browser context. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
