RE: Symantec Response B

I am curious about the software requiring the 1024 bit cert off the root. The dates of mis-issuance are 2013-2014, which is still early in adoption of the BRs. At that time, the scope of the BRs was confusing and lead to lots of discussions. Although the term "intended to be used for

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

On 12/04/17 10:47, Gervase Markham via dev-security-policy wrote: Section 5.3.1 of policy 2.4.1 defines what it means to be technically constrained for email sub-CAs (those with id-kp-emailProtection). It says: "If the certificate includes the id-kp-emailProtection extended key usage, then

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

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?) https://groups.google.com/d/msg/mozilla.dev.security.policy/IjgFwzGI_H0/-689uFoXBwAJ On Thursday, March 16, 2017 at 7:00:51 AM

Re: Grace Period for Sub-CA Disclosure

On 04/04/17 12:17, Gervase Markham via dev-security-policy wrote: On 27/03/17 22:12, Andrew Ayer wrote: [ Corresponding issue on GitHub: https://github.com/mozilla/pkipolicy/issues/67 ] This has now been added to the policy 2.5 draft with a one-week deadline. Gerv Gerv, Mozilla also

Re: Symantec Response L

On Wed, Apr 12, 2017 at 4:53 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/04/17 22:08, Eric Mill wrote: > > I'll leave it to others to opine on the severity of the mistake and the > > quality of the response, but I do want to at least

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

On 12/04/17 11:41, Kurt Roeckx wrote: > But I'm also wondering what you expect if it contains other EKUs like > client auth, code sign, unknown. Do we always consider them constraint? Formally, we don't care if they also have those EKUs, or whether the use of those EKUs is constrained, because

Re: Policy 2.5 Proposal: Require qualified auditors unless agreed in advance

On 12/04/17 11:37, Jakob Bohm wrote: > Does this (accidentally?) remove the ability of Mozilla to explicitly > distrust a specific formally qualified auditor, such as E HK? Good point. Not sure, but we should make that clear. Add to the end of that exception sentence ", or refuse audits from

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On Wed, Apr 12, 2017 at 10:15 AM, Peter Bowen wrote: > On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy > wrote: > > > > A certificate hash does provide distinct value. > > > > The certificate hash is what is desired.

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 16:15, Peter Bowen wrote: On Wed, Apr 12, 2017 at 5:57 AM, Ryan Sleevi via dev-security-policy wrote: A certificate hash does provide distinct value. The certificate hash is what is desired. Yes, there could be multiple certificates. But

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 14:19, Jakob Bohm wrote: On 12/04/2017 12:44, Kurt Roeckx wrote: On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what

Re: Symantec Response B

On Wed, Apr 12, 2017 at 4:24 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't think 2) applies. It's only their software, that obviously can't > be updated yet, and so won't enforce such limit. That doesn't prevent the > rest of us to set such

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 12/04/2017 12:44, Kurt Roeckx wrote: On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what was not. The policy already has some

Re: Symantec Response L

To add to Eric's response, the U.S. Federal PKI was built and is dependent on Policy OID validation. There are 25 OIDs registered with NIST that define different assurance levels and is heavily focused on people certificates although it is a broad use PKI for the U.S. Federal Government (USG).

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 2017-04-12 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what was not. The policy already has some requirements here, in section 3.1.3, mostly

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

On 2017-04-12 11:47, Gervase Markham wrote: "If the certificate includes the id-kp-emailProtection extended key usage, it MUST include the Name Constraints X.509v3 extension with constraints on rfc822Name, with at least one name in permittedSubtrees." I think this change itself makes

Re: Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

On 12/04/2017 11:47, Gervase Markham wrote: There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what was not. The policy already has some requirements here, in section 3.1.3, mostly

Re: Policy 2.5 Proposal: Require qualified auditors unless agreed in advance

On 12/04/2017 11:47, Gervase Markham wrote: Way back when, Mozilla wrote some requirements for auditors which were more liberal than "be officially licensed by the relevant audit scheme". This was partly because organizations like CACert, who were at the time pondering applying for inclusion,

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

Section 5.3.1 of policy 2.4.1 defines what it means to be technically constrained for email sub-CAs (those with id-kp-emailProtection). It says: "If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or

Policy 2.5 Proposal: Expand requirements about what an Audit Statement must include

There are some items that it would be very helpful for auditors to state in their public-facing audit documentation so that we can be clear about what was covered and what was not. The policy already has some requirements here, in section 3.1.3, mostly relating to dates. The proposal is to add

Policy 2.5 Proposal: Require qualified auditors unless agreed in advance

Way back when, Mozilla wrote some requirements for auditors which were more liberal than "be officially licensed by the relevant audit scheme". This was partly because organizations like CACert, who were at the time pondering applying for inclusion, might need to use unofficially-qualified

Re: Symantec Issues doc updated

On 11/04/17 23:07, Jakob Bohm wrote: > Please consider the fact that this is Easter week, and most of the > industry, including many people (on both the Browser and Symantec sides > of the process) are likely to be unavailable for precisely this week of > the entire year. > > In general, sending

Re: Symantec Response L

On 11/04/17 22:08, Eric Mill wrote: > I'll leave it to others to opine on the severity of the mistake and the > quality of the response, but I do want to at least properly communicate the > impact. Thank you. I have updated my write-up for Issue L. Gerv

Re: Next CA Communication

Hi Doug, Kathleen is unavailable this week, so I'll try and answer. (This might have been better as a new top-level post, though...) On 11/04/17 21:14, Doug Beattie wrote: > This is my understanding: > > - Under policy 2.3 a CA that is technically > constrained with EKU set to only secure email

Re: Symantec Response B

On 2017-04-11 17:54, Ryan Sleevi wrote: On Tue, Apr 11, 2017 at 11:44 AM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: The reply indicated that it was a non-browser application. So I understand that a browser should never see that certificate. There's