Thanks Andrew and Ryan. I can certainly see the intent to implement a comprehensive ban on SHA-1 with the "sign SHA-1 hashes" language in section 5.1.1. This implies that section 5.1.1 overrides the scope statement in section 1.1of our policy.
However, it is also apparent that S/MIME is intentionally not in scope [1]: Therefore, we would like to update Mozilla's CA policy to implement a "proper" SHA-1 ban. At the moment, it seems difficult to define a SHA-1 ban for email, so the current text leaves that for a future update. A number of CAs reported continuing issuance of code signing certificates [2] after this policy went into effect, and it appears that section 5.1.1 permit this as well. What it does not permit is the issuance of new SHA-1 CA certificates, even if constrained for uses other than serverAuth, with pathlen=0, containing data controlled by the CA. The evidence that I've found points to this being an oversight rather than an intentional ban on the issuance of the CA certificate that I described, but under the assumption that section 5.1.1 overrides section 1.1, then I have to agree that our policy forbids it. [1] https://groups.google.com/d/msg/mozilla.dev.security.policy/RwymOVM_Ldg/y2_OMydfDgAJ [2] https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 On Fri, Mar 22, 2019 at 4:43 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Fri, Mar 22, 2019 at 4:00 PM Andrew Ayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Fri, 22 Mar 2019 12:50:43 -0600 >> Wayne Thayer via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> > I've been asked if the section 5.1.1 restrictions on SHA-1 issuance >> > apply to timestamping CAs. Specifically, does Mozilla policy apply to >> > the issuance of a SHA-1 CA certificate asserting only the >> > timestamping EKU and chaining to a root in our program? Because this >> > certificate is not in scope for our policy as defined in section 1.1, >> > I do not believe that this would be a violation of the policy. And >> > because the CA would be in control of the entire contents of the >> > certificate, I also do not believe that this action would create an >> > unacceptable risk. >> >> It was the intent of section 5.1.1 to apply to such certificates, and >> the wording in 5.1.1, which talks about "CAs" signing "SHA-1 hashes" >> means that 5.1.1 applies even when the apparent signed data isn't a >> certificate in scope of Mozilla policy. This is necessary because the >> problem with hash collisions is that while the data the CA thinks it's >> signing might not be a certificate in scope of Mozilla policy, the hash >> might collide with a certificate that *is* in scope. >> > > I agree with Andrew - this was very much the intent. This is similar to > the advice given in a recent reply [1], is consistent with the past > discussion regarding OCSP signers, which GlobalSign had also brought up > [2][3], which past CAs have regarded as incidents [4][5], and which lead to > the exception Andrew mentions here. > > It was the intent of the policy that this be prohibited, except as noted. > [7] > > [1] > https://groups.google.com/d/msg/mozilla.dev.security.policy/vDhKG7T6sCM/vtGubR0pBwAJ > [2] > https://groups.google.com/d/msg/mozilla.dev.security.policy/NthdT8sOQQ0/q37006A6AAAJ > [3] > https://groups.google.com/d/msg/mozilla.dev.security.policy/aCJQ5JkYcVw/diq_e0_kAQAJ > [4] > https://groups.google.com/d/msg/mozilla.dev.security.policy/paXc44rj5PU/lfydcQ_HAgAJ > [5] > https://groups.google.com/d/msg/mozilla.dev.security.policy/6BdFdNQKJoY/NY_owWajAAAJ > [6] > https://groups.google.com/d/msg/mozilla.dev.security.policy/ScoboGpN4w4/GxUCmGWuBgAJ > [7] > https://groups.google.com/d/msg/mozilla.dev.security.policy/wVhRt63bTpU/FxxNlYzxCQAJ > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
