This may be getting a bit ahead of the discussion, but...
The exact relationship between WoSign and StartCom seems relevant to how these
violations should be handled.
Whether browsers decide to distrust WoSign, require CTs for all/future certs,
take some other "probationary" decision, or do not
On Wednesday, September 7, 2016 at 7:00:54 AM UTC-4, Gervase Markham wrote:
> Hi Richard,
>
> On 07/09/16 11:06, Richard Wang wrote:
> > This discuss has been lasting two weeks, I think it is time to end
> > it, it doesn’t worth to waste everybody’s precious time.
>
> Unfortunately, I think we ma
at 6:10 AM EST (24 minutes after Gervase's post), WoSign's CEO Richard Wang
responded to this topic. However, it has not entered the Google Groups archive.
I am posting his response below for completeness, so that his post can be part
of the archive and not just the email thread:
On Friday, September 16, 2016 at 6:07:56 AM UTC-4, Richard Wang wrote:
> Hi Gerv,
>
> This is the final report:
> https://www.wosign.com/report/WoSign_Incident_Final_Report_09162016.pdf
>
> Please let me if you have any questions about the report, thanks.
>
>
> Best Regards,
>
> Richard Wang
v-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Vincent Lynch
__
Here is my understanding, according to the wording in GlobalSign's incident
report (
https://downloads.globalsign.com/acton/attachment/2674/f-06d2/1/-/-/-/-/globalsign-incident-report-13-oct-2016.pdf
):
-Revocation of the certificate was intended. GlobalSign writes: "In a
revocation exercise w
or
> any other string are High Risk Certificate Requests
> (HRCR). I could define HRCR as being those that contain domain names
> that contain mixed script characters as defined in UTS #39 section 5.1.
> "apple-id-2.com" is not mixed scrip
n revoke this cert.
>
>
> >Why? It works just fine over HTTP, too.
>
>
> >- Matt
> ___
>
>
> dev-security-policy mailing list
>
>
> dev-security-policy@lists.mozilla.org
>
>
> https://lists.mozilla
Hi David,
I am the author of the research discussed in that Bleeping Computer post..
Your post is a bit brief, so I'm not sure if you are just sharing news, or
wanted to discuss a certain aspect of this story or topic.
So I will just share some general thoughts:
1. The most important thing to
On Tuesday, March 28, 2017 at 11:08:08 PM UTC-4, uri...@gmail.com wrote:
> For what it's worth, this is the latest post on facebook from the researcher.
> https://www.facebook.com/cbyrneiv/posts/10155129935452436
>
> The private key storage issue sounds like a reseller tool, like
> https://www.the
>
> Finally, what have you actually done to address EV revocation? You clearly
> didn't bother to tell Commonwealth Bank:
>
> https://www.commbank.com.au/
>
> One of the largest banks in Australia that their EV status would evaporate
> in Chrome. So what did you do to inform your customers about th
facebook post, and the Symantec website), I haven't
> read anything on Twitter.
>
> Again, I obviously can't speak for others, but any confusion over the
> facts here could have been easily avoided had Symantec made a full public
> statement about the Chris Byrne vulnerability the moment that it no longer
> posed a threat
right or wrong?
>
> Peter.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Vincent Lynch
On Sunday, May 7, 2017 at 6:09:19 PM UTC-4, Rick Andrews wrote:
> I'm posting this on behalf of Symantec:
>
> We would like to update the community about our ongoing dialogue with Google.
>
>
> Following our May 4th post, senior executives at Google and Symantec
> established a new dialogue
ther
> moving parts, but as noted above, delay is to be avoided.)
>
> We may in parallel ask further questions of Symantec, and expect timely
> answers (as this is a baseline requirement for participation in our root
> program), but this process will not
___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
ists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Vincent Lynch
.
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Hi Gerv,
I interpreted your wording as meaning that Symantec will be publicly posting a
new document (presumably to this list or blink-dev). Is this accurate?
If so, do you (or anyone else at Mozilla, since your vacation has now started)
know when Symantec plans on doing so?
-Vincent
On Mond
e information with the validity period,
> since only certificates valid greater than nine months will be
> affected outside of their normal replacement cycle. From Mozilla
> Firefox’s Telemetry, we know that Symantec issued certificates
> are responsible for 42% o
c discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
For posterity, here is a link to a separate thread started by D-Trust
containing their response to this report:
https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/UnR98QjWQQs
-Vincent
___
dev-security-policy mailing list
dev-security-p
wiki.mozilla.org/CA/Communications#November_2018_CA_Communication_.28Underscores_in_dNSNames.29
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
--
Vinc
23 matches
Mail list logo
