On 18/01/2019 19:21, piotr.grabow...@kir.pl wrote:
W dniu piątek, 18 stycznia 2019 18:44:23 UTC+1 użytkownik Jakob Bohm napisał:
On 17/01/2019 21:12, Wayne Thayer wrote:
Hello Piotr,
On Thu, Jan 17, 2019 at 6:23 AM Grabowski Piotr <piotr.grabow...@kir.pl>
wrote:
Hello Wayne,
I am very sorry for the delay. Please find below our answers to Ryan's
questions. Regarding the question why we didn't report this misissuance
of this 1 certificate as separate incident in my opinion it is still the
same incident. I can create new incident if you want me to. Taking into
account my email and Ryan's response I assumed it is not required to
create separate incident for misissuance of this 1 certificate.
I am not so concerned about creating a new bug and/or a new email thread.
My concern is that you did not report the new misissuance even though you
appear to have known about it. Why was it not reported as part of the
existing incident, and what is being done to ensure that future
misissuances - either in relation to existing or new incidents - are
promptly reported?
So our comments in blue:
I don't think it's reasonable to push the problem to your CA software
vendor.
- We are not pushing the problem to CA software vendor. I have just tried
to explain how it happened.
If Verizon does not provide this support, what steps will your CA take?
- We are almost sure that Verizon will provide at least policy field
validation for maximum field size which can be sufficient to eliminate
the last gap in our policy templates which in turn led us to misissuance
of this certificate. If Verizon will not provide this feature we will be
considering
usage of another UniCERT component - ARM plug-in - which analyzes
requests but this means custom development for us. It would be a big
change in many processes and the challange to preserve current security
state as well so this should be an absolute last resort.
If you know what those steps are, is there reason not to take them now? If
you do not know what those steps are, when will you know?
The main reason why we are not taking these steps now (changing processes
and custom development) is absolute conviction that the cost and the risk of
implementing them is much, much higher that the risk related with waiting
for that feature being delivered by vendor. Just to recall, now we have
the only gap which in the worst case can give us specific field in
certificate longer than RFC specifies. Of course we are practicing due care
and have put as much counter-measures as we can (procedure, labels above
the fields).
Your software is producing invalid and improper certificates. The
responsibility for that ultimately falls on the CA, and understanding what
steps the CA is taking to prevent that is critical. It appears that the
steps, today, rely on human factors. As the past year of incident reports
have shown, relying solely on human factors is not a reasonable practice.
-I agree entirely with you, that's why we will keep exerting pressure on
Verizon to deliver:
o Policy field size validation – in our opinion it is simple change request
and should be delivered ASAP.
o native x509lint or zlint feature
When can we expect an update from you on Verizon's response to your
request? If I was the customer, I would expect a prompt response from
Verizon.
Additional questions:
- Is this the same CA software that was used on Verizon's own CA or
SubCA, which had serious problem some time ago?
- Who else (besides KIR) is still using this software to run a public
CA?
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
Hello Jacob,
Could you give me the link to the incident with Verizon software you're talking
about?
There were a number of Verizon incident related messages on this
list/newsgroup from November 2016 to January 2017, all in connection
with Digicert taking over and cleaning up the Verizon CAs.
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
