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> 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)) } _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
