Piotr, I agree with Ryan and am awaiting your response to Ryan's questions. I am also awaiting an answer to why KIR did not report this misissuance.
- Wayne On Fri, Jan 11, 2019 at 10:28 AM Ryan Sleevi <[email protected]> wrote: > I don't think it's reasonable to push the problem to your CA software > vendor. > > If Verizon does not provide this support, what steps will your CA take? 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? > > 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. > > On Fri, Jan 11, 2019 at 3:50 AM Grabowski Piotr <[email protected]> > wrote: > >> Hello Wayne, >> >> Thank you for your email. >> >> I think it is still the same incident. In my opinion there is no need to >> create another thread. Let me explain how it happened. >> >> >> >> As I said in previous emails we have requested urgent need for pre-linting >> feature from Verizon just after the incident was reported. I have sent a few >> reminders >> >> and finally on 18th of December 2018 got a response : >> >> "The feature request of implementing pre-issuance linting was discussed with >> PM and development today. Our feeling is that UniCERT is policy-centric >> software and therefore the burden of ensuring that “misissuance” does not >> happen is on the implementer of the policies. To help with this, we provide >> registration policy templates in the Registration Policy Wizard and they >> ensure most of x509lint test. ", but the keyword here is *most.* >> >> We can not for example restrict the length of the field like >> organizationName to have no more than 64 characters. We can set it as >> mandatory or not. >> >> It is the only gap we have now in our policy templates. We tried to >> mitigate this risk putting the informational text on operators website and >> in the dedicated >> >> procedure to double check the orgranizationName text size when operator is >> filling up the form of certificate request but but this time he did not >> perform this check. The post-linting procedure officially came into a force >> on the 1st of January 2019 as a procedural step to check the certificate >> that was just issued so unfortunately this certificate was not encompassed >> by the procedure. The OCSP status is 'unknown' because the customer have not >> picked up the certificate yet. >> >> >> >> Anyway, I sent another email to Verizon that we need specific x509lint or >> zlint feature with fileld length validation so the case is in progress. >> >> Please belive me, we try to practice due care as much as we can but we are >> just one among many clients of Verizon and we don't have such a clout to >> >> force them to implement new feature in the timeline we propose. I have >> described in details our need and belive they will deliver the feature as >> soon as they can. >> >> >> >> We have already reinforced and made live our post-linting procedure to check >> not only certificate that was just issued but check wider range like this >> >> https://crt.sh/?caid=15985&opt=cablint,zlint,x509lint&minNotBefore=2019-01-01 >> >> >> >> TODO: >> >> - 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 >> >> >> >> >> >> 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 >> >> >> >> *From:* Wayne Thayer <[email protected]> >> *Sent:* Wednesday, January 09, 2019 9:52 PM >> *To:* Grabowski Piotr <[email protected]> >> *Cc:* [email protected]; mozilla-dev-security-policy < >> [email protected]> >> *Subject:* Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR >> violations (KIR) >> >> >> >> KIR recently misissued another (pre-)certificate with an organizationName >> field containing too many characters [1]. This is despite being given >> specific guidance earlier in this thread on the organizationName attribute >> [2]. I have requested a new incident report in the bug [3]. >> >> >> >> A pre-certificate was logged but the OCSP status is reported as >> "unknown", so I assume that KIR detected this prior to signing the >> certificate. If so, I find it particularly troubling that KIR decided not >> to report this, and that after 3 months they still have no commitment from >> their vendor to implement pre-issuance linting [4]. >> >> >> >> - Wayne >> >> >> >> [1] https://crt.sh/?id=1036631881&opt=zlint >> >> [2] >> https://groups.google.com/d/msg/mozilla.dev.security.policy/IRLlR1AJ0vA/daHgd-IXBAAJ >> >> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1495497 >> >> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1495497#c5 >> >> >> >> On Fri, Oct 12, 2018 at 8:16 AM Grabowski Piotr <[email protected]> >> wrote: >> >> Hello, >> >> My comments in blue. >> >> >> ------------------------------ >> >> *Od:* Ryan Sleevi <[email protected]> >> *Wysłane:* czwartek, 11 października 2018 04:53 >> *Do:* Grabowski Piotr >> *DW:* Wayne Thayer; mozilla-dev-security-policy >> *Temat:* Re: Odp.: Odp.: 46 Certificates issued with BR violations (KIR) >> >> >> >> >> >> On Wed, Oct 10, 2018 at 4:33 PM Grabowski Piotr via dev-security-policy < >> [email protected]> wrote: >> >> Hello Wayne, >> >> - Is the new dual control process documented in a manner that will be >> auditable by your external auditors? >> >> Yes, the new dual control process is already included in the document >> called instruction of the security of system Szafir (internal name of the >> PKI system) and it is one of the document that is presented to >> internal and external auditors. >> >> >> >> Has this been added to your CP/CPS? If not, why not? >> >> -in our CP/CPS we have already the statement that key functions require >> dual control >> >> >> >> Can you please detail the additional controls that were specified? >> >> >> >> - Despite the review, is it possible for one malicious employee to modify >> a policy template by themselves? If not, why not? >> >> It is impossible. CAO role is one of the most trusted role so it has to >> have physical access to datacenter room, dedicated domain >> credentials, smartcard (PIN) with certificate to login to CAO application >> module. >> >> >> >> This does not seem to describe why it is impossible. The description of >> controls here reads that it is possible for a CAO to do so, if malicious, >> and you merely trust the CAO to not be malicious. >> >> Yes, but you have in mind that the CAO roles are playing only by very big >> experience and experience (about 20 years) - these persons were building >> the system, so >> >> we can trust them. >> >> >> >> - Have you conducted an overall review of your practices looking for >> other areas where a human error can result in misissuance? If so, what >> did you find and how are you addressing it? >> >> Yes, we have conducted an overall review and have not found any other >> areas where a human error can result in misissuance. >> >> >> >> Put differently: Have you completed an examination of the controls in >> place to ensure that any and all configuration changes that may result in a >> change to the operation of the CA undergoes multi-party review prior to and >> following implementation, to ensure consistency with the CP and CPS? >> >> >> Are there any operations that may modify any state within the CA >> software, hardware, or operating environment that does not undergo >> multi-party review prior and following? >> >> >> >> If so, what are those operations. >> >> Every other key functions/operations require dual control. Here I mean >> all staring/ reconfiguration/ upgrade and so on. >> >> If not, what are the operations that you have considered and enumerated >> as requiring multi-party review prior to and following the modification? >> >> >> >> - Why, despite the numerous misissuances documented on this list, has KIR >> not even begun the process of implementing pre-issuance linting until now? >> >> We have started process of implementing pre-issuance linting just after >> your email pointing our misissuance. We have requested pre-issuance >> linting functionality/patch with high priority from Verizon. >> >> >> >> This does not answer the question. It states that you have begun the >> request, but it does not provide insight as to why you had not previously >> done so. >> >> >> >> - Why is KIR not performing post-issuance linting? This problem had been >> occurring for over a year and there are readily available tools ( >> https://crt.sh) that allow anyone to identify these problems. >> >> We will implement post-issuance linting as well. >> >> We were not aware about this misissuance. We have received the >> notification about misissuance in October this year and immediately started >> >> fixing the problem. So far no one was reporting to us that there is >> something wrong with any of our certificates. >> >> >> >> This indicates what you will do, but does not answer why you didn't do. >> Part of the post-mortem process is to understand what issues may have >> existed, given the readily available nature of the tool and the discussions >> on m.d.s.p. regarding other CAs. >> >> The same as above. Additionally we have contacted the customers and we >> are in the proccess of replacement of these certificates. >> >> >> >> For example, perhaps the CA did not have adequate staffing to ensure >> participation in m.d.s.p. Perhaps the CA team did not have adequate >> training to recognize the similarities and/or value in such. >> >> >> >> The expectations upon CAs will continue to increase, and the question is >> why did KIR S.A. not increase operational oversight in line with those >> increased expectations, which would have allowed better detection and >> prevention. It is positive to hear steps are being taken now to address it, >> but it's reasonable to question why steps weren't taken then, when this was >> a knowable and identified best practice and minimum expectation of CAs. >> >> KIR is subject to an annual audit of WebTrust compliance and so far the >> audit has not revealed any irregularities in the management of the CA. >> >> >> >> [image: logo] >> >> Krajowa Izba Rozliczeniowa S.A., zarejestrowana w Sądzie Rejonowym dla m. >> st. Warszawy, >> XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS >> 0000113064, >> NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony >> 5.445.000 zł >> >> >> >> Informacja zawarta w tej korespondencji jest przeznaczona tylko dla osoby >> lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i >> poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można >> kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. >> W przypadku otrzymania tej korespondencji przez pomyłkę, proszę powiadomić >> nadawcę za pomocą emaila zwrotnego i usunąć tę korespondencję (wraz z >> załącznikami) z Państwa systemu. >> >> The information contained in this transmission is intended only for the >> individual or entity to whom it is addressed. It may contain privileged and >> confidential information and if you are not an indicated recipient, you >> must not copy, distribute or take any action in reliance on it. If received >> in error, please notify the sender by return email and delete his >> transmission (and any attachments) from your system. >> >> >> [image: logo] >> >> Krajowa Izba Rozliczeniowa S.A., zarejestrowana w Sądzie Rejonowym dla m. >> st. Warszawy, >> XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod nr KRS >> 0000113064, >> NIP 526-030-05-17, REGON 012105474, kapitał zakładowy i wpłacony >> 5.445.000 zł >> >> >> Informacja zawarta w tej korespondencji jest przeznaczona tylko dla osoby >> lub jednostki, do której jest adresowana. Może ona zawierać zastrzeżone i >> poufne informacje i jeżeli to nie Państwo są wskazanym odbiorcą, nie można >> kopiować, rozpowszechniać lub podejmować żadnych czynności w oparciu o nią. >> W przypadku otrzymania tej korespondencji przez pomyłkę, proszę powiadomić >> nadawcę za pomocą emaila zwrotnego i usunąć tę korespondencję (wraz z >> załącznikami) z Państwa systemu. >> >> The information contained in this transmission is intended only for the >> individual or entity to whom it is addressed. It may contain privileged and >> confidential information and if you are not an indicated recipient, you >> must not copy, distribute or take any action in reliance on it. If received >> in error, please notify the sender by return email and delete his >> transmission (and any attachments) from your system. >> > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
