Ram A M wrote:
I basically agree. I would say that for high-assurance (auth.) high-service (SLA, feature robustness - revocation) the price could be much higher; FIs are used to paying big bucks to mitigate risk, large etailers make tremendous amounts of money and would probably be willing to pay much more. The current price is probably lower than the threshold for these entites because there is no support for quality differentiation in the client base and so FIs cannot be offered a great product for USD5000 with small ecommerce sites getting a USD200 service and my having access to a $50 service. This is IMO closer to what is demanded today and potentially the model we end up at in a few years as market pressures drive changes here and there until we navigate to a stable point.
Right. And, the current situation - compressing the cert market into one-size-fits-all - is unlikely to change until branding is introduced. See my rant on 'discrimination' in the cert market at:
http://iang.org/ssl/dr_self_signed.html
Incidentally, is "control-of-domain" the standard "term of art" in
the
CA industry for this? I've been using "domain validated" but IIRC I
just
pulled that out of thin air. If there's a term already in common use
I'd
prefer to use that instead.
I just made it up. I prefer this term because it talks to the attribute that CA issuance, to some degree, attests to. I also prefer homoglyph to homograph so there you go.
That's a good point. It is control of domain that is being tested, at the most fundamental level. Using the term "domain validated" opens the question as to just what has been validated.
Ultimately my point was that a CA cannot reasonably leverage mass market registrars for authentication to provide high assurance services since registrars cannot be expected to operate only high assurance registration services - the price points don't allow it.
I would agree with that basic point; although there have been many proposals to ask the registrars to control things like IDNs.
In any case I think, to your point, there is a pent up demand for low assurance certificates that can't be correctly addressed and that the cropping up of low assurance TLS certificate providers will force the hand of software providers to change the user expectation and interaction model.
Not to contradict myself, but is there really such a pent-up demand?
Sure, count me in. I want a low assurance cert for every one of my websites. I and the readers of the site don't care so much about being hit with an MITM or being spoofed by a phisher, they would just rather enjoy reading the stuff without anyone knowing which pages and what text and so forth they are reading.
It is fairly low assurance stuff, but some people who work in fairly high profile jobs like to comment on my FC posts; currently, they are inhibited from doing that as the posts are all in the clear and their sysadmins could snoop them. As we are talking financial services, sysadmin snooping is a real and present issue, and it's often mandated.
I agree in part. I think CAs would love to see broader adoption of certificates at a variety of assurance levels and that because the software providers do not have a direct incentive to support this that the system is taking the path it is - introduce lower cost lower assurance certificates since they appear to provide the same value (padlock) which I think will enable the backlash I suggested earlier.
Right. Again, check that rant. I think certain architects who were involved in the early construction of the PKI got it backwards and now we are all paying the price.
I don't know how many levels of bars there needs to be but I see a risk to the user in presenting the less robust or lower auth offerings to the user in such a way that they recognize it as a 'safe for banking.'
Yes, Branding solves all that. I'm not sure how it will pan out in the end, as right now there is some discussion about hierarchies of certs. But it doesn't seem insolvable.
iang
-- News and views on what matters in finance+crypto: http://financialcryptography.com/ _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
