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? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
