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
> TL
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 wrote:
> Thanks for taking a look. My understanding of Rapid7's methodology [1,
> 2] is that they knock on well-known ports. The services they emit data
>
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
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 l
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 b
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 that this proposal goes far enough.
Firs
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 clear
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 log
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 roots
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).
>
>
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. There's a reason why roots have 20-40 y
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"
>
-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 thinking
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 restri
-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
SC
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 propos
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 Symante
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
> th
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. (L
19 matches
Mail list logo