On 03/16/16 17:48, [email protected] wrote: > On Wednesday, March 16, 2016 at 6:03:26 AM UTC-7, Jakob Bohm wrote: >> On 16/03/2016 00:27, Charles Reiss wrote: >>> On 03/15/16 22:43, kwilson wrote: >>>> 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 and S/MIME 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 and S/MIME certificates chaining up to your included >>>> root certificates are no longer being issued. 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. (Required) >>> >>> For reasons discussed in thread on BR scope here (that >>> restrictions from certificate contents won't be effective against >>> a chosen-prefix collision attack), I was hoping that Mozilla >>> would ask whether CAs would continue issuing any SHA-1 >>> certificates, regardless of suitability for TLS or S/MIME (except >>> those that chain through technically constrained subCAs issued >>> before 2016). But perhaps that needs to be done in context of >>> more expansive improvements to Mozilla's policies. >>> > > > Should we add a question to the survey about each CA's plans for > issuance of SHA-1 based certificates other than TLS/SSL and S/MIME > certificates that chain up to their included root certs?
If Mozilla intends to use the survey to inform its decision about whether to distrust all SHA-1 certificates earlier than the current Jan 2017 date, yes. >> >> I would suggest that in order to make themselves compliant, CAs >> should be allowed to internally generate and issue a very limited >> number of new technically constrained SHA-1 subCAs, where extreme >> precautions are taken to ensure the internal data to be signed does >> not facilitate SHA-1 collisions. The major CAs probably did that >> before the 1/1/2016 deadline, but some of the smaller CAs may have >> not gotten that done yet. >> > > > Are you saying that CAs should be able to issue SHA-1 intermediate > certificates that are capable of issuing TLS/SSL certificates but are > technically constrained via name constraints to certain domains? I assume the idea is that the intermediates are technically constrained from signing TLS or S/MIME certificates at all; for example, with an extendedKeyUsage extension containing only code signing. > > Thanks, Kathleen > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
