Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Hi Ben, in order to avoid for every single audit the compilation work for the auditor (in person) on his qualification, independence, etc. as well as the need to crosscheck the statements he made, that was covered for the EU ETSI/eIDAS scheme by the accreditation of the body (organization;

Re: NAVER: Public Discussion of Root Inclusion Request

Thank you all for the comments during the public discussion phase. All matters raised in this public discussion has been fixed and then published our revised CPS, including changes in sections 4.9.3, 4.9.5, 5.4.1, 9.14, and 9.16.3. You can find the revised CPS v1.5.0 at our repository.

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Hi Clemens, I think this fundamentally misunderstands the proposal. As Ben mentioned, and as countless other schemes have highlighted, competency is with individuals, not organizations. While the eIDAS Scheme is relevant for eIDAS qualification, I think it's important to highlight that browsers

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

That sounds like a great idea, and sounds like a good compliment to an approach that several (Root) CAs have taken, of requiring all their externally-operated subordinate CAs review their auditors and audit scope with the root CAO, before finalizing the audit engagement. An example of how the

RE: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

Ben, We're concerned that these changes could unintentionally prevent many new auditors from being able to conduct audits, despite being Qualified Auditors. The problem is that CAs will understandably be very hesitant to use a new auditor, as they cannot risk having an audit conducted, and

RE: Policy 2.7.1: MRSP Issue #153: Cradle-to-Grave Contiguous Audits

So, I'd like to drill down a bit more into one of the cases you discussed. Let's assume the following: 1. The CAO [*] may or may not have requested removal of the CAC, but removal has not been completed. The CAC is still trusted by at least one public root program. 2. The CAO has destroyed the

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Nov 05, 2020 at 11:48:20AM -0500, Ryan Sleevi via dev-security-policy wrote: > competency is with individuals, not organizations. [snip] > I find the appeal to redundancy and the NAB, and further, the suggestion of > GDPR, to be a bit insulting to this community. This opposition to >

Re: Policy 2.7.1: MRSP Issue #152: Add EV Audit exception for Policy Constraints

On 10/16/20 11:26 PM, Ryan Sleevi wrote: Because of this, it seems that there is a simpler, clearer, unambiguous path for CAs that seems useful to move to: - If a CA is trusted for purpose X, that certificate, and all subordinate CAs, should be audited against the criteria relevant for X I am

Re: Policy 2.7.1: MRSP Issue #192: Require information about auditor qualifications in the audit report

On Thu, Nov 5, 2020 at 7:00 PM Wojtek Porczyk wrote: > On Thu, Nov 05, 2020 at 11:48:20AM -0500, Ryan Sleevi via > dev-security-policy wrote: > > competency is with individuals, not organizations. > > [snip] > > > I find the appeal to redundancy and the NAB, and further, the suggestion > of > >

Policy 2.7.1:MRSP Issue #205: Require CAs to publish accepted methods for proving key compromise

This email begins discussion of a potential change to section 6 of the Mozilla Root Store Policy . The method by which a person may provide a CA with proof of private key compromise has been an