With the RSA case, we were able to remove it because it affected a single CA (sk.ee) and we could communicate with them and get them to resolve the issue.

With this case, we know it affects a single public CA (ComSign) at the moment - they were the first to report - and we know it affects at least one vendor (Cisco).

Similar to RSA, I'd like to set a 6mo window for removing this workaround - the certificates unquestionably violate the specification. This means reissuing the certificates so they're no longer invalid. We'd need to get a sense of the scope of this - David, can you own following up with Cisco about the Cisco Network Setup Assistant and its invalid certificates?

Thanks for filing this Ryan.

We already have an e-mail thread with Cisco regarding this issue; CC'ed you on that.

As for the other potential deployments that are subject to the same issue - IIUC, it's very hard to know about them until this gets broken and customers start complaining.

I think a reasonably safe way to go forward with this issue would be to schedule the workaround to be disabled by default starting from some version, but add an admin policy that would allow to re-enable it (with a documented deprecation schedule for the policy itself). That way, customers will have a chance to know about the problems and fix their deployments during the transition period.
David, Ryan - WDYT?

I don't think the admin policy will be useful in this case, just as it wasn't for the past RSA issue, largely because the users affected are not going to be under enterprise managed scenarios. For example, both ComSign is and sk.ee was issuing invalid certificates (which itself is a violation of their obligations under the respective legal frameworks that establish their authority to do so).

That's where a fixed deprecation timetable (but on by default), with active communication with identified parties, is a useful strategy - especially when this is a somewhat esoteric spec violation (e.g. it's a mistake that is somewhat hard to make)

How would you feel about a Finch flag that only lasted for 6 mos, and which the server would set to disabled? Users could force-enable (via command-line), but not as an Enterprise policy. This more aptly reflects the practical impact.

Note that the admin policy would be sensible in cases like was  bug 788655 , where the problem was occurring in the chrome.enterprise.platformKeys API, which implies that it was a managed user (as the API is only for force-installed extensions).

But I have no idea of how prevalent such enterprise cases would be among the affected users overall. If there's some evidence that it's only a small minority - then agreed that the admin policy won't be that useful.

Note: I don't think an Enterprise Policy would help us get visibility into the issue or remediation for it. It's also a clear enough spec violation - that is, this was an implementation relying on a (ChromeOS) bug that wouldn't work reliably across systems anyway - so the barrier of risk is naturally much lower, and correcting the bug should be a priority :)

I think there would be some value in providing feedback to whoever is using these broken certificates that they are no longer going to be supported in the future. Otherwise, users/administrators who missed the deprecation announcement would not have time to prepare / re-issue their certificates.

An enterprise policy would technically be one way to deliver this feedback in the context of managed users (i.e. the administrator's certificates stop working, the administrator looks for solutions, finds that they can temporarily resolve it by turning on the policy and are now aware of the issue, so they can upgrade their infrastructure to versions including the fix).
There would probably be other ways to deliver this feedback though.

Deprecating without some form of targeted up-front information to affected users feels somewhat risky to me, but I've never done such a deprecation before so I'm not an expert :-)

Re: Command-line flag:
I agree that this makes sense for e.g. desktop users. However, note that managed users generally can't modify the command line, and their administrator can only change the command-line flags for the sign-in screen, not for the user session.

Through coincidence, Mozilla recently posted about some newly created intermediates exhibiting this problem ( https://groups.google.com/d/msg/mozilla.dev.security.policy/oY1CvbsBKo4/F8EPtp_vBwAJ ), pointing out that such certificates are not parsable in Go.

I present this both as a datapoint to capture the risk of shipping this too long (and the ecosystem ossifying) - as such intermediate CA certs are now correctly rejected in Chrome - and to highlight that the compatibility risk is already such that these certificates are not interoperable on systems.

Adding Enterprise-Triaged label so this doesn't appear on our triage list.

Re Comment #7: Ah, I had the impression that this issue is probably widespread among other components and we're the first ones to start rejecting these certs. But it looks like I was mistaken (which is good) :-).