[Posting on behalf of Google Chrome]
Hi Rob, Modifying the certificate to include the appropriate key usage will ensure alignment with BRs Section 7.1.2.1, but it also creates an additional violation given Sectigo’s CP and CPS prohibit modification. Further, this example highlights one of the challenges associated with CA certificate modification, particularly when considering root CA certificates that cannot be revoked. Unless certificate consumers or relying party applications have a mechanism to distrust the existing certificate, it could still be used during OCSP response validation. While I do not believe this specific scenario introduces security or interoperability concerns for Chrome users or other relying parties, the “problem” still exists. As far as I can tell, there are only two paths that would avoid the introduction of additional policy violations in the process of aligning with the BRs: 1. Establish a delegated responder and stop direct OCSP signing using the CA’s key 2. Migrate to a new root with the appropriate key usage We would prefer if Sectigo committed to one of the two options above. However, in the case of GTS <https://bugzilla.mozilla.org/show_bug.cgi?id=1652581>, the community established a precedent, perhaps unintentionally, that modification was an acceptable mechanism for addressing the missing key usage issue. Consequently, we are willing to accept Sectigo’s proposed path forward (i.e., modification), recognizing that: - the original violation is not fully remediated - the resolution triggers an additional CP violation that must be reported and included in a future audit report As stated in my last post, to further promote ecosystem improvement and reduce possible future confusion, we will continue exploring whether certificate modification should be prohibited long-term. We'd be happy to hear other perspectives from the community. Please let me know if you have any questions. - Ryan On Fri, Dec 10, 2021 at 5:36 PM Ryan Sleevi <r...@sleevi.com> wrote: > > > On Fri, Dec 10, 2021 at 3:12 PM Rob Stradling <r...@sectigo.com> wrote: > >> However, I'm not clear if you intended your post to also convey an >> opinion on Ryan Sleevi's view (expressed at >> https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00224.html >> and >> in https://bugzilla.mozilla.org/show_bug.cgi?id=1741777) that the GTS >> and Sectigo root replacement plans will not actually *remediate* the >> perceived non-compliance issue. >> > > Rob, > > I’m a bit surprised to see the verb “perceived” here; it suggests that you > may not think there’s a non-compliance issue with the existing practice? I > haven’t seen the final F2F minutes posted yet from the most recent > CA/Browser Forum, but from both CAs and root programs, and from the bug > itself, there seems to be no disagreement, except by Sectigo previously, > that there is in fact a compliance issue. I’m not trying to be difficult, > but I was just surprised a bit to see if phrased like that. > > If we accept a compliance issue, then the questions that remain is whether > OCSP responses are issued by certificates, or by key pairs/subject names, > and whether these alternative versions of roots are in scope. That is, the > only way this solution could be remediation is either if the (new) > responses are only tied to the (new) certificate, or if replacement somehow > fully removes the (old) certificate from scope. > > It’s unclear your position on both of these. Mozilla Policy has clarified > several times of doppelgängers being in scope, even explicitly within > policy. Similarly, we’ve seen plenty of incidents with other CAs who have > similarly understood and acknowledged the scope, and even crt.sh reports > these as disclosure required, as I understand it. > > If the digitalSignature-less certificate is in scope, and remains in scope > as transitively valid, then the only way it seems it could not be > non-compliance is if an OCSP response is somehow tied to a certificate, > rather than a keypair. > > We know a responderID byKey is tied to the shared key of both > certificates, ergo the response is issued by either/or/both, and byName is > tied to the subject name, which is also shared by both. > > Perhaps you can explain where the compliant view comes in? It’s unclear if > you’re arguing doppelgängers are or should be out of scope, or if this is > revisiting the earlier argument suggesting the BRs don’t actually require > digitalSignature for direct signing (the legacy roots). > > I totally appreciate you’re looking for clarity from Ryan, but for those > of us on the list (… or a beach 😅), perhaps you can articulate how you see > the solution proposed complying with policy? It doesn’t seem that > replacement can or should be able to declare “old” as out-of-scope, given > that the whole purpose of replacing old with a doppelgänger is to keep > everything signed by it valid and accepted. > > Just because replacement doesn’t remediate, it doesn’t shut down > conversation or remove options. It just necessitates explaining and sharing > more data showing the things being taken into consideration. That said, if > your goal is unambiguous remediation - without having to worry about BR > kremlinology or consequences - it seems rolling to a new key, as Sectigo > already planned to do, is the best way to resolve that. Why wouldn’t that > be an appropriate (long-term) remediation? It’s unclear if the answer from > Ryan is meant to change that prioritization, and if so, why it would? > >> -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADEW5O94rdDGZJrQVHrQnZ0Ms2_14KRw5xLNJ%2BuUb32x4%3DK8Yw%40mail.gmail.com.
