Re: Audit Reminder Email Summary

2018-03-20 Thread Weitsong Lin via dev-security-policy
TWCA have been updated the CAADB. Do we have to open the bug to update audit report status? Thanks, Robin Lin Kathleen Wilson於 2018年3月21日星期三 UTC+8上午7時30分51秒寫道: > On 3/20/18 12:43 PM, Kurt Roeckx wrote: > > On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via > > dev-security-policy

Re: Policy 2.6 Proposal: Move Compliance Date into policy

2018-03-20 Thread Wayne Thayer via dev-security-policy
On Tue, Mar 20, 2018 at 2:46 PM, Ryan Sleevi wrote: > > > On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote: >> >> > >> > Looking

Re: Audit Reminder Email Summary

2018-03-20 Thread Kathleen Wilson via dev-security-policy
On 3/20/18 12:43 PM, Kurt Roeckx wrote: On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via dev-security-policy wrote: Mozilla: Audit Reminder Root Certificates: Class 2 Primary CA Standard Audit: https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236 Audit Statement

Re: Policy 2.6 Proposal: Move Compliance Date into policy

2018-03-20 Thread Ryan Sleevi via dev-security-policy
On Tue, Mar 20, 2018 at 4:15 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote: > > > > > Looking through [1], it seems like the Compliance Date has only differed > > from the Publication

Re: Mis-issuance of certificate with https in CN/SAN

2018-03-20 Thread Matt Palmer via dev-security-policy
On Fri, Mar 16, 2018 at 04:28:10AM +, Ben Wilson via dev-security-policy wrote: > 7. List of steps your CA is taking to resolve the situation and ensure > such issuance will not be repeated in the future, accompanied with a > timeline of when your CA expects to accomplish these things. > >

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

2018-03-20 Thread Ryan Sleevi via dev-security-policy
Ah, good point. Yeah, I think that's a perfectly reasonable change. On Tue, Mar 20, 2018 at 2:45 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi wrote: > > > > > So, one aspect of this is

Re: TURKTRUST Non-compliance

2018-03-20 Thread Jakob Bohm via dev-security-policy
On 20/03/2018 20:55, Tim Hollebeek wrote: The BRs already cover this. The point is that once a CA stops auditing, there's an issue about ensuring conformance. Actually, they don't. They have an empty placeholder section for wind down procedures. Surely one could blindly apply the full BRs

Re: TURKTRUST Non-compliance

2018-03-20 Thread Wayne Thayer via dev-security-policy
On Tue, Mar 20, 2018 at 12:56 PM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think it's not going to be productive to spend a lot of time on the list > debating whether or not a CA can opt out of full BR compliance by simply > saying "we're winding

Re: Policy 2.6 Proposal: Move Compliance Date into policy

2018-03-20 Thread Wayne Thayer via dev-security-policy
On Tue, Mar 20, 2018 at 8:19 AM, Ryan Sleevi wrote: > > Looking through [1], it seems like the Compliance Date has only differed > from the Publication Date once (with 2.0). > It's not clear to me that the 2.5 failure to adoption was related to > ambiguity around compliance

Re: TURKTRUST Non-compliance

2018-03-20 Thread Eric Mill via dev-security-policy
On Tue, Mar 20, 2018 at 3:43 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 20/03/2018 18:49, Ryan Sleevi wrote: > >> On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >>> Are

Re: TURKTRUST Non-compliance

2018-03-20 Thread Jakob Bohm via dev-security-policy
On 20/03/2018 18:49, Ryan Sleevi wrote: On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: Are you suggesting that the BRs be modified so a CA that has ceased issuance can obtain a clean audit report without meeting all current

Re: Audit Reminder Email Summary

2018-03-20 Thread Kurt Roeckx via dev-security-policy
On Tue, Mar 20, 2018 at 12:07:54PM -0700, Kathleen Wilson via dev-security-policy wrote: > Mozilla: Audit Reminder > Root Certificates: >Class 2 Primary CA > Standard Audit: > https://bug1297034.bmoattachments.org/attachment.cgi?id=8849236 > Audit Statement Date: 2017-01-14 > BR Audit:

Re: Audit Reminder Email Summary

2018-03-20 Thread Kathleen Wilson via dev-security-policy
Forwarded Message Subject: Summary of March 2018 Audit Reminder Emails Date: Tue, 20 Mar 2018 19:00:18 + (GMT) Mozilla: Audit Reminder Root Certificates: GDCA TrustAUTH R5 ROOT Standard Audit: https://cert.webtrust.org/SealFile?seal=2231=pdf Audit Statement Date:

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

2018-03-20 Thread Wayne Thayer via dev-security-policy
On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi wrote: > > So, one aspect of this is the recently discussed risk - that is, a CA that > provides value for only 10 users presents a substantial amount of risk to > all Mozilla users, for both compromise and non-compliance. This is, >

Re: TURKTRUST Non-compliance

2018-03-20 Thread Ryan Sleevi via dev-security-policy
On Tue, Mar 20, 2018 at 1:30 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Are you suggesting that the BRs be modified so a CA that has ceased >> issuance can obtain a clean audit report without meeting all current BR >> requirements? >> >> > I am

Re: TURKTRUST Non-compliance

2018-03-20 Thread Jakob Bohm via dev-security-policy
On 20/03/2018 17:39, Wayne Thayer wrote: Jakob, On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 17/03/2018 01:23, Wayne Thayer wrote: Note, that if it is reasonably certain/validated that the only activity is maintaining

RE: Policy 2.6 Proposal: Update domain validation requirements

2018-03-20 Thread Tim Hollebeek via dev-security-policy
The language you quoted from me is a bit imprecise, my apologies. I was trying to get CAs to disclose previously undisclosed uses of (4). There are disclosed uses of (4), including from DigiCert, that haven’t made it into the BR methods yet, because in the past year, we have failed to pass

Re: Policy 2.6 Proposal: Update domain validation requirements

2018-03-20 Thread Wayne Thayer via dev-security-policy
Tim, On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek wrote: > > > * Add a new bullet on IP Address validation that forbids the use of BR > > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address > > validation processes in the CA’s CP/CPS. > > This is

Re: TURKTRUST Non-compliance

2018-03-20 Thread Wayne Thayer via dev-security-policy
Jakob, On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/03/2018 01:23, Wayne Thayer wrote: > > Note, that if it is reasonably certain/validated that the only activity > is maintaining CRLs/OCSP for the remaining unexpired

Re: Policy 2.6 Proposal: Update domain validation requirements

2018-03-20 Thread Ryan Sleevi via dev-security-policy
On Mon, Mar 19, 2018 at 6:32 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Section 2.2(3) defines very specific requirements for use of the BR 3.2.2.4 > domain validation methods. Now that 3.2.2.4.11 (“any other method”) has > been removed from the BRs

Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

2018-03-20 Thread Ryan Sleevi via dev-security-policy
On Mon, Mar 19, 2018 at 6:26 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A few months ago, we discussed our root inclusion criteria [1], and came to > a conclusion that I summarized and proposed in policy as follows: > > I would like to thank

Re: Policy 2.6 Proposal: Move Compliance Date into policy

2018-03-20 Thread Ryan Sleevi via dev-security-policy
On Mon, Mar 19, 2018 at 6:28 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Historically, the effective dates of new versions of the policy have been > maintained separately from the policy itself [1]. In our November > Communication, we learned that

Re: Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

2018-03-20 Thread Ryan Sleevi via dev-security-policy
I support this change On Mon, Mar 19, 2018 at 6:25 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > This new version of the policy won’t be completed until after 15-April, > which is the revised deadline for disclosure and auditing of unconstrained >