On Sat, Jan 18, 2020 at 9:22 AM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > 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.] It certainly was not meant that way. It is the essence of “rough consensus and running code”. Standards that describe idealized states, that don’t reflect reality, are standards that aren’t valuable. Similarly, when we talk standards that do things like deprecate insecure crypto or older protocol versions, we know there isn’t an IETF Enforcement Bureau that makes sure all of the “-diediedie” drafts are observed and implemented In a timely fashion. That’s what makes jokes like RFC 6919 so endearing and funny, because we know that it better reflects our unfortunate realities than 2119. 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. They are relevant in that they require they all be treated the same, for legal, policy, and other non-technical reasons, even when it’s understandably undesirable. I don’t disagree that there’s ample need for robust TLS issuance, and I agree that there’s ample ill-definition about what “WWW authentication” means and contains. Some CPSes are more explicit, some less, about what they allow. Supposedly, every time you’re getting a cert, you’re carefully reviewing all of these agreements as part of your selection of which CA to use ;) 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). I mean, this is why RFC 3647 exists. It exists for CAs to shift liability to Relying Parties (“We told you we do this stupid thing, right here”), and for Root Stores to shift liability to CAs (“You told us you would do this, right here”). CAs like to use it to further try to defend against any risk of distrust (“We told you we would do a stupid thing, and you trusted us anyway, so you can’t distrust us for doing a stupid thing”) There are CPSes that don’t include problematic clauses regarding EKUs, for sure, or which explicitly state how it’s interpreted in their PKI. That particular example is not meant to be a “universal example” of something forbidden, but to highlight how even if one relying party would like to ignore the CPS, when there are multiple constituencies, that doesn’t work. The only way you sort through those is to make sure the only two parties are you and the CA - aka defining a root store.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
