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.
Frank Hecker wrote:
> Ram0502 wrote:
> > I think there are potential applications of PKI outside phishing
> > prevention and further that PKI by itself is not a perfect
solution.
> > There are plenty of things that could be done to improve the safety
of
> > netizens; some risks or aspects of risks can be mitigated by use of
> > public key technologies. Different approaches and different
> > applications could have different requriements.
>
> Thanks for your comments; it's always good to see new perspectives in
> these discussions.
My pleasure.
>
> > The root list management approach to date in MF and Microsoft has
been,
> > more or less, to identify the CA legal entity and require that they
> > document their policies and practices and undergo an audit. Both
> > Microsoft and Netscape used to charge a huge amount for inclusion
in
> > their root lists which ensured the CAs had something to lose if
their
> > brand was tarnished, but it also kept smaller CAs off the list (it
may
> > be worth noting that quite a few of the CAs commonly trusted have
been
> > bought or sold or gone bankrupt - what policies and practices
survive
> > change of ownership?).
>
> Also worth noting is that buying an existing CA was one way in which
new
> CAs could enter the market and have their certs automatically
accepted,
> rather than having to go through the process of trying to get each
and
> every browser vendor to include their own (new) root certs. Another
way
> to bypass the browser vendors was to get yourself set up as a
> subordinate CA to a root CA whose cert was already in all the
browsers.
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.
>
> In effect what we had (and still have to some extent) was a situation
> where the browser vendors artificially constrained supply in the CA
> market, and companies had economic incentives to find ways to evade
> those constraints. I also think these artificial limits on
competition
> in the CA market caused prices for certs to remain higher than they
> otherwise might have.
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. 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.
>
> In many ways the dynamic playing out in the CA market today reminds
me
> of what happened to the domain registration market over the past few
> years: moving from a near-monopoly situation to a more fragmented
market
> as artificial constraints on the market are gradually removed. This
> prospect may be alarming to some people ("what? CAs descend to the
level
> of domain name registrars?") but I think it could actually be to our
> benefit, for reasons I alluded to previously: a fragmented market
with
> low market share for any given CA makes it easier to remove CAs if
> needed without causing excessive disruption to users.
I agree that a small subscriber base makes a root CA easier to remove;
I doubt that VeriSign (or others in the top tiers) will be caught
'below the line' so I don't see this as a practical concern.
>
> In any case I think there are powerful economic forces driving this
> transformation of the CA market, most notably forces driving
commercial
> for-profit CA services to become just one of many ancillary services
> offered by integrated "web presence" vendors, along with domain name
> registration, web site hosting, email service, blogging systems,
> e-commerce hosting and back-end payment processing, etc. I hope to
blog
> more on this soon (plus see my comments below).
I disagree. I think the reason we are seeing new lower assurance
services appearing is that there are no consequences yet..
I think that the reason the CAs that maintain higher standards (include
revocation pointers in certificates they issue, perform more stringent
authentication, have more secure data centers, and higher SLAs) is that
they have customers to whom it does matter even if their relying
parties don't realize they may want to care. How many banks offer
banking services in non-SSL sites? I suspect that if and when
revocation is turned on by default in IE banks may be less likely to
allow browsers that don't have it enabled where easy (i.e. because the
pointer is in the certificates). 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. 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. I am not
stating there is a legal responsibility; frankly I have no idea what
the legal grounding of this statement is in any country. I think it is
clear what user base expects and since MF wants to be a user focused
entity I think that statement should already be taken as true.
>
> > An advocate in nmpc suggests driving broader adoption of SSL by
> > changing the trust model in combination with loading additional
> > financial exposure on the CAs (ie make their brand/reputation
suffer
> > for their mistakes and weaknesses). Others advocate raising the bar
for
> > entry into the root list through other means. I think there is
merit to
> > both approaches.
>
> I think a lot of this debate comes down to the following: Do we try
to
> hold on the traditional notions of what a CA is and does, or do we
try
> to adapt to how the role of CAs might change as time goes on? Clearly
> there is a lot of sentiment in this forum that things like
> only-domain-ownership-validated SSL certs and low-assurance email
certs
> represent a falling away from the traditional standards that CAs
should
> meet, and may be the source of potential security risks (e.g., those
> related to phishing). As I've said before, this is a perfectly
> legitimate position to take.
>
> On the other hand I think domain-validated SSL certs and other
> lower-assurance certs are not going to go away, and if anything I
think
> they'll become more popular, because they meet the needs of a big
> portion of the potential customer base for certs. The thoughts on
> branding put forth by Ian and others to some extent represent
proposals
> on how to manage this market transition in a controlled way, by
making
> the CA market more like a "normal" market where people make their
> decisions based on their perception of vendors and their brands, as
> influenced by advertising, independent evaluations (e.g., Consumer
> Reports, J.D. Powers, etc.), and others' experiences.
I don't think control-of-domain certificates nor other low-assurance
certificates are going away. 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. We may see DNSEC drive domain validation
certificate adoption (assuming the community can agree to deploy
DNSSEC) - I don't' think that changes the nature of the discussion,
what keys will be trusted for DNSSEC? If the requirements for
authentication of a domain name + certificate bundle is high we may see
a very familiar discussion. 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.
>
> However I don't think Ian is going far enough in his thinking. My
> hypothesis is that in a few years there may not be a CA market in the
> traditional sense. Instead it may be subsumed into the broader market
> for "web presence", and "CA branding" really becomes proxy branding
for
> web presence providers. Consider a situation where a person or small
> business goes to "WebPresence Inc." and does the following:
>
> * registers a domain
> * signs up for web site hosting
> * contracts for various add-on services from a menu of services:
> * IMAP and/or webmail accounts
> * blogging facility (to create public and/or private blogs)
> * chat room(s) (for public or private chat)
> * streaming media service (to serve up audio or video content)
> * advertising service (to serve up contextual ads)
> * Internet storefront
> * back-end payment processing
> * and so on...
>
> Oh, and by the way, they sign up for an SSL cert for their domain,
and
> maybe also email certs for their bundled email accounts.
>
> What does "CA branding" do then? It shows that
"www.mylittlewebsite.com"
> is a "WebPresence site"; in other words, it advertises "WebPresence
> Inc." to every person viewing the site, each of whom represents a
> potential customer for "WebPresence Inc." IMO this significantly
changes
> the terms of the debate between Ian and Gerv about how end users
might
> respond to CA branding (e.g., by switching their custom from one
> Internet store to another based on the first store using a dodgy CA),
> because it changes the purpose of the branding from a "Seal of
Approval"
> model to a "Powered by Foo" model.
>
> From this point of view "CA branding" becomes the web equivalent of
the
> email signature tags inserted into messages by Hotmail and other
> providers. (And we all recall the great success of that practice in
> marketing Hotmail and other services.) And like those tags, "CA
> branding" doesn't depend on the site owner doing something (like
> inserting a "Powered by WebPresence Inc." graphic), the branding
"just
> happens".
>
> (Again, this whole topic of "CA branding" and how it might evolve is
> something else I hope to find time to blog about.)
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.
>
> > It seems to me that internet use is increasing and therefor so is
the
> > value to be garnered by criminals. I expect the approach criminals
take
> > will be path of least resistance and that the particular attacks
will
> > vary substantially to work around changes in the landscape. So what
do
> > we do? I don't expect we will find one new technology or
enhancement to
> > an existing technology that will solve all our problems. I think
the
> > right approach is to be practical and improve things even
imperfectly.
>
> I will go further and state that our goal should be to adapt to
changes
> occuring in CA market, as opposed to trying to hold back the tide,
and
> to do so in a way that provides a smooth "glide path" to whatever the
CA
> business will look like in the future. This means:
>
> * putting standards in place that are consistent with the way CAs
> currently operate and are likely to operate in the future (as opposed
to
> the way CAs were envisioned back in the dawn of the web)
>
> * encouraging (not discouraging) more competition in the CA market
and
> welcoming new entrants as long as they meet our minimum standards, in
> order to reduce the dominance of any one CA and make it easier to
"turn
> off" a CA if this is ever needed (remember -- a threat that can't be
> carried out is not a credible threat)
>
> * looking at some sort of "CA branding" scheme that provides
something
> for users, CAs, and us
I think I agree with all these points but I would caution that just
because things have been pretty good to date does not mean the current
system is good. I think there is an opportunity to capture the more
price-sensitive would be customers of SSL server certificates that is
driving the change and that this change will result in a demand to
change the model presented in software. This is what I see as the
market force that will drive the alignment of technology with
expectation. 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.
>
> > So to the topic at hand - what about the MF policy for PK root
> > inclusion. My opinion is that there are many approaches we could
take
> > to improve the security proposition some will require a lot of work
> > others less. The following are a few of my thoughts and
suggestions.
> >
> > For practical reasons I think it is easier to be tougher on the
> > admission and more lenient on the removal side as it is much more
> > difficult to orchestrate a reasonable removal without unduly
damaging
> > innocents such as web site operators who chose a CA that was later
> > removed from the trust list.
>
> Agreed, but removal becomes easier as average CA market share drops.
> Also, we have options short of actual removal; for example, we can
put
> in "informational bars" (not popups) with warnings to the user.
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 don't believe the bar can be set high enough on admission to the
root
> > list that it can be left unmaintained nor do I believe that any CA
is
> > capable of operating perfectly against strong policies such that
thinks
> > like revocation don't matter.
> >
> > I propose a requirement that every CA whose certificates will
identify
> > ecommerce sites or software publishers must support revocation
checking
> > through standard means, say a CRL or OCSP pointer in every
certificate.
> > This could have an SLA aspect such that the OCSP or CRL not lapse
(the
> > CRL pointer should never point at a CRL whose next-udate time is
three
> > days ago).
>
> These are good suggestions. The only problem is that Mozilla-related
> products do not enable CRL or OCSP checking by default, so this is
> irrelevant for typical users who do not change the default settings.
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. What is the reason MF software doesn't have revocation
turned on by default for at least the automated type of revocation
checking? I've been turning this on for a few years without much issue.
Everyone once in a while I find a site operating with a revoked cert or
with a cert that points at OCSP or CRL but the URL is unavailable.
There is one nasty case that I'm aware of - that of the WISP who uses
TLS/SSL for initial login but doesn't allow access to CRL/OCSP to
authenticate the server credential.
>
> (Apparently there are code issues preventing us from pre-loading CRL
> information; CRLs currently have to be downloaded "by hand". The
> long-term solution is presumably parsing and acting upon CRL-related
> information in certs, e.g., the CrlDistributionPoint extension or
> whatever it is. There may also be a kludgier short-term way to turn
this
> on using, e.g., a Firefox extension. But again, "we need a patch", as
> the saying goes.)
That's ok because CAs can include HTTP or LDAP URLs in certificates
that point at current CRLs or OCSP responders.
>
> > I think presentation of the CA logo leverages natural human and
market
> > systems to drive quality up for the consumer but practically this
seems
> > to be difficult as there is a UI real-estate issue - perhaps in
time we
> > will see the UI issue resolved through client software competition.
>
> It's quite possible that it will take inclusion of "CA branding" in
IE
> (assuming Microsoft does this as part of an overall anti-phishing
> strategy) to prompt Firefox developers to take a closer look at this.
> That's not necessarily a bad thing; Firefox has certainly looked to
> other browsers in the past for ideas about new features, and is none
the
> worse for having done so.
Totally agree. This is a natural and common occurrence. I was proposing
leading change in what I see as being in the web-client users'
interest.
>
> > Finally I think there is merit to having different requirements for
> > different applications of PKI. Compare the risks of interacting
with
> > your bank, installing software, and logging into your favorite
internet
> > portal so it recalls your content preferences. In the banking case
I
> > really care about authentication and encryption as does the bank.
If
> > you interact with your bank from your computer than you (and your
bank)
> > both care about what software you install. A few good keylogging
> > attacks in the press and we may see the priority of software
publishing
> > security increase.
>
> We also IMO have some work to do in this area as well, for example
doing
> a better job of protecting the integrity of mozilla.org software
> downloads and updates, using digital signatures and other techniques.
Totally agree. IMO one of the critical issues here is revocation.
>
> Frank
>
> --
> Frank Hecker
> [EMAIL PROTECTED]
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
