Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 09/05/17 18:25, Doug Beattie wrote: > I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by > 21st July 2017. > > I'm assuming this is the latest official draft: > > https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Yes :-) > Specifically, does this mean all new domain validations must conform to the > 10 methods, > or that all new issuance > must be based on domains validated with only these 10 methods? It means that all new validations must be done using one of the 10 methods. The rules for information reuse will, I hope, be clarified in an upcoming ballot in the CAB Forum. Assuming that ballot doesn't say anything ridiculous, Mozilla will allow reuse according to those rules. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Draft further questions for Symantec
On 08/05/17 13:24, Gervase Markham wrote: > 8) Please explain how the Management Assertions for your December 2014 Strike this question; it's based on a misunderstanding of how audits are done. Let's add: 10) Do you agree that, during the period of time that Symantec cross-signed the Federal PKI (Issue L), it was technically possible for issuers inside the FPKI to issue EV certs by inserting Symantec's EV OID? 11) If, in the Symantec Issues list or any other document relating to this matter we may publish in future, we have drawn a conclusion or inference about Symantec's PKI, actions or behaviour which is incorrect, we expect you to draw that to our attention, even if the truth is not as favourable to Symantec. Are there any incorrect inferences or conclusions in the Issues List which need to be corrected? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On Wed, May 10, 2017 at 2:06 PM, mono.riot--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote: > > The next step, if Symantec wish to continue to use their current PKI in > the future, should be logging (ASAP) *all* of the certificates they issued > to a CT log, then we'll know how deep is the rabbit hole. > > already the case since '15 > > https://security.googleblog.com/2015/10/sustaining- > digital-certificate-security.html The blog post is dated October 15, but the requirement* only came into effect June 1st, 2016 > although I'm not certain if this applied only to certs issued under the > Symantec brand. Any certs issued by any Symantec CA, regardless of brand, unless the CA is operated by a 3rd party under its own, separate, audit. Andrew *required for the cert to be trusted in Chrome. They are still free to issue certs that don't comply with the Chrome CT Policy, but those will cause an interstitial warning in Chrome. ___ > 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: Symantec: Update
On Wednesday, 10 May 2017 17:52:40 UTC+2, Gervase Markham wrote: > On 09/05/17 16:51, Gervase Markham wrote: > > * Editing the proposal to withdraw the "alternative" option, leaving > > only the "new PKI" option. > > This has now been done: > > https://docs.google.com/document/d/1RhDcwbMeqgE2Cb5e6xaPq-lUPmatQZwx3Sn2NPz9jF8/edit# > > > * Engagement here in m.d.s.p. with the community to refine and flesh out > > the "new PKI" proposal, based on the Google outline but examining it and > > enhancing it to make sure it is practical, both from an implementation > > perspective and to reduce disruption to sites as far as possible. > > I would appreciate people's comments on the details of the current draft. Makes sense to me. But it does seem to assume that Symantec will cooperate with this. What happens if they decide not to is less clear. Perhaps it would be a good idea to indicate which steps will be taken in any case? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Find a 5-year certificate
In this context, I was wondering: Has there been a discussion yet on Firefox enforcing cert lifetime in code not just via policy? Most everything seems to be in place already due to EV, but DV doesn't have a limit atm. [0] Now in practice, thanks to killing sha1, most of those legacy certs are probably distrusted anyway. But then again, backdating is technically possible, until full CT can provide protection in ~4 years iiuc, and it's a pretty stealthy way for CAs to subvert current guidelines (unless you do it WoSign-style I guess...) Limiting to 60 months could be done right now as a sanity check and shouldn't cause any problems, right? [0] https://github.com/mozilla/gecko-dev/blob/455ab646d315d265b4c0c3f712a69aae40985fcf/security/certverifier/NSSCertDBTrustDomain.cpp#L1112 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On Wednesday, May 10, 2017 at 7:59:37 PM UTC+2, Itzhak Daniel wrote: > The next step, if Symantec wish to continue to use their current PKI in the > future, should be logging (ASAP) *all* of the certificates they issued to a > CT log, then we'll know how deep is the rabbit hole. already the case since '15 https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html although I'm not certain if this applied only to certs issued under the Symantec brand. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Symantec: Update
On Tue, May 09, 2017 at 07:03:16PM +0200, Kurt Roeckx via dev-security-policy wrote: > > Instead of the removal of the roots, I suggest we either ask them > to revoke all the intermediate CAs that do not have the required > audits or that Mozilla adds them to OneCRL. Just to clarify, I believe that under 4.9.1.2 of the BRs, either point 5, 8 or 9, Symantec is required to revoke those certificates within 7 days. There is no indication that they follow the BR requirements, the audit report even says that Symantec does not control them, just monitor them. They are a clear danger. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
