On Fri, Dec 10, 2021 at 3:12 PM Rob Stradling <[email protected]> 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/[email protected]/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 "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGN%3D7YvOLa6WseY%3DANNQeHUW1eOXzrV2Wo8Kdf08ij0LQ%40mail.gmail.com.
