> 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? [IdenTrust Answer] Eventually, those RP will change their behavior. In the meantime, we need to maintain the behavior as it is. As I responded to Brian Smith, we are actively considering separation of our offerings to minimize the impact to our SSL customers as it has been suggested here. > 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. [IdenTrust Answer] We have made changes to the certificates linking back to the Public root, and they only include one OID consistent with the RFC. Going forward, we will have two approaches that are considered valid in the RFC. In other words, we will not include the CAB Forum OID in the end entity certificate unless it is in the subordinate CA explicitly or through the AnyPolicy value. The IdenTrust ACES CA 2 should provide the correct response now. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
