Re: Symantec: Draft Proposal

2017-05-08 Thread urijah--- via dev-security-policy
On Monday, May 8, 2017 at 7:21:46 AM UTC-4, okaphone.e...@gmail.com wrote: > Hi Rick, > > I don't see a "May 4th post". Where was it posted? Not here it seems. It's above--it links to https://www.symantec.com/connect/blogs/symantec-ca-continues-public-dialogue > > Also it's reasonable that

Re: Draft further questions for Symantec

2017-05-08 Thread wizard--- via dev-security-policy
In addition to requesting disclosure of intermediates that have been (even if not currently are) able to issue server certs, and the catchall, both of which seem excellent, I encourage Mozilla to consider asking these questions as part of an implemented remedy plan. That is, put in motion

Re: Draft further questions for Symantec

2017-05-08 Thread richmoore44--- via dev-security-policy
On Monday, May 8, 2017 at 1:24:28 PM UTC+1, Gervase Markham wrote: > I think it might be appropriate to have a further round of questions to > Symantec from Mozilla, to try and get some clarity on some outstanding > and concerning issues. Here are some _proposed_ questions; feel free to > suggest

RE: Email sub-CAs

2017-05-08 Thread Doug Beattie via dev-security-policy
Hi Gerv, I wanted to get the latest Mozilla thoughts on the audit requirements for TCSCs based on the discussion we started last month. I understand the BR requirement if the CA can issue server auth certificates, this was discussed here:

Re: Draft further questions for Symantec

2017-05-08 Thread urijah--- via dev-security-policy
It may be necessary to expand that definition to intermediates that were capable of issuing certificates within the past year (or longer). On Monday, May 8, 2017 at 9:31:21 AM UTC-4, Alex Gaynor wrote: > I'm not the best way to phrase this, so please forgive the bluntness, but I > think it'd be

Re: Draft further questions for Symantec

2017-05-08 Thread Alex Gaynor via dev-security-policy
Thanks Kurt. Alex On Mon, May 8, 2017 at 11:22 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2017-05-08 15:31, Alex Gaynor wrote: > >> I'm not the best way to phrase this, so please forgive the bluntness, but >> I >> think it'd be appropriate to

Re: Draft further questions for Symantec

2017-05-08 Thread Alex Gaynor via dev-security-policy
I'm not the best way to phrase this, so please forgive the bluntness, but I think it'd be appropriate to ask at this point if Symantec has disclosed all necessary intermediates (I believe this would be defined as: chain to their roots in our trust store, are not expired, are not revoked, and are

Re: Symantec: Draft Proposal

2017-05-08 Thread Alex Gaynor via dev-security-policy
Hi Rick, Does Symantec plan to introduce new facts into the conversation, or is all the information we are currently considering accurate and complete? If there's no new information, I don't see why the community of participants in m.d.s.p. should pause. I think it's a point of pride for many of

Re: Symantec: Draft Proposal

2017-05-08 Thread wizard--- via dev-security-policy
It makes perfect sense if the game plan is to force continued delays of decisions on the part of root programs! Which appears to be exactly what is happening. After all, wait long enough, and it can be claimed that all possibly bad things would be expired, so don't distrust us, m'ok. I think

Re: Draft further questions for Symantec

2017-05-08 Thread Kurt Roeckx via dev-security-policy
On 2017-05-08 14:24, Gervase Markham wrote: 1) Did any of the RAs in your program (CrossCert and co.) have the technical ability to independently issue EV certificates? If they did not not, given that they had issuance capability from intermediates which chained up to EV-enabled roots, what

Draft further questions for Symantec

2017-05-08 Thread Gervase Markham via dev-security-policy
I think it might be appropriate to have a further round of questions to Symantec from Mozilla, to try and get some clarity on some outstanding and concerning issues. Here are some _proposed_ questions; feel free to suggest modifications or other questions, and I will decide what to send officially

Re: Symantec: Draft Proposal

2017-05-08 Thread okaphone.elektronika--- via dev-security-policy
Hi Rick, I don't see a "May 4th post". Where was it posted? Not here it seems. Also it's reasonable that Symantec wants to "address impact to their customers" but what about impact to all of the browsers users? It may be a good idea to try and address (in your proposals) that to. So far I

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

2017-05-08 Thread Dimitris Zacharopoulos via dev-security-policy
On 8/5/2017 1:18 μμ, Gervase Markham wrote: On 05/05/17 19:44, Dimitris Zacharopoulos wrote: * MUST include an EKU that has the id-kp-emailProtection value AND * MUST include a nameConstraints extension with o a permittedSubtrees with + rfc822Name entries scoped in the

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

2017-05-08 Thread Dimitris Zacharopoulos via dev-security-policy
On 6/5/2017 1:19 πμ, Peter Bowen via dev-security-policy wrote: One other question: Does your proposal allow a TCSC that covers both ServerAuth and EmailProtection for the domains of the same organization? Or put another way, would your proposed language force an organization wanting to run

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

2017-05-08 Thread Gervase Markham via dev-security-policy
On 05/05/17 19:44, Dimitris Zacharopoulos wrote: > * MUST include an EKU that has the id-kp-emailProtection value AND > * MUST include a nameConstraints extension with > o a permittedSubtrees with > + rfc822Name entries scoped in the Domain (@example.com) or >Domain

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

2017-05-08 Thread Gervase Markham via dev-security-policy
On 05/05/17 22:21, Jakob Bohm wrote: > The issue would be implementations that only check the EE cert for > their desired EKU (such as ServerAuth checking for a TLS client or > EmailProtection checking for a mail client). In other words, relying > parties whose software would accept a chain such

Re: Email sub-CAs

2017-05-08 Thread Gervase Markham via dev-security-policy
On 05/05/17 18:58, Peter Bowen wrote: >> Right now the policy does not require disclosure of CA-certificates >> that the CA deems are technically constrained. I believe this was made the case for some mix of the following reasons: a) the CA did not want to reveal every customer it had; b) this

Re: Changing CCADB domains

2017-05-08 Thread Rob Stradling via dev-security-policy
On 06/05/17 10:25, Jesper Kristensen via dev-security-policy wrote: Mozilla could CNAME from ccadb.org to .force.com, and then declare that the ccadb.org URLs are the official ones. Is that what you meant, Peter? You cannot set up a CNAME without configuring Salesforce, since they would not