Hello Piotr, On Thu, Jan 17, 2019 at 6:23 AM Grabowski Piotr <[email protected]> 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. > Regards , > > > Piotr Grabowski > Linia biznesowa podpis elektroniczny > Krajowa Izba Rozliczeniowa S.A. > ul. rtm. W. Pileckiego 65 > 02-781 Warszawa > > Tel. +48 22 545 56 76 > > Tel. +48 507 024 083 > > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
