Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
DigiCert Assured ID Root CA and Global Root CA EV Request
513 views
Skip to first unread message
Wayne Thayer
Nov 16, 2018, 7:00:27 PM11/16/18
to mozilla-dev-security-policy
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
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
Wayne Thayer
Nov 29, 2018, 1:39:14 PM11/29/18
to mozilla-dev-security-policy
Reminder: the 3-week discussion period for this request to EV-enable two
DigiCert roots ends next Friday 7-December.
- Wayne
DigiCert roots ends next Friday 7-December.
- Wayne
Ryan Sleevi
Nov 29, 2018, 2:19:02 PM11/29/18
to Wayne Thayer, mozilla-dev-security-policy
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.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
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.
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Jeremy Rowley
Nov 29, 2018, 4:17:45 PM11/29/18
to ry...@sleevi.com, Wayne Thayer, mozilla-dev-security-policy
We can revoke them all by then. The question is do the browsers really want us to?
Since we started a public discussion, here's the details:
There are several prominent websites that use certs with underscore characters in connection with major operations. I was hoping to get permission to post the names of these companies before I started a public discussion, but se le vie - the discussion already started. These companies are currently in their blackout period which ends around mid-Jan. We're scheduled to revoke on Jan 14th per the BR change. However, we've heard back from several of them that they won't complete the migration by then. This will take down several of the Fortune 500's websites for a change in the BRs that no one can understand. What we're wondering is how the browsers feel about revocation vs. shutting down the sites. Public discussion is welcome while I still try to get the names. Unfortunately, most companies of that size require a legal review of the communication before we can post their name...
-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, November 29, 2018 12:19 PM
To: Wayne Thayer <wth...@mozilla.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert Assured ID Root CA and Global Root CA EV Request
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-secur...@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 <wth...@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://clicktime.symantec.com/a/1/adm9pTelz2Ycom-02ypNzTJ8tHbaHBnhr
> > 4KpinQCwlc=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1165472
> > gvhgZ8YgRI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8960346
> > Arsg3rBYtU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8987141
> > E7BVELpayo=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D364568
> > pfWf4rjru8=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fcert.webtrust.org%2FViewSeal%3Fid%3D2452
> > ** BR:
> > https://clicktime.symantec.com/a/1/XxCChbVOI6x4T0xXj3mYGLskxSLg7PEes
> > qb-ZCodC-w=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fwww.cpacanada.ca%2Fwebtrustseal%3Fsealid%
> > 3D2453
> > ** EV:
> > https://clicktime.symantec.com/a/1/UGW5q2yxuSpQkiZdmASM_exdyNuTMq7sB
> > KM5AESInbg=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fwww.cpacanada.ca%2Fwebtrustseal%3Fsealid%
> > 3D2454
> > https://clicktime.symantec.com/a/1/O9JYNG1ODgoz45BvP1rtuQ1QxiPhhm7y9
> > a3dEe7U0fg=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1483715) that it continued to rely on a deprecated method of
> > https://clicktime.symantec.com/a/1/JsoAuHhi-PH3oxLp8eOn2RnOWn1RegTIf
> > 8D4HkGnT3k=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1458024
> > [2]
> >
> https://clicktime.symantec.com/a/1/d9qobeACNddYcwU0y3KulpBh5BAI5g357_X
> 3bLQziI8=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Fbugzilla.mozilla.org%2Fbuglist.cgi%3Ff1%3Dcreation_ts%26lis
> t_id%3D14436306%26short_desc%3Ddigicert%26o1%3Dgreaterthan%26resolutio
> n%3D---%26resolution%3DFIXED%26resolution%3DINVALID%26resolution%3DWON
> TFIX%26resolution%3DINACTIVE%26resolution%3DDUPLICATE%26resolution%3DW
> ORKSFORME%26resolution%3DINCOMPLETE%26resolution%3DSUPPORT%26resolutio
> n%3DEXPIRED%26resolution%3DMOVED%26query_format%3Dadvanced%26short_des
> c_type%3Dallwordssubstr%26v1%3D2017-09-01%26component%3DCA%2520Certifi
> cate%2520Compliance
> > [3]
> >
> https://clicktime.symantec.com/a/1/cv29LZ0aMprGOGP3_i9pJvIKtU03dtxW01C
> lStku4ME=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Fcrt.sh%2F%3Fcaid%3D1687%26opt%3Dcablint%2Czlint%2Cx509lint%
> 26minNotBefore%3D2017-01-01
> > [4]
> > https://clicktime.symantec.com/a/1/xc0YnRyh-a3ErupOK8QqNRBNxXuPDjBX9
> > Aqp368RZ0E=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fcrt.sh%2F%3Fid%3D629259396%26opt%3Dcablin
> > t [5]
> > https://clicktime.symantec.com/a/1/SV_QEIGx9OD76mw9OSUCq01xxi0dND28F
> > gvPNzlkUVg=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1397958
> > [6]
> >
> https://clicktime.symantec.com/a/1/a5MBE9vDL2Lz9YnepFJgbhktPwQwb5rd833
> IHUVRsKI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Fcrt.sh%2F%3Fcaid%3D1191%26opt%3Dcablint%2Czlint%2Cx509lint%
> 26minNotBefore%3D2017-01-01
> > [7]
> > https://clicktime.symantec.com/a/1/NvH3EThd5lzzDF41sCi-VlkV7i-tAOz7q
> > B9EZCo9Hig=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fcrt.sh%2F%3Fid%3D286404787%26opt%3Dzlint
> > [8]
> > https://clicktime.symantec.com/a/1/6dqQTS86zKEnATv1ByYBYXBQbs1t1FLW6
> > L7OQulY_5c=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2FApplication_Proce
> EC3gwZaU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
Since we started a public discussion, here's the details:
There are several prominent websites that use certs with underscore characters in connection with major operations. I was hoping to get permission to post the names of these companies before I started a public discussion, but se le vie - the discussion already started. These companies are currently in their blackout period which ends around mid-Jan. We're scheduled to revoke on Jan 14th per the BR change. However, we've heard back from several of them that they won't complete the migration by then. This will take down several of the Fortune 500's websites for a change in the BRs that no one can understand. What we're wondering is how the browsers feel about revocation vs. shutting down the sites. Public discussion is welcome while I still try to get the names. Unfortunately, most companies of that size require a legal review of the communication before we can post their name...
-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, November 29, 2018 12:19 PM
To: Wayne Thayer <wth...@mozilla.com>
Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert Assured ID Root CA and Global Root CA EV Request
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-secur...@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 <wth...@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:
> > 4KpinQCwlc=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1165472
> >
> > * BR Self Assessment is here:
> > https://clicktime.symantec.com/a/1/yUphkRZlY4hiWQzfLqXz_e6_F7P6T9IN6
> > * BR Self Assessment is here:
> > gvhgZ8YgRI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8960346
> >
> > * Summary of Information Gathered and Verified:
> > https://clicktime.symantec.com/a/1/25vbrlC4oNIH-rmRpBBOoNpXg9-MyHD3b
> > * Summary of Information Gathered and Verified:
> > Arsg3rBYtU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8987141
> >
> > * 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://clicktime.symantec.com/a/1/WoyWUFbnpkb4mbYZEFqYVeHOLyYBa9QA_
> > * 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
> > ** CPS:
> >
> https://www.digicert.com/wp-content/uploads/2018/08/DigiCert_CPS_v416.
> >
> > * 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:
> > E7BVELpayo=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D364568
> >
> > * 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://clicktime.symantec.com/a/1/xUfp8YkRY4bmisyJbV3vrcdh6t1ivVaSu
> > * 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:
> > pfWf4rjru8=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fcert.webtrust.org%2FViewSeal%3Fid%3D2452
> > ** BR:
> > https://clicktime.symantec.com/a/1/XxCChbVOI6x4T0xXj3mYGLskxSLg7PEes
> > qb-ZCodC-w=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fwww.cpacanada.ca%2Fwebtrustseal%3Fsealid%
> > 3D2453
> > ** EV:
> > https://clicktime.symantec.com/a/1/UGW5q2yxuSpQkiZdmASM_exdyNuTMq7sB
> > KM5AESInbg=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fwww.cpacanada.ca%2Fwebtrustseal%3Fsealid%
> > 3D2454
> > a3dEe7U0fg=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1483715) that it continued to rely on a deprecated method of
> > 8D4HkGnT3k=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1458024
> > [2]
> >
> https://clicktime.symantec.com/a/1/d9qobeACNddYcwU0y3KulpBh5BAI5g357_X
> 3bLQziI8=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Fbugzilla.mozilla.org%2Fbuglist.cgi%3Ff1%3Dcreation_ts%26lis
> t_id%3D14436306%26short_desc%3Ddigicert%26o1%3Dgreaterthan%26resolutio
> n%3D---%26resolution%3DFIXED%26resolution%3DINVALID%26resolution%3DWON
> TFIX%26resolution%3DINACTIVE%26resolution%3DDUPLICATE%26resolution%3DW
> ORKSFORME%26resolution%3DINCOMPLETE%26resolution%3DSUPPORT%26resolutio
> n%3DEXPIRED%26resolution%3DMOVED%26query_format%3Dadvanced%26short_des
> c_type%3Dallwordssubstr%26v1%3D2017-09-01%26component%3DCA%2520Certifi
> cate%2520Compliance
> > [3]
> >
> https://clicktime.symantec.com/a/1/cv29LZ0aMprGOGP3_i9pJvIKtU03dtxW01C
> lStku4ME=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Fcrt.sh%2F%3Fcaid%3D1687%26opt%3Dcablint%2Czlint%2Cx509lint%
> 26minNotBefore%3D2017-01-01
> > [4]
> > https://clicktime.symantec.com/a/1/xc0YnRyh-a3ErupOK8QqNRBNxXuPDjBX9
> > Aqp368RZ0E=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fcrt.sh%2F%3Fid%3D629259396%26opt%3Dcablin
> > t [5]
> > https://clicktime.symantec.com/a/1/SV_QEIGx9OD76mw9OSUCq01xxi0dND28F
> > gvPNzlkUVg=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1397958
> > [6]
> >
> https://clicktime.symantec.com/a/1/a5MBE9vDL2Lz9YnepFJgbhktPwQwb5rd833
> IHUVRsKI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Fcrt.sh%2F%3Fcaid%3D1191%26opt%3Dcablint%2Czlint%2Cx509lint%
> 26minNotBefore%3D2017-01-01
> > [7]
> > https://clicktime.symantec.com/a/1/NvH3EThd5lzzDF41sCi-VlkV7i-tAOz7q
> > B9EZCo9Hig=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fcrt.sh%2F%3Fid%3D286404787%26opt%3Dzlint
> > [8]
> > https://clicktime.symantec.com/a/1/6dqQTS86zKEnATv1ByYBYXBQbs1t1FLW6
> > L7OQulY_5c=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv&u=https%3A%2F%2Fwiki.mozilla.org%2FCA%2FApplication_Proce
> > ss
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/45-p_OLIEymkbRnqdgO-Lanwpk8_elXpRzC
> >
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> EC3gwZaU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9sh
> ljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxr
> bkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3
> Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg
> 5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhn
> Vjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQ
> hASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=htt
> ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/45-p_OLIEymkbRnqdgO-Lanwpk8_elXpRzCEC3gwZaU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZwj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_YznwhbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWouOh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInYiEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIeJAcE67idnv&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
Wayne Thayer
Nov 29, 2018, 6:18:23 PM11/29/18
to Jeremy Rowley, Ryan Sleevi, mozilla-dev-security-policy
I would appreciate it if we could move the discussion of exceptions to the
deadline for revoking certificates containing underscores to a new thread.
As it relates to this request, any failure to meet the revocation deadline
would trigger the creation of an incident bug. (that is unless we as a
community decide otherwise)
I am not of the opinion that the existence of such a bug would change the
outcome of this discussion. If others feel that it might, I am not opposed
to holding the discussion open. Meanwhile, i'd suggest we stick to
discussing the current facts of this request.
- Wayne
On Thu, Nov 29, 2018 at 2:17 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:
deadline for revoking certificates containing underscores to a new thread.
As it relates to this request, any failure to meet the revocation deadline
would trigger the creation of an incident bug. (that is unless we as a
community decide otherwise)
I am not of the opinion that the existence of such a bug would change the
outcome of this discussion. If others feel that it might, I am not opposed
to holding the discussion open. Meanwhile, i'd suggest we stick to
discussing the current facts of this request.
- Wayne
On Thu, Nov 29, 2018 at 2:17 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:
Ryan Sleevi
Nov 29, 2018, 6:59:14 PM11/29/18
to Wayne Thayer, Jeremy Rowley, Ryan Sleevi, mozilla-dev-security-policy
Sure, my intent was to keep it narrowed to understanding the potential
impact to this conversation.
I raise this concern because I think it would reflect poorly if these
certificates were not revoked. There has been past precedent - e.g. not
granting EV to Turktrust after misissuance came to light, post inclusion
process discussions - that are relevant and applicable to know whether this
precedent still holds. And, as Jeremy’s reply highlights, it sounds like
there is non-trivial risk of such actions happening.
I would find it difficult, especially if these certificates are EV
certificates, to believe that the standards are being upheld in a way that
deserves EV recognition if a CA does not make a timely revocation.
Similarly, there has been past precedent that failures are best called out
early, during the inclusion process, as they become more difficult to
remediate, short of distrust, once they are included, and thus are also
treated more seriously.
Given these past precedents, it should not seem unreasonable to suggest
that any recognition of EV is perhaps contingent upon no new incidents
coming to light in the weeks following such discussions. Alternatively, if
that is seen to be too extreme, that any incidents being shared following
that deadline should result in a return to public discussion, with the
default assumption being that EV will not be granted/be removed, might
equally provide a clearer set of expectations, and align with Mozilla’s
interest in ensuring CAs consistently meet expectations.
impact to this conversation.
I raise this concern because I think it would reflect poorly if these
certificates were not revoked. There has been past precedent - e.g. not
granting EV to Turktrust after misissuance came to light, post inclusion
process discussions - that are relevant and applicable to know whether this
precedent still holds. And, as Jeremy’s reply highlights, it sounds like
there is non-trivial risk of such actions happening.
I would find it difficult, especially if these certificates are EV
certificates, to believe that the standards are being upheld in a way that
deserves EV recognition if a CA does not make a timely revocation.
Similarly, there has been past precedent that failures are best called out
early, during the inclusion process, as they become more difficult to
remediate, short of distrust, once they are included, and thus are also
treated more seriously.
Given these past precedents, it should not seem unreasonable to suggest
that any recognition of EV is perhaps contingent upon no new incidents
coming to light in the weeks following such discussions. Alternatively, if
that is seen to be too extreme, that any incidents being shared following
that deadline should result in a return to public discussion, with the
default assumption being that EV will not be granted/be removed, might
equally provide a clearer set of expectations, and align with Mozilla’s
interest in ensuring CAs consistently meet expectations.
Wayne Thayer
Dec 13, 2018, 7:33:52 PM12/13/18
to Jeremy Rowley, Ryan Sleevi, mozilla-dev-security-policy
My main concern with this request is the misissued certificates identified
by linters that have not been revoked - I have included my comments and
links from the original message below.
It appears that DigiCert is not planning to remediate these certificates -
can a representative from DigiCert confirm that?
If these certificates are not revoked, I feel that it would be consistent
with our treatment of other CAs to deny this request. I would appreciate
everyone's opinion on that, and also if you think that the amount of
misissuance is reason enough to deny this request, even if the misissuance
is remediated.
=============================
by linters that have not been revoked - I have included my comments and
links from the original message below.
It appears that DigiCert is not planning to remediate these certificates -
can a representative from DigiCert confirm that?
If these certificates are not revoked, I feel that it would be consistent
with our treatment of other CAs to deny this request. I would appreciate
everyone's opinion on that, and also if you think that the amount of
misissuance is reason enough to deny this request, even if the misissuance
is remediated.
=============================
* 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.
[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.
[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
=============================
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
Jeremy Rowley
Dec 13, 2018, 9:23:22 PM12/13/18
to Wayne Thayer, Ryan Sleevi, mozilla-dev-security-policy
* The TERENA SSL CA 3 subordinate has misissued a number of certificates [3], most of which are not revoked.
- We can revoke these. I have no issue remediating them. I didn’t realize these were an ongoing concern.
* 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].
- That’s fine, but the answer still stands as why we didn’t revoke them before. Gerv told us we didn’t need to revoke them because they didn’t represent an actual security concern. I can go find the email if that helps.
* 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].
Here’s the breakdown:
FATAL: x509: RSA modulus is not a positive number
Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 2^256-1. The team implementing this thought saw SHOULD and thought it was optional. They missed the sentence before which says the public exponent MUST be equal to 3 or more. I’ll file and incident report on this.
FATAL: asn1: structure error: integer not minimally-encoded
I think this one is a false positive? It’s caused by padded zeros which aren’t expressly prohibited. Want us to revoke these?
ERROR: The common name field in subscriber certificates must include only names from the SAN extension
This one is a false positive
ERROR: DNSNames must have a valid TLD
This is a false positive
ERROR: The 'Organization Name' field of the subject MUST be less than 64 characters
This is one of the issues mentioned above. We can revoke all of these. We didn’t know Mozilla was waiting on that.
ERROR: CAs MUST NOT issue subscriber certificates with validity periods longer than 39 months regardless of circumstance.
False positive
ERROR: The country name field MUST contain the two-letter ISO code for the country or XX
Grr.. I dislike this one (XK was used instead of XX). Although recognized as a temporary code for Kosovo, technically XK is not an official ISO code so it violates the strict letter of the law. We’ll revoke these.
ERROR: Subject name fields must not contain '.','-',' ' or any other indication that the field has been omitted
False positive. The BRs say “All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.” With the strict wording policy that seems in effect, organizationalUnit is not “All other optional attributes”. It’s a defined attribute and thus cannot be “other”.
ERROR: Explicit text has a maximum size of 200 characters
False positive I think….
ERROR: Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST have a Validity Period no greater than 39 months.
False positive
ERROR: Subscriber Certificate: subject:localityName MUST appear if subject:organizationName, subject:givenName, or subject:surname fields are present but the subject:stateOrProvinceName field is absent.
Wow. I hadn’t seen this. It’ll be revoked and we’ll look at what happened.
* 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.
Thanks Wayne. I can confirm we will revoke all mis-issued certs.
From: Wayne Thayer <wth...@mozilla.com>
Sent: Thursday, December 13, 2018 5:34 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert Assured ID Root CA and Global Root CA EV Request
My main concern with this request is the misissued certificates identified by linters that have not been revoked - I have included my comments and links from the original message below.
It appears that DigiCert is not planning to remediate these certificates - can a representative from DigiCert confirm that?
If these certificates are not revoked, I feel that it would be consistent with our treatment of other CAs to deny this request. I would appreciate everyone's opinion on that, and also if you think that the amount of misissuance is reason enough to deny this request, even if the misissuance is remediated.
=============================
[3] https://crt.sh/?caid=1687 <https://crt.sh/?caid=1687&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01> &opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
It appears that DigiCert is not planning to remediate these certificates - can a representative from DigiCert confirm that?
If these certificates are not revoked, I feel that it would be consistent with our treatment of other CAs to deny this request. I would appreciate everyone's opinion on that, and also if you think that the amount of misissuance is reason enough to deny this request, even if the misissuance is remediated.
=============================
[4] https://crt.sh/?id=629259396 <https://crt.sh/?id=629259396&opt=cablint> &opt=cablint
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1397958
[6]https://crt.sh/?caid=1191 <https://crt.sh/?caid=1191&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01> &opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[7] https://crt.sh/?id=286404787 <https://crt.sh/?id=286404787&opt=zlint> &opt=zlint
=============================
Rob Stradling
Dec 15, 2018, 5:19:19 AM12/15/18
to Jeremy Rowley, Wayne Thayer, Ryan Sleevi, mozilla-dev-security-policy
Hi Jeremy. Comments inline...
On 14/12/2018 02:23, Jeremy Rowley via dev-security-policy wrote:
<snip>
requirements for the public exponent, but this lint issue refers to the
RSA modulus.
The modulus (n) is the product of two prime numbers (p and q). AIUI,
it's not possible for a prime number to be negative, so n=p*q will
always be positive.
> FATAL: asn1: structure error: integer not minimally-encoded
>
> I think this one is a false positive? It’s caused by padded zeros which aren’t expressly prohibited. Want us to revoke these?
No, this isn't a false positive. The ASN.1 Distinguished Encoding Rules
(DER) expressly prohibit this.
Quoting from X.690 12/97:
"8.3 Encoding of an integer value
...
8.3.2 If the contents octets of an integer value encoding consist of
more than one octet, then the bits of the first octet and bit 8 of the
second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE – These rules ensure that an integer value is always encoded in the
smallest possible number of octets."
The public exponent (65537) in https://crt.sh/?asn1=628933973 is encoded
as 02 04 00 01 00 01 (02=INTEGER, 04=length in bytes), whereas the only
valid encoding is 02 03 01 00 01.
> ERROR: The common name field in subscriber certificates must include only names from the SAN extension
>
> This one is a false positive
Yes, I think so. This must've been due to cached linting results,
generated by an old linter version.
It's impractical to re-lint every cert known to crt.sh every time a
linter is updated. But to facilitate this particular discussion, I've
relinted all of the certs issued by https://crt.sh/?caid=1191 for which
lint issues had previously been identified.
> ERROR: DNSNames must have a valid TLD
>
> This is a false positive
Yes, except for https://crt.sh/?id=845405886&opt=zlint, which has been
discussed previously:
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg10727.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1500621
<snip>
It could be argued that this cert's validity period is 39 months + 12 hours:
https://crt.sh/?id=282328562&opt=zlint,x509lint,cablint
Thankfully the BRs now define maximum validity periods in terms of days
rather than months.
<snip>
other optional attributes".
However, the second sentence begins "Optional attributes...". The
"other" qualifier is not there, and since Subject:organizationalUnitName
is an optional attribute, it is in scope for the "MUST NOT contain
metadata" requirement.
> ERROR: Explicit text has a maximum size of 200 characters
>
> False positive I think….
Yes, this appears to be a bug in ZLint.
The User Notice string in https://crt.sh/?id=289322499&opt=zlint is 169
characters long. It's a BMPString, so each character is encoded in 2
octets. Presumably ZLint is counting the number of bytes instead of the
number of characters.
Note the x509lint warning "explicitText is not using a UTF8String"
though, which stems from RFC5280 forbidding the use of BMPString in this
context:
"Conforming CAs SHOULD use the
UTF8String encoding for explicitText, but MAY use IA5String.
Conforming CAs MUST NOT encode explicitText as VisibleString or
BMPString."
RFC6818 un-forbids it, but AFAICT the BRs don't recognize RFC6818.
<snip>
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
On 14/12/2018 02:23, Jeremy Rowley via dev-security-policy wrote:
<snip>
> Here’s the breakdown:
>
> FATAL: x509: RSA modulus is not a positive number
>
> Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 2^256-1. The team implementing this thought saw SHOULD and thought it was optional. They missed the sentence before which says the public exponent MUST be equal to 3 or more. I’ll file and incident report on this.
No, you've misunderstood the error message. You're talking about the
>
> FATAL: x509: RSA modulus is not a positive number
>
> Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 2^256-1. The team implementing this thought saw SHOULD and thought it was optional. They missed the sentence before which says the public exponent MUST be equal to 3 or more. I’ll file and incident report on this.
requirements for the public exponent, but this lint issue refers to the
RSA modulus.
The modulus (n) is the product of two prime numbers (p and q). AIUI,
it's not possible for a prime number to be negative, so n=p*q will
always be positive.
> FATAL: asn1: structure error: integer not minimally-encoded
>
> I think this one is a false positive? It’s caused by padded zeros which aren’t expressly prohibited. Want us to revoke these?
(DER) expressly prohibit this.
Quoting from X.690 12/97:
"8.3 Encoding of an integer value
...
8.3.2 If the contents octets of an integer value encoding consist of
more than one octet, then the bits of the first octet and bit 8 of the
second octet:
a) shall not all be ones; and
b) shall not all be zero.
NOTE – These rules ensure that an integer value is always encoded in the
smallest possible number of octets."
The public exponent (65537) in https://crt.sh/?asn1=628933973 is encoded
as 02 04 00 01 00 01 (02=INTEGER, 04=length in bytes), whereas the only
valid encoding is 02 03 01 00 01.
> ERROR: The common name field in subscriber certificates must include only names from the SAN extension
>
> This one is a false positive
generated by an old linter version.
It's impractical to re-lint every cert known to crt.sh every time a
linter is updated. But to facilitate this particular discussion, I've
relinted all of the certs issued by https://crt.sh/?caid=1191 for which
lint issues had previously been identified.
> ERROR: DNSNames must have a valid TLD
>
> This is a false positive
discussed previously:
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg10727.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1500621
<snip>
> ERROR: CAs MUST NOT issue subscriber certificates with validity periods longer than 39 months regardless of circumstance.
>
> False positive
How long is a month?
>
> False positive
It could be argued that this cert's validity period is 39 months + 12 hours:
https://crt.sh/?id=282328562&opt=zlint,x509lint,cablint
Thankfully the BRs now define maximum validity periods in terms of days
rather than months.
<snip>
> ERROR: Subject name fields must not contain '.','-',' ' or any other indication that the field has been omitted
>
> False positive. The BRs say “All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.” With the strict wording policy that seems in effect, organizationalUnit is not “All other optional attributes”. It’s a defined attribute and thus cannot be “other”.
You're right that Subject:organizationalUnitName doesn't fall under "All
>
> False positive. The BRs say “All other optional attributes, when present within the subject field, MUST contain information that has been verified by the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable.” With the strict wording policy that seems in effect, organizationalUnit is not “All other optional attributes”. It’s a defined attribute and thus cannot be “other”.
other optional attributes".
However, the second sentence begins "Optional attributes...". The
"other" qualifier is not there, and since Subject:organizationalUnitName
is an optional attribute, it is in scope for the "MUST NOT contain
metadata" requirement.
> ERROR: Explicit text has a maximum size of 200 characters
>
> False positive I think….
The User Notice string in https://crt.sh/?id=289322499&opt=zlint is 169
characters long. It's a BMPString, so each character is encoded in 2
octets. Presumably ZLint is counting the number of bytes instead of the
number of characters.
Note the x509lint warning "explicitText is not using a UTF8String"
though, which stems from RFC5280 forbidding the use of BMPString in this
context:
"Conforming CAs SHOULD use the
UTF8String encoding for explicitText, but MAY use IA5String.
Conforming CAs MUST NOT encode explicitText as VisibleString or
BMPString."
RFC6818 un-forbids it, but AFAICT the BRs don't recognize RFC6818.
<snip>
--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
Peter Gutmann
Dec 15, 2018, 8:19:26 PM12/15/18
to Jeremy Rowley, Rob Stradling, Ryan Sleevi, mozilla-dev-security-policy, Wayne Thayer
Rob Stradling via dev-security-policy <dev-secur...@lists.mozilla.org> writes:
>The public exponent (65537) in https://crt.sh/?asn1=628933973 is encoded as
>02 04 00 01 00 01 (02=INTEGER, 04=length in bytes), whereas the only valid
>encoding is 02 03 01 00 01.
Yep, this is what dumpasn1 says about it:
557 4: INTEGER 65537
: Error: Integer '00 01 ...' has non-DER encoding.
Peter.
0 new messages