Bonsoir, Le mercredi 19 novembre 2014 01:03:29 UTC+1, Renne Rodriguez a écrit :
[...] > 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. I've read that argument before for some Java software, where the client sets issuerKeyHash with an empty value and only populates the issuerNameHash field. Including the whole certificate chain isn't forbidden, of course. But I'd be tempted to say that those RP should die. This minority forces a penalty to be paid by the majority (browsers, good players). In order to lower that penalty, you could maybe consider to not include the root in the response. What value could have a root certificate transmitted that way, since trust in a TA MUST come out-of-band? > Comment 4: > The OCSP responders answer "unknown" when asked to verify the 2 given > intermediate certificates. Not a blocker, but probably not expected. > [IdenTrust] Our configuration was incorrect in the OCSP. We have corrected > it and you should be able to receive the appropriate responses. That seems to be done for the "Commercial" root, but not for the "Public" root. Trying to validate certificate for intermediate CA "IdenTrust ACES CA 2" still gives an unknown answer. Again, no opposition from my side to this request. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
