Hiya, On 18/01/2020 13:55, Ryan Sleevi wrote: > No. The root store operators make the rules. Standards that align with > their needs are the standards they use and apply. > > Nothing you say or do has any impact without implementor, and if you go > against the grain of where implementors are going or already at, they are > useless standards that will be ignored. > > It would similarly be a mistake to think “Ah, but I control an SMTP server, > I am thus an implementor and empowered”. You are indeed an implementor... > for your root store. And if existing contracts and requirements prevent a > CA from serving your needs from the same hierarchy they are serving other > root store needs, which they increasingly will, then again, there’s no real > power unless you define your own root store.
I have to say that comes across as fairly arrogant. I guess that's by the by, but it makes me happy that I don't need to play in the CAB forum space:-) [I'm sure it wasn't meant to be arrogant, and it has been a long thread which can lead to irritability, but that's how it struck me.] I've no real axe to grind here (definitely not wrt EAP), but, as a private key holder I do use web PKI CAs for email servers as well as for web servers. Turning that off would disimprove security for the Internet without (IMO) any real justification as to it producing a real improvement in the web PKI. (I do control the domains.) I don't buy that mentions of diginotar or equivalent misissuance problems are really relevant myself. That, and I've always considered CP/CPS as legal window dressing, initially for the benefit of CAs but judging from the above, now apparently mostly for the benefit of web PKI root store maintainers (aka browsers). So yeah, count me amongst those who'd suggest fixing the policy to match what's better for the Internet is the right approach, even if it's not an approach that might get traction in CAB forum. S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu