Re: Kamu SM: Information about non-compliant serial numbers
26 Mart 2019 Salı 19:19:24 UTC+3 tarihinde Wayne Thayer yazdı: > Melis: Thank you for this incident report. I have filed > https://bugzilla.mozilla.org/show_bug.cgi?id=1539190 and assigned it to you > to track this issue. > > Will you please have one of your colleagues add you as a Kamu SM contact in > CCADB? That will allow me to confirm that you are representing Kamu SM. > > - Wayne > > On Mon, Mar 25, 2019 at 7:16 AM Melis BALKAYA via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > As a preliminary note, Kamu SM would like to express that the only > > affected 2 certificates are the test certificates issued to our own domains > > in order to fulfill the related requirement of Mozilla Root Inclusion > > Request. > > > > 1. How your CA first became aware of the problem (e.g. via a problem > > report submitted to your Problem Reporting Mechanism, a discussion in > > mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and > > the time and date. > > > > While Mozilla root inclusion process of Kamu SM, we had noticed that our > > test certificates has serial number lower than 64 bits. Our system had been > > updated to generate serial numbers with greater than 64 bit entropy in > > 2017. > > > > We monitor mozilla.dev.security.policy group daily based and we became > > aware of the EJBCA problem about DarkMatter concerns on 2019-02-26. > > > > 2. A timeline of the actions your CA took in response. A timeline is a > > date-and-time-stamped sequence of all relevant events. This may include > > events before the incident was reported, such as when a particular > > requirement became applicable, or a document changed, or a bug was > > introduced, or an audit was done. > > > > 2017-02-03 Kamu SM has issued three test certificates which are valid, > > expired and revoked in order to fulfill the related Mozilla Root Inclusion > > process requirement. > > > > 2017-03-07 In CP/CPS reviewing for Mozilla Root Inclusion Request of Kamu > > SM, we had noticed that our random number generator was not generating > > serial numbers with 64-bit entropy. Then, we changed the procedure for > > generating serial numbers as greater than 64-bit entropy. Our “valid test > > SSL certificate” was renewed with such a serial number. We did not take an > > action for other two test certificates because one is revoked and the other > > is expired. > > > > 2019-02-26 We became aware of the EJBCA problem about DarkMatter concerns. > > > > 2019-03-08 We have informed software developer team about the raised > > issue. > > > > 2019-03-11 They checked all certificates issued by "CN=TUBITAK Kamu SM SSL > > Sertifika Hizmet Saglayicisi - Surum 1”. They came to the conclusion that > > none of the issued certificates other than the two test certificates > > mentioned above are affected by this issue. > > > > 3. Whether your CA has stopped, or has not yet stopped, issuing > > certificates with the problem. A statement that you have will be considered > > a pledge to the community; a statement that you have not requires an > > explanation. > > > > Since none of our customer certificates are affected by the serial number > > entropy problem, we have continued to issue SSL certificates. > > > > 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. > > > > 2017-02-03 Kamu SM has issued three test certificates which are valid, > > expired and revoked in order to fulfill the related Mozilla Root Inclusion > > process requirement. > > > > 2019-03-19 With the announcement of the list of CAs that have been > > noncompliant with BR 7.1, we have investigated that two test certificates > > that are issued in the process of the Mozilla root inclusion request are > > affected by this issue. > > > > 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. > > > > 2017-02-03 testsslrevoked.kamusm.gov.tr (0xbe64996b) > > https://crt.sh/?id=95903318 > > > > 2017-02-03 testsslexpired.kamusm.gov.tr (0x76cb4f6c) > > https://crt.sh/?id=95903322 > > > > 6. Explanation about how and why the mistakes were made or bugs > > introduced, and how they avoided detection until now. > > > > Our certificate issuance system has been updated before we have included > > Mozilla Root Store. > > > > 7. List of steps your CA is taking to resolve the situation and ensure > > such issuance will not be repeated in the future, accompanied with a > > timeline of when your CA expects to accomplish these things. > > > > Our affected test certificates were not valid since the beginning, and it > > is not allowed to issue a valid subscriber certificate which has a serial > > number lower than 64 bit in our
Re: Policy 2.7 Proposal: Clarify Point-in-Time Audit Language
I'm not sure whether it's necessary to indicate support, but since silence can sometimes be ambiguously interpreted: I support these changes and believe they achieve the desired outcome. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Policy 2.7 Proposal: Clarify Point-in-Time Audit Language
I'm [hopefully] beginning with a simple change that clarifies the language used for Point-in-Time (PiT) audits used in policy. Section 3.1.3 of our policy currently references a "point-in-time assessment", and section 8 uses the undefined abbreviation "PITRA", which stands for "point-in-time readiness assessment". A readiness assessment refers to an engagement between an auditor and a CA that does not produce a public audit report. It's clear that we want a PiT audit. The proposed changes are: https://github.com/mozilla/pkipolicy/compare/2.7@%7B03-21-19%7D...2.7 I will appreciate feedback from anyone who has concerns with these changes. - Wayne This is https://github.com/mozilla/pkipolicy/issues/151 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Next Root Store Policy Update
I've added a few more issues that were recently created to the list for 2.7: https://github.com/mozilla/pkipolicy/labels/2.7 176 - Clarify revocation requirements for S/MIME certs 175 - Forbidden Practices wiki page says email validation cannot be delegated to 3rd parties I plan to begin posting issues for discussion shortly. On Fri, Mar 8, 2019 at 2:12 PM Wayne Thayer wrote: > Later this month, I would like to begin discussing a number of proposed > changes to the Mozilla Root Store policy [1]. I have reviewed the list of > issues on GitHub and labeled the ones that I recommend discussing: > https://github.com/mozilla/pkipolicy/labels/2.7 They are: > > 173 - Strengthen requirement for newly included roots to meet all current > requirements > 172 - Update section 5.3 to include Policy Certification Authorities as an > exception to the mandatory EKU inclusion requirement > 171 - Require binding of CA certificates to CP/CPS > 170 - Clarify Section 5.1 about allowed ECDSA curve-hash pair > 169, 140 - Extend Section 8 to also encompass subordinate CAs > 168, 161, 158 - Require Incident Reports, move practices into policy > 163 - Require EKUs in end-entity certificates (S/MIME) > 162 - Require disclosure of CA software vendor/version in incident report > 159 - Clarify section 5.3.1 Technically Constrained > 152 - Add EV audit exception for policy constrained intermediates > 151 - Change PITRA to Point-in-Time assessment in section 8 > > I will appreciate any feedback on the proposed list of issues to discuss. > > I do recognize that the current DarkMatter discussions could result in the > need to add some additional items to this list. > > I have created a new branch for drafting these changes [1] and made one > commit that adds a bullet to the BR Conformance section informing the > reader that Mozilla policy has a more restrictive list of approved > algorithms [3] > > As we've done in the past, I plan to post individual issues for discussion > in small batches over the next few months, with the goal of finalizing > version 2.7 by June. > > - Wayne > > [1] > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > [2] https://github.com/mozilla/pkipolicy/blob/2.7/rootstore/policy.md > [3] https://github.com/mozilla/pkipolicy/issues/167 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New report: Intermediate CA Certificates with their own audit statements
Copy-paste correction: 2) Intermediate CA Certificates with their own audit statements (CSV) https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAuditsCSV On 3/27/19 11:50 AM, Kathleen Wilson wrote: All, Just FYI that we have added the following two reports to wiki.mozilla.org/CA/Intermediate_Certificates 1) Intermediate CA Certificates with their own audit statements (HTML) https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits 2) Intermediate CA Certificates with their own audit statements (CSV) https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV These reports are Filtered By: CA Owner/Certificate Record Type equals Intermediate Certificate AND Revocation Status equals Not Revoked AND Mozilla Root Status for the root cert equals Included,Change Requested AND Audits Same as Parent equals False AND Valid To (GMT) greater than TODAY AND Technically Constrained equals False I plan to add an "Audit Letter Validation (ALV)" button to the intermediate certificate records in the CCADB. Then I will add columns to these reports to indicate the ALV results and when the ALV was last run on the record. Thanks, Kathleen PS: There is already an Incident Report for the KPN outdated audit statements that you will notice in these reports. https://bugzilla.mozilla.org/show_bug.cgi?id=1539296 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
New report: Intermediate CA Certificates with their own audit statements
All, Just FYI that we have added the following two reports to wiki.mozilla.org/CA/Intermediate_Certificates 1) Intermediate CA Certificates with their own audit statements (HTML) https://ccadb-public.secure.force.com/mozilla/IntermediateCertsSeparateAudits 2) Intermediate CA Certificates with their own audit statements (CSV) https://ccadb-public.secure.force.com/mozilla/PublicIntermediateCertsRevokedWithPEMCSV These reports are Filtered By: CA Owner/Certificate Record Type equals Intermediate Certificate AND Revocation Status equals Not Revoked AND Mozilla Root Status for the root cert equals Included,Change Requested AND Audits Same as Parent equals False AND Valid To (GMT) greater than TODAY AND Technically Constrained equals False I plan to add an "Audit Letter Validation (ALV)" button to the intermediate certificate records in the CCADB. Then I will add columns to these reports to indicate the ALV results and when the ALV was last run on the record. Thanks, Kathleen PS: There is already an Incident Report for the KPN outdated audit statements that you will notice in these reports. https://bugzilla.mozilla.org/show_bug.cgi?id=1539296 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Buypass Incident Report - intermediate certificates noncompliant with BR 7.1
We do not intend to revoke the end-user certificates. We consider this to be a compliance issue for the CA certificates only. The CAs (i.e. the private keys) and end-user certificates issued from the CAs are not affected. Regards Mads -Original Message- From: dev-security-policy On Behalf Of Malcolm Doody via dev-security-policy Sent: onsdag 27. mars 2019 00:42 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Buypass Incident Report - intermediate certificates noncompliant with BR 7.1 Are you intending to revoke all of the end-user certificates issued from the non compliant certificates? If not, then can you state why? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
