Re: Symantec Response L

2017-04-13 Thread Myers, Kenneth (10421) via dev-security-policy
I don't know if it was mentioned elsewhere but Symantec had an MOA with the Federal PKI which required cross-certificates. If Symantec revoked it, the MOA would also have been violated which would have severed the trust with the Federal PKI and Symantec customers. To the particular IdenTrust

RE: Symantec Response B

2017-04-13 Thread Jeremy Rowley via dev-security-policy
Because the certificate improperly included Symantec's BR-compliance OID. If the cert wasn't a BR-covered certificate but included the BR compliance OID, then the cert was still mis-issued and should be disclosed. Jeremy -Original Message- From: dev-security-policy

Re: Email sub-CAs

2017-04-13 Thread douglas.beattie--- via dev-security-policy
On Thursday, April 13, 2017 at 10:49:17 AM UTC-4, Gervase Markham wrote: > On 13/04/17 14:23, Doug Beattie wrote: > > In 3.2 the term Technically Constrained is not defined to be any > > different than the BRs (or perhaps even less restrictive). > > You mean 2.3, right? Yes, 2.3. > I would say

Re: Email sub-CAs

2017-04-13 Thread Ryan Sleevi via dev-security-policy
On Thu, Apr 13, 2017 at 10:48 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Section 3.1.2.1 specifies that any CA capable of issuing secure email > > certificates must have a "WebTrust for CAs" audit (or corresponding > > ETSI audit). This is a

Re: SHA-1 serverAuth cert issued by Trustis in November 2016

2017-04-13 Thread Gervase Markham via dev-security-policy
On 12/04/17 21:39, uri...@gmail.com wrote: > Is there an expectation of a resolution of some sort to this matter? > Also, their most recent audit is apparently overdue (perhaps related to the > SHA-1 mis-issuance?) > >

Re: Email sub-CAs

2017-04-13 Thread Gervase Markham via dev-security-policy
On 13/04/17 14:23, Doug Beattie wrote: > In 3.2 the term Technically Constrained is not defined to be any > different than the BRs (or perhaps even less restrictive). You mean 2.3, right? I would say Inclusion section, bullet 9 gives the definition of technically constrained. For email certs,

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

2017-04-13 Thread Rob Stradling via dev-security-policy
Thanks Gerv. :-) On 13/04/17 14:46, Gervase Markham via dev-security-policy wrote: Hi Rob, You either have a great memory or good search-fu; well done for digging this out! On 12/04/17 22:14, Rob Stradling wrote: Gerv, FYI what you're proposing here

Re: Grace Period for Sub-CA Disclosure

2017-04-13 Thread Rob Stradling via dev-security-policy
On 13/04/17 14:50, Gervase Markham wrote: On 12/04/17 21:21, Rob Stradling wrote: Mozilla also requires CAs to disclose intermediate cert revocations to CCADB. Should there be a corresponding time limit in the policy regarding how soon after revocation this disclosure must occur? There is:

Re: Grace Period for Sub-CA Disclosure

2017-04-13 Thread Gervase Markham via dev-security-policy
On 12/04/17 21:21, Rob Stradling wrote: > Mozilla also requires CAs to disclose intermediate cert revocations to > CCADB. Should there be a corresponding time limit in the policy > regarding how soon after revocation this disclosure must occur? There is: "If a non-exempt intermediate

Re: Symantec Response B

2017-04-13 Thread Gervase Markham via dev-security-policy
Symantec's bug opens with the words: "At the end of 2013, Symantec issued a cert to one of its customers that did not comply with several provisions of the CA/Browser Forum Baseline Requirements."[0] So Symantec, at least, thought that this cert fell under the BRs. If their case was that it did