Re: Changing CCADB domains

On 05/05/17 04:25, Peter Bowen via dev-security-policy wrote: On Wed, May 3, 2017 at 10:52 AM, Kathleen Wilson via dev-security-policy wrote: All, I think it is time for us to change the domains that we are using for the CCADB as follows. Change the

Re: [EXT] Re: Symantec: Draft Proposal

Steve, Thank you for the prompt response, and I am glad this certificate was in fact validated internally by Symantec. On Tuesday, May 2, 2017 at 6:55:13 PM UTC-4, Steve Medin wrote: > > -Original Message- > > From: dev-security-policy [mailto:dev-security-policy- > >

Re: [EXT] Symantec: Draft Proposal

Steve, I am glad to see that Symantec is willing to continue public discussion on possible paths forward. But these responses still seem to continue to focus on the RA issue, and do not respond to or address all of the other serious issues identified here. For example, issue Y (Q9) -- un- or

Re: Symantec: Draft Proposal

On Fri, May 5, 2017 at 9:02 AM, Gervase Markham via dev-security-policy wrote: > On 04/05/17 21:58, Ryan Sleevi wrote: > > I asked Symantec what fields CrossCert had control over. Their answer is > here on page 3: >

Re: [EXT] Symantec: Draft Proposal

On 05/05/17 04:30, Steve Medin wrote: > Gerv, thank you for your draft proposal under consideration. We have posted > our comments and detailed information at: > https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue It feels somewhat strange to have this disjointed

Re: Updating Root Program wiki pages

On 04/05/17 18:42, Kathleen Wilson wrote: > Gerv is leading the effort to clean up Mozilla's Root Store related > wiki pages. With lots of help from Kathleen :-) > Please let me know if information that you need disappears, and you > are not able to find it by starting with

Re: Changing CCADB domains

On 05/05/17 16:08, Gervase Markham via dev-security-policy wrote: On 05/05/17 10:22, Rob Stradling wrote: Mozilla could CNAME from ccadb.org to .force.com, and then declare that the ccadb.org URLs are the official ones. It would need to be .ccadb.org, as we plan to use www.ccadb.org as an

Re: Symantec: Draft Proposal

On 04/05/17 19:30, Jakob Bohm wrote: > 1. Issue D actually seems to conflate three *completely different* > issues: Are you sure you are not referring to the Issues List document here rather than the proposal? > 2. If the remaining unconstrained SubCAs are operated by Symantec and > subject

Re: Changing CCADB domains

On 05/05/17 10:22, Rob Stradling wrote: > Mozilla could CNAME from ccadb.org to .force.com, and then > declare that the ccadb.org URLs are the official ones. It would need to be .ccadb.org, as we plan to use www.ccadb.org as an introductory website for the CCADB, once Mozilla IT configures things

Re: Symantec: Draft Proposal

On 04/05/17 21:58, Ryan Sleevi wrote:> rather, it was based on the evidence that there were issues > and patterns that were unresolved, and thus sought to minimize the impact > of an eventual total distrust in a gradual way. So the first Chrome proposal had the explicit target of an eventual

Re: Symantec: Draft Proposal

On 2017-05-04 22:55, Alex Gaynor wrote: I believe this further underscores finding Y, and others related to lack of visibility into and BR-compliance of Symantec's intermediates. The fact that we can still be finding new intermediates leaves me to wonder if this is really the last of them, or

Re: [EXT] Symantec: Draft Proposal

It is clear to me from reading this that there is a significant gap between Symantec's perspective on the severity of the issues discussed and the perspective of many m.d.s.p. participants. Hopefully this email will serve to highlight some specific areas that contribute to this gap, and which

Re: Symantec: Draft Proposal

On Fri, May 5, 2017 at 9:18 AM, Gervase Markham wrote: > On 05/05/17 17:09, Peter Bowen wrote: >> We know that the RAs could use different certificate profiles, as >> certificates they approved had varying issuers, and "Issuer DN" has >> the same "No(1)" that CP has in the table

Re: Symantec: Draft Proposal

On 05/05/2017 17:37, Gervase Markham wrote: On 04/05/17 19:30, Jakob Bohm wrote: 1. Issue D actually seems to conflate three *completely different* issues: Are you sure you are not referring to the Issues List document here rather than the proposal? I am referring to the "summary" of D

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that takes all comments into account? From what I understand, the Subordinate CA Certificate to be considered Technically Constrained only for S/MIME: * MUST include an EKU that has the

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > > Looking at https://github.com/mozilla/pkipolicy/issues/69 > > do you have a proposed language that takes all comments into account? From > what I understand, the

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via dev-security-policy wrote: Looking at https://github.com/mozilla/pkipolicy/issues/69 do you have a proposed language that takes

Re: Symantec: Draft Proposal

On 05/05/17 17:09, Peter Bowen wrote: > We know that the RAs could use different certificate profiles, as > certificates they approved had varying issuers, and "Issuer DN" has > the same "No(1)" that CP has in the table in the doc you linked. I > don't see any indication of what profiles each RA

More CrossCert antics

CrossCert appear to be issuing BR-noncompliant certs under KISA roots now: https://crt.sh/?cablint=101=40347=cablint We don't trust KISA as it's a Super-CA: https://crt.sh/?caid=55=cablint https://bugzilla.mozilla.org/show_bug.cgi?id=335197 https://bugzilla.mozilla.org/show_bug.cgi?id=1310580 but

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 01/05/17 09:55, Gervase Markham wrote: > "Each entry in permittedSubtrees must either be or end with a Public > Suffix." (And we'd need to link to publicsuffix.org) Aargh. This should, of course, be "Public Suffix + 1" - i.e. an actual domain owned by someone. > The second option is harder to

Re: Symantec: Draft Proposal

On Fri, 5 May 2017 17:18:38 +0100 Gervase Markham via dev-security-policy wrote: > On 05/05/17 17:09, Peter Bowen wrote: > > We know that the RAs could use different certificate profiles, as > > certificates they approved had varying issuers, and "Issuer

Re: Email sub-CAs

(Resending as the attached file was too large) On Fri, May 5, 2017 at 10:46 AM, Peter Bowen wrote: > On Thu, Apr 20, 2017 at 3:01 AM, Gervase Markham via > dev-security-policy wrote: >> On 15/04/17 17:05, Peter Bowen wrote: >>> Should

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy wrote: > > > On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: >> >> On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via >> dev-security-policy

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 05/05/2017 22:45, Dimitris Zacharopoulos wrote: On 5/5/2017 10:58 μμ, Peter Bowen wrote: On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy wrote: On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri,

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On 5/5/2017 10:58 μμ, Peter Bowen wrote: On Fri, May 5, 2017 at 11:58 AM, Dimitris Zacharopoulos via dev-security-policy wrote: On 5/5/2017 9:49 μμ, Peter Bowen via dev-security-policy wrote: On Fri, May 5, 2017 at 11:44 AM, Dimitris Zacharopoulos via

Re: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

On Fri, May 5, 2017 at 2:21 PM, Jakob Bohm via dev-security-policy wrote: > On 05/05/2017 22:45, Dimitris Zacharopoulos wrote: >> >> >> >> On 5/5/2017 10:58 μμ, Peter Bowen wrote: >>> >> >> I don't know if all implementations doing path validation, use the