On 12/07/2017 16:47, Ryan Sleevi wrote:
On Wed, Jul 12, 2017 at 10:19 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
* Comodo re-issued certs with the same key. I wonder if there should be
a rule that once a key compromise event is known to the CA it
Hi Peter,
Thanks for your guesses.
Buy no those issues in our system.
Best Regards,
Richard
-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, July 14, 2017 8:55 AM
To: Richard Wang
Cc: r...@sleevi.com; Jonathan Rudenberg
Richard,
I can only guess what Ryan is talking about as the report wasn't sent
to this group, but it is possible that the system described could not
meet the Baseline Requirements, as the BRs do require certain system
designs. For example, two requirements are:
"Require that each individual in
Hi Ryan,
Thanks for your detail info.
But I still CAN NOT understand why you say and confirm that the new system
cannot and does not comply with BR before we start to use it.
We will do the BR audit soon.
Best Regards,
Richard
On 14 Jul 2017, at 00:50, Ryan Sleevi
In the description of the remediation of the vulnerabilities, aspects of
the design are shared, particularly in discussing remediation. These
aspects reveal design decisions that do not comply with the BRs, and are
significant enough to require re-design.
I agree that this can be difficult to
2017年7月10日月曜日 15時00分04秒 UTC+9 Richard Wang:
> Please note that the Mozilla requirement is:
>
> " 5. Provide auditor[3] attestation that a full security audit of the CA’s
> issuing infrastructure has been successfully completed. "
> " [3] The auditor must be an external company, and approved by
> You will fail #4. Because your system, as designed, cannot and does not
> comply with the Baseline Requirements.
Is there a design outline in the security audit as well? No one in the
community can judge either yours or WoSign's statement as this information is
not shared with us. I suggest
You will fail #4. Because your system, as designed, cannot and does not
comply with the Baseline Requirements.
As such, you will then
(4.1) Update new system, developing new code and new integrations
(4.2) Engage the auditor to come back on side
(4.3) Hope you get it right this time
(4.4)
Hi Ryan,
I really don't understand where the new system can't meet the BR, we don't use
the new system to issue one certificate, how it violate the BR?
Our step is:
(1) develop a new secure system in the new infrastructure, then do the new
system security audit, pass the security audit;
(2)
Richard,
That's great, but the system that passed the full security audit cannot
meet the BRs, you would have to change that system to meet the BRs, and
then that new system would no longer be what was audited.
I would encourage you to address the items in the order that Mozilla posed
them -
On Thu, Jul 13, 2017 at 7:07 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 12/07/17 15:47, Ryan Sleevi wrote:
> > One challenge to consider is how this is quantified. Obviously, if you
> > reported to Comodo the issue with the key, and then they
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
On 13/07/17 04:43, Matt Palmer wrote:
> Who should we contact at Cure 53? Or should we just use the "business
> enquiries" contact address on their website?
I doubt Cure53 would be able to tell you anything more than what has
been said in the released summary document.
Gerv
On 12/07/17 15:47, Ryan Sleevi wrote:
> One challenge to consider is how this is quantified. Obviously, if you
> reported to Comodo the issue with the key, and then they issued another
> certificate with that key, arguably that's something Comodo should have
> caught.
I'd say so.
> However, if
14 matches
Mail list logo