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 and not
a management error, some topics do however reoccur below, but in the
context of management decisions ...
Thus, in the CPs linked to our old practices, we explicitly
specify that we allow ourselves to issue a certificate if we have
previously obtained the consent of the organization and this even if the
DNS CAA record had not yet been updated by the applicant.
13. Did or
Do you consider that this CPS was in line with the BRs and Mozilla policy?
14.
If so, can you expand on your reasoning, and if not, why did you consider it
appropriate to operate to a CPS that did not fully account for your
obligations under the BRs and Mozilla policy?
The
instructions given to the RA operators were initially aligned with this
commitment, however, given the few alerts encountered, the operators still
blocked the issue until the records were up-to-date and consistent. Thus,
except for a certificate that was issued in accordance with our CP / CPS,
all the others were subject to greater control than we had committed.
Nevertheless, in addition to the training and awareness operations carried
out regularly, following this incident, we sensitized and re-trained all
the staff of the RA on the practices and controls to be operated, and also
on the controls implemented automatically without possible bypass.
The problem does not relate to our training,
15.
That's certainly the sense I'm getting. It seems that the core problem is
that your organisation appears to take compliance with the BRs as something
of a "nice to have", rather than a "must have". This raises the question of
what other elements of the BRs you aren't adhering to, but just haven't
tripped over yet, which my questions were attempting to identify.
finally better than what was stated in our CP / CPS. The problem comes
from the fact that we operate several controls having the same purpose,
but whose methods differ because emanating from different requirements
standards.
16.
Based on what you've provided so far, I'm afraid I can't see how you come to
that conclusion. CAA records indicate consent to issue for a specific CA or
list of CAs given by the party in control of the DNS for a domain. Nothing
you've described appears to be equal to or a strict superset of that.
Additional questions that would be relevant to get answers for:
17. Which criteria were required under your old policy to override a CAA
failure? (Besides rechecking after a DNS change by the applicant)?
I realize these were only used once, but the incorrect criteria you
had instructed your validation officers to use would be interesting
to understand how this mistaken policy was created.
18. How many certificates were delayed until the customer changed their
CAA records?
19. How many certificates were not issued because CAA failed and was not
corrected by the applicant changing their DNS?
20. Have you informed CAB/F about the specific situations in questions
17 to 19 above.
21. Are there any other places where your CP / CPS do or did fall short
of the BR requirements?
22. Are there any places where your CP / CPS do or did fall short of
Mozilla requirements beyond the BRs? (This wasn't one, it was a BR).
23. Which validation controls listed in your CP / CPS are not fully
enforced by automated systems? (Your answers suggest at least one,
so make sure your answer is complete).
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public 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
