On Wed, Mar 30, 2016 at 2:23 PM, Kathleen Wilson <kwil...@mozilla.com> wrote:
> On 3/30/16 1:53 PM, Jeremy Rowley wrote: > >> I think a required move away from SHA1 client certs requires a bit more >> planning. >> >> 1) There hasn't been a formal deprecation of all SHA-1 certificates in >> any root store policy. There has been a formal deprecation by the CAB Forum >> of SHA1 server certificates. Considering many of the client cert issuance >> is governed by various national schemes (FBCA in the US and the Qualified >> Cert program in the EU), care is necessary in enacting policies that impact >> the use of client certificates. Although I recognize the need for Mozilla >> to ensure a safe onine experience for all its users, I'm sure they don't >> want to undermine entire trust frameworks built on these certificates. >> (Yes, I know FBCA requires SHA2 now). >> >> 2) The browsers are already deploying code to reject SHA1 certificates >> encountered. If this is true, what is the harm in continued SHA1 client >> certificate issuance until the national schemes have all updated their >> requirements? Mozilla is protected but the national bodies (and financial >> institutions) can continue using their software for client authentication. >> I do think we should move to SHA2, but I don't think the prior notice has >> occurred with respect to SHA1 client certs. >> >> 3) Because Mozilla doesn't have a policy against reissuance of SHA1 >> intermediates for client certificates, I don't think your suggestion to >> only permit reissuance of limited SHA1 intermediates is feasible. I do >> think requiring a constraint against general SHA1 intermediates (that lack >> technical restrictions to prevent server certs) is a good idea to ensure >> the intermediates are only used for s/MIME or code signing. >> >> 4) Documenting why outdated algorithms/key sizes/anything else are used >> always ends up being "For support of legacy devices". I don't see much >> value in that. It becomes an exercise in creating an automatic label >> applied to each certificate. >> >> In all, I think clientAuth certs are different than serverAuth certs. CAs >> issuing clientAuth certs wouldn't necessarily be aware of the intent to >> deprecate. I also do not think Mozilla has as large of stake in client >> certificates as it does server certs. Therefore, any plan to move away from >> SHA1 client certs should start with: >> A) An announcement that client certs will be deprecated >> B) A question to the public about what software is still requiring the >> use of SHA1 certs and the impact of requiring SHA2 certs, and >> C) A date when SHA1 client certs will be deprecated >> >> Again, I'm not opposed to moving to SHA2 client certs, but I don't think >> Mozilla has conveyed to the public its intent to do so. >> >> >> > > I think Jeremy is correct, that Mozilla's previous communications about > SHA-1 certs was only in regards to TLS/SSL certs. > > Would anyone object to me changing Actions 1a and 1b to the following? > Looks reasonable to me. > (note, using date 2016-04-01 for the CAs who don't have the Websites trust > bit enabled will make it so we can easily filter out those responses) > ~~ > 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. This includes TLS/SSL certificates, as well as any > intermediate certificates that they chain up to. Check your systems and > those of your subordinate CAs to ensure that SHA-1 based TLS/SSL > certificates chaining up to your included root certificates are no longer > being issued, and that any such certificates issued after 2016-01-01 have > been revoked. Please enter the last date that a SHA-1 based TLS/SSL > certificate was issued that chained up to your root certificates included > in Mozilla's program. If your included root certificates do not have the > Websites trust bit enabled, then please enter 2016-04-01. (Required) > > > ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL > certificates that chain up to your root certificates included in Mozilla's > CA Certificate Program will either expire or be revoked. If your included > root certificates do not have the Websites trust bit enabled, then enter > 2016-04-01. > > As previously communicated we plan to show the “Untrusted Connection” > error whenever a SHA-1 certificate is encountered in Firefox after January > 1, 2017. > > We recommend that you put safeguards into place that will prevent the > future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 > based intermediate certificates that chain up to your root certificates > included in Mozilla's CA Certificate Program. (Required) > > ~~ > > > I think we can keep Action 1c as-is, because option (d) should capture > information about issuance of S/MIME certs. > > > Thanks, > Kathleen > > > > _______________________________________________ > 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
