Re: Entrust Root Certification Authority - G4 Inclusion Request
Having received no further comments, I have recommended approval of this request in bug 1480510. - Wayne On Tue, Oct 8, 2019 at 4:23 PM Wayne Thayer wrote: > On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote: >> >> > We will update section 4.2 and 9.12.3 in the next release of the CPS. >> >> The CPS Has been updated to address the above issues, see >> https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf >> . >> >> I've verified these updates. > > This request has been in discussion for quite a while now. Please post any > further comments by next Tuesday 15-October, and I will plan to end the > discussion period at that time. > > - Wayne > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
On Mon, Oct 7, 2019 at 9:09 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote: > > > We will update section 4.2 and 9.12.3 in the next release of the CPS. > > The CPS Has been updated to address the above issues, see > https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf > . > > I've verified these updates. This request has been in discussion for quite a while now. Please post any further comments by next Tuesday 15-October, and I will plan to end the discussion period at that time. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
On Monday, July 29, 2019 at 5:22:19 PM UTC-4, Bruce wrote: > We will update section 4.2 and 9.12.3 in the next release of the CPS. The CPS Has been updated to address the above issues, see https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190930-version-36.pdf. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote: > ==Bad== > * The most recent BR audit report lists two additional qualifications > related to the Network Security requirements: > ** During the Period, there were instances of some Certificate Systems not > undergoing a Vulnerability Scan at least every three (3) months. > ** During the Period, there were instances where a technical control to > restrict remote access to only those devices owned or controlled by Entrust > did not operate effectively. Deloitte has issued a Specified Procedures Report to address the above qualified items. The report has been added to https://bugzilla.mozilla.org/show_bug.cgi?id=1480510. Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
On Fri, Aug 2, 2019 at 9:59 AM Doug Beattie wrote: > Ryan, > > GlobalSign has been thinking along these lines, but it's not clear how > browsers build their path when a cross certificate is presented to them in > the TLS handshake. > Excellent! Happy to help in any way to make that possible and easier :) > Can you explain how chrome (windows and Android) builds a path when a > cross > certificate is delivered? What about the case when the OS (Microsoft > specifically) has cached the cross certificate, is it different? > It's unclear the objective of the question. That is, are you trying to figure out what happens with both paths are valid, or how it handles edge cases, etc? At present (and this is changing), Chrome uses the CryptoAPI implementation, which is the same as IE, Edge, and other Windows applications. You can read a little bit about Microsoft's logic here: - https://blogs.technet.microsoft.com/pki/2010/05/12/certificate-path-validation-in-bridge-ca-and-cross-certification-environments/ And a little about how the IIS server selects which intermediates to include in the TLS handshake here: - https://support.microsoft.com/en-us/help/2831004/certificate-validation-fails-when-a-certificate-has-multiple-trusted-c The "short answer" is that, assuming both are trusted, either path is valid, and the preference for which path is going to be dictated by the path score, how you can influence that path score, and how ties are broken between similarly-scoring certificates. Android's selection logic is somewhat simpler, but it supports exploring multiple variations of an intermediate in the attempt to explore a possible path. With this approach, we'd require our customers to configure their web > servers to always send down the extra certificate which: > * complicates web server administration, > I'm not sure I understand this; that is, what's different from the existing need to configure the issuing intermediate? I can understand challenges faced with, say, IIS (which attempts to automatically send the chain), but that's only an issue based on how the CA constructs the scoring, and even that can be overridden. > * increases TLS handshake packet sizes (or extra packet?), and > * increases the certificate path from 3 to 4 certificates (SSL, issuing > CA, Cross certificate, Root), which increases the path validation time and > is typically seen as a competitive disadvantage > I'm surprised and encouraged to hear CAs think about client performance. That certainly doesn't align with how their customers are actually deploying things, based on what I've seen from the httparchive.org data (suboptimal chains requiring AIA, junk stapled OCSP responses, CAs putting entire chains in OCSP responses). As a practical matter, there are understandably tradeoffs. Yet you can allow your customers the control to optimize for their use case and make the decision best for them, which helps localize some of those tradeoffs. For example, when you (the CA) is first rolling out such a new root, you're right that your customers will likely want to include the cross-signed version back to the existing root within root stores. Yet as root stores update (which, in the case of browsers, can be quite fast), your customer could chose to begin omitting that intermediate, and rely on intermediate preloading (Firefox) or AIA (everyone else). In this model, the AIA for your 'issuing intermediate' would point to a URL that contained your cross-signed intermediate, which would then allow them to build the path to the legacy root. Clients with your new root would build and prefer the shorter path, because they'd have a trust anchor matching that (root, key) combination, while legacy clients could still build the legacy path. > Do you view these as meaningful issues? Do you know of any CAs that have > taken this approach? Definitely! I don't want to sound dismissive of these issues, but I do want to suggest it's good if we as an industry start tackling these a bit head-on. I'm particularly keen to understand more about how and when we can 'sunset' roots. For example, if the desire is to introduce a new root in order to transition to stronger cryptography, I'd like to understand more about how and when clients get the 'strong' chain or the 'weaker' chain and how that selection may change over time. I'm understanding to 4K roots - while I'd rather we were in a world where 2K roots were viable because we were rotating roots more frequently (hence the above), 4K roots may make sense given the pragmatic realities that these end up being used much longer than anticipated. If that's the case, though, it's reasonable to think we'd retire roots <4K, and it's reasonable to think we don't need multiple 4K roots. That's why I wanted to flesh out these considerations and have that discussion, because I'm not sure that just allowing folks to select '2K vs 4K' for a particular CA really helps move the needle far enough in user
RE: Entrust Root Certification Authority - G4 Inclusion Request
Ryan, GlobalSign has been thinking along these lines, but it's not clear how browsers build their path when a cross certificate is presented to them in the TLS handshake. Can you explain how chrome (windows and Android) builds a path when a cross certificate is delivered? What about the case when the OS (Microsoft specifically) has cached the cross certificate, is it different? With this approach, we'd require our customers to configure their web servers to always send down the extra certificate which: * complicates web server administration, * increases TLS handshake packet sizes (or extra packet?), and * increases the certificate path from 3 to 4 certificates (SSL, issuing CA, Cross certificate, Root), which increases the path validation time and is typically seen as a competitive disadvantage Do you view these as meaningful issues? Do you know of any CAs that have taken this approach? -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, August 1, 2019 2:51 PM To: Bruce Cc: mozilla-dev-security-policy Subject: Re: Entrust Root Certification Authority - G4 Inclusion Request On Fri, Jul 26, 2019 at 4:29 PM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote: > > (In a personal capacity, as normally noted but making sure to > > extra-note > it > > here) > > > > Hi Wayne, > > > > It wasn't clear to me from the inclusion request, did Entrust give a > reason > > for the requested addition? For example, do they plan to stop > > issuing > from > > one of the included roots and have it removed? > > The purpose of the inclusion request is to add a 4096-bit RSA root > which will be used to support larger keys as we move ahead. We are not > looking at this root to replace our current roots, but plan to migrate > to the new root as the demand for larger keys grows. We are not > planning remove any of our roots at this time. > It seems like it should be technically possible to use this root to replace an existing root, which seems like it would align well with the goal of ensuring larger key support going forward. For example, if "tomorrow" (hypothetically; I know it takes time) you: 1) Cross-signed the 4K root with an existing root 2) Issued a new issuing intermediate under the 4K root 3) Issued all new certificates going forward from that new issuing intermediate Then it would seem like there's a path to ensure that all clients which support your existing, legacy roots, would automatically support your 4K root, building a path to your legacy root. Clients which installed/shipped the 4K root would build shorter paths, and without the intermediate signature from the legacy root to the 4K root. Once all of your existing "Legacy" certificates expire (that is, those issued from your old legacy issuing intermediate) - which, admittedly, would likely be 825 days from "tomorrow" - clients could remove support for the "Legacy" certificate without breaking any existing certificates. Did you consider such a transition plan? That would allow clients to minimize the number of roots a given organization has, which helps reduce the security risk and maintenance overhead to clients, while still allowing a smooth and seamless transition. It seems like a win for everyone, and would be great to know more about those considerations if deciding to accept this new root. >From the current description, it sounds like this new root may not provide clear user benefit, since it's not clear that it's functionally differentiated from the existing root, which seems to be wholly sufficient for the cryptographic needs of Firefox users. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy 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: Entrust Root Certification Authority - G4 Inclusion Request
On Fri, Jul 26, 2019 at 4:29 PM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote: > > (In a personal capacity, as normally noted but making sure to extra-note > it > > here) > > > > Hi Wayne, > > > > It wasn't clear to me from the inclusion request, did Entrust give a > reason > > for the requested addition? For example, do they plan to stop issuing > from > > one of the included roots and have it removed? > > The purpose of the inclusion request is to add a 4096-bit RSA root which > will be used to support larger keys as we move ahead. We are not looking at > this root to replace our current roots, but plan to migrate to the new root > as the demand for larger keys grows. We are not planning remove any of our > roots at this time. > It seems like it should be technically possible to use this root to replace an existing root, which seems like it would align well with the goal of ensuring larger key support going forward. For example, if "tomorrow" (hypothetically; I know it takes time) you: 1) Cross-signed the 4K root with an existing root 2) Issued a new issuing intermediate under the 4K root 3) Issued all new certificates going forward from that new issuing intermediate Then it would seem like there's a path to ensure that all clients which support your existing, legacy roots, would automatically support your 4K root, building a path to your legacy root. Clients which installed/shipped the 4K root would build shorter paths, and without the intermediate signature from the legacy root to the 4K root. Once all of your existing "Legacy" certificates expire (that is, those issued from your old legacy issuing intermediate) - which, admittedly, would likely be 825 days from "tomorrow" - clients could remove support for the "Legacy" certificate without breaking any existing certificates. Did you consider such a transition plan? That would allow clients to minimize the number of roots a given organization has, which helps reduce the security risk and maintenance overhead to clients, while still allowing a smooth and seamless transition. It seems like a win for everyone, and would be great to know more about those considerations if deciding to accept this new root. >From the current description, it sounds like this new root may not provide clear user benefit, since it's not clear that it's functionally differentiated from the existing root, which seems to be wholly sufficient for the cryptographic needs of Firefox users. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
On Friday, July 26, 2019 at 1:25:13 PM UTC-4, Wayne Thayer wrote: > ==Meh== > * BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly > specify the set of Issuer Domain Names that the CA recognises in CAA > "issue" or "issuewild" records as permitting it to issue.” The Entrust CPS > instead references section 3.2.2.8 where the Issuer Domain Name is listed. > * CPS section 9.12.3 is blank. Mozilla recommends against this [11]. We will update section 4.2 and 9.12.3 in the next release of the CPS. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
On Friday, July 26, 2019 at 1:45:06 PM UTC-4, Ryan Sleevi wrote: > (In a personal capacity, as normally noted but making sure to extra-note it > here) > > Hi Wayne, > > It wasn't clear to me from the inclusion request, did Entrust give a reason > for the requested addition? For example, do they plan to stop issuing from > one of the included roots and have it removed? The purpose of the inclusion request is to add a 4096-bit RSA root which will be used to support larger keys as we move ahead. We are not looking at this root to replace our current roots, but plan to migrate to the new root as the demand for larger keys grows. We are not planning remove any of our roots at this time. Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Entrust Root Certification Authority - G4 Inclusion Request
(In a personal capacity, as normally noted but making sure to extra-note it here) Hi Wayne, It wasn't clear to me from the inclusion request, did Entrust give a reason for the requested addition? For example, do they plan to stop issuing from one of the included roots and have it removed? In general, my thoughts as it applies to any new root inclusion is to ask about the value provided to the community. I think there is exceptional value in retiring roots that may have existed prior to the Baseline Requirements, or which had a significant number of compliance issues. I think a transition to a 'clean' root helps restore confidence and trust in the organization level, by reducing the risk at the certificate-level. Similarly, additions for algorithm agility may also be beneficial to the community, by helping ensure robust and consistent support. It wasn't clear to me if either of these applied. Put differently, will Entrust be retiring one or more of its existing roots in support of adding this new root? I can think of several ways they might be able to do so seamlessly, as demonstrated by other CAs, so it would seem a useful exercise to consider. With respect to the compliance matters, as captured on the bugs, I am concerned, both about the nature of the issues and the detail provided. Comparatively, other CAs have been much more descriptive in their analysis and evaluations, and that's helped restore faith in the organization after an incident has occurred. For example, I've highlighted on other CAs' incidents quality responses like [1], or highly detailed responses like [2]. I note that many of the incidents you've noted don't really rise to that level of detail, and thus some lingering concerns remain. I'm wondering if whether the present root inclusion request provides an opportunity to improve that situation, without discouraging the reporting of incidents. I'm not sure I have something concrete on how to do that right now, but wanted to highlight it for possible consideration and discussion. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551374 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1556948 On Fri, Jul 26, 2019 at 1:25 PM Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This request is to include the Entrust Root Certification Authority - G4 as > documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1480510 > > * BR Self Assessment is here: > https://bug1480510.bmoattachments.org/attachment.cgi?id=8997108 > > * Summary of Information Gathered and Verified: > https://bug1480510.bmoattachments.org/attachment.cgi?id=9016839 > > * Root Certificate Download URL: > https://bug1480510.bmoattachments.org/attachment.cgi?id=8997105 > > * CP/CPS: > > https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190725-version-35.pdf > > * This request is for Websites and Email trust bits. EV treatment is > requested. > ** EV Policy OID: .16.840.1.114028.10.1.2 > > * Test Websites: > ** Valid: https://validg4.entrust.net/ > ** Expired: https://expiredg4.entrust.net/ > ** Revoked: https://revokedg4.entrust.net/ > > * CRL URL: http://crl.entrust.net/g4ca.crl > > * OCSP URL: http://ocsp.entrust.net/ > > * Audit: Annual audits are performed by Deloitte according to the WebTrust > for CA, BR, and EV audit criteria. > ** WebTrust for CAs and EV: > > https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230012 > ** BR: > > https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf > > I’ve reviewed the CPS, BR Self Assessment, and related information for the > Entrust Root Certification Authority - G4 inclusion request that is being > tracked in this bug and have the following comments: > > ==Good== > * I’m pleased to see the “Other Matters” section of this and last year’s > audit reports. > * This root was signed in 2015, but there is no evidence that it has been > used other than to sign test certificates, and I can find no evidence of > misissued certificates chaining to this root. > > ==Meh== > * Entrust has had some compliance issues recorded during the life of this > root certificate that are now resolved: > ** Metadata in ST and OU fields [1] [2] > ** OCSP responding “good” for unknown certificates. [3] > ** IP address in dNSName form [4] and [5] > ** Late revocation of misissued certificates [6] > ** Question marks in certificate O and L fields [7] > ** Issued certificates to incorrect organization [8] > ** AffirmTrust Issuing CA Impacted by EJBCA Serial Number Issue [9] > ** Late revocation of underscore certificates [10] > * External RAs are permitted, but the CPS I originally reviewed (version > 3.2) did n
Entrust Root Certification Authority - G4 Inclusion Request
This request is to include the Entrust Root Certification Authority - G4 as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1480510 * BR Self Assessment is here: https://bug1480510.bmoattachments.org/attachment.cgi?id=8997108 * Summary of Information Gathered and Verified: https://bug1480510.bmoattachments.org/attachment.cgi?id=9016839 * Root Certificate Download URL: https://bug1480510.bmoattachments.org/attachment.cgi?id=8997105 * CP/CPS: https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ssl-cps-english-20190725-version-35.pdf * This request is for Websites and Email trust bits. EV treatment is requested. ** EV Policy OID: .16.840.1.114028.10.1.2 * Test Websites: ** Valid: https://validg4.entrust.net/ ** Expired: https://expiredg4.entrust.net/ ** Revoked: https://revokedg4.entrust.net/ * CRL URL: http://crl.entrust.net/g4ca.crl * OCSP URL: http://ocsp.entrust.net/ * Audit: Annual audits are performed by Deloitte according to the WebTrust for CA, BR, and EV audit criteria. ** WebTrust for CAs and EV: https://www.cpacanada.ca/generichandlers/aptifyattachmenthandler.ashx?attachmentid=230012 ** BR: https://www.entrustdatacard.com/-/media/documentation/licensingandagreements/ecs/2019-entrust-baseline-requirements-report.pdf I’ve reviewed the CPS, BR Self Assessment, and related information for the Entrust Root Certification Authority - G4 inclusion request that is being tracked in this bug and have the following comments: ==Good== * I’m pleased to see the “Other Matters” section of this and last year’s audit reports. * This root was signed in 2015, but there is no evidence that it has been used other than to sign test certificates, and I can find no evidence of misissued certificates chaining to this root. ==Meh== * Entrust has had some compliance issues recorded during the life of this root certificate that are now resolved: ** Metadata in ST and OU fields [1] [2] ** OCSP responding “good” for unknown certificates. [3] ** IP address in dNSName form [4] and [5] ** Late revocation of misissued certificates [6] ** Question marks in certificate O and L fields [7] ** Issued certificates to incorrect organization [8] ** AffirmTrust Issuing CA Impacted by EJBCA Serial Number Issue [9] ** Late revocation of underscore certificates [10] * External RAs are permitted, but the CPS I originally reviewed (version 3.2) did not make it clear that domain validation will not be delegated as required by BR section 1.3.2. Entrust addressed this in the current version. * BR section 2.2 requires section 4.2 of a CA’s CP and/or CPS to “clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.” The Entrust CPS instead references section 3.2.2.8 where the Issuer Domain Name is listed. * CPS section 9.12.3 is blank. Mozilla recommends against this [11]. ==Bad== * Entrust self-reported a bug in which they had improperly encoded an IP address in a certificate. [4] In March 2018, they indicated in the bug that they would implement pre-issuance linting, but not until early 2019. It was ultimately implemented in May 2019. While pre-issuance linting is not a requirement, it is certainly a best practice and taking over a year to implement it is discouraging. It appears [12] that at least one other misissuance would have been prevented if pre-issuance linting had been implemented sooner. * Entrust’s current and prior [13] BR audit reports contain a qualification for failing to address critical vulnerabilities within 96 hours. Entrust engaged Deloitte to confirm the the problem had been remediated in September 2018. [14] The current period-of-time report confirms that the issue was remediated as of 30-June 2018. * The most recent BR audit report lists two additional qualifications related to the Network Security requirements: ** During the Period, there were instances of some Certificate Systems not undergoing a Vulnerability Scan at least every three (3) months. ** During the Period, there were instances where a technical control to restrict remote access to only those devices owned or controlled by Entrust did not operate effectively. * Entrust has the following open CA compliance bugs (as of 25-June): ** Outdated audit statement for intermediate cert [15] ** Certificate issued with incorrect Country Code [16] ** Certificate issued with validity greater than 825 days [17] ** SHA-1 Issuance and other misissuance while testing [18] * CPS version 3.2 section 9.8.2.2 appeared to limit liability to $1000 USD per Subscriber, but EVGL section 18 sets a minimum of $2000 USD. Entrust addressed this in the current version. This begins the 3-week (minimum) comment period for this request [19]. I will greatly appreciate your thoughtful and constructive feedback on the decision to include this root certificate. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?
