Re: DigiCert Assured ID Root CA and Global Root CA EV Request
Rob Stradling via dev-security-policy 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: 5574: INTEGER 65537 : Error: Integer '00 01 ...' has non-DER encoding. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert Assured ID Root CA and Global Root CA EV Request
Hi Jeremy. Comments inline... On 14/12/2018 02:23, Jeremy Rowley via dev-security-policy wrote: > 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 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=zlint, which has been discussed previously: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg10727.html https://bugzilla.mozilla.org/show_bug.cgi?id=1500621 > ERROR: CAs MUST NOT issue subscriber certificates with validity periods > longer than 39 months regardless of circumstance. > > False positive How long is a month? It could be argued that this cert's validity period is 39 months + 12 hours: https://crt.sh/?id=282328562=zlint,x509lint,cablint Thankfully the BRs now define maximum validity periods in terms of days rather than months. > 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 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=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. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert Assured ID Root CA and Global Root CA EV Request
: 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=cablint,zlint,x509lint=2017-01-01> =cablint,zlint,x509lint=2017-01-01 [4] https://crt.sh/?id=629259396 <https://crt.sh/?id=629259396=cablint> =cablint [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1397958 [6]https://crt.sh/?caid=1191 <https://crt.sh/?caid=1191=cablint,zlint,x509lint=2017-01-01> =cablint,zlint,x509lint=2017-01-01 [7] https://crt.sh/?id=286404787 <https://crt.sh/?id=286404787=zlint> =zlint = On Thu, Nov 29, 2018 at 4:17 PM Wayne Thayer mailto:wtha...@mozilla.com> > wrote: 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 smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
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. = * 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] https://crt.sh/?caid=1687=cablint,zlint,x509lint=2017-01-01 > [4] https://crt.sh/?id=629259396=cablint > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=1397958 [6] https://crt.sh/?caid=1191=cablint,zlint,x509lint=2017-01-01 [7] https://crt.sh/?id=286404787=zlint = On Thu, Nov 29, 2018 at 4:17 PM Wayne Thayer wrote: > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert Assured ID Root CA and Global Root CA EV Request
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert Assured ID Root CA and Global Root CA EV Request
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 wrote: > 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 > On Behalf Of Ryan Sleevi via dev-security-policy > Sent: Thursday, November 29, 2018 12:19 PM > To: Wayne Thayer > Cc: mozilla-dev-security-policy < > mozilla-dev-security-pol...@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-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 > wrote: > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: DigiCert Assured ID Root CA and Global Root CA EV Request
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 On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, November 29, 2018 12:19 PM To: Wayne Thayer Cc: mozilla-dev-security-policy 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-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 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=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 > > gvhgZ8YgRI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60 > > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ > > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn > > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou > > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY > > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53 > > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe > > JAcE67idnv=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 > > Arsg3rBYtU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60 > > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ > > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn > > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou > > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY > > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53 > > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe > > JAcE67idnv=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen > > t.cgi%3Fid%3D8987141 >
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-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 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
Re: DigiCert Assured ID Root CA and Global Root CA EV Request
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 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
