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.

Attachment: 0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Reply via email to