Re: Policy 2.7 Proposal: Forbid Delegation of Email Validation for S/MIME Certificates
On 5/13/19 10:24 AM, Wayne Thayer wrote: The BRs forbid delegation of domain and IP address validation to third parties. However, the BRs don't forbid delegation of email address validation nor do they apply to S/MIME certificates. Delegation of email address validation is already addressed by Mozilla's Forbidden Practices [1] state: "Domain and Email validation are core requirements of the Mozilla's Root Store Policy and should always be incorporated into the issuing CA's procedures. Delegating this function to 3rd parties is not permitted." I propose that we move this statement (changing "the Mozilla's Root Store Policy" to "this policy") into policy section 2.2 "Validation Practices". This is https://github.com/mozilla/pkipolicy/issues/175 I will appreciate everyone's input on this proposal. - Wayne [1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Delegation_of_Domain_.2F_Email_Validation_to_Third_Parties All, As the person who filed the Github issue for this, I would like to provide some background and my opinion. Currently the 'Delegation of Domain / Email Validation to Third Parties' section of the 'Forbidden Practices' page says: "This is forbidden by the Baseline Requirements, section 1.3.2. Domain and Email validation are core requirements of the Mozilla's Root Store Policy and should always be incorporated into the issuing CA's procedures. Delegating this function to 3rd parties is not permitted." Based on the way that section is written, it appears that domain validation (and the BRs) was the primary consideration, and that the Email part of it was an afterthought, or added later. Historically, my attention has been focused on TLS certs, so it is possible that the ramifications of adding Email validation to this section was not fully thought through. I don't remember who added this email validation text or when, but I can tell you that when I review root inclusion requests I have only been concerned about making sure that domain validation is not being delegated to 3rd parties. It wasn't until a representative of a CA brought this to my attention that I realized that there has been a difference in text on this wiki page versus the rules I have been trying to enforce. That is when I filed the github issue. I propose that we can resolve this discrepancy for now by removing "/ Email Validation" from the title of the section and removing "and Email" from the contents of the section. Unless we believe there are significant security reasons to add our own S/MIME required/forbidden practices at this time, my preference is to wait for the CA/Browser Forum to create the S/MIME Working Group, and for that group to identify the S/MIME baseline requirements. Then we can add policy and required/forbidden practices based on the S/MIME BRs provided by that group. I do realize that my proposal is unfair to CAs who have been diligently following this section of this wiki page. Your diligence is appreciated, and your contributions to this discussion will also be appreciated. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Changes to ccadb.org site and report links
All, We've made the following changes to the ccadb.org site. 1) The general links providing data for all CAs and certs in the CCADB have been updated from "mozilla" to "ccadb". In particular the first three links in the General section on the Resources tab have been updated. https://ccadb.org/resources#general * All certs (root and intermediate) in CCADB (CSV) * List of CA problem reporting mechanisms (email, etc.) * List of CAA Identifiers The new links: http://ccadb-public.secure.force.com/ccadb/AllCertificateRecordsCSVFormat https://ccadb-public.secure.force.com/ccadb/AllProblemReportingMechanismsReport https://ccadb-public.secure.force.com/ccadb/AllCAAIdentifiersReport The old links still work, but please migrate to the new links at your convenience. 2) A new page has been added to the "For CAs" tab called "Request Access". This new page includes a link to a form that can be used for CAs to request access to the CCADB when they are in the root inclusion process for Mozilla's or Microsoft's programs. A submitted form creates a Lead in the CCADB that normally will be processed by me (for Mozilla) or Karina (for Microsoft). Once verified and approved, the Lead will generate the new CA Owner record and corresponding Primary Point of Contact. As always, I appreciate your thoughtful and constructive feedback on the CCADB. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: GlobalSign misissuance: 4 certificates with invalid CN
Hi Nick, I updated our Mozilla ticket this this info and I wanted to also supply it here because it answers your questions also https://bugzilla.mozilla.org/show_bug.cgi?id=1552586 Here is an update to this incident: 5/20: After further analysis of the issue, it was determined that the cause was not the V1 API in general, but that there was a missing check for CN/SAN validation which was being skipped in a certain scenario. Specifically, when the "AEG" product code was being used, this check was skipped. Typically the AEG product code is used for non-public SSL certificates, and we found that the conditional CN/SAN check for the publicly trust thread was not being executed. 5/21: We rolled out updated code that now properly checks the CN and SAN values for the AEG product code. We also rolled back the V1 support to permit continued use of that API. While it's not being used for certificate issuance, it was being used for some other functions that impacted customer operations for the prior few days. We reviewed all certificates issued via this product code and found that these were the only 4 that didn't comply. Others have asked if we had skipped any other checks, like CAA, when following this AEG product thread. Over the past few days we've reviewed the code and threads and have determined that no other required checks or validations were skipped. Organization and Domain validation is done via our Enterprise model and these certificate requests all were subject to those constraints. We're continuing to inspect the AEG thread to double and triple check that no other required validation steps were missed and will report back if we find anything new to report, but at this point I believe that we can close this incident. Doug -Original Message- From: Nick Lamb Sent: Saturday, May 18, 2019 3:02 AM To: dev-security-policy@lists.mozilla.org Cc: Doug Beattie Subject: Re: GlobalSign misissuance: 4 certificates with invalid CN On Fri, 17 May 2019 21:11:41 + Doug Beattie via dev-security-policy wrote: > Today our post issuance checker notified us of 4 certificates were > issued with invalid CN values this afternoon. > > > > We posted our incident report here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1552586 Thanks Doug, I have two questions that seem relevant to this incident, because it is reminiscent of problems we had with the sprawl of issuance systems under Symantec 1. I have examined one of the certificates and I see it contains a bogus SAN dnsName matching the CN. Please let us know which constraints that should be in place weren't in place for this API, for example could the customer have successfully obtained a certificate for a FQDN which has CAA policy saying GlobalSign should not issue ? 2. The API is described as "deprecated" but I'd like more details to understand what that means from a practical standpoint. A subscriber was able (and by the sound of things continues to be able) to cause issuance through this API - was there already a specific date after which GlobalSign had announced (to such customers) that the API would cease availability? Is an equivalent, but so far as you understand compliant, replacement API for these customers already available ? How should a GlobalSign customer have known this API (or software using it) was deprecated and when they needed to stop using it? "In coordination with the customer, we are assured that no more non-compliant certificates will be issued" certainly reads to me like you know this API could issue more non-compliant certs right now, but you're content to let a subscriber pinky swear not to do so. I don't think that's what Mozilla has in mind with the phrase "a pledge to the community" but perhaps Wayne disagrees. Nick. smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Certinomis Issues
On 5/16/19 4:39 PM, Wayne Thayer wrote: On Thu, May 16, 2019 at 4:23 PM Wayne Thayer wrote: I will soon file a bug requesting removal of the “Certinomis - Root CA” from NSS. This is https://bugzilla.mozilla.org/show_bug.cgi?id=1552374 Thank you to Wayne and all of you who have investigated concerns about the recent activities and operations of the CA Certinomis. I have appreciated the thoughtful consideration that you have put into the investigation and discussion. I approved Bugzilla Bug #1552374, for the removal of the following root certificate in NSS 3.45 and Firefox 69 [1]. Common Name: Certinomis - Root CA SHA-1 Fingerprint: 9D70BB01A5A4A018112EF71C01B932C534E788A8 SHA-256 Fingerprint: 2A99F5BC1174B73CBB1D620884E01C34E51CCB3978DA125F0E33268883BF4158 Trust Bits: Websites This root is *not* enabled for EV treatment As Wayne previously explained[2], Certinomis may apply for inclusion of a new root certificate, and the new root certificate may be cross-signed by a currently included CA under certain conditions. Thanks, Kathleen [1] https://wiki.mozilla.org/Release_Management/Calendar [2] https://groups.google.com/d/msg/mozilla.dev.security.policy/rmU311hOIIc/oYuxQJbEAQAJ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
