Re: DarkMatter Concerns

I appreciate the ground work Fabio put into this thus far, and want to see further discussion on it. I think the safest way to quantity and frame the discussion is asking if a CA (or subCA) has a vested interest in surveillance, other business interest, or government ties which would put a CA to

Re: DEFCON Talk - Lost and Found Certificates

On 08/19/2018 12:56 PM, Eric Mill via dev-security-policy wrote: > On Thu, Aug 16, 2018 at 6:52 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> It seems that my response to this presentation has brought out the crowd >> of people who are constantly

Re: Fond Farewell to Gerv Markham

While I didn't know Gerv personally, I always respected his insight and knowledge I've gotten from years lurking on this list. He will be missed :/ Michael On 07/29/2018 12:23 PM, Kathleen Wilson via dev-security-policy wrote: Dear Fellow Mozillians, It is with deep sorrow that we share the

Re: Discovering unlogged certificates in internet-wide scans

On 03/31/2018 09:53 PM, Tim Smith wrote: > On Sat, Mar 31, 2018 at 6:28 PM, Michael Casadevall via > dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > Thanks for taking a look. My understanding of Rapid7's methodology [1, > 2] is that they knock o

Re: Discovering unlogged certificates in internet-wide scans

On 03/31/2018 06:14 PM, Tim Smith via dev-security-policy wrote: > Hi MDSP, > > I went looking for corpuses of certificates that may not have been > previously logged to CT and found some in the Rapid7 "More SSL" dataset, > which captures certificates from their scans of non-HTTPS ports for >

Re: Google Plan for Symantec posted

On 05/21/2017 02:37 PM, userwithuid wrote: > 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.

Re: Google Plan for Symantec posted

On 05/19/2017 05:43 PM, Kurt Roeckx wrote: > So I think we have a few categories of certificates: > - Those issued in the past, which can still be valid for up to 3 > years. I'm not sure when the last 5 year certificates are > supposed to expire, or if they all expired, but I don't think >

Re: Google Plan for Symantec posted

Comments inline. On 05/19/2017 05:10 PM, Jakob Bohm wrote: > Suggested trivial changes relative to the proposal for Mozilla use: > > 3. All non-expired Symantec issued certificates of any kind (including > SubCAs and revoked certificates) shall be CT logged as modified by #4 > below. All

Re: Symantec: Update

On 05/19/2017 10:25 AM, Gervase Markham wrote: > Embedding SCTs is not the only way SCTs can be delivered - they can come > in the SSL handshake or via OCSP. Requiring them to be embedded does > have the advantage that certificates now carry an unforgeable timestamp, > and it was something I

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/17/2017 05:04 AM, Kurt Roeckx wrote: > If the key is compromised, you can't rely on any date information > anymore, you need to revoke it completely and break things. > Won't that only be true in certificates without SCTs? Once you have a

Re: Configuring Graduated Trust for Non-Browser Consumption

On 05/16/2017 01:04 PM, Jakob Bohm wrote: > > Could you please point out where in certdata.txt the following are > expressed, as I couldn't find it in a quick scan: > > 1. The date restrictions on WoSign-issued certificates. > > 2. The EV trust bit for some CAs. > Not the OP, but WoSign

Re: Configuring Graduated Trust for Non-Browser Consumption

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/16/2017 11:10 AM, Peter Bowen wrote: > Jakob, > > What I think Ryan has been trying to express is his view that this > request is not possible. A *stable* data format is unable to > express future graduated trust rules. > I've been

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

On 05/16/2017 08:40 AM, Rob Stradling wrote: > On 16/05/17 13:24, Michael Casadevall via dev-security-policy wrote: > >> Just spitballing ideas here, but in Alex's case, part of me would be >> tempted to see if X509 could be extended with a new "CanIssueUntil" >&

Re: [FORGED] Re: Configuring Graduated Trust for Non-Browser Consumption

On 05/16/2017 06:05 AM, Peter Gutmann wrote: > Ryan Sleevi via dev-security-policy > writes: > > Unless someone has a means of managing frequent updates of the root > infrastructure (and there isn't one, or at least none that work), this will > never fly.

Re: Symantec: Update

On 05/16/2017 03:50 AM, Michael Casadevall wrote: > On 05/15/2017 06:05 PM, Jakob Bohm wrote: >> > > - A three-day grace period shall be in place from the issuance date of > a certificate to when it must be in the CT logs for validation reasons > (this is in line with other proposals here). > >

Re: Symantec: Update

On 05/15/2017 06:05 PM, Jakob Bohm wrote: > > Ok, that's much better. > Yay for reasonable courses of action. We'll see if it goes into the next proposal. >> I can see the point here, but I'm not sure I agree. Every time we keep >> digging, we keep finding more and more problems with these

Re: [EXT] Re: Draft further questions for Symantec

I took a stab at trying to grok this. I find I have more questions and a lot more concerns the more I read though. Please let me know if I'm not the only one having issues decoding the responses. Here's my first impressions: RA & EV: Were all the certificates issued by the RAs uploaded to a CT

Re: Symantec: Update

On 05/15/2017 09:32 AM, Jakob Bohm wrote: > This won't work for the *millions* of legitimate, not-misissued, > end certificates that were issued before Symantec began SCT > embedding (hopefully in the past) and haven't expired before such > an early deadline. > Sorry, I could have been more

Re: Symantec: Update

On 05/11/2017 09:53 AM, Jonathan Rudenberg via dev-security-policy wrote: > >> On May 10, 2017, at 11:52, Gervase Markham via dev-security-policy >> wrote: >> >> I would appreciate people's comments on the details of the current draft. > > I don’t think