在 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
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
> 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.
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
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
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
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
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,
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
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
>
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
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
> 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
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
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
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
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.
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
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
> 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
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
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:
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
26 matches
Mail list logo