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
> 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
https://lists.mozilla.org/listinfo/dev-securit
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
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 b
To me, the most noticable difference between how Google and Mozilla can take
action is with regards to exisiting certs. As proposed, Google has a really
neat timeline to get rid of Symantec's questionable legacy stuff quickly and
effectively. (Legacy stuff which we - and arguably Symantec themse
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 sp
On Monday, May 22, 2017 at 4:46:16 PM UTC, Gervase Markham wrote:
> On 21/05/17 19:37, userwithuid wrote:
> > With the new proposal, the "minimal disruption" solution for Firefox
> > will require keeping the legacy stuff around for another 3.5-4 years
> > and better solutions will now be a lot hard
For completeness, same for EV: https://crt.sh/?cn=ev&icaid=46855
Looks like some poor soul has been experimenting with test certificates for 3
weeks now, but has yet to succeed in issuing one that isn't violating the BRs...
___
dev-security-policy maili
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 u
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
imple
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 in
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, CNN
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 interm
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 miss
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 Star
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
[4
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 t
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 reason to be confident that a cross-signed
18 matches
Mail list logo