Thanks for the timely information, Kathleen. We have two browser plans proposed so far, where Microsoft's will present an unmodified UI until the two milestones, and Google's will soon introduce an advisory trust icon guiding the end user that the site they are visiting is not using the best possible certificate technology available.
Do you or FF product management have an instinct or decision on which way Firefox may go in the time leading up to the first enforcement date of 1/1/16? Would you demote EV UI for two year SHA-1 EV certs on 1/2/15 because notAfter crosses the future deprecation target? Given no exposure caused by SHA-1 use until 1/1/16, would you plan for any UI warning that a site is using a SHA-1 certificate prior to that end of issuance milestone? Understood as a basic point that any change in SHA-1 integrity would warrant an all new plan appropriate to the event. Kind regards, Steven Medin Product Manager, Identity and Access Management Verizon Enterprise Solutions -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+steve.medin=verizonbusiness....@lists.mo zilla.org] On Behalf Of Kathleen Wilson Sent: Thursday, August 28, 2014 12:53 PM To: [email protected] Subject: Re: Formalize a SHA-1 deprecation announcement? Yep. I recently added the following. Feedback welcome/appreciated. https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates == SHA-1 certificates may be compromised when attackers can create a fake cert that hashes to the same value as one with a legitimate signature, and is hence trusted. Mozilla can mitigate this potential vulnerability by turning off support for SHA-1 based signatures. The SHA-1 root certificates dont necessarily need to be removed from NSS, because the signatures of root certificates are not validated (roots are self-signed). Disabling SHA-1 will impact intermediate and end entity certificates, where the signatures are validated. There are still many end entity certificates that would be impacted if support for SHA-1 based signatures was turned off. Therefore, we are hoping to give CAs time to react, and are planning to turn off support for SHA-1 based signatures in 2017. Note that Mozilla will take this action earlier if needed to keep our users safe. CAs should not be issuing new SHA-1 certificates, and should be migrating their customers off of SHA-1 intermediate and end-entity certificates. If a CA still needs to issue SHA-1 certificates for compatibility reasons, then those SHA-1 certificates should expired before 2017. == Also, this topic is on my list of things to included in the next CA Communication. I was hoping to not have to do another CA Communication until I have migrated the CA Program data into SalesForce.com and have a more automated way to handle CA Communications and responses. (this project has started, more info to come as we make progress) I can make an announcement in Mozilla's Security Blog if you all think that is needed. (btw... I'm also drafting a security blog about 1024-bit certs.) Thanks, Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
