On Tue, Oct 9, 2018 at 5:30 AM Grabowski Piotr <[email protected]> wrote:
> Hello Wayne, > > Please find our comments below: > > > So far the process for modifying policy templates was controlled by only > one person at the moment. Although these persons > have an extensive experience in PKI and preparing certificate templates > and in common daily duties they work with serveral CA's and with hundreds > of templates and it was the first (and we hope the last) time > that something was misconfigured . This incident showed us that this > process should be definitely changed and that's why practicing due care > we are updating remediation steps or plan for: > > 1. Reviewed all certificate policy templates for ensuring that all of them > are BR comliant. /done > 2. All the certificates owners were contacted and agreed on issuance new > BR compliant certificates in time convenient for them, preferably not later > than by the end of this year and revocation current ones. /done > 3. Added procedural step for periodic certificate policy templates > validation. /done > > 4. Implement dual CAO control for modifying policy template which requires > the presence of 2 CAO's (Certification Authority Operators) /done > 5. CAO audit logs will be daily scanned by system Auditor for policy > change events and comapared if they match events from point 4) /done > 6. Implement pre-issuance linting - we have sent request, *urgent need* > to our PKI software vendor about delivery this functionality. > If we know the timeframe we will update this report. > > Do you think it is a sufficient response to incident? > I do appreciate your prompt response, but #4 in particular strikes me as an inadequate quick fix lacking any plan to make a concerted effort to learn from this mistake. - Is the new dual control process documented in a manner that will be auditable by your external auditors? - How is version control maintained for policy templates? - Despite the review, is it possible for one malicious employee to modify a policy template by themselves? If not, why not? - 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? - Why, despite the numerous misissuances documented on this list, has KIR not even begun the process of implementing pre-issuance linting until now? - 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. Also, please respond to Ryan's email questioning how this happened. - Wayne > > > > Best Reagrds > Piotr Grabowski > ------------------------------ > *Od:* Wayne Thayer <[email protected]> > *Wysłane:* poniedziałek, 8 października 2018 19:13:46 > *Do:* Grabowski Piotr > *DW:* mozilla-dev-security-policy > *Temat:* Re: 46 Certificates issued with BR violations (KIR) > > Thank you for the incident report. I have posted it to the bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1495497 > > On Mon, Oct 8, 2018 at 8:25 AM piotr.grabowski--- via dev-security-policy < > [email protected]> wrote: > >> Here's the incident report: >> >> 1. How your CA first became aware of the problem (e.g. via a problem >> report submitted to your Problem Reporting Mechanism, via a >> >> discussion in mozilla.dev.security.policy, or via a Bugzilla bug), and >> the date. >> >> Email from Wayne Thayer Oct 1, 2018 >> >> 2. A timeline of the actions your CA took in response. >> >> A. Oct 2, 2018 - Investigation began. >> B. Oct 4, 2018 - Found impacted certificate policy templates. >> C Oct 4, 2018 - All the certificates owners were contacted and agreed on >> issuance new BR compliant certificates in time convenient for them, >> preferably not later than by the end of this year and revocation >> current ones. >> D. Oct 8, 2018 - Fixed impacted certificate policy templates. >> E. Oct 8, 2018 - This disclosure. >> >> Ongoing: >> F. Replacement of impacted certificates >> G. Training of periodic certificate policy templates validation. >> >> 3. Confirmation that your CA has stopped issuing TLS/SSL certificates >> with the problem. >> >> Confirmed. >> >> 4. A summary of the problematic certificates. For each problem: number >> of certs, and the date the first and last certs with that problem >> >> were issued. >> >> There are 46 certificates. The certificates were issued between Feb 20, >> 2017 and Sep 25, 2018. >> >> 5. The complete certificate data for the problematic certificates. The >> recommended way to provide this is to ensure each certificate is >> >> logged to CT and then list the fingerprints or crt.sh IDs, either in the >> report or as an attached spreadsheet, with one list per distinct >> problem. >> >> Added as attachment >> >> https://crt.sh/?caid=15985&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 >> >> 6. Explanation about how and why the mistakes were made or bugs >> introduced, and how they avoided detection until now. >> >> The the incident concerns 46 certificates in the vast majority issued on >> KIR S.A. internal system purposes. >> The root cause of this issue was human error in certificate policy >> templates. >> >> "Human error" is not a sufficient response to this questions. Please > describe the process in place for modifying policy templates and how it > failed to catch this problem. > >> >> Remediation items: >> >> 1. Reviewed all certificate policy templates for ensuring that all of >> them are BR comliant. >> 2. All the certificates owners were contacted and agreed on issuance new >> BR compliant certificates in time convenient for them, preferably not later >> than by the end of this year and revocation current ones. >> 3. Added procedural step for periodic certificate policy templates >> validation. >> >> None of these remediation items will prevent future problems of this > nature. How will you improve your processes to prevent future misissuance? > > I assume that KIR S.A. has not implemented pre-issuance linting. Why not? > Is there a plan to implement pre-issuance linting? When? > >> >> We have by the way question about error: ERROR: The 'Organization Name' >> field of the subject MUST be less than 64 characters. >> According to https://www.ietf.org/rfc/rfc5280.txt and the note from this >> RFC 'ub-organization-name INTEGER ::= 64. For UTF8String or UniversalString >> at least four times the upper bound should be allowed. So what is the max >> length of this field for UTF8String? >> >> Page 113 of RFC 5280 limits the length of the field to 64 characters > regardless of the data type: > > -- Naming attributes of type X520OrganizationName: > -- X520OrganizationName ::= > -- DirectoryName (SIZE (1..ub-organization-name)) > -- > -- Expanded to avoid parameterized type: > X520OrganizationName ::= CHOICE { > teletexString TeletexString > (SIZE (1..ub-organization-name)), > printableString PrintableString > (SIZE (1..ub-organization-name)), > universalString UniversalString > (SIZE (1..ub-organization-name)), > utf8String UTF8String > (SIZE (1..ub-organization-name)), > bmpString BMPString > (SIZE (1..ub-organization-name)) } > > > [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
