Re: Symantec Test Cert Misissuance Incident

On 15/10/15 10:54, Rob Stradling wrote: > Rick, your report [1] states that... > >"...the certificates never left Symantec's secure test labs or the A charitable reading of this might be "the private keys never left...". But yes, it might help to have more details on what exactly is being

A pragmatic solution for the S/MIME trust bit

The earlier comments on this list have shown that S/MIME is in active use (e.g. in communication between different academic instutions), and that a decision to remove the S/MIME trust bit from the Mozilla CA list would mean a functional regression for those users. In my opinion, the discussion

Re: Symantec Test Cert Misissuance Incident

On 15/10/15 00:04, Rick Andrews wrote: On Tuesday, October 13, 2015 at 5:16:10 PM UTC-7, Charles Reiss wrote: This list of test certs for owned domains contains an entry for a cert with serial number 0xc222a issued by RapidSSL CA, valid from 05/18/2013 22:27:16 GMT to 06/20/2015 13:57:13 GMT

Re: Symantec Test Cert Misissuance Incident

Rick, your report [1] states that... "...the certificates never left Symantec's secure test labs or the QA test machine, and they were never visible to any end user... One of these test certificates with a CN=www.google.com was an Extended Validation (EV) test certificate and was

Re: Symantec Test Cert Misissuance Incident

On 14/10/15 18:16, Gervase Markham wrote: On 14/10/15 13:47, Rob Stradling wrote: (There are actually 187 rows, but 3 certs are counted twice) And that's not perhaps because one copy is with a CT poison extension, and the other is with an SCT? That's extremely unlikely. None of those 3 are

Re: Policy Update Proposal -- Remove Email Trust Bit

On Tue, Oct 13, 2015 at 5:04 AM, Kathleen Wilson wrote: > I believe that such a resource commitment would satisfy all of the > arguments against the Email trust bit that Ryan so eloquently summarized. > [3] > > Is this a fair assessment? > > Is there anything else that

Re: Policy Update Proposal -- Align with RFC 3647 now

Ryan Sleevi wrote: > On Thu, October 15, 2015 12:30 pm, Kathleen Wilson wrote: > > It was previously suggested[1] that we align Mozilla's CA Certificate > > Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with > > Mozilla's policy, as well as

Re: SECOM Request for EV Treatment

2015年8月26日水曜日 4時29分37秒 UTC+9 Ryan Sleevi: > On Wed, August 5, 2015 2:51 pm, Kathleen Wilson wrote: > > SECOM has applied to enable EV treatment for the "Security Communication > > RootCA2" root certificate that was included in NSS via Bugzilla Bug > > #527419. > > > > SECOM is a Japanese

Re: Policy Update Proposal: Remove Code Signing Trust Bit

All, Thank you for your patience throughout this long discussion. I appreciate all of your thoughtful and constructive input. I feel confident now that we should do the following: 1) Remove reference to the code signing trust bit from version 2.3 of Mozilla's CA Certificate Policy. 2) When

Policy Update Proposal -- Align with RFC 3647 now

All, It was previously suggested[1] that we align Mozilla's CA Certificate Policy to RFC 3647, so CAs can compare their CP/CPS side-by-side with Mozilla's policy, as well as the BRs and audit criteria (such as the forthcoming ETSI 319 411 series). I responded by postponing that work to a

Re: A pragmatic solution for the S/MIME trust bit

We are indeed asking for: (1) A one time effort to define/improve policy around the Email trust bit. (after doing some research, and understanding the situation) (2) Occasional refinement to the policy (3) Evaluate the requests to enable the Email trust bit (4) Improve the S/MIME code that folks

Re: A pragmatic solution for the S/MIME trust bit

I don't want to get bogged down into the discussion about *how* to write/update the policy regarding the Email trust bit at this point in time. If someone commits to take the time to do some research and become familiar with this area, their proposal for how to update policy regarding the

Re: Symantec Test Cert Misissuance Incident

Rob, Gerv - Thanks for your input. We are collating all feedback and are planning to publish another update soon. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy