Le jeudi 20 novembre 2014 21:23:41 UTC+1, Brian Smith a écrit :
> Renne Rodriguez <[email protected]> wrote:
> > 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.
>
> Thanks,
> Brian
>
> [1] http://tools.ietf.org/html/rfc6960#section-4.2.2.2
This:
[...]
1. Matches a local configuration of OCSP signing authority for the
certificate in question, or
[...]
was present in RFC2560, and is still present in RFC6960, same section
(4.2.2.2), it just has moved to the end of the section.
This justifies that in some cases (not under CABF BR rules), a whole chain of
certificates needs to be included in the response.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
