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> wrote: > Hello, > > My comments in blue. > > > ------------------------------ > *Od:* Ryan Sleevi <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> 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. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
