Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 11:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > For a certificate capable of being used for SSL-enabled servers, the CA > must ensure that the applicant has registered the domain(s) referenced in > the certificate or has

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Given this discussion, there must be no other CAs using method 9 or 10, > else they would have come forward by now with disclosures and have > demonstrated their compliance..

Re: TLS-SNI-01 and compliance with BRs

Peter, On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What does Mozilla expect to be verified? We know the 10 methods allow > issuance where "the applicant has registered the domain(s) referenced in > the certificate or

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 2:58 PM, Doug Beattie wrote: > Matthew, > > > > That’s a good summary. It seems we have 2 methods that can be used only > if the CAs using the methods have the design and risk mitigation factors > reviewed and approved. It’s basically the

Re: Taiwan GRCA Root Renewal Request

This root inclusion request is currently in the public discussion phase [1] After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the following comments: ==Good== 1. GRCA has requested that this root be constrained to issuing certificates for .tw domains. 2. The BR Self

RE: TLS-SNI-01 and compliance with BRs

Matthew, That’s a good summary. It seems we have 2 methods that can be used only if the CAs using the methods have the design and risk mitigation factors reviewed and approved. It’s basically the old “any other method”, except before you can use it, the Root programs must review the

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:44 PM, Matthew Hardeman wrote: > Ultimately, if it should arise that other CAs who rely on mechanisms > implementing or claiming to implement method #10 have similar risk and > vulnerabilities, those CAs should be called to task for not having

Re: TLS-SNI-01 and compliance with BRs

One opinion I'd like to add to the discussion... In as far as that at this point, it looks like it's time for guidance from the root programs officially on whether or not and under what circumstances TLS-SNI-01 and/or any other mechanism based on method #10 are allowable moving forward I'd

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 9:22 AM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think we’ve gotten off track. While the general discussion is good and > we need to update the validation methods to provide more precise details, I > want to get back to

Re: TLS-SNI-01 and compliance with BRs

The following discussion is only a sketched out idea and thus does not classify all the 10 blessed methods: One rule that could reasonably be added to the BR or Mozilla requirements for the various methods could be this general safety rule: - Validation methods that check control over a

Re: TLS-SNI-01 and compliance with BRs

> On Jan 19, 2018, at 7:22 AM, Doug Beattie via dev-security-policy > wrote: > > Many CA’s haven’t complied with the Mozilla requirement to list the methods > they use (including Google btw), so it’s hard to tell which CAs are using > method 10. Of

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 10:22 AM, Doug Beattie wrote: > > > I think we’ve gotten off track. While the general discussion is good and > we *need* to update the validation methods to provide more precise > details, I want to get back to the point in hand which is

RE: TLS-SNI-01 and compliance with BRs

I think we’ve gotten off track. While the general discussion is good and we need to update the validation methods to provide more precise details, I want to get back to the point in hand which is asking if the ACME TLS-SNO-01 method is compliant with method 10. If method 10 specified that

RE: TLS-SNI-01 and compliance with BRs

My recollection is that there were a number of CA/B forum participants (including me) who asked repeatedly if method #10 could be expanded beyond a single sentence. I don't remember anyone speaking up in opposition, just silence. I continue to support making sure that all of the validation

Re: Updating Root Inclusion Criteria (organizations)

On 19/01/2018 11:09, Gervase Markham wrote: On 19/01/18 01:05, Jakob Bohm wrote: 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

Re: Updating Root Inclusion Criteria (organizations)

On 19/01/18 01:05, Jakob Bohm wrote: > 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

Re: Updating Root Inclusion Criteria

On 18/01/18 14:24, Ryan Sleevi wrote: > Or, conversely, that we cannot discuss inclusion policies in isolation from > discussion root policies - we cannot simultaneously work to strengthen > inclusion without acknowledging the elephant in the room of the extant CAs. We aren't necessarily