Erwann,
Thank you for your input, it was insightful. See our responses below.
Comment 1:
Intermediate certificates include EKU OIDs for IPSec {Tunnel, User, End
System}, which is weird; why would anyone want a *public* certificate to
authentify against a virtual *private* network? That's not a blocker. These EKU
OIDs are obsolete anyway.
[IdenTrust answer] These Intermediate CAs are used to issue both SSL and device
certificates. Some of those device certificates still require those EKU OIDs,
in some cases in combination with Server Auth EKU OID. At this time, there is
not a strict requirement of separation of SSL versus other device certificates.
We are following discussions about the idea of having a dedicated intermediate
CA to SSL. If this were to become a requirement, we will become compliant that
that time.
Comment 2:
The sha2ssl-acesvalid subscriber certificate includes the BR IV policyId OID,
but this OID isn't granted to the issuer. Not a blocker, but if a RP
explicitely requires this OID to be present, this chain will be rejected (see
recent discussions on CABForum about CP OID chaining).
[IdenTrust answer] We have followed the discussion in CAB Forum and we agree
with the approaches that were discussed there. We will be making a change to
either the subordinate CA (resigning) or to the end-entity profiles (removing
second OID). We will update the list on what approach we will take.
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.
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.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
