Re: Mozilla Policy Requirements CA Incidents
In the spirit of improving transparency, I've gone and filed https://github.com/mozilla/pkipolicy/issues/192 , which is specific to auditors. However, I want to highlight this model (the model used by the US Federal PKI), because it may also provide a roadmap for dealing with issues like this / those called by policy changes. Appendix C of those annual requirements for the US Federal PKI includes a number of useful requirements (really, all of them are in line with things we've discussed here), but two particularly relevant requirements are: *Guidance*: Previous year findings Did the auditor review findings from previous year and ensure all findings were corrected as proposed during the previous audit? *Commentary*: Often, the auditor sees an Audit Correction Action Plan, POA, or other evidence that the organization has recognized audit findings and intends to correct them, but the auditor is not necessarily engaged to assess the corrections at the time they are applied. The auditor should review that all proposed corrections have addressed the previous year’s findings. *Guidance*: Changes Because the FPKI relies on a mapped CP and/or CPS for comparable operations, has the auditor been apprised of changes both to documentation and operations from the previous audit? *Commentary*: CPs change over time and each Participating PKI in the FPKI has an obligation to remain in synch with the changing requirements of the applicable FPKI CP (either FBCA or COMMON Policy) – has the participating PKI’s CP and CPS been updated appropriately? If there have been other major changes in operations, has a summary since the last year’s audit been provided or discussed with the auditor? This might be a model to further include/require within the overall audit package. This would likely only make sense if also adding "Audit Operational Findings" (which Illustrative Guidance for WebTrust now includes guidance on, but which ETSI continues to refuse to add) and "Audit MOA Findings" (for which "MOA" may be instead seen as "Mozilla Root Certificate Policy" - i.e. the things above/beyond the BRs). We've already seen WebTrust similarly developing reporting for "Architectural Overview", and they've already updated reporting for "Assertion of Audit Scope", thus showing in many ways, WebTrust already has the tools available to meet these requirements. It would similarly be possible for ETSI-based audits to meet these requirements, since the reports provided to browsers need not be as limited as a Certification statement; they could include more holistic reporting, in line with the eIDAS Conformity Assessment Reports. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Request received : Re: Intent to Ship: Move Extended Validation Information out of the URL bar ref:_00DU0Lfqj._5001v17KQlt:ref
We have received your request 03531375 and it is being processed by our support team. To leave additional comments, reply to this email. ref:_00DU0Lfqj._5001v17KQlt:ref ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
The finding is from public information that is relevant to the current value of EV certificates, which is a central part of this discussion. -R On 10/14/2019 11:10 AM, Paul Walsh via dev-security-policy wrote: I have two questions Ronald: 1. What should I look for? I just see a DV cert from Let’s Encrypt. 2. Why did you message the entire community about whatever it is you’ve found? Thanks, Paul Sent from my iPhone On Oct 12, 2019, at 11:04 AM, Ronald Crane via dev-security-policy wrote: Just FYI, metacert.com served up this cert recently: https://crt.sh/?id=1884181370 . -R ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Request received : Re: Intent to Ship: Move Extended Validation Information out of the URL bar ref:_00DU0Lfqj._5001v17KPuw:ref
We have received your request 03531223 and it is being processed by our support team. To leave additional comments, reply to this email. ref:_00DU0Lfqj._5001v17KPuw:ref ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
I have two questions Ronald: 1. What should I look for? I just see a DV cert from Let’s Encrypt. 2. Why did you message the entire community about whatever it is you’ve found? Thanks, Paul Sent from my iPhone > On Oct 12, 2019, at 11:04 AM, Ronald Crane via dev-security-policy > wrote: > > Just FYI, metacert.com served up this cert recently: > https://crt.sh/?id=1884181370 . > > -R > > ___ > 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
Request received : Re: Intent to Ship: Move Extended Validation Information out of the URL bar ref:_00DU0Lfqj._5001v17KLYI:ref
We have received your request 03530327 and it is being processed by our support team. To leave additional comments, reply to this email. ref:_00DU0Lfqj._5001v17KLYI:ref ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
Already the screenshots of the report from 2016 on page 3 show why no normal user can recognize if a website was encrypted or if an EV certificate was in use. The browser manufacturers must agree on a uniform, easy-to-understand presentation of the security indicators and not change them every month. The screenshot from the 2019 report also shows why normal users cannot tell if an EV certificate is in use: it is simply not recognizable cause most of the indicators are deleted. Please repeat the test with a browser that displays the full company name in green AND the complete address bar in green. In my opinion, the two linked reports are not acceptable due to deliberate destruction of the security features in the browser UX. Am Donnerstag, 10. Oktober 2019 00:23:28 UTC+2 schrieb Ryan Sleevi: > On Wed, Oct 9, 2019 at 6:06 PM Paul Walsh via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > I believe an alternative icon to the encryption lock would make a massive > > difference to combating the security threats that involve dangerous links > > and websites. I provided data to back up my beliefs. > > > > Here's peer-reviewed data, in top-tier venues, that shows the beliefs are > unfounded: > https://ai.google/research/pubs/pub48199 > https://ai.google/research/pubs/pub45366 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
