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. 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 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 From: Wayne Thayer <wtha...@mozilla.com> Sent: Thursday, January 17, 2019 12:55 AM To: Ryan Sleevi <r...@sleevi.com> Cc: Grabowski Piotr <piotr.grabow...@kir.pl>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Odp.: Odp.: Odp.: 46 Certificates issued with BR violations (KIR) 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 <r...@sleevi.com<mailto:r...@sleevi.com>> 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 <piotr.grabow...@kir.pl<mailto:piotr.grabow...@kir.pl>> 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 <wtha...@mozilla.com<mailto:wtha...@mozilla.com>> Sent: Wednesday, January 09, 2019 9:52 PM To: Grabowski Piotr <piotr.grabow...@kir.pl<mailto:piotr.grabow...@kir.pl>> Cc: r...@sleevi.com<mailto:r...@sleevi.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>> 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 <piotr.grabow...@kir.pl<mailto:piotr.grabow...@kir.pl>> wrote: Hello, My comments in blue. ________________________________ Od: Ryan Sleevi <r...@sleevi.com<mailto:r...@sleevi.com>> 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 <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> 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. [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. [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. [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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
