Re: 825 days success and future progress!

On 03/04/2018 02:35, Kurt Roeckx wrote: On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy wrote: seems to be mostly justified as a poor workaround for the browsers and certificate libraries not properly implementing reliable revocation checks. The problem is not in

Re: Policy 2.6 Proposal: Require audits back to first issuance

Thanks Tim and Ryan for the information on WebTrust Root Key Generation Ceremony audit reports. Can anyone say if an equivalent public-facing report exists for ETSI audits? If so, I think we should require CAs to provide these reports with their root inclusion requests. Regarding the issue of

Re: Audits for new subCAs

On 03/04/2018 02:15, Wayne Thayer wrote: On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: While Entrust happens to do this, as a relying party, I dislike frequent updates to CP/CPS documents just for such formal changes. This

Re: 825 days success and future progress!

On Tue, Apr 03, 2018 at 02:11:07AM +0200, Jakob Bohm via dev-security-policy wrote: > seems > to be mostly justified as a poor workaround for the browsers and > certificate libraries not properly implementing reliable revocation > checks. The problem is not in the libraries, or even the

Re: Audits for new subCAs

On Mon, Apr 2, 2018 at 4:36 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > While Entrust happens to do this, as a relying party, I dislike frequent > updates to CP/CPS documents just for such formal changes. > > This creates a huge loophole. The CP/CPS

Re: 825 days success and future progress!

Furthermore in IT departments of smaller companies, setting up new automations or upgrading otherwise functioning systems to ones that include automation is much harder than it is for a mastodon like Siemens. The main arguing for ever shorter validity periods seems to come from very few

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

On 02/04/2018 18:26, Tom Delmas wrote: Following the discussion on https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394 What is the position of Mozilla about the submission to ct-logs of the final certificate when there is already a pre-certificate? As it helps

Re: Audits for new subCAs

On 29/03/2018 20:46, Wayne Thayer wrote: Thanks everyone for your input on this topic. I'm hearing consensus that we should not require a newly issued subordinate CA certificate to appear on an audit statement prior to being used to sign end-entity certificates. This is something that could be

Re: Audits for new subCAs

On 02/04/2018 17:12, Julian Inza wrote: El sábado, 31 de marzo de 2018, 3:01:29 (UTC+2), Wayne Thayer escribió: On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi wrote: I think, for new CAs, the KGC report and the stated CP/CPS, combined with ensuring that the next audit that

Fwd: FW: Complying with Mozilla policy on email validation

I'm forwarding this for Tim because the list rejected it as SPAM. *From:* Tim Hollebeek *Sent:* Monday, April 2, 2018 2:22 PM *To:* 'mozilla-dev-security-policy' *Subject:* Complying with Mozilla policy on email validation Mozilla policy

RE: 825 days success and future progress!

By practical means in an IT department of a large company, it is always easier to discuss about money, if such a plan is written down in a standard that can be referenced and shown (like the BRGs) than in the depths of the archive of a mailing list. So if there is a plan, I would like to

Re: 825 days success and future progress!

In past discussions, the proposal was 1 year to 2 years, and 1 year to 1 year after that. We're now at the midway point, so it seems appropriate to discuss how to get shorter. On Mon, Apr 2, 2018 at 3:11 PM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:

Re: 825 days success and future progress!

Tim, I think it's far more productive to help clarify misunderstandings. For example, based on your statement, it sounds like you're actually opposed to any change - and the objection that it's not "significantly different" is simply a misleading objection. If that's not the case, then can you

RE: 825 days success and future progress!

Hi all! >From the discussions we had in the last months internally at Siemens IT >department about the 825 days rule, I can report that our server operators >need a long term roadmap in this issue. The main point here is, that there are >a hell lot of applications out there that don't (easily)

RE: 825 days success and future progress!

Ryan, I’ve warned you several times, do not put words in my mouth. I support the status quo, for now. We can talk about future changes in the future. -Tim From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, April 2, 2018 2:58 PM To: Tim Hollebeek Cc:

Re: 825 days success and future progress!

On Mon, Apr 2, 2018 at 2:28 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 18 months is not significantly different from 825 days. So there's really > no benefit. > So it sounds like you're supportive of 13 months, then, so that we arrive at an

RE: 825 days success and future progress!

Yes, if we wanted to go to 13 months quickly, we would have gone directly there. Getting to 13 months quickly is not a goal. That’s not having it both ways, that having an understanding of how the ecosystem actually works. The majority of the CAB forum, and not just CAs, but also many

Re: 825 days success and future progress!

Hi Tim, I'd have suggested an even shorter period, say 13 months, except I anticipated CAs would object that it was too great a change too suddenly, precisely as they did when this subject was last discussed! While I appreciate that changing BRs can be difficult for customer communications, the

RE: 825 days success and future progress!

18 months is not significantly different from 825 days. So there's really no benefit. People have to stop wanting to constantly change the max validity period. It's difficult enough to communicate these changes to consumers and customers, and it really drives them nuts. I can only imagine what

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió: > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote: > > I fully understand the proposed solution about 2018 roots but as I > > previously said some concerns arise, [...] > > > That is unfortunate for

825 days success and future progress!

Afternoon all! A month ago a new BR rule went into effect, putting a maximum validity period of 825 days on newly issued certificates. Truthfully, I was expecting tons of CAs to screw up, forget to implement it, or have no technical controls, and there to be tons of miss-issuance. To me delight,

Re: Submission to ct-logs of the final certificate when there is already a pre-certificate

Mozilla currently doesn't have any policy with respect to Certificate Transparency, so I think diving in on this particular point is putting the cart before the horse :-) Currently Firefox does not check/require SCT presence nor does the Mozilla root program require certificates to be logged.

Submission to ct-logs of the final certificate when there is already a pre-certificate

Following the discussion on https://community.letsencrypt.org/t/non-logging-of-final-certificates/58394 What is the position of Mozilla about the submission to ct-logs of the final certificate when there is already a pre-certificate? As it helps discover bugs (

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Mon, Apr 2, 2018 at 11:02 AM, Julian Inza via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió: > > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote: > > > I fully understand the

Re: Audits for new subCAs

El sábado, 31 de marzo de 2018, 3:01:29 (UTC+2), Wayne Thayer escribió: > On Thu, Mar 29, 2018 at 12:55 PM, Ryan Sleevi wrote: > > > > > I think, for new CAs, the KGC report and the stated CP/CPS, combined with > > ensuring that the next audit that covers the period of time

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

El lunes, 2 de abril de 2018, 3:53:08 (UTC+2), Tom Prince escribió: > On Sunday, April 1, 2018 at 4:16:47 AM UTC-6, ramiro...@gmail.com wrote: > > I fully understand the proposed solution about 2018 roots but as I > > previously said some concerns arise, [...] > > > That is unfortunate for