Hello,
The decision was taken at one of our security committees where all changes and
developments that could impact the practices and compliance of our authority
are validated. This is why all the actors of these security committees have
been made aware of the incident and the fact that we
On 04/10/2018 19:40, Wayne Thayer wrote:
On Thu, Oct 4, 2018 at 9:48 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
(In reply to Matt Palmer in message-id
mailman.78.1538620059.2924.dev-security-pol...@lists.mozilla.org)
I seem to recall that the bad
On Thu, Oct 4, 2018 at 9:48 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I seem to recall that the bad practice was explicitly called out in
> their (old) CP/CPS, which was applicable at the time. Thus any similar
> misunderstanding should be
On Wed, Oct 3, 2018 at 7:27 PM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Oct 03, 2018 at 09:31:08AM -0700, Wayne Thayer wrote:
> > On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org>
On 04/10/2018 04:27, Matt Palmer wrote:
On Wed, Oct 03, 2018 at 09:31:08AM -0700, Wayne Thayer wrote:
On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
...
...
...
Alternately, if the BRs *are*, in fact, sufficiently clear in
On Wed, Oct 03, 2018 at 09:31:08AM -0700, Wayne Thayer wrote:
> On Mon, Oct 1, 2018 at 4:49 AM Matt Palmer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > Thank you for this clear statement of your validation interface design.
> > Unfortunately, this sounds like a
Hi Matt,
I appreciate your interest in getting to the root causes of this issue, and
the polite and professional manner in which you are asking questions.
However, I am concerned that this line of questioning seem to have reached
the limits of Certigna's analysis capabilities, and is thus
On Wed, Sep 26, 2018 at 07:36:57AM -0700, josselin.allemandou--- via
dev-security-policy wrote:
> Thank you for your exchanges. We hope that the additions below will answer
> your questions.
It appears that your response has removed most indications of what parts of
your message are my
Hello
Thank you for your exchanges. We hope that the additions below will answer your
questions.
Was the action required to manually override the CAA validation failure
different from what would be required if the CAA validation had succeeded?
Could an operator have just "clicked the same
On Sun, Sep 16, 2018 at 03:07:44PM -0700, josselin.allemandou--- via
dev-security-policy wrote:
> > 1. Can you explain in more detail the user experience of the RA interface
> > which was used to misissue this certificate? Specifically, did approval
> > of the issuance in the face of a CAA
Hello
Thank you all for your feedback for which we have tried to provide additional
information below. Know that if necessary, you will also find the description
of our practices through the following links:
• our CPS :
* Services CA :
Josselin: thank you for filing this incident report, and for your answers
to the questions being asked in this thread.
Please add the incident report to the related bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1485413
I will also ask you to answer the new questions that have been asked to
> The unqualified mention of "September 8" confused me at first, but it
> obviously refers to the "CAA Mandatory BR" taking effect on "September
> 8, 2017", thus the single misissuance probably happened between
> September 8, 2017 and when they changed the policy on August 31, 2018.
>
>
On 12/09/2018 14:51, RS Tyler Schroder wrote:
On Tuesday, September 11, 2018 at 3:34:45 AM UTC-4, josselin@gmail.com
wrote:
The audit of our previous CAA check practices ensured that the CA/B Forum
requirements were met except for a single certificate for which the CA was not
authorized
On Tuesday, September 11, 2018 at 3:34:45 AM UTC-4, josselin@gmail.com
wrote:
> The audit of our previous CAA check practices ensured that the CA/B Forum
> requirements were met except for a single certificate for which the CA was
> not authorized to issue according to the DNS CAA record.
>
I have numbered the new questions from 13 and up and added 7 more
questions at the end.
On 12/09/2018 05:11, Matt Palmer wrote:
On Tue, Sep 11, 2018 at 07:22:18AM -0700, josselin.allemandou--- via
dev-security-policy wrote:
Snipped the 12 questions that assumed this was an RA mistake
On Tue, Sep 11, 2018 at 07:22:18AM -0700, josselin.allemandou--- via
dev-security-policy wrote:
> It is important to remember that our CA is also subject to compliance with
> national standards (e.g. RGS) which are more stringent for some controls
> than ETSI standards or BRs. These standards
Hello,
Thank you for your contribution. We hope that the returns below will allow you
to better understand our past practices that led to the creation of this ticket.
It is important to remember that our CA is also subject to compliance with
national standards (e.g. RGS) which are more
On Tue, Sep 11, 2018 at 12:34:34AM -0700, josselin.allemandou--- via
dev-security-policy wrote:
> This failure is related to our old practices that led to a control of the
> DNS CAA records with automatic alerts for the Registration Officers, but
> the blocking of the certificate request was not
19 matches
Mail list logo
