Hi Kathleen, Would this be a good opportunity to ask CAs to do an audit of any undisclosed cross-signatures they may have to other unconstrained roots?
For example, there were two recently discovered cross-signatures to the Federal Bridge by commercial CAs, Identrust and Symantec. Once it was identified that Identrust had not disclosed this cross-signature, Identrust revoked it: https://bugzilla.mozilla.org/show_bug.cgi?id=1037590#c26 While services like censys.io and crt.sh are doing wonders for finding things like this, it would also be beneficial to have CAs use their own vantage point over their cross-signatures to identify other possible gaps between what Mozilla understands their root store to trust and what it could potentially be made to trust. -- Eric On Thu, Mar 10, 2016 at 6:43 PM, <[email protected]> wrote: > On Tuesday, February 2, 2016 at 9:51:02 AM UTC-8, Kathleen Wilson wrote: > > All, > > > > I would like to start drafting the next CA Communication, with the goal > > of sending it around the end of February. > > > > For reference, previous CA Communications are here: > > https://wiki.mozilla.org/CA:Communications > > > > > I will greatly appreciate your feedback on the following draft of the > March 2016 CA Communication. > Are the appropriate topics covered? > Are the questions and available responses clear and sufficient? > Do you have suggestions about when the 'TBD' dates should be? > Any other thoughtful and constructive feedback on this will also be > appreciated. > > I delayed the CA Communication in order to add further customization to > the CA Community in Salesforce that will enhance how the communication and > survey responses are done. CAs will respond to this communication by > logging in to the CA Community in Salesforce. > > To view the draft of the March 2016 CA Communication as it will appear for > each CA in Salesforce, please browse to > https://wiki.mozilla.org/CA:Communications#March_2016 > and click on "Link to DRAFT of March 2016 CA Communication" > > The differences between this page and what the CA will see in the CA > Community in Saleforce are: > - The date picker fields, check boxes, and text entry fields are not > clickable/editable. > - There is no 'Submit' button at the bottom of the page. > > For your convenience I have copy-and-pasted the text from that page below. > > ~~~ > March 2016 CA Communication > > Dear Certification Authority, > > This survey requests a set of actions on your behalf, as a participant in > Mozilla's CA Certificate Program by [DATE TBD]. > > To respond to this survey, please login to the CA Community in Salesforce, > click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA > Communication' survey. Please enter your initial response by [DATE TBD]. > After that, you may update your responses until the survey Expiration Date > of [TBD], by following these same steps. > > A compiled list of CA responses to the survey action items will be > automatically published. > > In addition to responding to the action items in this survey, we request > that you follow and contribute to discussions in the > mozilla.dev.security.policy forum, which includes discussions about > upcoming changes to Mozilla's CA Certificate Policy, questions and > clarification about policy and expectations, root certificate > inclusion/change requests, and certificates that are found to be > non-compliant with the CA/Browser Forum's Baseline Requirements. Your > contributions to the discussions will help shape the future of Mozilla's CA > Certificate Program. > > Participation in Mozilla's CA Certificate Program is at our sole > discretion, and we will take whatever steps are necessary to keep our users > safe. Nevertheless, we believe that the best approach to safeguard that > security is to work with CAs as partners, to foster open and frank > communication, and to be diligent in looking for ways to improve. Thank you > for your cooperation in this pursuit. > > Regards, > > Kathleen Wilson > Mozilla CA Program Manager > > ACTION #1a: As previously communicated, CAs should no longer be issuing > SHA-1 certificates chaining up to root certificates included in Mozilla's > CA Certificate Program. Check your systems and those of your subordinate > CAs to ensure that SHA-1 certificates chaining up to your included root > certificates are no longer being issued. Please enter the last date that a > SHA-1 certificate was issued that chained up to your root certificate(s) > included in Mozilla's program. (Required) > > > ACTION #1b: Enter the date when all of the SHA-1 certificates that chain > up to your root certificate(s) included in Mozilla's CA Certificate Program > will either expire or be revoked. As previously communicated we plan to > show the "Untrusted Connection" error whenever a SHA-1 certificate is > encountered in Firefox after January 1, 2017. (Required) > > > ACTION #1c: Enter the date by which safeguards will be put into place that > will prevent the future issuance of SHA-1 certificates that chain up to > your root certificate(s) included in Mozilla's CA Certificate Program. If > you have already completed this, then please enter the approximate date > when those safeguards were completed. (Required) > > > ACTION #2: Version 2.1 of Mozilla's CA Certificate Policy added the > requirement that CAs must provide public-facing documentation about > certificate verification requirements and annual public attestation of > conformance to the stated certificate verification requirements for all > certificates that are capable of being used to issue new certificates, and > which directly or transitively chain to their certificate(s) included in > Mozilla's CA Certificate Program that are not technically constrained as > described in section 9 of Mozilla's CA Certificate Inclusion Policy. > > Respond with the date by which you plan to complete entry into Mozilla's > CA Community in Salesforce of the PEM data, CP/CPS, and audit statements > for all certificates that are capable of being used to issue new > certificates, and which directly or transitively chain to your > certificate(s) included in Mozilla's CA Certificate Program that are not > technically constrained as described in section 9 of Mozilla's CA > Certificate Inclusion Policy. This includes every intermediate certificate > (chaining up to your root certificates in Mozilla's program with the > Websites trust bit enabled) that is not Technically Constrained via > Extended Key Usage and Name Constraint settings. > > The date that you enter must be on or before [DATE TBD]. (Required) > > > ACTION #3: Mozilla has implemented OneCRL to push lists of revoked > intermediate certificates to the Firefox browser. > > Respond with the date by which you plan to complete entry into Mozilla's > CA Community in Salesforce of the data for all revoked (non-expired) > certificates that were capable of being used to issue new certificates, and > which directly or transitively chain to your certificate(s) included in > Mozilla's CA Certificate Program and were not technically constrained as > described in section 9 of Mozilla's CA Certificate Inclusion Policy. > > The date that you enter must be on or before [DATE TBD]. (Required) > > > ACTION #4: In the process of implementing mozilla::pkix, a number of > compatibility issues were encountered involving certificates that did not > conform to the CA/Browser Forum's Baseline Requirements. To maintain > interoperability, some workarounds were added to allow these malformed or > improper certificates to validate successfully. However, to improve the > state of the web PKI, we plan to remove these workarounds in Firefox 49. > This means that if a certificate has a notBefore date after May 31, 2016, > and is affected by any of these workarounds (see below), it will not > validate successfully in Firefox 49. > > The purpose of this question is to identify interoperability problems that > may arise when we make the planned code changes, so we will appreciate your > diligence in investigating your certificate issuance practices and > previously issued certificates before you respond to this question. > > Please select all of the issues in the list below that exist in > certificates that chain to your root certificates included in Mozilla's CA > Certificate Program that will be valid after the release of Firefox 49 in > September 2016. > > The Bug Numbers below refer to Bugzilla Bugs. (Required) > > - id-Netscape-stepUp in Extended Key Usage extension instead of > id-kp-serverAuth. Workaround to be removed in Bug #982932. > - DER: default value of OPTIONAL BOOLEAN explicitly encoded. Workaround > to be removed in Bug #989518. > - DER: pathLenConstraint included when cA:False. Workaround to be removed > in Bug #985025. > - Use of subject CN for naming information. Workaround to be removed in > Bug #1245280. > - Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug > #[TBD]. > - nameConstraints/subjectAlternativeName encoding mismatches. Workaround > to be removed in Bug #[TBD]. > - Empty SEQUENCE in OCSP responses. Workaround to be removed in Bug > #[TBD]. > - keyUsage lacking keyEncipherment for certs with RSA keys. Workaround to > be removed in Bug #[TBD]. > - None of the above > > ACTION #4 TEXT INPUT: For each of the items that you selected above, > please provide the number of existing certificates with that problem, when > the last of those certificates were issued, and when the last of those > certificates expire. > > > ACTION #5: Review the root certificates that you currently have included > in Mozilla's CA Certificate Program, and let us know which of your root > certificates may be removed, and when. For instance, if you have old root > certificates that are being replaced by newer root certificates, indicate > when you expect to finish migrating your customers to the new root > certificates. Provide the Issuer Field and SHA-256 Fingerprint of each root > certificate that may be removed, and the date when the root certificate may > be removed. (Required) > > > ACTION #6: All certificates that directly or transitively chain to your > root certificate(s) included in Mozilla's CA Certificate Program must > comply with Mozilla's CA Certificate Policy. This includes test > certificates. > > Review your policies, procedures, and auditing about issuance of test > certificates, what domain names may be used in test certificates, and the > domain verification procedures that must be followed for test certificates. > > [TBD] > What else should we say here? > -- What sort of responses to we want from CAs? > -- Rules about testing and test certs (per Symantec incident) > -- What sorts of things do we want to make sure CAs do and don't do > regarding testing? (Required) > > ~~~ END > > As always, I will appreciate your thoughtful and constructive feedback. > > Thanks, > Kathleen > > > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
