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
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
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
ev-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
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
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
>
>
> 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
instrument the usage of CAs. Further, few public metrics exist
> for intersecting usage information with the validity period,
> since only certificates valid greater than nine months will be
> affected outside of their normal replacement cycle. From Mozilla
>
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
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
cussion 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
>
-
d 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 wait around for those answers.
>
_
> 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.mo
ip or control by applicant"), not a negative requirement ("domain
> must not have anything important on it").
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla
> >Why? It works just fine over HTTP, too.
>
>
> >- Matt
> ___
>
>
> dev-security-policy mailing list
>
>
> dev-security-policy@lists.mozilla.org
>
>
> https://lists.mozilla.org/listinfo/dev-security-pol
UTS #39 section 5.1.
> "apple-id-2.com" is not mixed script so it is not a HRCR based on this
> definition.
>
> Thanks,
> Peter
> ___
> 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
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
18 matches
Mail list logo
