3 ms·

Admittedly it's a stretch, but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from bein

Admittedly it's a stretch, but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS." https://www.chromium.org/Home/chromium-security/root-ca-policy/ https://www.chromium.org/Home/chromium-security/root-ca-poli... I also find it hypocritical that Google wants a multi-certificate architecture when they won't allow sysadmins their own certificate: https://issuetracker.google.com/issues/168169729?pli=1 https://issuetracker.google.com/issues/168169729?pli=1

gruez 2y ago
>but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS." It's probably a downstream effect from iOS not allowing third party rendering engines on ios, and the API for safari webview doesn't allow developers to swap out the TLS stack. >I also find it hypocritical that Google wants a multi-certificate architecture when they won't allow sysadmins their own certificate: https://issuetracker.google.com/issues/168169729?pli=1 https://issuetracker.google.com/issues/168169729?pli=1 It really isn't. The linked issue seems to revolve around allowing root CAs to be added without user involvement, which presents privacy/security issues. Meanwhile being able to support multi-certificate in this context is motivated by being able to use newer cryptographic algorithms while still being able to support legacy devices, eg. presenting ECDSA certificate to modern devices but presenting an RSA certificate to decades old IOT devices that only support RSA. I don't see how that's contradictory with "we don't want to allow installing CAs behind users' backs because it might be abused to spy on them".

3 ms·

Admittedly it's a stretch, but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from bein

by mrbluecoat 2y ago

gruez 2y ago
>but I can't help but wonder why "Apple policies prevent the Chrome Root Store and corresponding Chrome Certificate Verifier from being used on Chrome for iOS." It's probably a downstream effect from iOS not allowing third party rendering engines on ios, and the API for safari webview doesn't allow developers to swap out the TLS stack. >I also find it hypocritical that Google wants a multi-certificate architecture when they won't allow sysadmins their own certificate: https://issuetracker.google.com/issues/168169729?pli=1 https://issuetracker.google.com/issues/168169729?pli=1 It really isn't. The linked issue seems to revolve around allowing root CAs to be added without user involvement, which presents privacy/security issues. Meanwhile being able to support multi-certificate in this context is motivated by being able to use newer cryptographic algorithms while still being able to support legacy devices, eg. presenting ECDSA certificate to modern devices but presenting an RSA certificate to decades old IOT devices that only support RSA. I don't see how that's contradictory with "we don't want to allow installing CAs behind users' backs because it might be abused to spy on them".