On 4/17/05, Ian G <[EMAIL PROTECTED]> wrote:
> Hi Kyle,
>
>
> Kyle Hamilton wrote:
> > I have some very grave concerns with the release candidate of the
> > Certificate Policy 1.0 (CP1RC), as posted on Frank Hecker's site. Many of
> > these are based on accounting and accountability, as well as knowledge of
> > what's occurring within the financial industry.
>
> Excellent to hear! You may be a little late, in that
> it is already submitted to the next stage. But,
> assuming there is some chance of future debate on it
> all, let's discuss.
...since there's always a chance for refinement for the policy, and
indeed almost a requirement for it [Goedel's Theorem of Incompleteness
being what it is -- forgive my not including the umlaut in his name;
I'm not sure how to do it], discussion is always appropriate. As
well, I'm hoping that some of the MoFo execs read the list.
> > To be certain that I can properly explain where I'm coming from, I'll have
> > to provide an affirmation, and give a little bit of history:
> >
> > - I believe that having more CAs in the world is an inevitability.
>
> Perhaps likely but I'm not sure that is so relevant
> to what I believe should be the real goal, which is
> security for users.
Well, the question comes in when you try to define 'security'.
1) Authentication: Verify the identity of the person you're talking with.
2) Secrecy: Verify that nobody else can hear what you're saying.
3) Tamper-evidence: Verify that nobody else changed what you're hearing.
Secrecy and Tamper-Evidence are fairly easy concepts, but
Authentication includes a fairly interesting word, 'identity'. Since
everyone has more than one identity (you are [EMAIL PROTECTED],
member of the mozilla-crypto list... but also Ian <whatever your last
name is>, holder of <whatever bank accounts you hold>, <possible
husband/father>, <whatever your job title is>, etc), my ability to
verify your identity is limited to the context in which I'm discussing
cryptography with you now -- that is, [EMAIL PROTECTED], member of
mozilla-crypto.
The historical idea of 'identity' within the X.500 framework has
always been specified as 'legal/fiscal' -- the identity by which
governments know their citizens. (This isn't at all surprising, given
that X.500 et al were ratified by the CCITT, now the ITU, which is a
branch of the United Nations -- and only stakeholders who have a
financial interest and governments could take part in the standards
process.) This led to the idea of CAs, which ended up spawning the
creation of an X.-series protocol by ANSI related to the operations of
CAs within the US. (I don't have my references up at the moment, so
please call me on anything that I say which is blatantly incorrect.)
These two identities are at odds -- not so much because they're
incompatible, but because given one I cannot deduce the other. This
means that if we were to attempt to establish secure communication via
email (signed, encrypted messages sent between each other), I would
not be able to verify that your 'Ian G' identity is the same as your
legal identity. (Since I use my mostly-full name to sign my mails,
you wouldn't have the same issue as such, but that's only because of
my choices to export my identity information into this context.)
So, it would make sense to have a CA that would be willing to assert
that you are '[EMAIL PROTECTED], member of mozilla-crypto' -- but the
only CA that would be able to make that assertion with any authority
would be a CA run by the people who run the mozilla-crypto list.
(That is, the mozilla-crypto list has a central database of members, a
central point of administration, and people can be booted from it if
they spam -- thus making it plausibly desirable to be able to revoke
the certificates thus issued if someone shows themselves to be a bad
citizen.)
However, it would also be useful to be able to prove context-dependent
identity outside of the original context -- for example, when one of
the MoFo execs wants to express that "the execs are discussing
<this>", it would be very helpful to be able to verify that with a
certificate from a "Mozilla Foundation Executives" CA. Or a "Module
Owners CA". Or such. (The 'security' module owner holds a specific
role, and that role can be transferred to somebody else.)
This leads to a notion of "context-dependent identity" -- which can be
generalized to be a "role-dependent identity", or perhaps more simply
"role identity". Note that in this case, "financial and legal
identity" is a specific role identity that people have; this notion of
expanding identity is a proper superset of the 'fiscal identity'
concept.
> > - I believe that restricting which CAs are allowed to embed their root
> > certificates beyond purely technical/interoperability concerns is
> > counterproductive.
>
> Concur.
Note, however, that I didn't say that restricting what those
certificates are allowed to assert is counterproductive.
Financial/fiscal CAs play an important role: they provide some level
of assurance of financial/fiscal identity. This means that operations
which rely on the financial/fiscal identity being known (such as, say,
financial or fiscal operations, like a request to the PayPal site to
transfer money to someone else's account) need to be assured that the
request is actually going to PayPal and not somebody else's site that
looks and feels like PayPal's site in all respects.
(This is why I'm annoyed with Thawte's SSL123 program -- it violates
the paradigm which was specifically created in response to their only
issuing High-Assurance certificates to websites, thus encouraging a
certain complacency about verifying site details. No browser
currently existing has the code necessary to enforce Thawte's stated
policy, and Thawte is now abusing that lack.)
Expanding the role of a CA from 'financial/fiscal' to 'anyone with a
URL' removes the ability to trust that the financial/fiscal identity
has been assured by someone trustworthy, unless the certificate
attributes are verified. (There are loopholes to the financial/fiscal
identity verification which can allow fraud to occur, most
certainly... however, the fraud would not need to only be perpetrated
against one individual in that case, thus increasing the liability
incurred by the fraud and the chance for detection [many eyes are
better than one].)
If a given CA is forthright about what it will certify, though, and
doesn't deviate from it, it's possible to trust it for what it says it
is. At least as far as you trust the CA to not deviate from it.
Fiscal frauds are much more quantifiably damaging than social frauds,
after all.
> > - I believe that X.500, as a concept, is a joke. Thus, I believe that
> > requiring certificates to only be issued with X.501 DNs is absolutely
> > intolerable.
>
> OK. I think this is a widely held view among security
> fields, but in corporate circles, especially those that
> are selling product, it is the "best practices" view.
> That will change over time; especially now that there
> is a groundswell against the use of models that do not
> protect the user.
"Best Practices" only happens to work for those people who rely on the
content of the certificate for some business-related reason. There is
no model in place for an association which wants to issue certificates
so that its members may securely communicate, and "best practices" in
corporate circles do not hold in that circumstance.
Furthermore, if X.500 is held to be a "best practice", why don't
companies hook up their LDAP servers to the global Directory which was
envisioned? [slightly red herring, I know, and you may ignore this
question if you wish.]
> > On the flip side, however, I also have to frame my arguments within my
> > knowledge of accounting, business, and law. (I'm not a CPA, MBA, or lawyer
> > by any means, and my interpretations are my own. I have discussed these
> > concepts with legal professions in the past, and I continue to refine them
> > as appropriate, but these are the extents of my knowledge and authority.)
>
> Let's hear it! We need more perspectives in the debate.
>
>
> > - Cryptography can be used to verify legal/fiduciary identity.
>
> I don't think so. (But let's leave that for now.)
The USPS actually has a CA-type identity certification program... or
at least it did, unless it was removed in later regulations. Banks,
which must have access (by law, in the US -- all of my arguments are
US-based, if you had not yet noticed) to at least two forms of
identification are in the perfect position to be able to certify the
binding of a keypair to a specific legal/fiscal/financial identity --
as they are liable for fraudulent transactions which they allow to
occur against the customer's account.
There are certain circumstances in which verification of
legal/fiduciary identity verification can take place in cryptographic
trust systems -- most of which rely upon a "secure device" to hold the
key and certificate, and perform the necessary operations to prove the
possession of the private key. I would very much enjoy discussing
this topic further, though we can take it off-list as necessary.
> > - People involved in a financial transaction are required to collect a
> > certain amount of information about each other -- running the gamut from
> > "the money's good" for cash transactions, to the verification that the
> > person giving a given CC number actually owns it ("the card verification
> > code matches", or as brick&mortar merchants were originally required to do,
> > "verify that the signature matches").
>
> If you were to say, "people want to collect information ..."
> I would agree. Or, if people had every right to collect
> information before trading, yes. Required? No. Must?
> Definately not. Have to be protected from...? No chance,
> risk is good. Risk is what lets us learn. Making mistakes
> is critical and integral to our future survival. Risk is
> the foundation of capitalism. The day someone steps into
> to protect us from our own mistakes is the day we lose our
> own self, and our own choice, and our freedom. We have
> the right to make mistakes, and woe be he who tries to
> take that from us.
I should perhaps amend that statement: "People who wish to maintain a
level of legal accountability are required to obtain certain
information about each other. If they wish to forego the ability to
hold someone legally to task, they may forego the collection of that
information.
Transactions that occur outside of the bounds of what is legal (for
example, illegal drug trading) automatically have no legal recourse,
because to attempt to bring legal recourse to bear they would have to
admit to engaging in an activity which carries criminal liability.
Cash is the only viable option for this type of trade, and that is one
reason why it is very easy to obtain credit or debit cards anymore --
to ensure that transactions are traceable, not only forward (from the
buyer to the seller), but also backward (from the seller back to the
buyer, if the seller is busted).
> > - It is not legal to sell a product without a warranty of merchantability.
>
> Where did you read that? Who told you that?
>
> Caveat emptor. If a good is bad, then there may be an
> action. But how do you imply a warranty?
Uniform Commercial Code of the US, and various Supreme Court decisions
since its adoption by the several states. Disclaimers of warranties
are not enforceable. (For example, if you purchase a car and it
breaks down in some manner that causes danger to you or other vehicles
on the road, and it's determined to be a manufacturing fault, then the
manufacturer is liable -- even if you signed a document stating that
you're waiving the warranty of merchantability or fitness for a
particular purpose.)
Caveat emptor, indeed -- but its action is to reduce fraud by
increasing the enforcement and liability associated with wilfully and
intentionally selling shoddy merchandise.
Software is a different story -- it's licensed, not sold, and terms of
licenses may include disclaimers of warranty.
> > The person paying must obtain information about the merchant in order to
> > take them to task for it, however.
>
> OK. There may be an action against a bad merchant. In
> law this is a reasonable statement. But, the fact that
> there may be an action does not mean anything until it
> is tried in court. Disputes need to be resolved, they
> are not automatically awarded to the party we most want
> to win. What I'm saying here is that you are building
> up a conclusion on a thread of logic that does not support
> it.
Most certainly -- but in order to bring an action, you must know who
you're bringing the action against. (Courts have specifically and
repeatedly rejected the notion of a "John Doe" lawsuit against someone
who cannot be identified for service.) That's the function of a
certification of fiscal/legal identity by a CA.
> > - The Certifying Authority is required, because of these legal/fiduciary
> > reasons, to verify the legal/fiduciary identity of anyone who requests a
> > certificate.
>
> No. If you think otherwise, please cite. AFAIK, a CA
> has no fiduciary or legal duty to do anything at all,
> except as may be expressed under certain digital sig
> laws; and those need to fully regulated (in that many
> jurisidictions left them incomplete). And that's quite
> rare and has never been tested in court, to my knowlege.
A CA has a legal duty to uphold its agreements. Most CAs (and
certainly all commercial CAs that I know of) include their CPS by
reference into all of their agreements, thus binding them to that with
civil liability (or criminal liability, if violation is done wilfully
and thus fraudulently).
> There's a lot of hype. And there's reality. In reality
> a CA has no duty to do anything. They may get massacred
> in court one day over their statements and pretentions,
> but that's not something we as users or browser manufacturers
> can rely upon. Until that day, be careful.
The US does have a digital signature law, at the federal level, which
has the power to govern any and all transfers of money or goods based
on digital signatures. It's been a while since I've read it, so I'm
going to read it again to be certain of what it says before I go off
onto any conjectures.
Most certainly, 'be careful'. Everyone should be careful online...
but if the price of that care is to depress or suppress economic
activity, there's issues that seriously need to be fixed. The
commercial CA industry has been unregulated primarily because of its
willingness to self-police; however, if it ceases doing that,
regulation will follow. Online sales are (in my opinion) too
important to the US's economy to allow anyone involved to be
unfaithful.
> > This is encoded as an international standard, part of the
> > X.500 series [I don't remember which one off the top of my head]. [minor
> > quibble: many of the X.500 series of 'recommendations' have been
> > standardized by the International Standards Organization, thus I use the
> > term 'standard'.]
>
> It really matters not a jot if it is encoded in international
> standards or not. Remember, the Internet itself is not an
> international standard, it is an IETF standard, which is
> just a bunch of nerds who go to conferences every 6 motnhs.
>
> International standards have no standing unless you grant
> them yourself, they do not give you any force over other
> people. They are, to all intents and purposes, documents
> for other people.
Right... just as the American National Standards Institute doesn't
have any means to enforce its standards on people within the US.
(Except that their standards are the ones that get encoded into law...
and since ANSI is a member organization of the ISO, guess which
standards it's going to end up following and having encoded into the
aforementioned legislation?)
> > Netscape, back when it created SSL, attempted to make it as
> > internationally-standard as possible, and thus implemented the restriction
> > that all certificates must be in X.509 format for identification. The SSL
> > standard went on to become an Internet standard, superseded by SSLv3, then
> > TLSv1, and now there are the (not yet standard) extensions to TLS which
> > finally started accepting non-X.509 certificates as peer identity
> > certificates. (Specifically, OpenPGP.)
>
> As far as I know, TLS is an RFC, but is not an international
> standard. Either way it doesn't matter. It's simply not
> important whether it is or not.
What's important is the interoperability. But look at the original
purposes for which Netscape created SSL, trying to build an
application which could be used over the CIX for commercial purposes
without having to worry too much about it being eavesdropped by
unauthorized parties...
> > For 10 years, customers have been taught that if there's a lock icon (in the
> > beginning of Netscape it was a 'solid key' icon and a blue bar), the
> > connection is secure. This is true as far as it goes -- nobody can
>
> Er... I'm not sure I even agree with that. Customers were
> told it was secure. They weren't told what secure meant.
>
> And when phishing turned up, all those people who said you
> were secure from spoofing kind of disappeared. All those
> people who said it was secure were never able to answer the
> question as to whether it was relevant in a world of server
> hacking.
>
> So if you can figure it out, you're doing better than I.
So I go back to my original question: what /is/ 'secure' defined as?
> > eavesdrop on it, certainly, but you still have to explicitly ask your
> > browser who it is who has been issued the certificate which has been
> > trusted.
>
> Yeah. Now this is a big hole in SSL's secure model. So
> big you could drive a truck or an oil tanker through it.
To be fair, I think this is an artifact of 640x480 screen resolutions.
Now that we have higher resolutions available, there's no reason we
can't have something like a 'security bar' that pops up in a specific,
unspoofable format that says 'You are talking to: <DN>. Identity
assured by: <CA DN> (manually trusted | browser built-in). for more
information, click [lock icon].' Granted, I'm abusing the concept of
'unspoofable' here (though putting it in a special unscriptable color
in the browser's status line at the bottom is fairly secure against
javascript and java attacks, it wouldn't do anything against plug-in
developers).
> > (When the only webserver operators who got certificates that would
> > work had to prove their identity to the CA, that made a bit of sense... it
> > made certain that you were only giving your credit card number or financial
> > information, which was Netscape's initial drive for implementation of SSL,
> > to someone who had had his legal identity verified. It provided for the
> > reduction of 'con men' in the game.)
>
> No. That was just the advertising. The reality was that
> there were no economic con. There still isn't; phishing's
> too easy. Con men, unlike techies, are economically
> motivated and know when to leave a con alone. Don't worry,
> they'll get to SSL-protected comms soon enough. But they
> ain't there yet.
*gasp* you mean the UN willingly created a useless recommendation that
wouldn't do anything that it said it would? :)
> > However, there's some new issues in light of this. People are much more
> > willing to put their credit card number on any website that is 'secured'.
> > People even apply for credit cards over the net, across 'secured' websites.
> > Remove the requirement for identity proof to obtain a certificate, and you
> > suddenly remove the barrier, making con-men much more able to do their jobs
> > without interdiction.
>
> OK, let's get serious here. You are assuming that the current
> "strong identity" checks are working to keep conmen out. Let
> me propose a counter theory: they haven't bothered! The day
> they want to, they won't find much difficulty.
Under the current structure of CAs being trusted for everything or
nothing in a given domain (www server ID, email ID, code signing ID)?
You're right. Under the current structure of users having to go
through a manual process to figure out who they're talking to? You're
right.
> Now, if this is the case, the so called "identity barrier"
> hasn't been tested. You have no reason therefore to have any
> faith in it. Unless you can present some evidence, we have to
> simply assume that it *might* protect or it might not.
Much of the problem here is that CC customers aren't liable for more
than $50 at most, and there's no economic incentive for them to learn
to do their own due diligence.
> (I predict it won't. There are lots of examples and case
> evidence where certs have been available in *any* name for
> several years. No barriers there except plonking down the
> dosh.)
Are these certs that have been issued by CAs that have had their certs
embedded in general-use browsers? If so, can you provide specifics?
(If not, I don't think it's relevant in this discussion.)
> > Also, the VISA network recently started demanding much more stringent
> > control of customer information. In conjunction with identity, this imposes
> > a high degree of accountability... but only if the customer knows who they
> > give their credit card information to, and thus who to hold to account.
>
> I agree that the browser should always tell the user who
> signed the cert. That's a no-brainer.
>
> But, one objection. Where did we say that SSL and CAs and
> web browser manufacturers were working for VISA? Who pays the
> salaries around here? Why is it that you assume that purpose
> of SSL and certificates is to protect credit cards?
The purpose of SSL and certificates /was originally/ to provide for
the ability to securely identify who you were talking with, with
tamper-resistance and privacy as options. What you do with it is your
own business. However, the initial inability to import a CA
certificate other than Verisign's into Netscape, and then the
inability to get your CA cert embedded if you didn't follow the same
type of verification process that Verisign used, created a de facto
environment that allowed Netscape to advertise that you could (in the
financial/fiscal identity sense) purchase things securely, online.
Remember: I am NOT, under any circumstances, against multiple CAs, nor
do I think that the only application of SSL is fiscal. However, just
as law is made by slow and considered movements of rational thought, I
am stuck in a mindset that requires that "what has gone before" be
taken into account when deciding "what comes next".
> In practice, credit cards already have protection. They are
> protected in most states beyond $50 or equiv. Why are we then
> expecting the net to do more? And, if we are expecting the
> net - that's all the Mozilla programmers, all the Apache
> programmers, me, Frank and yourself ... the TLS committee,
> and anyone in the crypto community that's ever contributed -
> then, where do we collect our paycheck for the work we have
> done in protecting VISA?
They're protected by federal regulation to $50, but VISA/MC and their
card issuers have generally chosen to reduce that to $0. At least in
the US. [/minor quibble]
As for 'expecting the net to do more', with your caveats: I have a
vested interest in ensuring that the economy of the US continues to
recover. Getting involved in browser security is one of the most
important ways that I have to do that. (As with open source in
general... sometimes creating a good product is worth more than direct
economic compensation.)
I'm not 'expecting the net to do more'. I'm 'expecting the net to
uphold its original design principles'. Work together for the common
good, create standards and procedures and "Best Current Practices" for
the benefit of the whole, avoid non-interoperable proprietary
extensions to the best of your ability, and use the knowledge which
has been gleaned before to improve things incrementally. Yes, the
IETF is a bunch of geeks who like to party every half-year or so...
but the IETF also ended up creating the de facto standard for
interoperability, above and beyond that which the ITU (then CCITT) was
able to offer.
Currently, there are a lot of attacks against the IETF process. I'm
finding it interesting watching to see how the game unfolds.
> I'm sorry. There's a mistake here. SSL is for protecting *all*
> users from *any* threats. VISA is not the only one, and they
> should not be permitted to set their standards without paying
> the piper.
Absolutely. VISA needs to either create its own CA and its own CPS
that it (and its member financial institutions) can live with, or
contract to another CA that has a CPS that it (and its member
financial institutions) can live with. They haven't, because the
current crop of commercial CAs have done their job for them (by
adhering to ITU, ISO and ANSI requirements for certificate issuance).
This is why I say that it's inevitable for more CAs to crop up -- the
current ones all address slightly different needs.
This doesn't mean that we get to abdicate our responsibility to the
users of the software, though.
> > So, what I would propose is 'warn the user when submitting a form to a site
> > secured by a CA that does not provide for proper identity in its CPS, and
> > audited by (for example) the WebTrust auditing process.' Also, impose
>
> You are proposing that for all CAs and all certs? IMHO, no
> CA conducts proper identity, because that's a concept that is
> very hard. It really only exists in the minds of those who
> don't need to rely on it.
So how do you do 'proper identity'?
> Let me put it this way. If you were from the fraud world and
> were interested in using certs to stop fraud, you'd be ignoring
> identity totally and discussing what the $$$ guarantee on each
> cert was worth. Anything else is meaningless (identity included).
2 times the price of a certificate, at least in Thawte's.
> > policies on the certificates issued by those CAs [I'm explicitly thinking
> > Thawte, here], and require that they uphold the terms in their CPS as far as
> > can be verified.
>
> No chance. Mozilla, me, you, no person anywhere nearby has
> any chance in hell of telling CAs what to do. Even Microsoft
> has a problem with that.
The only way to win is not to play their game, and the only way to do
that is to yank the trust of their root.
> Thwarte? What's wrong with ...
>
> > (Thawte's CPS states that they will only issue web-server certificates to
> > entities with High Assurance of identity. Thawte has recently started
> > issuing, from the same root, certificates to entities with merely web
> > address verification, through its SSL123 program -- I will assume that you
> > all know this, and move on.)
>
> ... OK. Yes. Here's what I suggest you do. TELL EVERYONE.
> Yell it from the rooftops. But, this is no grounds to
> stop supporting Thwarte as a member of the root list. If
> they want to run the risk of being a low faith supplier
> of certs, let them. Tell the users!
Absolutely -- but how do we tell the users that there are issues with
the issuer of the certificate? The same interface is brought up for
Verisign, for Entrust, for EVERY OTHER TRUSTED CA. There's no
warning, no way of informing, nothing.
> > CAs which have audited CPSs that state that they will only issue
> > certificates with O=, OU=, S=, L=, and C= attributes in the DN to entities
> > which have had their legal identity verified should have their issued
> > certificates validated as such, and only 'trusted' for forms submittal if
> > those attributes truly exist, otherwise warn in the same way as a
> > non-audited CA. (The idea is to ensure that the policy which is stated is
> > actually upheld.)
>
> Tell everyone. Give us some documented examples. Make
> their lives not worth living.
If I had the money necessary to get an SSL123 certificate, I would
submit that as evidence. Unfortunately, I don't. And I don't think
Thawte's going to give me lists of websites that have purchased their
certificates under the SSL123 program.
> > At issue is identity theft, and 'phishing'. I've installed the CACert root
> > in my browser, and have a webserver which has a certificate therefrom. I am
> > in the process of figuring out if the other redirection-warnings are
> > sufficient to provide at least a notice that there's some issue with the
> > connection, for other possible bug reports.
>
> Good stuff. I like CACert. I think they would get a 7-8
> points in any serious identity breach. Which is to say, I
> know how to breach their checks. The "classical" CAs are
> all below 5, which is to say, everyone knows how to breach
> their checks. So ...don't trust your money with their certs,
> alone, make sure you do due diligence on the merchants.
...and how do you do due diligence on the merchants if the
legal/fiscal identity isn't known? You're arguing in circles, here.
> As you and every other user already does.
Actually, since I know what I'm looking for, I do. 'every other
user', though... yeah. :P
> > Now. As I said before, I'm all for the idea of alternate CAs, and I am all
> > for certificates being issued based on information available to those
> > alternate CAs. I believe that membership organizations (and even websites
> > with forums and such) should run their own CAs, issuing certificates to
> > people who prove possession of access credentials to accounts within those
> > realms. These CAs should /not/ be trusted for financial transactions,
> > because they don't prove fiscal identity... and eventually I'd like to see a
> > user-interface change in all browsers where the lock icon is joined by some
> > kind of 'fiscal verification' icon when the certificate is issued by an
> > audited fiscal CA in accordance with its CPS. (Get WebTrust to have its own
> > CA, which issues chained CA certificates to commercial CAs which it has
> > audited. Why it doesn't do that already is beyond me.)
>
> Nah... there is nothing special about *financial* transactions
> except that it is easy to work out how much money is at risk.
The other special aspect of 'financial' transactions is that you have
the ability to ensure accountability through the legal system. At
least hypothetically.
> There's nothing in the book that says you need to show fiscal
> identity. (What the hell is fiscal identity, anyway? Are we
> working for the fiscal authorities? Is this the agenda? Since
> when is Mofo an agent of the fiscal police?)
When are users reliant upon MoFo to provide a secure framework for
conducting business over the net? It's not the fiscal police that
MoFo has a duty to, it's the users -- who need all the help they can
get.
(Besides. Nothing's going to change in the socioeconomic system if
these things aren't changed, if users aren't forcefed the ability to
do their own due diligence. As I mentioned before, law changes very
slowly, and much of this electronic commerce thing is still legally
unexplored territory. VISA and banks would absolutely love it if
there were a way to force culpability onto the end-user if said
end-user was remiss in his or her due diligence. It would eventually
become the standard, and then the standard would be encoded into law.
Whoever says we're not creating the prototype instruments which will
be used to shape future society is ignoring the effect of the printing
press. :P)
> Finance has been conducted on a dynamic, negotiating basis since
> the dawn of time. People have very strong abilities to know when
> *not* to trust deals. The process of arriving at trust is very
> well developed in people's heads. It is a most amazing thing to
> watch. But, it is nothing, niz, nada, zip to do with SSL certs,
> identity and the notions of certain companies that thought that
> they could make a billion of dotcom naivete. Those companies are
> gone. (well almost.) Let's concentrate on what we have here and
> now, which is protecting *browser* users from *real* threats.
Yes. And in the 19th century, robber barons and other "old money
folk" got their money by what would today be called swindling and
cheating. That's where the current legal system, and a whole host of
"Thou Shalt Not (on pain of)" laws come from.
> I.e., phishing. And, some small amount of eavesdropping. But
> primarily phishing.
I absolutely agree that phishing is a real threat. This is why I'm so
anti-Thawte at the moment.
> Thanks for commenting!
And thank you for your insights. :)
Cordially,
Kyle A Hamilton
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
