On Thursday, April 9, 2015 at 9:32:48 AM UTC-7, Kathleen Wilson wrote:
> All,
>
> I would like to send the next CA Communication in late April or early
> May, and request CAs to respond to it within one month. For this
> communication I plan to use SalesForce to email a customized survey link
> to the Primary Point of Contact for each CA owner, and the responses
> will be collected via SalesForce. I also plan to use SalesForce to
> generate a report of the responses that I will publish.
>
> I will greatly appreciate your thoughtful and constructive feedback on
> the draft of the CA Communication below.
>
> CAs, please do *not* send me your responses yet. Every CA will need to
> respond via the survey link that will be sent to their Primary Point of
> Contact.
>
>
> == Begin DRAFT==
>
> Dear Certification Authority,
>
> This note requests a set of actions on your behalf, as a participant in
> Mozilla's CA Certificate Program. Please reply by <date> with your
> response to these action items. A compiled list of CA responses to the
> action items will be published.
>
> ACTION #1
> You have received this email because you are currently the Primary Point
> of Contact (POC) regarding your CA's root certificates that are included
> in NSS. We plan to issue a SalesForce Community Plus License to each
> Primary POC, so CAs can input and manage their own CA data directly in
> Mozilla's CA Program instance of SalesForce. This includes the
> publicly-disclosed and audited subordinate CA data, as well as the
> revoked intermediate certificate data.
>
> Respond with one of the following:
> A) I am the Primary POC, and the SalesForce Community Plus License
> should be sent to me.
> B) The Primary POC for our CA has changed to... <name, email address,
> phone number -- note that this personal data will not be published>
>
> ACTION #2
> As you know, every CA in Mozilla's program whose root certificate(s) are
> enabled for the websites (SSL/TLS) trust bit must annually provide a
> public-facing audit statement according to the BRs, in addition to the
> other audit statements as listed in section 11 of Mozilla's CA
> Certificate Inclusion Policy. Please carefully review this wiki page
> with your auditor: https://wiki.mozilla.org/CA:BaselineRequirements.
>
> For each root in the program, respond with one of the following:
> A) Mozilla's spreadsheet of included root certificates has the correct
> link to our most recent Baseline Requirements audit statement.
> B) Here is the most recent Baseline Requirements audit statement for our
> certificates that are included in Mozilla's CA program: <insert link
> here>.
> C) We plan to send Mozilla our current public-facing Baseline
> Requirements audit statement by <insert date here and explain reason for
> delay>.
> D) The websites (SSL/TLS) trust bit is not enabled for our certificates
> that are included in Mozilla's CA program.
> E) We do not have a current Baseline Requirements audit statement for
> this root certificate, because <explain reason -- If phasing out use of
> the root then indicate date when the certs expire or when the root may
> be removed>.
>
> ACTION #3
> After January 1, 2016, we plan to show the "Untrusted Connection" error
> whenever a SHA-1 certificate issued after that date is encountered in
> Firefox. And after January 1, 2017, we plan to show the "Untrusted
> Connection" error whenever any SHA-1 certificate is encountered in Firefox.
>
> Guidance about SHA-1 Certificates has been provided here:
> - https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates
> -
> https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
>
> Respond with one of the following:
> A) We are no longer issuing SSL SHA-1 certificates that chain up to our
> roots in Mozilla's program. We never issued any SHA-1 certificates which
> were valid beyond January 1, 2017.
> B) We are no longer issuing SSL SHA-1 certificates that chain up to our
> roots in Mozilla's program. In the past, we did issue SHA-1 certificates
> which were valid beyond January 1, 2017, but they have all now been
> revoked/replaced.
> C) We are no longer issuing SSL SHA-1 certificates that chain up to our
> roots in Mozilla's program. We have issued <number of> SSL SHA-1
> certificates that are valid beyond January 1, 2017, that we have not yet
> revoked/replaced, and we plan to have them revoked/replaced by <date>.
> D) We currently plan to stop issuing SSL SHA-1 certificates that chain
> up to our roots in Mozilla's program by <date>. We have issued <number
> of> SSL SHA-1 certificates that are valid beyond January 1, 2017, that
> we have not yet revoked/replaced, and we plan to have them
> revoked/replaced by <date>.
>
> ACTION #4
> Workarounds were implemented to allow mozilla::pkix to handle the things
> listed here:
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
> We plan to remove these workarounds soon, so that new certificates with
> these problems will fail. Please check your certificate issuance to
> ensure you are no longer issuing certificates with these problems. 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.
>
> Respond with one of the following:
> A) We have not and will not issue certificates with any of the problems
> listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.
> B) We have previously issued certificates with the following problems
> listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list
> the problems that needed to be fixed, and the number of existing
> certificates with each problem>. The last of those certificates were
> issued on <insert dates here, one date per problem>, and expire on
> <insert dates here, one date per problem>.
>
> ACTION #5
> We wish to understand what support you are providing for IPv6
> (http://www.google.com/intl/en/ipv6/statistics.html) in the part of your
> infrastructure that faces relying parties (CRL and OCSP servers). One
> reason for this is that IPv6-only servers who want to staple, or
> IPv6-only clients who want to do revocation checking, will need to
> access the OCSP servers. (Note that the Mozilla root store is used by
> more clients than Firefox, and clients have varying approaches to
> revocation.)
>
> Respond with one of the following:
> A) We support IPv6 for all our CRL and OCSP servers.
> B) We support IPv6 for all OCSP servers but not CRL servers.
> C) We support IPv6 for all CRL servers but not OCSP servers.
> D) We partly support IPv6. <Please give details>
> E) We do not yet support IPv6, but have a plan to do so <Please give
> implementation dates>
> F) We do not support IPv6, and have no plans to do so.
>
>
> Thank you for your attention to the above listed action items. We will
> appreciate your prompt response.
>
> Additionally, we plan to update Mozilla's CA Certificate Policy soon,
> and will be discussing proposed policy updates in the
> mozilla.dev.security.policy forum. We encourage you to monitor the
> discussions to see how the updates will impact you, and your
> participation in the discussions will help shape the policy updates.
>
> 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
> Module Owner of Mozilla's CA Certificates Module
>
> =====End DRAFT========
What about Mozilla's own aus3.mozilla.org certificate for which the SHA-1
intermediate was pinned?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
