Re: Discovering unlogged certificates in internet-wide scans

As an FYI only: We did review the one cert cited below for term length. The certificate was issued in 2013 before the current max term duration was defined. This cert is grandfathered in and does not require revocation. In May of this year it expires. regards, Daymion On Sunday, April 1,

Re: Audits for new subCAs

On Fri, Apr 6, 2018 at 3:09 PM, Peter Bowen wrote: > > A CP is an optional document and may be maintained by an entity other > than the CA. For example there may be a common policy that applies to > all CAs that have a path to a certain anchor. So including the CA > list in

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/04/2018 18:55, Wayne Thayer wrote: > >> On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos >> wrote: >> >> My proposal is "CAs MUST NOT distribute or

c=US policy layer in development

https://groups.google.com/forum/#!forum/cus-policy-layer ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Getting back to the earlier question about email certificates, I am now of the opinion that we should limit the scope of this policy update to TLS certificates. The current language for email certificates isn't clear and any attempt to fix it requires us to answer the bigger question of "under

c=US policy layer in development

If Mozilla develops an open product, then why are some discussions unavailable to users even for reading? (I'm not sure that this will protect against the PRISM intelligence system inside Google groups, so you have secrets from random users?) ___