Please excuse the length of this post. If you're not interested in the topic you may be able to salvage this post as bed time reading.
Actually I typically read (and respond to) n.p.m.crypto postings in the early morning before I get up to get showered and dressed :-)
[re CA acquisitions and related events]
Totally agree. Perhaps this suggests requiring that the WebTrust (or other audits) are repeated regularly (every N years depending on the trust-bits) and on certain trigger events (within X months of transfer of ownership/control of the keys) if the audit/conformance is part of the MF inclusion policy.
We could certainly consider that. However there are a lot of CAs out there which appear to be perfectly reputable but at the same time don't seem to have updated their WebTrust documentation for a while. (They may have done the audits, but that's not clear from their public information.) I think for now I'd like to take this item under advisement for a future version of the policy, as opposed to addressing it in the 1.0 version.
In any case I want to go back and look at CA certs already included and determine their status, and that would be a good time to look at the current state of audits for those CAs and see what existing practices really are.
[on my contention that artificial constraints on supply have kept cert prices artificially high]
I disagree but I think it would be hard to base a position exclusively on fact. My opinion is that because of the way the safety of website interaction is presented to users there may have been and may still see a backlash against software that doesn't maintain the bar for admission at a level such that the low point in the fence is not the authentication of the site.
As you say, it's difficult to say. It's not clear to me that users have reacted negatively in the past to software with a low "bar for admission" -- has any such software actually been released in the browser/email space? As to what the future will hold, I guess we'll see.
However I should note that there's another possible explanation for relatively high SSL cert prices (beyond the fact that CAs incur relatively high costs to provide a certain level of assurance): that the past and current target market for SSL certs has not been especially price-sensitive, since a few hundred dollars is a relatively low price in the context of putting together an e-commerce site. (Of course this is a tautology, since the price in effect determines the market, drving away potential customers who are in fact price-sensitive.)
Further that the reasons authentication has not been attacked very much are adoption rates of ecommerce, transaction sizes, easy of other (criminal) attacks especially due to the novice nature of most internet participants. This has been slowly changing and may reach tipping point in the next year or three especially as the existing weak points are bolstered through any variety of means.
I agree that this is a real possibility, as I think do most if not all of the people who've posted here. My only caveat is that I don't necessarily see authentication of SSL cert holders as the last line of defense, which if breached would lead to defeat; rather I think it's one element in an overall strategy that should include multiple elements and address not only prevention of attacks but also detection and response. (Your comments about CRLs and OCSP are germane here, as are discussions of how we could quickly remove CA certs, update whitelists or blacklists, and so on.)
[re my contention that economic forces will drive greater emphasis on lower assurance certs]
I disagree. I think the reason we are seeing new lower assurance services appearing is that there are no consequences yet..
This is an point of discussion, and I think the future of the CA industry (including any potential for real growth) will hinge upon it.
I see at least three possibilities going forward:
1. There continue to be no serious issues with low assurance certs (i.e., "no consequences" as you put it). In this case the growth of low assurance services is purely constrained by customer demand (and I should add that I do think there are constraints on this demand, as noted below).
2. There are in fact serious consequences with low assurance certs, and browser and email vendors react by refusing to accept them (i.e., removing low-assurance CAs from their root lists or otherwise blacklisting such certs). This in turns kills any future possibility of low assurance services getting off the ground.
3. There are consequences with low assurance certs, but they get addressed by changes that allow browser and email vendors and their customers to differentiate between types of certs in a reasonable way. This puts us back in the case where low assurance services can grow if there is in fact customer demand.
I agree with notion that the expectation the market has set for users is that the padlock or gold key or gold address bar etc means a site is good enough for commerce and banking.
I think the reverse is true as well: The expectation has been set that only commerce and banking sites need concern themselves with using SSL and SSL certificates. I think this is probably the key demand-side constraint on the growth of low assurance certificate services.
Being a software publisher that goes along with this expectation might impose a responsibility to operate under policies that ensure that expectation is not completely off target.
To "ensure that expectation is not completely off target" doesn't sound quite as positive as "to ensure that expectation is met" :-) The simple fact is that for quite some time now browsers have accepted low-assurance SSL certs. In your opinion, by doing so have the browser vendors acted in accordance with their responsibility as you've outlined it above? Or is it simply that if times change and there are serious consequences to accepting low assurance certs, that browser vendors have a responsibility to change their policies?
I don't think control-of-domain certificates nor other low-assurance certificates are going away.
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 don't think that control-of-domain and low assurance are necessarily bound. Consider a company that does heavy authentication of the ownership of a domain before issuing a certificate to the domain controller (i.e. making sure it really is "Mickey Mouse" at "1122 Boogie Woogie Avenue" per the who-is data ;) - this would of course be more expensive the lower authentication offering.
But see, I would consider this a full-blown "identity-authenticated" SSL certificate, assuming that the CA took some additional measures to verify the identity of the domain controller, e.g., asking for and reviewing ID documents.
I think in practice the major dividing line may not be "low assurance" vs. "high assurance" or "control-of-domain" vs. "identity verification" but rather whether the verification process can be fully automated (at least from the CA's end) or not. After all, in the end this is what is going to drive a CA's marginal cost to issue each new cert, and hence will determine how low CAs can price certs and how they position cert offerings from a marketing point of view.
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? As I noted above I think that CAs and others have set users' expectations such that potential cert customers may believe that SSL and SSL certs are only for banks and e-commerce sites, not for them.
To echo something I wrote in a recent blog post on Clayton Christensen's "disruptive innovation" theories, I think that in order to grow significantly CAs will really have to "compete against nonconsumption", and that entails finding new things that ordinary users want to do for which SSL and certs are the answer, or at least a key component of the answer.
[re my thoughts on "CA branding" in the context of integrated "web presence" vendors]
If the bundling is as broad as you propose in this example than I'm guessing the customer is spending a whole lot of money and is less likely to be fleeting and so it can live and die by its own brand. If unbundled offerings are still available and a bad guy can buy (or other wise get) a low assurance fully trusted by software TLS server certificates that will be a more cost effective attack that cannot be prevented without high authentication and cannot be efficiently recovered from without proper revocation checking and SLAs.
Good points all. On second thought the problem with my thesis is that there will always be unbundled cert offerings, for two reasons:
* for large e-commerce sites the various components (hosting, SSL certs, etc.) will almost always be acquired from separate vendors (or they'll just self-host)
* even in the market for individual web presence the vendors will offer unbundled cert offerings as ways to make an initial sale to new customers currently hosted elsewhere, just as domain registrars offer low-cost domains as loss leaders to get new business, with the hope that they can then sell add-on services later.
So the bottom line is that any "CA branding" will still have a strong element of "third party endorsement" as opposed to "powered by".
To reiterate I don't think that eliminating low assurance or low service robustness or low SLA roots is the solution as that eliminates much potential value to society, I think that the current models in web browsers is not sustainable in the face of the greater applicability of PKI to society and the distinct needs of I'll pick banks compared to folks who want to send encrypted personal email.
This is pretty much my position as well, and one shared by others too. I think the problem is a) figuring out what the new models in web browsers (and email software) should be, especially given the UI constraints we're working under (limited screen space, desire not to confuse users); and b) getting the browser developers to implement these new models.
Today most of the lower bar CAs have little adoption. There are a handful of CA roots that are responsible for 95% of the market (I'm guessing) - these CAs are likely to be willing to defend their position by providing at least best practices in terms of the base technology like revocation.
I actually don't expect that "lower bar" CAs will be able to take customers from "higher bar" CAs. I think the only possibility of "lower bar" CAs is to compete against nonconsumption by finding new customers that the "higher bar" CAs are not addressing and would not be likely to pursue.
[re cert validation not being turned on by default in Mozilla, etc.]
This is IMO a failure to take advantage of what's out there - it raises the bar on those CAs willing to pay the cost of service revocation information and does no harm to a CA who wants to operate at very low costs as they would simply not publish CRL nor OCSP pointers in their certificates.
I agree, I don't like it either, and I don't think anyone associated with Mozilla/NSS crypto development does either.
What is the reason MF software doesn't have revocation turned on by default for at least the automated type of revocation checking?
We've discussed this before, but I'd prefer to let the developers answer directly because I can't remember all the relevant issues. However I think in the end it comes down to a lack of developer resources to implement features like CrlDistributionPoint, etc., and this in turn is because neither corporations nor the Mozilla Foundation are currently funding crypto development specifically targeted at the browser and email clients -- development of the NSS crypto library is focused on the crypto needs of server software (e.g., SunONE Directory Server, etc.), and development of PSM (the browser/email client component mediating between NSS and the user) is currently stalled for lack of people to do it.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
