On Thursday, 11 May 2017 19:08:06 UTC+2, Gervase Markham wrote:
> On 11/05/17 13:02, wiz...@ida.net wrote:
> > That said, it is fair point that the plan should spell out what happens if
> > symantec does not cooperate.
>
> I think we should cross that bridge when we come to it, which I hope we
在 2017年5月11日星期四 UTC+8下午5:58:00,Rob Stradling写道:
> On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
>
> >> * CPS Appendix1: Certificate information of the publicly trusted CAs: Most
> >> of the listed CAs can't be found in crt.sh - it would be great to get them
> >> CT logged.
> >>
>
Cory, from your point of view is there interest in being able to tell Requests
"I want the no-compromises trust store" and accept a reduced compatibility in
exchange for knowing that you're a little safer ?
Right now, as a programmer I have three choices with Requests:
Verify=True: The default,
I think you left this a bit implicit Cory, so I figured it's worth spelling
out: the strength of Mozilla's CA program, as a tool for making the web
stronger, comes from having people using it, that's the carrot that forces
people to meet our standards (also the fact that as a transparent, root
prog
> On 11 May 2017, at 19:27, Gervase Markham wrote:
>
> On 11/05/17 18:05, Alex Gaynor wrote:
>> I don't think Cory's arguing against browsers making use of these types of
>> remediations, he just wants the non-browser clients to be able to
>> participate as well :-)
>
> Sure. I'm just heading o
On 11/05/17 18:05, Alex Gaynor wrote:
> I don't think Cory's arguing against browsers making use of these types of
> remediations, he just wants the non-browser clients to be able to
> participate as well :-)
Sure. I'm just heading off that argument at the pass :-)
Gerv
__
On 11/05/17 13:02, wiz...@ida.net wrote:
> That said, it is fair point that the plan should spell out what happens if
> symantec does not cooperate.
I think we should cross that bridge when we come to it, which I hope we
won't. Not that I'm not prepared to cross it, but there's no point
devising
On 11/05/17 12:46, Rob Stradling wrote:
> There's a "Created by" field (Username, Timestamp) and a "Last Modified
> By" field (Username, Timestamp) in the CCADB, but neither of these
> fields are currently provided in the public CSV reports that Mozilla
> publishes.
Rob: do you think you could enh
On Thu, May 11, 2017 at 1:03 PM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Cory,
>
> On 11/05/17 15:21, Cory Benfield wrote:
> > While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can
Hi Cory,
On 11/05/17 15:21, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily.
Unfortunately, this is not a good enough reason to remove graduate trust
proposals from our arsenal of pos
On Thu, May 11, 2017 at 11:57 AM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Ryan,
>
> I think you've correctly highlighted that there's a problem -- the Mozilla
> CA store is "designed" to be consumed from NSS, and CA-specific
> remediations are a part o
Ryan,
I think you've correctly highlighted that there's a problem -- the Mozilla
CA store is "designed" to be consumed from NSS, and CA-specific
remediations are a part of that (hash algorithms, maximum certificate
lifetimes, and any number of other important technical controls).
Unfortunately, w
But if you use the trust database without using NSS, you no longer fit into
any of the assumptions or security models with the discussions here on
m.d.s.p.
A good example of this would be EKU related misissuance. NSS, like
CryptoAPI and several other platforms, has for the past 15 or so years
enfo
On Thursday, May 11, 2017 at 3:21:41 PM UTC+1, Cory Benfield wrote:
> While I’m very supportive of this kind of remediation, it is not a
> remediation that non-browser implementations can follow very easily. For
> example, I run a downstream non-browser HTTP client[1] that by default uses a
> p
All,
While this ongoing discussion regarding Symantec is going on, I wanted to chime
in quickly to make a suggestion about graduated trust. Many of the proposals
that Mozilla, Google, and other teams running CA programs put forward in cases
of CA misbehaviour is to transition a CA from “trusted
Both sets had been publicly disclosed through affirmative publishing in the
repositories of the respective CAs--that's probably how your crawler found
them, because I don't believe they are issuing SSL/TLS certificates. I
thought I had disclosed the ones chaining to the DigiCert Orion Health
inter
> 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.
Symantec has demonstrated that they have no interested in engaging with the
Mozilla co
Possibly this is irrelevant, but I have some concerns on how Symantec, it seems
to me, is willfully mischaracterizing their certificate compliance issues in
their prepared remarks to their investors yesterday.[1]
It makes it sound as if there are some generic certificate industry changes
that a
Dear Steve and Rick,
This is an official communication from the Mozilla CA program requesting
Symantec's answers to the following questions by close of business on
Monday 15th May. Your answers will be posted in
mozilla.dev.security.policy if you don't put them there yourselves. Your
speedy attent
Symantec, in previous blog posts on their site, has indicated that they will
support their customers [1].
That said, it is fair point that the plan should spell out what happens if
symantec does not cooperate. It seems appropriate to have the plan do what it
says -- scheduled phase out of the o
On 11/05/17 12:28, Kurt Roeckx via dev-security-policy wrote:
On 2017-05-11 13:07, Rob Stradling wrote:
It would seem that DigiCert noticed these 19 intermediates appear on
https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep,
because they've all now been disclosed to the CCADB.
T
On 2017-05-11 13:07, Rob Stradling wrote:
It would seem that DigiCert noticed these 19 intermediates appear on
https://crt.sh/mozilla-disclosures#undisclosed whilst I was asleep,
because they've all now been disclosed to the CCADB.
They should've been disclosed some time ago, however.
Does the
Yesterday I knocked together a script that: scrapes a URL (or a list of
URLs) for certificate files; then attempts to build a trust chain (using
https://crt.sh/gen-add-chain) for each certificate found; then submits
to some CT logs any trust chains that crt.sh hasn't previously seen.
I've thro
> 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
On 11/05/17 10:42, wangsn1206--- via dev-security-policy wrote:
* CPS Appendix1: Certificate information of the publicly trusted CAs: Most
of the listed CAs can't be found in crt.sh - it would be great to get them
CT logged.
Already get CT logged for GDCA TrustAUTH R5 ROOT,and such operation c
Hi Andrew,
Thanks for the comments. Please check our following responses.
> * Please don't protect your PDFs for printing
>
We have removed the restrictions on the printing of the PDF documents and
re-uploaded them to the BUG, these documents are available at:
https://bug1128392.bmoattachments
On 10/05/17 18:12, userwithuid wrote:
> Limiting to 60 months could be done right now as a sanity check and shouldn't
> cause any problems, right?
https://bugzilla.mozilla.org/show_bug.cgi?id=908125 .
Gerv
___
dev-security-policy mailing list
dev-secu
27 matches
Mail list logo