Thank you for the continued updates, and for relaying the deadline by which these will be revoked.
On Thu, Aug 31, 2017 at 9:35 PM, identrust--- via dev-security-policy < [email protected]> wrote: > 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 > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
