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?
Best Reagrds
Piotr Grabowski
________________________________
Od: Wayne Thayer <wtha...@mozilla.com>
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
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
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)) }
[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
