Re: FW: StartCom inclusion request: next steps

On Tue, Sep 19, 2017 at 3:09 PM, Nick Lamb via dev-security-policy wrote: > I have no doubt that this was obvious to people who have worked for a public > CA, but it wasn't obvious to me, so thank you for answering. I think these > answers give us good

Re: Old roots to new roots best practice?

On Monday, September 18, 2017 at 1:58:03 AM UTC, Ryan Sleevi wrote: > I agree, Gerv's remarks are a bit confusing with respect to the concern. > You are correct that the process of establishing a new root generally > involves the creation of a self-signed certificate, and then any > cross-signing

Re: Old roots to new roots best practice?

Forgot the links: [1] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/hNOJJrN6WfE [2] https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/RJHPWUd93xE/RqnC3brRBQAJ [3] https://crt.sh/?spkisha256=fbe3018031f9586bcbf41727e417b7d1c45c2f47f93be372a17b96b50757d5a2

Old roots to new roots best practice?

Quoting Gerv from the latest StartCom thread [1]: "* The key for their new root certificate was also used in a couple of intermediates (one revoked as it was done incorrectly - again, lack of testing!). While this is probably not a policy violation, it's not good practice." Everyone including

Re: Expired Certificates Listed by Certificate Manager

On Tuesday, August 15, 2017 at 12:32:01 PM UTC, Gervase Markham wrote: > OneCRL does not obsolete certdata.txt-based distrust because not > everyone checks OneCRL. While we can't add every cert in OneCRL to > certdata.txt, we should add the big dis-trusts to it. Do you think > there's anything

Re: StartCom cross-signs disclosed by Certinomis

On Friday, August 4, 2017 at 12:27:13 AM UTC, Kathleen Wilson wrote: > Along this line of discussion, I have not felt comfortable with StartCom's > current root inclusion request (bug #1381406), because Hanno raised a concern > about the private key used by the new root is also used by two

Re: Expired Certificates Listed by Certificate Manager

On Wednesday, July 26, 2017 at 12:55:06 AM UTC, David E. Ross wrote: > Under the Servers tab for Certificate Manager, I see several root > certificates whose expiration dates have passed. I believe these were > all marked untrusted at one time. For example, I see six DigiNotar > certificates,

Re: Final Decision by Google on Symantec

WRT to the deadlines: If the decision is to sync up, I think it's worth noting that Firefox probably needs to release 2-3 weeks after a Chrome "release date" to achieve this in practice. Why? Firefox updates take ~10days from release date to reach previous version numbers. Chrome _can_ do it

Re: An alternate perspective on Symantec

Inspired by David's message, 2 suggestions for the Symantec plan: 1. Mozilla - and ideally Google as well - should clearly and explicitly communicate in the official statement on this that the "new" Symantec will still be strictly monitored even after the current remediation plan has been

Re: Symantec response to Google proposal

On Tuesday, June 6, 2017 at 2:03:29 PM UTC, Gervase Markham wrote: > > 1) Scope of Distrust > > Google proposal: existing CT-logged certificates issued after 1st June > 2016 would continue to be trusted until expiry. > Symantec proposal: all CT-logged certificates should continue to be > trusted

Re: Google Plan for Symantec posted

On Sunday, May 21, 2017 at 11:31:54 PM UTC, Michael Casadevall wrote: > There's also a fair number of points dealing with who can sign and for > what while Symantec spins up the new roots (which the Google proposal > says a trusted third party CA signed by Symantec"). > > I'm against this point

Re: CA Problem Reporting Mechanisms

On Wednesday, May 17, 2017 at 11:24:54 AM UTC, Gervase Markham wrote: > Well, such contacts are normally per CA rather than per root. I guess we > could add it on the CA's entry. Tbh, I'm not really familiar with your salesforce setup, I was just using this as a stand-in for "place where CA can

Re: CA Problem Reporting Mechanisms

After skimming the responses and checking a few CAs, I'm starting to wonder: Wouldn't it be easier to just add another mandatory field to the CCADB (e.g. "revocation contact"), requiring $URL or $EMAIL via policy and just use that to provide a public list? It seems to me that most revocation

Re: Find a 5-year certificate

> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 . > > Gerv Wow, embarrassingly weak google-fu on my part... Sorry and thanks! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Find a 5-year certificate

In this context, I was wondering: Has there been a discussion yet on Firefox enforcing cert lifetime in code not just via policy? Most everything seems to be in place already due to EV, but DV doesn't have a limit atm. [0] Now in practice, thanks to killing sha1, most of those legacy certs are