W dniu czwartek, 17 stycznia 2019 21:12:58 UTC+1 użytkownik Wayne Thayer napisał: > 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.
I have response from Verizon that they will send us a patch containing some pre-issuance linting features on 03/02. By the way I kindly inform you that I’m out of the office from 28/01 to 07/02 and will be responding to my emails when I return on 11/02. Regards Piotr Grabowski > > 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
