Re: New Blog Post on 398-Day Certificate Lifetimes
On Fri, Jul 10, 2020 at 10:48:39AM -0600, Ben Wilson via dev-security-policy wrote: > Some people have asked whether two-year certificates existing on August 31 > would remain valid. The answer is yes. Those certificates will remain > valid until they expire. The change only applies to certificates issued on > or after Sept. 1, 2020. A histogram of the number of certificates grouped by their notBefore date is going to show a heck of a bump on August 31, I'll wager. Will be interesting to correlate notBefore with SCTs. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
EV-enablement Request of Identrust
This is a request to EV-enable the IdenTrust Commercial Root CA 1, as documented here: https://bugzilla.mozilla.org/show_bug.cgi?id=1551703 * Summary of Information Gathered and Verified: https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0417 * SHA2 hash for Root CA Certificate: 5D56499BE4D2E08BCFCAD08A3E38723D50503BDE706948E42F55603019E528AE * Root Certificate Download URL: http://validation.identrust.com/roots/commercialrootca1.p7c * Identrust’s BR Self Assessment is located here: https://bugzilla.mozilla.org/attachment.cgi?id=9153636 (Excel Spreadsheet Download) * CPS: https://www.identrust.com/sites/default/files/resources/identrust_trustid_cps_v4.7.3_06.15.2020.pdf * Test Website: https://ev-valid.identrustssl.com/ * EV Policy OIDs: 2.16.840.1.113839.0.6.9, 2.23.140.1.1 * CRL URL: http://validation.identrust.com/crl/commercialrootca1.crl * OCSP URL: http://commercial.ocsp.identrust.com * Audit: A period of time WebTrust EV annual audit report was provided on August 16, 2019, by Schellman & Company, LLC, a licensed WebTrust auditor. That and other WebTrust audit reports are available from the bottom of the following applicant page: https://www.identrust.com/support/documents/trustid. I’ve reviewed the CPS, BR Self Assessment, and related information for this inclusion request. Comments and concerns regarding the CPS were satisfactorily addressed as noted in https://bugzilla.mozilla.org/show_bug.cgi?id=1551703. I now recommend that the IdenTrust Commercial Root CA 1 be enabled for Extended Validation treatment. This begins the 3-week comment period for this request. I will greatly appreciate your thoughtful and constructive feedback on Identrust’s request. Sincerely yours, Ben Wilson ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New Blog Post on 398-Day Certificate Lifetimes
Yes, that's right. On Fri, Jul 10, 2020 at 12:11 PM Doug Beattie wrote: > Ben, > > For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC. > > > -Original Message- > From: dev-security-policy > On > Behalf Of Ben Wilson via dev-security-policy > Sent: Friday, July 10, 2020 12:49 PM > To: mozilla-dev-security-policy > > Subject: Re: New Blog Post on 398-Day Certificate Lifetimes > > Some people have asked whether two-year certificates existing on August 31 > would remain valid. The answer is yes. Those certificates will remain > valid > until they expire. The change only applies to certificates issued on or > after Sept. 1, 2020. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New Blog Post on 398-Day Certificate Lifetimes
Ben, For the avoidance of doubt, I assume this means Sept 1, 00:00 UTC. -Original Message- From: dev-security-policy On Behalf Of Ben Wilson via dev-security-policy Sent: Friday, July 10, 2020 12:49 PM To: mozilla-dev-security-policy Subject: Re: New Blog Post on 398-Day Certificate Lifetimes Some people have asked whether two-year certificates existing on August 31 would remain valid. The answer is yes. Those certificates will remain valid until they expire. The change only applies to certificates issued on or after Sept. 1, 2020. ___ 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: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Fri, Jul 10, 2020 at 12:01 PM ccampetto--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wouldn't be enough to check that OCSP responses are signed with a > certificate which presents the (mandatory, by BR) id-pkix-ocsp-nocheck? > I've not checked, but I don't think that subordinate CA certificates have > that extension You're describing a behaviour change to all clients, in order to work around the CA not following the profile. This is a common response to many misissuance events: if the client software does not enforce that CAs actually do what they say, then it's not really a rule. Or, alternatively, that the only rules should be what clients enforce. We see this come up from time to time, e.g. certificate lifetimes, but this is a way of externalizing the costs/risks onto clients. None of this changes what clients, in the field, today do. And if the problem was caused by a CA, isn't it reasonable to expect the problem to be fixed by the CA? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
Mr. zxzxzx9, The "real" risk, which is illustrated through an adversary, vulnerability, impact probability, risk mitigation strategy and the residual risk doesn't matter. Hence is not discussed. I've yet to see a comprehensive risk assessment on this matter. The primary reason there is no real discussion is all the CAs have chickened out due to the "distrust" flag from Mr. Sleevi. This is supposed to be a community to freely discuss but he essentially mentioned arguing = distrust. "Distrust" is equivalent to a death sentence to a CA. So...can't really blame em chickening out. As an individual observing this whole situation, I'm wondering too. You are not alone. Best regards, T.K. On 7/10/2020 7:35 PM, zxzxzx9--- via dev-security-policy wrote: On Wednesday, July 8, 2020 at 6:02:56 AM UTC+3, Ryan Sleevi wrote: The question is simply whether or not user agents will accept the risk of needing to remove the root suddenly, and with significant (e.g. active) attack, or whether they would, as I suggest, take steps to remove the root beforehand, to mitigate the risk. The cost of issuance plus the cost of revocation are a fixed cost: it's either pay now or pay later. And it seems like if one needs to contemplate revoking roots, it's better to do it sooner, than wait for it to be an inconvenient or inopportune time. This is why I meant earlier, when I said a solution that tries to wait until the 'last possible minute' is just shifting the cost of misissuance onto RPs/Browsers, by leaving them to clean up the mess. And a CA that tries to shift costs onto the ecosystem like that seems like it's not a CA that can be trusted to, well, be trustworthy. This assumes that the private key of these intermediate CAs will inevitably get compromised. Why such an assumption? Following the same argument we can assume that the private key of any root CA will inevitably get compromised and suggest all CAs to revoke their roots already today. Does not seem to make sense. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New Blog Post on 398-Day Certificate Lifetimes
Some people have asked whether two-year certificates existing on August 31 would remain valid. The answer is yes. Those certificates will remain valid until they expire. The change only applies to certificates issued on or after Sept. 1, 2020. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Wednesday, July 8, 2020 at 6:02:56 AM UTC+3, Ryan Sleevi wrote: > The question is simply whether or not user agents will accept the risk of > needing to remove the root suddenly, and with significant (e.g. active) > attack, or whether they would, as I suggest, take steps to remove the root > beforehand, to mitigate the risk. The cost of issuance plus the cost of > revocation are a fixed cost: it's either pay now or pay later. And it seems > like if one needs to contemplate revoking roots, it's better to do it > sooner, than wait for it to be an inconvenient or inopportune time. This is > why I meant earlier, when I said a solution that tries to wait until the > 'last possible minute' is just shifting the cost of misissuance onto > RPs/Browsers, by leaving them to clean up the mess. And a CA that tries to > shift costs onto the ecosystem like that seems like it's not a CA that can > be trusted to, well, be trustworthy. This assumes that the private key of these intermediate CAs will inevitably get compromised. Why such an assumption? Following the same argument we can assume that the private key of any root CA will inevitably get compromised and suggest all CAs to revoke their roots already today. Does not seem to make sense. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: SECURITY RELEVANT FOR CAs: The curious case of the Dangerous Delegated Responder Cert
On Wednesday, 8 July 2020 05:02:56 UTC+2, Ryan Sleevi wrote: > On Tue, Jul 7, 2020 at 10:36 PM Matt Palmer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Mon, Jul 06, 2020 at 10:53:50AM -0700, zxzxzx9--- via > > dev-security-policy wrote: > > > Can't the affected CAs decide on their own whether to destroy the > > > intermediate CA private key now, or in case the affected intermediate CA > > > private key is later compromised, revoke the root CA instead? > > > > No, because there's no reason to believe that a CA would follow through on > > their decision, and rapid removal of trust anchors (which is what "revoke > > the root CA" means in practice) has all sorts of unpleasant consequences > > anyway. > > > > Er, not quite? > > I mean, yes, removing the root is absolutely the final answer, even if > waiting until something "demonstrably" bad happens. > > The question is simply whether or not user agents will accept the risk of > needing to remove the root suddenly, and with significant (e.g. active) > attack, or whether they would, as I suggest, take steps to remove the root > beforehand, to mitigate the risk. The cost of issuance plus the cost of > revocation are a fixed cost: it's either pay now or pay later. And it seems > like if one needs to contemplate revoking roots, it's better to do it > sooner, than wait for it to be an inconvenient or inopportune time. This is > why I meant earlier, when I said a solution that tries to wait until the > 'last possible minute' is just shifting the cost of misissuance onto > RPs/Browsers, by leaving them to clean up the mess. And a CA that tries to > shift costs onto the ecosystem like that seems like it's not a CA that can > be trusted to, well, be trustworthy. Wouldn't be enough to check that OCSP responses are signed with a certificate which presents the (mandatory, by BR) id-pkix-ocsp-nocheck? I've not checked, but I don't think that subordinate CA certificates have that extension ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
