Re: Policy 2.7 Proposal: Require EKUs in End-Entity Certificates
Brian, I think we are in agreement that this isn't a desirable addition to our policy. On Mon, Apr 1, 2019 at 5:36 PM Brian Smith via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> > wrote: > > Here when you say "require EKUs," you mean that you are proposing that > software that uses Mozilla's trust store must be modified to reject > end-entity certificates that do not contain the EKU extension, if the > certificate chains up to the roots in Mozilla's program, right? That would be a logical goal, but I was only contemplating a policy requirement. If so, how > would one implement the "chain[s] up to roots in our program" check? What's > the algorithm? Is that actually well-defined? > > My starting proposal would be to reject all EE certs issued after a certain future date that don't include EKU(s), or that assert anyEKU. If your point is that it's not so simple and that this will break things, I suspect that you are correct. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Audit Reminders for Intermediate Certs
All, CCADB sends email on the first Tuesday of each month to CAs with outdated audit statements in their intermediate cert records. An audit statement is determined to be outdated when its Audit Period End Date is older than 1 year + 3 months. https://wiki.mozilla.org/CA/Email_templates#Outdated_Audit_Statements_for_Intermediate_Certificates Below is the summary of the email that was sent today. Kathleen Forwarded Message Subject: Summary of April 2019 Outdated Audit Statements for Intermediate Certs Date: Tue, 2 Apr 2019 14:00:24 + (GMT) CA Owner: Government of The Netherlands, PKIoverheid (Logius) - Certificate Name: MinIenW PKIoverheid Organisatie Services CA - G3 SHA-256 Fingerprint: 16C94A8CCC15C983825B5BD3F2DC68D694C8A320F2328ECD8C9CA57DE51DA0E5 Standard Audit Period End Date (mm/dd/): 11/15/2017 - Certificate Name: MinIenW PKIoverheid Organisatie Persoon CA - G3 SHA-256 Fingerprint: 0664F1D1A7355700201D2F4431DC43B0BCEAB129A8CABFD4ED87D04341EF Standard Audit Period End Date (mm/dd/): 11/15/2017 - Certificate Name: MinIenM Organisatie CA - G2 SHA-256 Fingerprint: BDD191FD3B4AC34B4D2F62EFAFBD07CEAB6581BCFE6C129F5916F1892FBD5394 Standard Audit Period End Date (mm/dd/): 11/15/2017 - Certificate Name: MinIenM Autonome Apparaten CA - G2 SHA-256 Fingerprint: 3B011284D8EBE902841CEC48F9D7F18BEF71BA404835717D5D2BEF5655710793 Standard Audit Period End Date (mm/dd/): 11/15/2017 CA Owner: AC Camerfirma, S.A. - Certificate Name: InfoCert Organization Validation CA 3 SHA-256 Fingerprint: 247A6D807FF164031E0EB22CA85DE329A3A4E6603DBC6203F0C6E282A9C9EA84 Standard Audit Period End Date (mm/dd/): 12/06/2017 BR Audit Period End Date (mm/dd/): 12/06/2017 - Certificate Name: Intesa Sanpaolo Organization Validation CA SHA-256 Fingerprint: 27CDD699DE15EE88A05BB10ED9DF2FC5E4CA25B5FDD42988963A38EC8940D55A Standard Audit Period End Date (mm/dd/): 12/07/2017 BR Audit Period End Date (mm/dd/): 12/07/2017 - Certificate Name: MULTICERT SSL Certification Authority 001 SHA-256 Fingerprint: 06A57D1CD5879FBA2135610DD8D725CC268D2A6DE8A463D424C4B9DA89848696 Standard Audit Period End Date (mm/dd/): 12/19/2017 BR Audit Period End Date (mm/dd/): 12/19/2017 CA Owner: DigiCert - Certificate Name: ABN AMRO CA - G2 SHA-256 Fingerprint: AF6BFC9FF646FA900FEA0D79B89932304E27F84CC9E261BDE52B0EC04CF5AD85 Standard Audit Period End Date (mm/dd/): 05/24/2017 - Certificate Name: ABN AMRO CA - G2 SHA-256 Fingerprint: B91AF4B7FFC8DB435304212030724BECB2F23686552149FD671339C9528A65F9 Standard Audit Period End Date (mm/dd/): 05/24/2017 - Certificate Name: ABN AMRO Test CA - G2 SHA-256 Fingerprint: 52D90CEF761E2458A8B51638EF0A0513584EBA986E740C573AD2A73882818EE9 Standard Audit Period End Date (mm/dd/): 05/24/2017 - Certificate Name: Philips Extranet CA - G4 SHA-256 Fingerprint: E20AFEA72530C529D4046852144A267337221C5BE303528C07EF640BCAD6F091 Standard Audit Period End Date (mm/dd/): 07/22/2017 - Certificate Name: Shell Information Technology International CA - G3 SHA-256 Fingerprint: 91603DADB54CBCDEDD43805EA7A272EB31DF8444775064A01821C2B650890DCE Standard Audit Period End Date (mm/dd/): 07/22/2017 Comment: Incident Report for these outdated audit statements https://bugzilla.mozilla.org/show_bug.cgi?id=1539296 CA Owner: Entrust - Certificate Name: LAWtrust2048 CA2 SHA-256 Fingerprint: 4957DED341054641139CBAB3B96006545D094D449590FB08AE9A78D05A40BD83 Standard Audit Period End Date (mm/dd/): 12/31/2017 CA Owner: QuoVadis - Certificate Name: VR IDENT SSL CA 2016 SHA-256 Fingerprint: FD3E44280C8DCBE8CF8CF55511E0669C8537945DA1FA7468C0EA52B686DD5B68 Standard Audit Period End Date (mm/dd/): 12/31/2017 BR Audit Period End Date (mm/dd/): 12/31/2017 - Certificate Name: VR IDENT EV SSL CA 2016 SHA-256 Fingerprint: 55B0CD2CCAD18E25977D906DAC9FA8B8643D7A258E7B3837F1157A13AC19D187 Standard Audit Period End Date (mm/dd/): 12/31/2017 BR Audit Period End Date (mm/dd/): 12/31/2017 EV SSL Audit Period End Date (mm/dd/): 12/31/2017 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
SwissSign: Error in OrganisationIdentifier in signature/seal certificate
The following incident report is also posted in Bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1541064 Incident Report 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. An unusual organisationIdentifier for an Austrian entity was detected within an end-user certificate for an electronic signature/seal (no SSL certificate) in the internal review cycle and reported for further evaluation to the compliance function. 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. Timeline of incident handling - 29.03.2019, 17:06 CET report by an internal employee - 01.04.2019, ~10:00 CEST Compliance team double checks with the Certificate Authority Manager the reported certificate - 01.04.2019, 14:11 CEST Compliance team informs TÜV Austria (SwissSign Auditor) of a possible noncompliance (via e-mail). - 01.04.2019, -16:00 CEST Compliance team reviews the Austrian laws and registration number practices. => confirmation of a misissuance because of form factor - 01.04.2019, 16:00 CEST risk evaluation for community and customer => low risk rating - 02.04.2019, 09:00 - 10:15 CEST Compliance team reviews the customer application together with the operationally responsible team => evaluation of reason of mistake - 02.04.2019, 11:00 CEST Compliance team has a conference call with TÜV Austria to confirm the misissuance because of the form factor. - 02.04.2019, 13:15 CEST Documentation of the incident report - 02.04.2019, 15:00 CEST Order for revocation and establishing contacts with the customer - 02.04.2019, 16:30 CEST Publishing incident report in moz.dev.security.policy and Bugzilla 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. Already in February 2019 and independent from this report SwissSign decided because of business-reasons to stop issuing seal certificates for non-Swiss entities. (see below why we still issue seals for Swiss entities) 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. As of today, only one seals is affected. Further inspections are ongoing 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. The following signature/seal certificate (not SSL) is affected: Issuing CA: SwissSign CH Person Platinum CA 2017 - G22 Serial number: 31:ab:70:1b:f4:a2:89:ad:b7:91:92:57:c4:f2:f4:ed SHA2 fingerprint: 60:30:91:32:16:DE:24:F1:06:32:F5:BA:F1:61:0F:93:BD:E3:F8:5F:02:E0:82:50:46:A1:90:40:EE:5A:87:1D 6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now. Our customer is based in Austria. The reason for revocation is that a space was added to the organisationIdentifier. The organisationIdentifier in Austria has the following structure "NTRAT-" followed by the official registration number (in this case the Austrian Firmenbuchnummer) which consists of 6 digits (e.g. NTRAT-123456). Sometimes this number is followed by a check digit in form of a letter (e.g. "NTRAT-123456a"). Based on our current research both alternatives are equal and are used in official matters. The mistake was introduced as the information provided by the customer included a space after the hyphen (NTRAT- 123456a). The RAO checklists at that time included that the Firmenbuchnummer matches the official registration. This was the case because: - if you enter the number in the search engine you receive the correct customer - if you enter the customer's name you receive the correct number. Looking back the checklist should have included a checkpoint saying: "For Austrian entities the form of an organisationIdentifier MUST follow the structure "NTRAT-123456a"." Additional remediation is not needed as we stopped issuing seals (based on ZertES the Swiss Signature law) for non-Swiss entities (Feb 2019). For Swiss entities the space would have been detected as the checklist has more details and the people doing the checks know exactly what to expect. Should we decide to start issuing seals for the European jurisdiction we will create detailed checklists for different European nations based on
