On Monday, August 28, 2017 at 3:28:01 PM UTC-4, [email protected] wrote: > On Friday, August 18, 2017 at 7:22:06 PM UTC-4, [email protected] wrote: > > On Thursday, August 17, 2017 at 2:35:15 PM UTC-4, Jonathan Rudenberg wrote: > > > > On Aug 17, 2017, at 14:24, identrust--- via dev-security-policy > > > > <[email protected]> wrote: > > > > > > > > Hello, In reference to 3)"Certificates that appear to be intended as > > > > client certificates, but have the anyExtendedKeyUsage EKU, putting them > > > > in scope for the Mozilla Root Policy." > > > > The following 6 client certificates that have been identified as server > > > > certificates and have been flagged as non-compliant. However, these > > > > certificates do not contain FQDN, IP Address, nor ‘TLS Web Server > > > > Authentication’ EKU. As such in order for us to proceed with our > > > > analysis and determine if any remediation is required, we need > > > > clarification in the exact nature of non-compliance as it relates to > > > > Mozilla Root Policy or CAB Forum Baseline Requirement (ideally with > > > > pointer to the specific requirement in the corresponding documents). > > > > > > The Mozilla Root Store Policy section 1.1 (Scope) says: > > > > > > > This policy applies, as appropriate, to certificates matching any of > > > > the following (and the CAs which control or issue them): > > > > … > > > > 3. End-entity certificates which have at least one valid, unrevoked > > > > chain up to such a CA certificate through intermediate certificates > > > > which are all in scope, such end-entity certificates having either: > > > > - an Extended Key Usage (EKU) extension which contains one or more of > > > > these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, > > > > id-kp-emailProtection; or: … > > > > > > The six certificates linked contain the anyExtendedKeyUsage KeyPurposeId > > > and were issued by an intermediate that is also in scope, so they are in > > > scope for the Mozilla Root Policy and by extension the Baseline > > > Requirements. > > > > > > Jonathan > > > > As an update to the reported issue of misclassification of client > > certificates as server certificates, based on our continuing internal > > investigations, feedback from our user community, and also taking into > > account the feedback posted in this forum, we plan to proceed as follows: > > 1.Nolater than August 31, 2017 we will discontinue new or reissuance of > > human certificate with the anyExtendedKeyUsage extension from all IdenTrust > > ACES CAs. > > 2.We will allow continued use of the current certificates and replace or > > let them expire through natural lifecycle because: > > a. These certificates are not sever certificates > > b. All certificates issued are from audited CA(s) with public disclosure of > > audit result > > c. The legacy application usage requires anyExtendedKeyUsage extension at > > the present time though we are phasing out support of such application. > > d. These certificates do not pose a security concern meriting immediate > > revocation > > e. Replacement of these certificates will result in significant negative > > impact on our customers. > > Effective August 28, 2017, IdenTrust has discontinued new issuance or > reissuance of human certificates with the anyExtendedKeyUsage extension from > all IdenTrust ACES CAs.
IdenTrust continues to work our customers in revoking/replacing ACES SSL certificates with these reported issues: - https for OCSP validation instead of http in AIA extension; - Invalid “US Government” as o= in the SDN; - Invalid OtherName in the SAN extension. For those customers that have not replaced their certificates by September 15, 2017, we will revoke their them. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
