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
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
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
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
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.
>
>
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
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
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
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
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
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
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:
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:
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,
>
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
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
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
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
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
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
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
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
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
>
23 matches
Mail list logo