Re: Updating Root Inclusion Criteria (organizations)

2018-01-18 Thread Jakob Bohm via dev-security-policy
On 18/01/2018 11:01, Gervase Markham wrote: On 17/01/18 19:49, Jakob Bohm wrote: 3. Major vertical CAs for high value business categories that issue   publicly trusted certificates at better than EV level integrity.  For How do you define "major"? And "high value business category"? Major

Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread J.C. Jones via dev-security-policy
That would be the right place. At the time there was not universal desire for these validation mechanisms to be what I'd call 'fully specified'; the point of having them written this way was to leave room for individuality in meeting the requirements. Of course, having a few

Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread J.C. Jones via dev-security-policy
As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked through it in the Validation Working Group. The ADN lookup is DNS, and what you find when you connect there via TLS, within the certificate, should be the random value (somewhere). 3.2.2.4.10 was written to permit ACME's

Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Matthew Hardeman via dev-security-policy
The trouble is that the BRs for those methods are really really vague. I don't know that one can make a stronger case for misissuance versus properly issued in these cases. I'm certainly no fan of the mechanism in TLS-SNI-01 and regard it deficient in the face of real world deployment

Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Alex Gaynor via dev-security-policy
I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01 performs a DNS lookup for the ADN, connects to that IP, and initiatives a TLS connection with the .acme.invalid SNI value. Certificates don't exist on Domain Names if we think really hard about it, but servers with IPs that

TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Doug Beattie via dev-security-policy
Now that I'm more familiar with method 9 and 10 domain validation methods and heard a few side discussions about the topic, it's made me (and others) wonder if the ACME TLS-SNI-01 is compliant with BR Method 10. The BRs say: 3.2.2.4.10. TLS Using a Random Number Confirming the Applicant's

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Alex Gaynor via dev-security-policy
Self-assessment is insufficient :-) That's why we require audits, review issued certificates for technical violations, and attempt to empower domain owners to identify misissuance. As we move to a world with greater participation of public CAs in Certificate Transparency (hopefully 100%

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Ryan Sleevi via dev-security-policy
On Thu, Jan 18, 2018 at 9:33 AM, Ryan Sleevi wrote: > > > On Thu, Jan 18, 2018 at 9:11 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 18/01/18 13:55, Ryan Sleevi wrote: >> > Was it your intent to redefine the problem like

RE: Updating Root Inclusion Criteria

2018-01-18 Thread Tim Hollebeek via dev-security-policy
> I think this is a vote for the status quo, in which we have been accepting > CAs that don't meet the guidance provided under 'who may apply' Perhaps slightly less strong than that. I think Mozilla should be willing to consider accepting them if there is a compelling reason to do so. “Why

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Gervase Markham via dev-security-policy
Hi Ryan, On 18/01/18 13:55, Ryan Sleevi wrote: > I do want to point out that you are substantially changing the goals from > what Wayne posited. That is, you have moved the goalpost from being > 'objective' to being what is 'fair', and 'fair' will inherently be a > subjective evaluation. One of

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Jonathan Rudenberg via dev-security-policy
> On Jan 18, 2018, at 08:53, Ryan Sleevi wrote: > > If Mozilla was committed to an equitable set of criteria for both incumbents > and newcomers, then one natural consequence of this is that all incumbents > should be required to rotate their keys to new roots, created under

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Gervase Markham via dev-security-policy
On 18/01/18 13:53, Ryan Sleevi wrote: > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at > the detriment to both user security and the ecosystem. If your goal is for > policies that do not favor incumbents, then it seems a significantly > different discussion should

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Ryan Sleevi via dev-security-policy
On Thu, Jan 18, 2018 at 4:59 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 19:14, Ryan Hurst wrote: > > Since Google's PKI was mentioned as an example, I can publicly state > > that the plan is for Google to utilize the Google Trust

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Ryan Sleevi via dev-security-policy
On Thu, Jan 18, 2018 at 4:24 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 15:13, Jonathan Rudenberg wrote: > > I like this concept a lot. Some concrete ideas in this space: > > > > - Limit the validity period of root certificates to a

RE: Camerfirma's misissued certificate

2018-01-18 Thread Juan Angel Martin (AC Camerfirma) via dev-security-policy
Hi Rob, We've some costumers that really appreciates that we include them. But I can also tell you that you are absolutely right and now we're studying to modify this parameter in our OCSP. Thanks a lot Juan Angel -Mensaje original- De: Rob Stradling [mailto:rob.stradl...@comodo.com]

Re: Camerfirma's misissued certificate

2018-01-18 Thread Rob Stradling via dev-security-policy
Hi Juan. Is there a particular technical reason why you feel the need to include "all the certs chaining up to the roots" in your OCSP responses? When an OCSP response is signed directly by the CA that issued the corresponding certificate, the OCSP response does not need to contain any

Re: Updating Root Inclusion Criteria (organizations)

2018-01-18 Thread Gervase Markham via dev-security-policy
On 17/01/18 19:49, Jakob Bohm wrote: > 3. Major vertical CAs for high value business categories that issue >   publicly trusted certificates at better than EV level integrity.  For How do you define "major"? And "high value business category"? > 4. Selected company CAs for a handful of

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Gervase Markham via dev-security-policy
On 17/01/18 19:14, Ryan Hurst wrote: > Since Google's PKI was mentioned as an example, I can publicly state > that the plan is for Google to utilize the Google Trust Services > infrastructure to satisfy its SSL certificate needs. While I can not > announce specific product roadmaps I can say that

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Gervase Markham via dev-security-policy
On 17/01/18 15:41, Peter Bowen wrote: > In the interest of transparency, I would like to add one more example > to your list: > > * Amazon Trust Services is a current program member. Amazon applied > independently but then subsequently bought a root from Go Daddy > (obvious disclosure: Wayne was

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Gervase Markham via dev-security-policy
On 17/01/18 15:13, Jonathan Rudenberg wrote: > I like this concept a lot. Some concrete ideas in this space: > > - Limit the validity period of root certificates to a few years, so that the > criteria can be re-evaluated, updated, and re-applied on a rolling basis. Are you saying we should do

Re: Updating Root Inclusion Criteria

2018-01-18 Thread Gervase Markham via dev-security-policy
On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should focus less on the questions of whether a CA > is "appropriate" or "deserving" of participation in the Mozilla Root > Program, and more on whether they are willing and able to fulfill the > expectations of them as a steward of