This deadline is roughly five weeks before all underscore certificates must be revoked (per Ballot SC12). Given the number of underscore certificates under various DigiCert operated hierarchies, would you think it appropriate to consider whether or not SC12 (and, prior to that, the existing BR requirements in force when those certificates were issued) was followed by that date?
More concretely: If DigiCert were to fail to revoke certificates by that deadline, would it be a reason to consider denying EV status to these roots / removing (if a decision is made to grant) it? I realize the goal is to close discussion a month prior to that date, but I suspect such guidance about the risk of failing to abide by SC12, and failing to revoke by January 15, would be incredibly valuable to DigiCert and their customers. On Thu, Nov 29, 2018 at 1:39 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Reminder: the 3-week discussion period for this request to EV-enable two > DigiCert roots ends next Friday 7-December. > > - Wayne > > On Fri, Nov 16, 2018 at 5:00 PM Wayne Thayer <wtha...@mozilla.com> wrote: > > > This request is to enable EV treatment for the DigiCert Assured ID Root > CA > > and DigiCert Global Root CA as documented in the following bug: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1165472 > > > > * BR Self Assessment is here: > > https://bug1165472.bmoattachments.org/attachment.cgi?id=8960346 > > > > * Summary of Information Gathered and Verified: > > https://bug1165472.bmoattachments.org/attachment.cgi?id=8987141 > > > > * Root Certificate Download URLs: > > ** Global: https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt > > ** Assured: https://www.digicert.com/CACerts/DigiCertAssuredIDRootCA.crt > > > > * CP/CPS: > > ** CP: > > https://www.digicert.com/wp-content/uploads/2018/08/DigiCert_CP_v416.pdf > > ** CPS: > > > https://www.digicert.com/wp-content/uploads/2018/08/DigiCert_CPS_v416.pdf > > > > * These roots are already included with Websites and Email trust bits. EV > > treatment is requested. > > ** EV Policy OID: 2.23.140.1.1 > > ** Original inclusion request: > > https://bugzilla.mozilla.org/show_bug.cgi?id=364568 > > > > * Test Websites: > > ** Global: > > *** Valid: https://global-root-ca.chain-demos.digicert.com/ > > ***Expired: https://global-root-ca-expired.chain-demos.digicert.com/ > > *** Revoked: https://global-root-ca-revoked.chain-demos.digicert.com/ > > ** Assured: > > *** Valid: https://assured-id-root-ca.chain-demos.digicert.com/ > > ***Expired: https://assured-id-root-ca-expired.chain-demos.digicert.com/ > > *** Revoked: > https://assured-id-root-ca-revoked.chain-demos.digicert.com/ > > > > * CRL URLs: > > ** Global: http://crl3.digicert.com/DigiCertGlobalRootCA.crl and > > http://crl4.digicert.com/DigiCertGlobalRootCA.crl > > ** Assured: http://crl3.digicert.com/DigiCertAssuredIDRootCA.crl and > > http://crl4.digicert.com/DigiCertAssuredIDRootCA.crl > > > > * OCSP URL: http://ocsp.digicert.com/ > > > > * Audit: Annual audits are performed by Scott S Perry, CPA according to > > the WebTrust for CA, BR, and EV audit criteria. > > ** WebTrust: https://cert.webtrust.org/ViewSeal?id=2452 > > ** BR: https://www.cpacanada.ca/webtrustseal?sealid=2453 > > ** EV: https://www.cpacanada.ca/webtrustseal?sealid=2454 > > > > Additionally, DigiCert is undergoing quarterly audits (due to the > Symantec > > acquisition) that include the DigiCert Global Root CA and has been > posting > > the reports [1]. > > > > > > I’ve reviewed the CPS, BR Self Assessment, and related information for > the > > DigiCert Assured ID Root CA and DigiCert Global Root CA request that is > > being tracked in this bug and have the following comments: > > > > ==Good== > > * Other than my two comments below, the CP and CPS are in good shape and > > they are well written and regularly updated. > > > > ==Meh== > > * These are old roots, created in 2006, however, DigiCert has provided a > > continuous chain of audits back to their creation [1] > > * CPS section 3.2.2 permitted DigiCert to use vulnerable BR domain > > validation methods 3.2.2.4.9 and 3.2.2.4.10. They are described as > > deprecated in the latest version. > > * DigiCert has had quite a number of compliance bugs over the past 18 > > months [2]. All but one is resolved (that one is awaiting the subordinate > > CA to move to a managed PKI), DigiCert is generally responsive, and they > > have self-reported a number of these issues. > > > > ==Bad== > > * DigiCert’s most recent quarterly audit report states “During our > > examination, we noted DigiCert publicly reported ( > > https://bugzilla.mozilla.org/show_bug.cgi?id=1483715) that it continued > > to rely on a deprecated method of domain validation when renewing > > certificates after the stated transition date of August 1, 2018. As a > > result, DigiCert had to revalidate all affected 1233 certificates over > 154 > > domains.“ At least one of the certificates the required revalidation > chains > > to the DigiCert Global Root CA. > > * The TERENA SSL CA 3 subordinate has misissued a number of certificates > > [3], most of which are not revoked. DigiCert’s response in this bug > states > > “We were under the impression from previous communications with Mozilla > > that certain types of errors identified did not require certificate > > revocation. It would help if Mozilla could indicate which certificate > > errors are believed to require revocation. We will then review the lists > to > > see which certificates need to be revoked.” I do not believe that Mozilla > > should create such a list, and we have set a precedent for requiring > > revocation for at least some of the errors that are identified - e.g. > > metadata in subject fields [4]. > > * In addition, DigiCert previously reported that they had addressed the > > problem of metadata in subject fields for certificates issued by the > Terena > > subordinate [5]. > > * Linters identify a large number of misissued certificates under the > > DigiCert SHA2 Secure Server CA intermediate [6]. Many of these are false > > positives (e.g. ZLint expects CN and SAN fields to be lowercased), but > some > > are not and of those many are not revoked - e.g. [7]. > > * CPS section 3.2.2 did not, in my opinion, adequately specify the > > procedures employed to perform email address verification as required by > > Mozilla policy section 2.2(2). The latest update addressed this. > > > > This begins the 3-week comment period for this request [8]. > > > > I will greatly appreciate your thoughtful and constructive feedback on > the > > decision to grant EV treatment to these root certificates. > > > > - Wayne > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1458024 > > [2] > > > https://bugzilla.mozilla.org/buglist.cgi?f1=creation_ts&list_id=14436306&short_desc=digicert&o1=greaterthan&resolution=---&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=INACTIVE&resolution=DUPLICATE&resolution=WORKSFORME&resolution=INCOMPLETE&resolution=SUPPORT&resolution=EXPIRED&resolution=MOVED&query_format=advanced&short_desc_type=allwordssubstr&v1=2017-09-01&component=CA%20Certificate%20Compliance > > [3] > > > https://crt.sh/?caid=1687&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 > > [4] https://crt.sh/?id=629259396&opt=cablint > > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1397958 > > [6] > > > https://crt.sh/?caid=1191&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 > > [7] https://crt.sh/?id=286404787&opt=zlint > > [8] https://wiki.mozilla.org/CA/Application_Process > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
