On Tue, Sep 19, 2017 at 3:09 PM, Nick Lamb via dev-security-policy
> 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
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
Forgot the links:
Quoting Gerv from the latest StartCom thread :
"* 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
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
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
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
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
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
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
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
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
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
> https://bugzilla.mozilla.org/show_bug.cgi?id=908125 .
Wow, embarrassingly weak google-fu on my part... Sorry and thanks!
dev-security-policy mailing list
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. 
Now in practice, thanks to killing sha1, most of those legacy certs are
Mail list logo