Misc AADS & X9.59 Discussions
AADS Postings and Posting Index,
next, previous
- home
- The case against directories
- Who's afraid of Mallory Wolf?
- Who's afraid of Mallory Wolf? (addenda)
- Armoring websites
- Who's afraid of Mallory Wolf?
- Who's afraid of Mallory Wolf?
- The case against directories
- Bank Float May Sink
- Labour to launch ID card - and it'll cost you £25
- "Marginot Web" (SSL, payments, etc)
- Microsoft Identity Server Prepped For Windows Server 2003
- Oasis Pushes Global E-procurement Standardization
- Tackling security threats from within
- A Trial Balloon to Ban Email?
- blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
- blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
- Payments as an answer to spam
- Payments as an answer to spam (addenda)
- Payments as an answer to spam (addenda)
- Payments as an answer to spam (addenda)
- Payments as an answer to spam (addenda)
- Financial Privacy To Take The Floor
- Identity Theft Losses Expected to Hit $2 Trillion by 2005
- Maybe It's Snake Oil All the Way Down
- Microsoft Ties Security to Verisign
- OASIS and RosettaNet Set Standards Alliance
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- Maybe It's Snake Oil All the Way Down
- An attack on paypal
- An attack on paypal
- virus attack on banks (was attack on paypal)
- The real problem that https has conspicuously failed to fix
- An attack on paypal
- Keyservers and Spam
- An attack on paypal (trivia addenda)
- An attack on paypal
- The real problem that https has conspicuously failed to fix
- certificates & the alternative view
- An attack on paypal
- PKI "not working"
- PKI "not working"
- Keyservers and Spam
- An attack on paypal
- UK: PKI "not working"
- basic question: semantics of "map", "tie", etc in PKI
- replay & integrity
- E-banking is board-level Issue, Says Basel Committee
- Feds, industry warn of spike in ID theft scams
- Committee calls for better e-banking security management
- IT Managers Critical Front in War on Identity Theft
- Draft E-Authentication Policy for Federal Agencies
- The Best ID Plan? Wait and See
- IT Security to be added to FAR
- Kinko's spy case: Risks of renting PC's
The case against directories
Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 03/23/2003 12:16 PM
To: David Chadwick <d.w.chadwick@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
epay@xxxxxxxx, ietf-pkix@xxxxxxxx
Subject: Re: The case against directories
ref:
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
we've had some long term experience in this. the kerberos reference
.... was from one of the audit visits that my wife and I did on
project athena .... and sitting thru an extended detailed description
of the "new" cross-domain kerberos protocol .... and various
subsequent discussons.
however, going back even further ... almost 25 years ago ... a couple
of us were sitting around friday night trying to think up ways of
getting upper management interesting in online use. one of the
compelling business uses was an online telephone directory (for some
450,000 or so employees & increasing). we had some simple
objectives .... 1) online lookup elapsed time faster than reaching for
a local site paper directory and looking it up, 2) take 2 person weeks
or less to implement, 3) take less than a half person day per month to
support, 4) in addition to existing informaiton like name, telephone
number, internal mail-stop ... allow it to grow into things like email
address.
so we started contacting various plant sites .... asking for process
that would regularly transmit the machine readable copy that they used
for producing the site's paper directory. It turned out what started
to consume the most time were discussions with the site security
officers about security classification of an online directory
.... that was only available inside the corporation ... and only
contained name and telephone number ... and was an exact duplicate of
the paper directory. Paper directories were classified internal use
only .... the security officers wanted to classify the equivalent
information (even if it was only name and telephone number) when made
available online at a significantly higher security level (even if it
was only accesable from inside the corporation).
much longer (including technical) description of the online telephone
directory effort:
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
note that the internal network at the time was larger than the
internet/arpanet and continued larger up thru approximately 1985.
http://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
http://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET
http://www.garlic.com/~lynn/internet.htm#22 internal network's 1000th node
http://www.garlic.com/~lynn/2003d.html#59 unix
totally random trivia was in the mid-80s i was told that the internal
network had over half of all link encryptors in the world.
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
d.w.chadwick@xxxxxxxx on 3/22/2003 7:26 am wrote:
Lynn
well said. Access controls and privacy issues apply regardless of
technologies.
David
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 10:10:53 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf?
Cc: cryptography@xxxxxxxx
At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote:
Who's afraid of Mallory Wolf?
slight observations ... i've heard of no cases of credit card number
intercepted on the internet "in flight" (requiring crypto) ... and no
known cases of MITM attack (requiring certificates)
However there have been some cases of impersonation ... being directed
to a counterfeit web-site. I know of no cases of that being done with
DNS cache poisoning ... which is also what certificates are targeted
at ... both MITM and other impersonations of various kind. the ones
i'm aware of is that the person clicks on some URL and goes to that
site .... which is a counterfeit website. This isn't caught by SSL
... since it just compares the domain name in the URL against the
domain name in the certificate presented by the server. Since the
subterfuge happens well before any DNS cache is involved ... the SSL
check of matching domain names doesn't catch anything. There have also
been various impersonation involving frames and other screen painting
techniques.
There have been cache poisonings (ip-address take over) ... there have
been also incidents in the press of domain name hijacking ... sending
updates to domain name infrastructure convincing them that somebody
else is the new domain name owner. getting a new certificate as the
new domain name owner is also a way of subverting the SSL check of
matching domain names.
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1
http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2
people registering public keys at the same time they register domain names was one of the suggested countermeasures to domain name hijacking.
There was another press thing last week regarding DNS attacks. The
issue raised by the DNS attack last fall and the latest warning is
that these have the potential to bring the internet to a halt.
http://www.computerworld.com/securitytopics/security/story/0,10801,79576,00.html
so there is some effort regarding dns integrity because of its
critical importance for just having internet function at all.
past dns attack refs:
http://www.garlic.com/~lynn/2003.html#49
also
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,75564,00.html
http://www.zdnetindia.com/news/commentary/stories/73781.html
http://www.zdnetindia.com/print.html?iElementId=73777
from a cost of business standpoint ... i've suggested why not use the
existing DNS infrastructure to distribute server public keys in the
same way they distribute ip-address (they are pieces of information
bound to the domain name, a function of the domain name
infrastructure).... and are capable of distributing other things
... like administrative & technical contacts .... although that is
getting restricted ... some bleed over from pkix
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories
they could be naked public keys ... which would also be subject to DNS
cache poisoning ... or they could be "signed" public keys
.... doesn't need all the baggage of x509 certs ... can just be really
simple signed public key.
Slightly related to the above posting about long ago and far away
.... when looking at allowing people (20 plus years ago) on business
trips to use portable terminals/PCs to dial in and access the internal
network/email .... a vulnerability assesement found that one of the
highest problem areas was hotel PBXs. as a result a special 2400 baud
encrypting modem was created. encrypting modem anecdote from the
time:
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
... these weren't in any related to the link encryptors from the
previous reference (aka supposedly over half of the link encryptors in
the world were installed on the internal network).
in any case, there was a big concern about numerous kinds of
evesdropping ... requiring encryption for information hiding. however,
the current internet credit card scenario seems to be that it is so
much easier to harvest a whole merchant file with tens or hundreds of
thousands of numbers ... than trying to get them one or two at a time
off some internet connection.
note that the x9.59 approach has always been to remove the credit card
numbers as a point of attack (form of shared-secret) by requiring all
transactions to be authenticated. as a result, just knowing the number
isn't sufficient for fraud (countermeasure against all account number
harvesting .... regardless of the technique and whether insider or
outsider attack):
http://www.garlic.com/~lynn/x959.html#x959
the low-hanging fruit theory is that if merchant sites were armored
then there could be more interest in evesdropping-based harvesting
... (leading to more demand for internet encryption). However.
armoring merchant sites is difficult since 1) there are potentially
millions, 2) human mistake is frequent/common vulnerability, 3) still
leaves insiders as threat.
other parts of security proportional to risk thread:
http://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#28 Security Proportional to Risk (was: IBM Mainframe at home)
Who's afraid of Mallory Wolf? (addenda)
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 10:21:47 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf? (addenda)
Cc: cryptography@xxxxxxxx
.... and while I don't know of any internet-based evesdropping for
account number harvesting .... there are numerous reports of skimming
in the physical world .... harvesting of account numbers by all sorts
of techniques. These include things like video cameras by crooks
trained on various kinds of POS and other terminals.
misc. skimming references:
http://www.garlic.com/~lynn/aadsm12.htm#40 In Brief: Anti-'Skimming' Guidelines Coming
http://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
http://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
http://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data From ATMs (including PINs)
http://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
http://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In The US
http://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
http://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data From ATMs (including PINs)
http://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
http://www.garlic.com/~lynn/2002i.html#74 A Lesson In Security
http://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert?
http://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ?
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
Armoring websites
Refed: **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 12:29:17 -0700
To: Ian Grigg <iang@xxxxxxxx>
Subject: Armoring websites
Cc: cryptography@xxxxxxxx, epay@xxxxxxxx
ref:
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)
here is discussion of armoring websites with respect to security
proportional to what is at risk
http://www.garlic.com/~lynn/2001h.html#61 net banking, is it safe???
http://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk
random refs to hardened sites:
http://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation.
http://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
http://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
http://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002m.html#6 Dumb Question - Hardend Site ?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2003c.html#52 diffence between itanium and alpha
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Mon, 24 Mar 2003 17:50:17 -0700
To: daw@xxxxxxxx (David Wagner)
Subject: Re: Who's afraid of Mallory Wolf?
Cc: cryptography@xxxxxxxx
At 10:02 PM 3/24/2003 +0000, David Wagner wrote:
You could take your argument even further and ask whether any crypto
was needed at all. After all, most attacks have worked by
compromising the endpoint, not by sniffing network traffic. I'll let
you decide whether to count this as a success story for SSL, or as
indication that the crypto wasn't needed in the first place. (I'm a
little skeptical of this argument, by the way, but hey, if we're
playing devil's advocate, why not aim high?)
I assert that there may be more sites that transmit credit card
numbers w/o crypto, as sites that use SSL (although transaction rates
are highly skewed so they even if it were ten times the number of
sites, it might represent fewer actual transmissions). I don't have
actual numbers, but I am aware of significant number of
sites. However, I would contend that harvesting numbers from end-point
merchant files has significantly higher return (ROI, expected results
for the effort) than any sort of network evesdropping ... and that it
is practically impossible to provide the necessary armoring as
countermeasure for this vulnerability; end point attacks by either
insider and outsider (historically, insider attacks on financial
infrastructure have represented vast majority of incidents. While it
may be possible to do a single armored site .... it isn't practical to
do a million such sites (for one thing, people make too many mistakes)
... as per previous ref to security proportional to risk (and the
merchant file risk is proportional to the credit limits of the
accounts, not the specific merchant transaction).
I would expect that network evesdropping would be employed where
vulnerability was something other than kind of fraud do'able by
attacking the end-point merchant file. Note however, skimming (various
kinds of electronic & non-electronic recording) does go on in the
physical world. Part of the issue may be that the target object
(account number) has much lower occurance in general internet traffic
(physical world skimming involves traffic that is almost solely
account numbers). If you just have to skim, there are some number of
points that are much more target rich environments (better fraud ROI)
than internet traffic.
There is some phrase that if the only thing you know how to use is a
hammer, then every solution may involve a nail.
The fundamental problem with account numbers is that they are
effectively a kind of shared-secret .... acquiring/harvesting the
numbers enables fraud. There are significant number of business
processes that require the availability of the account numbers. This
is one of the reasons for the end-point merchant files and also why
"SET" (with significantly more complex crypto infrastructure and
essentially only, also addressing data in-flight) offered very little
additional over what my wife and I were involved with setting up the
original SSL for e-commerce.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
The point of x9.59 wasn't to add even more layers of crypto and
information hiding to protect these shared-secrets .... but to change
the business model so that the account numbers were no longer
shared-secrets. X9.59 uses simple digital signature for authenticated
payment transactions and a business rule that account numbers used in
x9.59 transactions can't be used in non-authenticated payment
transactions.
http://www.garlic.com/~lynn/x959.html#x959
aka just by evesdropping an x9.59 transactions or harvesting account
numbers used in x9.59 transactions doesn't enable a crook to initiate
a fraudulent payment transaction.
Who's afraid of Mallory Wolf?
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 25 Mar 2003 15:32:00 -0700
To: bear <bear@xxxxxxxx>
Subject: Re: Who's afraid of Mallory Wolf?
Cc: Ian Grigg <iang@xxxxxxxx>, cryptography@xxxxxxxx
At 12:09 PM 3/25/2003 -0800, bear wrote:
ISP's don't want to support encrypted links
because it raises their CPU costs. And mail
clients generally aren't intelligently designed
to handle encrypted email which the mail servers
could just "pass through without decrypting and
encrypting".
circa '95 .... there were comments that ISP's didn't want to verify
from/spoofed packet addresses on DHCP modem connections because it
increased their router cpu costs (actually one of the most common
routers didn't have enuf processor power to implement even trivial
packet filtering on modem lines).
http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
now there is the observation in this thread (or the previous thread)
that many websites use SSL very sparingly because it cuts their web
traffic capacity by 80-90 percent (http vis-a-vis https given the same
hardware).
Typical sequence is that person clicks-on/types something and goes to
a site with straight HTTP, they shop for a while ... until they are
ready to check-out, they then click on the "check-out" button. That
button supplies a URL that sends them off to a HTTPS site (aka the
user didn't actually originated the HTTPS url) ... where all the
payment information is provided. Now since the client/consumer never
provided the actual HTTPS sequence .... but it was provided for them
by a webpage at the HTTP site they were shopping at .... it is
presumably trivial for the HTTP site that they are shopping at to make
sure that the HTTPS URL domain that clients are sent to .... matches
the certificate domain at that site (and a lot of shopping URLs have a
lot of appended history so that it is relatively easily contrived that
the consumer doesn't notice the domain name of the "check-out/payment"
page).
A lot of the requirement for encryption is end-to-end ... or at least
VPN-like .... so encrypted packets should mostly be transparent to
operations in their ISP roles. This isn't as true on the web-hosting
side of the house ... where SSL or similar encryption activity can
represent significant additional CPU processing load.
The case against directories
From: Lynn Wheeler
Date: 03/28/2003 08:34 AM
To: Peter Gietz <Peter.Gietz@xxxxxxxx>
cc: Anders Rundgren <anders.rundgren@xxxxxxxx>,
ietf-pkix@xxxxxxxx, owner-ietf-pkix@xxxxxxxx
Subject: Re: The case against directories
the one detailed implementation presentation I've seen on a SAML based
product .... looked exactly like Kerberos .... but the transmissions
were SAML-encoded (and carried authorizations in addition to
authentication)
misc kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
peter.gietz@xxxxxxxx on 3/28/2003 4:55 am wrote:
> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense. The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.
>
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.
SAML is a good but complex means for communicating
authorizations ans assertions, it is not a whole middleware
infrastructure.
Bank Float May Sink
From: Lynn Wheeler
Date: 03/31/2003 12:27 PM
To: Alanslater@xxxxxxxx
cc: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Re: Bank Float May Sink
the reference was not between technology issues of substitute checks
and e-check .... the reference was to some common business issues
regarding float (as in the subject line). there were two specific
processing implementations for e-check done by two different
organizations. one of the organizations chose a specific
implementation because it had more float than the other implementation
(and there was lots of business discussion of float with regard to
e-echeck) ... it appeared that lots of the business people seemed to
believed that the business issues of float by far dominated numerous
different technical implementations.
somewhat related is that the ACH networks tend to perform settlement
of some amount of check related funds (fedwire tends to handle higher
value settlement). however the aads nacha trials:
http://www.garlic.com/~lynn/x959.html#aads
used the ATM debit network providing real-time authorization.
there is some comparison with canada which is now doing ACH settlement
twice a day .... eliminating some amount of float in the ACH network
(however, canada has much fewer participants that need to be
syncronized).
random past discussion of float
http://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
http://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
http://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
http://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
alanslater@xxxxxxxx on 3/31/2003 8:55 arm wrote:
Lynn --
It would be incorrect to associate Substitute Checks in any way with
the FSTC e-check project. Several years ago, I created the concept of
Substitute Checks as a way to overcome the obstacles the industry
faced in implementing truncation projects. On the surface, the
concept is anti-intuitiive and defies logic (we're in the process of
solving the problem that it was also illegal) -- but it works.
Simply put, the concept allows an entity to digitize the image of a
check, place that digitized image into the payments system and then,
most importantly, gives the paying bank the option of accepting the
digital image or re-creating a paper copy, including MICR, for
payment. The Check Clearing for the 21st Century Act gives the same
legal standing to the digital image or re-created paper copy as the
original paper copy now has.
There are profound implications for this. Reduction in float is one
of the minor benefits. There are significant benefits that accrue to
consumers, banks and businesses from substitute checks. Consider the
benefits to consumers if the checks they deposit at an ATM are
digitized. Since banks no longer have to physically pick up checks
daily during very tight timeframes, checks deposited up to say 7pm
could be processed the same day (currently many banks use a noon
cutoff). This would make the funds from the deposited checks
available a business day sooner and would earn them additional
interest. Banks could accept deposits for other banks thereby
providing the other banks customers additional time-place convenience
without increasing in fact decreasing the other bank's risk of
returned checks. Merchants could be empowered and paid to accept
deposits further increasing consumer convenience.
With digitized images, banks could verify signatures and look for
signs of fraud at the time of deposit and make decisions about
availability on the spot.
Post offices could be used to create the digital images of payments
thereby eliminating physically moving the mail in addition to
physically moving the paper check.
For overseas payments, US checks become readily accepted payment
vehicles because the foreign countries can present these checks
electronically as if they had an office in the US down the block from
the paying bank.
I can go on for a long time about the benefits of this type of payment
but I'll end it here. However, if you have any ideas about how we
should handle checks presented in Hong Kong at 9 a.m. local time which
are presented in the U.S. on the day before they were written, I'd
like to know.
Regards,
Alan
Labour to launch ID card - and it'll cost you £25
From: Lynn Wheeler
Date: 04/20/2003 04:41 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Labour to launch ID card - and it'll cost you £25
http://news.telegraph.co.uk/core/Content/displayPrintable.jhtml?xml=/news/2003/04/20/nid20.xml&site=5
Labour to launch ID card - and it'll cost you £25
By Colin Brown and Francis Elliott
(Filed: 20/04/2003)
Everyone in Britain will have to pay around £25 for a compulsory
identity card under proposals being put to the cabinet by David
Blunkett, the Home Secretary.
The "smart" card will identify the holder using iris-recognition
technology. Failure to carry the card will not be an offence but
police will be able to order people to present it at a police station.
The charge is aimed at overcoming resistance to the scheme from the
Treasury. Until now Cabinet support for a national compulsory identity
card has been outweighed by the Treasury, which has objected to
footing the estimated £1.6 billion bill.
... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
"Marginot Web" (SSL, payments, etc)
Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 04/20/2003 05:01 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: "Marginot Web" (SSL, payments, etc)
note that x9.59 addresses many of the payment transaction issues,
however various social engineering vulnerabilities can still exist.
article:
http://www.iang.org/ssl/maginot_web.html
from above:
[4] This has been going on for a long time in the e-gold community,
but now seems to have crossed over to credit cards
New way to steal password. A Discover credit card customer receives an
e-mail telling him that his account is on hold due to inactivity, and
that in order to reactivate his account, he must log in to this phony
Web site. The information collected includes plenty of data that would
enable identity theft Social Security number, mother's maiden name,
account number, and passwords. Similar scams have targeted PayPal and
eBay customers.
http://www.msnbc.com/news/884810.asp
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,79380,00.html
http://tinyurl.com/7mgh
...........
the above referenced article includes references to the following
threads/postings
http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#27 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#28 How effective is open source crypto? (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#29 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#30 How effective is open source crypto? (aads addenda)
http://www.garlic.com/~lynn/aadsm13.htm#31 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#33 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#34 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm13.htm#37 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)
http://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Microsoft Identity Server Prepped For Windows Server 2003
From: Lynn Wheeler
Date: 04/29/2003 04:41 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Identity Server Prepped For Windows Server 2003
http://www.internetweek.com/breakingNews/showArticle.jhtml;jsessionid=XOGY0QCHI1VBQQSNDBCCKH0CJUMEYJVN?articleID=9400091
Microsoft Identity Server Prepped For Windows Server 2003
By Paula Rooney, CRN
San Francisco -- Microsoft is turning its attention to the identity
management space.
To that end, the software giant is preparing to launch the Microsoft
Identity Server, formerly referred to as Microsoft MetaDirectory
Services 2003, said Bill Veghte, corporate vice president of
Microsoft's Windows Server Group.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Oasis Pushes Global E-procurement Standardization
From: Lynn Wheeler
Date: 04/29/2003 04:43 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Oasis Pushes Global E-procurement Standardization
http://www.internetnews.com/dev-news/article.php/2197641
April 28, 2003
Oasis Pushes Global E-procurement Standardization
By Mark Leon
The Organization for the Advancement of Structured Information
Standards (OASIS) consortium has created a forum for government
agencies, organizations, and private companies to work together on
global e-procurement standards.
The new Electronic Procurement Standardization (EPS) Technical
Committee will analyze requirements, identify gaps, and make
recommendations for improving the interoperability of XML, internet
based e- procurement systems.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Tackling security threats from within
Refed: **, - **, - **
From: Lynn Wheeler
Date: 04/29/2003 04:46 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Tackling security threats from within
note some amount of following is about identity theft (by insiders)
and identity management (as a security paradigm/coutermeasure).
http://www.infoworld.com/article/03/04/25/17FEinjob_1.html
Tackling security threats from within
Bolstering your company's security system provides protection against
the enemy within
By David L. Margulius
April 25, 2003
A University of Texas student steals 55,000 Social Security numbers
from the school's administrative databases. A UBS Pain Webber system
administrator activates a logic bomb in the company's network, causing
$3 million in damage. A disgruntled Australian IT employee commandeers
his company's sewage management software to dump millions of gallons
of raw sewage into local parks and rivers.
... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
A Trial Balloon to Ban Email?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: Adam Back <adam@xxxxxxxx>
Subject: Re: A Trial Balloon to Ban Email?
Cc: cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>
the proposal in the past has been that ISPs filter spam at ingress
from their customers. the counter-argument has been that there are
lots of ISPs that can't be trusted to do it.
So it is much easier for ISPs to have lists of other trusted &/or
untrusted ISPs that they will accept email from.
It is orders of magnitude easier (and more efficient) for ISPs to do
ingress filtering for SPAM and effectively ISP blacklists than it is
to populate the whole consumer infrastructure.
There are still some ways to slip thru the cracks with small amounts
.... but it isn't the 40-80% volume of all email that is seen today.
It does have an analogous downside to the individual privacy issues
... which are that the big ISPs could use blacklisting for other
purposes than addressing SPAM issues.
Some of the ingress filtering pushback may be similar to the early
counter-arguments for packet ingress filtering related to ip-address
spoofing. however, that seemed to be more a case of disparity among
the router vendors in which could & could not implement ingress
filtering. as majority of the router vendors achieved such capability
... the push-back significantly reduced.
http://www.garlic.com/~lynn/rfcidx7.htm#2267
2267 -
Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing, Ferguson P., Senie D., 1998/01/23
(10pp) (.txt=21032) (Obsoleted by 2827)
there already are logs relating ingress email to originating ISP
customer id. that could be made available via some sort of legal
action. the only issue then is the strength of authentication that is
performed on customer connection to the ISP ... rather than some sort
of origin authentication for every email.
At 03:40 AM 5/9/2003 +0100, Adam Back wrote:
Yes, there is some discussion of it on slashdot, including several
other people who have commented similarly to anonymous that it is a
pretty big privacy invasion and centralised control point problem.
The claim that you can optionally be anonymous and not use a cert, or
get an anonymous cert is plainly practically bogus. You'd stand about
as much chance of having your mail read as if you shared mail hub with
spamford wallace -- ie 90+% of internet mail infrastructure would drop
your mail on the floor on the presumption it was spam.
Plus a point I made in that thread is that it is often not in the
internet user's interests to non-repudiably sign every message they
send just to be able to send mail because that lends amunition to
hostile recipients who from time-to-time target internet users for
bullshit libel and unauthorised investment advice etc.
Companies also are I would expect somewhat sensitive to not signing
everything for similar reasons as those behind their retention
policies where they have policies of deleteing emails, files and
shredding paper files after some period.
In addition PKIs because of the infrastructure requirements have
probem complex to setup and administer. So now we've taken one hard
problem (stopping spam) and added another hard problem (hierarchical
PKI deployment) and somehow this is supposed to be effective at
stopping spam.
In addition unless there is significant financial cost for
certificates and/or signifcant and enforceable financial penalty and
good identification and registration procedures enforced by the CAs it
wouldn't even slow spammers who would just get a cert, spam, get
revoked, get another cert and repeat.
Certificate revocation is already a weak point of PKI technology, and
to reasonably stop spam before the spammer manages to send too many
millions of spams with a cert, you have to revoke the cert PDQ!
And finally it all ends up being no more than an expensive
implementation of blacklists (or I suppose more properly whitelists),
because the CAs are maintaining lists of people who have not yet been
revoked as spammers. Some click through agreement isn't going to stop
spammers. Legislation or legal or financial threat is going to stop
spammers either because any level of registration time identity
verification that is plausibly going to be accepted by users, and this
is also limited by the cost -- higher assurance is more cost which
users also won't be willing to accept -- will be too easy for the
spammers to fake. And email is international and laws are not.
It is pretty much an "internet drivers license" for email.
I also think that fully distributed systems such as hashcash are more
suitable for a global internet service. My preferred method for
deploying hashcash is as a token exempting it's sender from bayesian
filtering, and any other content based or sender based filtering.
That way as an email user you have an incentive to install a hashcash
plugin http://www.cypherspace.org/hashcash/ because it will ensure
your mail does not get deleted by ever-more aggressive filtering and
scattergun blackhole systems. The camram system
http://www.camram.org/ is a variant of this.
It also more directly addresses the problem: it makes it more
expensive for spammers to send the volumes of mail they need to to
break even.
Adam
On Fri, May 09, 2003 at 03:50:02AM +0200, Nomen Nescio wrote:
> Lauren Weinstein, founder of People for Internet Responsibility, has
> come out with a new spam solution at http://www.pfir.org/tripoli-overview.
>
> According to this proposal, the Internet email architecture would be
> revamped. Each piece of mail would include a PIT, a Payload Identity
> Token, emphasis on Identity. This would be a token certifying that you
> were an Authorized Email User as judged by the authorities. Based on
> your PIT, the receiving email software could decide to reject your
> email.
>
> It is anticipated that all Pits considered acceptable by the vast
> majority of all Tripoli-compliant software user would be digitally
> signed by one or more designated, trustworthy, third-pary authorities
> who would be delegated the power to certify the validity of identity
> and other relevant information within Pits.
>
> In other words, here comes Verisign again.
>
> It is anticipated that in most cases, in order for the sender of an
> e-mail message to become initially certified by a Pit Certification
> Authority (PCA), the sender would need to first formally accept
> Terms of Service (ToS) that may well prohibit the sending of spam,
> and equally importantly, would authorize the certification authority
> to "downgrade" the sender's authentication certification in the case
> of spam or other ToS violations.
>
> Thus you have to be politically acceptable to the Powers That Be in
> order to receive your license to email, aka your PIT. And be careful
> what you say or your PIT will be downgraded.
>
> Unfortunately he doesn't discuss various crypto protocol issues:
>
> If the PIT is just a datum, what keeps someone from stealing your PIT
> and spams with it?
>
> If the PIT is a cert on a key, what do you sign? The message? What if
> it gets munged in transit, as messages do? You've just lost most of
> your email reliability.
>
> Or maybe you sign the current date/time? Then delayed mail is dead mail.
>
> Or maybe you respond to a challenge and sign that? That won't work if
> relays are involved, because they can't sign for you.
>
> Spam is a problem, but it's no excuse to add more centralized
> administrative control to the Internet. Far better to go with a
> decentralized solution like camram.sourceforge.net, basically a matter
> of looking for hashcash in the mail headers. This raises the cost to
> spammers without significantly impacting normal users.
>
blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Date: Fri, 09 May 2003 23:35:36 -0600
To: Adam Back <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>
Currently ISPs typically "notice" when they get complaints. ISPs could
do a much better job of actively noticing and limiting mail at ingress
... as opposed to waiting for somebody to complain and canceling the
account. Many of the recent statements about ISPs can't limit email at
ingress dynamically are similar to the comments about not being able
to filter ingress packets if their origin address didn't match the ip
address of the sender (as stated in the original posting) ... per the
ingress packet filtering RFC referenced in the original post.
My original post mentioned that the ISPs could then do their own
effort of blacklisting (of other ISPs). Currently spam blacklists can
be somewhat like vigilantes .... with the argument analogy that since
vigilantly justice can make mistakes then there shouldn't be any
highway patrol, FBI, and/or secret service. ISPs would be expected to
filter on ingress of email from their own customers .... and even if
the 10 top ISPs blacklisted other ISPs that didn't do a reasonable job
of ingress filtering ... it could start to put a big dent in the
spamming business, possibly cutting it from 40-80% of existing email
down under 5-10%. It is sort of like stop signs and stop lights
.... there are typically hundreds of more intersections than there are
traffic enforcers .... however with sufficient leverage ... it can
significantly improve the situation ... even if it can be proved that
it can't, absolutely, 100% guarantee one hundred percent compliance.
I didn't make any statement about ISPs attempting to identify spammers
when they register the account .... the original post was only with
regard to ISPs doing active email ingress filtering. My ISP recognizes
and bills me extra if I'm simultaneously connected multiple times
... there is a little latitude for modem hanging, my dropping the line
... but the modem not reporting it ... and my connecting on a
different modem. It also does traffic load-leveling if I really try
and hit it hard. If it can bill extra for simultaneous connects and
traffic load leveling, it can do both packet ingress filtering and
email ingress filtering.
past thread drawing the analogy that the information superhighway is
something like the wild west .... w/o traffic rules, traffic signs,
traffic lights, speed limits, and enforcement. start with a couple
hundred people in town .... and went to millions ... and there still
isn't even any rule about which side of the road people should be
driving on.
http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
At 06:02 AM 5/10/2003 +0100, Adam Back wrote:
On Fri, May 09, 2003 at 10:11:52AM -0600, Anne & Lynn Wheeler wrote:
> So it is much easier for ISPs to have lists of other trusted &/or
> untrusted ISPs that they will accept email from.
Any internet user needs to be able to send mail to any other internet
user. Which means the default has to be open (blacklists rather than
whitelists). Then you have the blackhole lists like ORBs etc, which
block domains used predominantly by spammers. But the problem is
spammers don't stay in one place, they buy service from ISPs and spam
flat-out until the ISP notices and cancels the account. Some ISPs are
more grey -- they want to make money from spammers by providing them
service, and some ISPs just don't notice or respond that quickly. The
ISP can't distinguish spammers from non-spammers when they receive
customer orders. The blackhole people are arbitrary vigilantes by and
large, so the overall effect you might argue does reduce spam, but it
also results in lost mail.
My experience was I couldn't get mail from my brother who was using
btinternet, one of the largest ISPs in the UK because some idiot
blackholer blackholed their dynamic IPs. Not doubt there were at some
time some spammers using BTinternet as with just about any other ISP.
Recently I couldn't receive mail from John Gilmore, and so it goes.
So I don't see how this is a "solution", rather it is just a broken
countermeasure with scatter gun fall-out of false positives for all
the other people who find themselves sharing the same ISP as spammers
long enough for the blackhole people to add them.
Adam
blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Date: Sat, 10 May 2003 09:36:43 -0600
To: Adam Back <adam@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: blackhole spam => mail unreliability (Re: A Trial Balloon to Ban Email?)
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>, cypherpunks@xxxxxxxx, cryptography@xxxxxxxx, lauren@xxxxxxxx, Adam Back <adam@xxxxxxxx>
do you think that earthlink would automatically blacklist aol if it
found incoming spam from aol? I think that earthlink would contact aol
and say ... your ingress filtering doesn't seem to be working. It
would only be after all attempts to understand aol's ingress filtering
that earthlink might take action.
again ... it is analogous to somebody hearing about traffic lights for
the first time and coming up with all the reasons why people would
ignore traffic lights.
I would claim that the current issue isn't that spam exists (aka
traffic violations), it is that there are billions of spams each
day. and that this easily cuts the majority of it if the top ten start
doing ingress mail filtering and that ingress mail filtering is orders
of magnitude more efficient than other kinds of solutions.
the blacklisting isn't for the mistakes ... it is for the ISPs that
obviously aren't going to follow the traffic rules.
so there are lots of kinds of tunneling. the major ISPs are already
doing ingress filtering for email not coming from a recognizable
customer. so tunneling actually reduces to a common vulnerability with
ISPs not doing ingress email filtering (aka the tunneling issue to a
ISP that isn't doing ingress email filtering is common vulnerability
with a customer directly getting an email account with ISP that isn't
doing ingress email filtering). So the issue comes back to ISPs that
are recognized as not doing ingress email filtering.
So lets say this gets something like 80 percent of the traffic
violations.
So the majority of the random traffic violations are now starting to
be taken care of. There are 1) the corporations effectively operating
as private ISPs, 2) compromised machines, 3) random anarchy.
So both #2 and #3 are vulnerabilities treated just the same as a real
spammer getting a real account and directly doing spam. These two
vulnerabilities should be caught be ingress email filtering. Real
spammers caught by ISP ingress filtering, compromised machines caught
by ISP ingress filtering, and hit&run anarchist caught by ingress
filtering .... all appear to be a common vulnerability caught by
ingress email filtering.
The issues actual reduce to a very few simple, non-complex
vulnerabilities from a business process standpoint (ignoring all the
technology twists and turns): 1) ISPs that do ingress email filtering
and 2) ISPs that do not do ingress email filtering.
If ISPs are doing ingress email filtering .... then all the situations
of known spammers, spammers masquerading enormously getting accounts,
spammers compromising other machines and masquerading enormously,
tunneling, etc ... all get taken care of. There are still the periodic
traffic accidents where somebody might be able to do a couple hundred
before getting cut .... but it probably reduces over 90 percent of the
traffic.
So the remain issue is whether an ISP is following the traffic laws
and doing ingress email filtering or flagrantly flaunting the law and
letting millions of spam thru. This is regardless of whether it is a
real public ISP ... or effectively a corporate/private ISP. The other
ISPs then use blacklisting. The first line of defense is that all ISPs
are to do ingress email filtering and the 2nd line of defense is that
the major ISPs do blacklisting on the ISPs that obviously are
flaunting the law.
The primary business issue is that majority of spam is being done for
some profit .... that the cost of sending the spam is less than the
expected financial return. This should address the 99 percentile.
Again, it is very simple, first line of defense is ingress email
filtering. This is only a moderate extension of what the major ISPs
are currently doing with regard to not accepting email from entities
that are obviously not their customers, current traffic limiting
business rules, etc. The second line of defense is blacklisting ISPs
that aren't following the traffic rules. I claim, it actually is
rather much simpler and much more effective.
So back to the obvious traffic violations. One is the compromised
machines. Large proportion of the compromised machines are their
because they all got hit by spamming virus. I claim, that over time if
over 90 percent of spamming gets cut ... then 90 percent of the
machines that get compromised by virus in spam can also get cut.
Situation is now down to large number of compromised machines each
sending couple hundred emails each ... staying under the ingress
filtering radar. That is orders of magnitude better than the current
situation but it is starting to reduce the case to manageable traffic
violations.
So this scenario gets down to providing significantly more focus on
compromised machines ... and back to a recent comment about lots of
vendors saying that consumers won't pay for better security
... because they have no motivation. This is somewhat the insurance
industry theory of improving on severity of traffic accidents (what
motivated automobile manufactury to build safer cars). My ISP
currently charges me extra over the flat rate for certain behavioral
activities. Violating ingress email filtering rules would be such a
valid inducement. I get ingress email filtering accident insurance the
premiums are based on the integrity of the machine i'm operating.
So, two simple rules .... 1) ISPs do ingress email filtering, and 2)
ISPs blacklist other ISPs that flagrantly violate the ingress email
filtering rules.
With a sizeable reduction in spam, there is corresponding sizeable
reduction in compromised machines. However, compromised machines that
do spam and hit the ISPs ingress email filtering rules, get fined. It
is treated as accident and operating an unsafe vehicle. You can get
accident and fine insurance .... but the premium is related to kind of
machine you operate. Some inducement for consuming public to purchase
safer machines. The two simple rules ... with the fines for violations
then provides some inducement for consumer buying habit regarding
purchasing safer machines. And it is all quite similar to policies and
practices currently in place.
Payments as an answer to spam
Date: Sat, 17 May 2003 08:07:35 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Payments as an answer to spam
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
At 11:03 AM 5/15/2003 -0400, Anton Stiglic wrote:
PODS using something à la PGP would not
imply PKI, but still a centralized server
as you said.
Payment systems don't need a PKI, but
a centralized server as you said, and
also needs some kind of financial
institution to bootstrap things (which is easier
to do in a closed system, than in an open
system like the Internet).
x9.59 standard for all elecronic payments can use digital signatures
w/o PKI or certificates ... just public key registered with account
and connectivity to senders financial institution. It isn't
"centralized" any more than the existing payment card operation is
centralized .... aka huge number of different consumer financial
institutions all with their individual operation and account
records. however, much of it is based on a private network
interconnecting all of these financial operations that predates the
existing internet ... but effectively functionally equivalent.
The existing payment card infrastructures are open in the sense thay
they do have an international standard, iso8583 .... in much the same
way that certificates have iso international standard. and there are
numerous interconnects between the internet and these infrastructure
... witness the existing electronic commerce. It is less open than the
"internet" in the sense that there are contractual, institutional, and
financial obligations that are necessary to directly participate (but
i believe that will tend to be always true except in the cases of toy
demos). However, that isn't precluding the migration of more
electronic commerce related traffic to internet-based technology in
various ways. The issue isn't directly whether it is internet-related
technology or non-internet related technology .... but much more of an
issue whether there are explicit legal and other obligations required
to participate.
x9.59 standard reference
http://www.garlic.com/~lynn/x959.html#x959
account record public key infrastructures
http://www.garlic.com/~lynn/x959.html#aads
Payments as an answer to spam (addenda)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 May 2003 09:21:21 -0600
To: "Anton Stiglic" <astiglic@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: <iang@xxxxxxxx>, <cryptography@xxxxxxxx>
The existing payment card infrastructure (credit, debit, online
stored-value, 3rd party, etc) had used a PKI-type infrastructure prior
to about 1970, aka credential (in this case in the guise of a plastic
physical card with varioius embossing and printing) that could be used
in offline transactions, unconnected transactions.
The transition to online transactions started in the early '70s
... used an electronic end-point in the guise of magstripe added to
the existing physical credential ... while they were emboddied in the
same physical package, they represented totally different paradigms.
The existing PKI certificates are a return to the offline, pre-70s
paradigm that the existing payment card infrastructure left long
ago. The existing payment card paradigm is not only online in the
sense that it checks whether the account is still valid ... but also
checks real-time, aggregated information regarding whether there is
sufficient funds.
OCSP for PKIs is a limiting baby step into an online world with
real-time checking of whether the offline credential is still valid
.... but it doesn't actually make it into the 1970s where a stale,
static certificate is redundant and superfluous and there is direct
access to much higher quality real-time and possibly aggregated
information used for financial operations. OCSP is actually a more
timely version of the paper booklets that were distributed in the 50s
& 60s .... not an actual switch from a basically offline paradigm to
an online paradigm.
Frequently there were were comments equating statements about
redundant and superfluous certificates as being a transition to a
centralized paradigm. However the issue isn't with regard to
centralized/non-centralized ... which is effectively orthogonal to the
issue regarding stale, static certificates .... it is an issue of
offline/online (not centralized/non-centralized). There is the issue
that if it is online paradigm ... it is possible to have either a
centralized or a non-centralized paradigm .... which is somewhat more
difficult to have such option in a purely offline paradigm.
random past posts on redundant and superfluous offline credentials for an online paradigm
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki6 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki7 CFP: PKI research worksho
http://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a max amount in a X.509v3 certificat e?
http://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put a max amount in a X.509v3 certificate?
http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
http://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
http://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
Payments as an answer to spam (addenda)
Date: Sat, 17 May 2003 17:56:52 -0600
To: Rich Salz <rsalz@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: "cryptography@xxxxxxxx" <cryptography@xxxxxxxx>
At 07:17 PM 5/17/2003 -0400, Rich Salz wrote:
Curious.
A couple of years ago, we'd go around explaining that CRL's were the
paper booklets, and OCSP was the Verifone terminal, giving per-transactional
validity to the credentials.
I still think that makes more sense than your analogy. But then, the
company I was working for back then is now gone.
/r$
the description was that CRLs were an exact analogy of the paper
booklet, while OCSP is a more timely version of the paper booklet; aka
it is a more timely solution for an offline paradigm ... using a
little bit of online technology; but not with the actual transition
from an offline paradigm to an online paradigm.
theoretically, the payment system could have preserved the offline
paradigm and just used the online terminal to check whether the
offline credential is still valid .... however, they actually used the
online capability to actually change from an offline paradigm to an
online paradigm ... rather than using the online capability as sort of
a kludgey crutch for continuing to prop up an offline paradigm.
Payments as an answer to spam (addenda)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sat, 17 May 2003 18:22:18 -0600
To: Rich Salz <rsalz@xxxxxxxx>
Subject: Re: Payments as an answer to spam (addenda)
Cc: "cryptography@xxxxxxxx" <cryptography@xxxxxxxx>
At 07:17 PM 5/17/2003 -0400, Rich Salz wrote:
A couple of years ago, we'd go around explaining that CRL's were the
paper booklets, and OCSP was the Verifone terminal, giving
per-transactional validity to the credentials.
I still think that makes more sense than your analogy. But then, the
company I was working for back then is now gone.
/r$
actually, i believe that my wife and I were one of the first to use
the comparison of CRLs to the paper booklets at about the same time we
coined the term certificate manufacturing to distinguish the SSL
infrastructure from a PKI (in conjunction with this thing that was to
be called electronic commerce).
some old booklet references:
http://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
http://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
http://www.garlic.com/~lynn/aadsm2.htm#strawm4 AADS Strawman
http://www.garlic.com/~lynn/aadsm2.htm#activity AADS Activity
http://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust
http://www.garlic.com/~lynn/aadsm5.htm#spki3 Simple PKI
misc. certificate manufacturing refs:
http://www.garlic.com/~lynn/aadsm2.htm#scale Scale (and the SRV record)
http://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
http://www.garlic.com/~lynn/aadsm3.htm#kiss7 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm5.htm#pkimort2 problem with the death of X.509 PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Payments as an answer to spam (addenda)
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Sun, 18 May 2003 06:47:13 -0600
To: pgut001@xxxxxxxx (Peter Gutmann)
Subject: Re: Payments as an answer to spam (addenda)
Cc: rsalz@xxxxxxxx, cryptography@xxxxxxxx
At 05:50 PM 5/18/2003 +1200, Peter Gutmann wrote:
So I agree with the statement that "OCSP is actually a more timely
version of the paper booklets that were distributed in the 50s & 60s".
A real solution to the problem would follow the online authorisation
model used for financial transactions, just a straight
"Accepted/Declined" response, rather than the "Maybe/Maybe not"
silly-walk that OCSP does.
But the actual transformation from offline paradigm to online paradigm
had nothing to do with the credential. In the credential world, there
is something emboddied in the credntial that convinces the relying
party to accept or reject the operation modula a currently
valid/active credential (aka as previously outline, these credentials
are stale, static subset copy of some master information someplace,
typically kept in an account record). The transition to the online
paradigm involved asking is the payment approved, nothing to do
(directly) with the validity of any credential. The certification
authority had up-to-date information about authentication ... but also
up-to-date and aggregated information about patterns leading up to
this event. The certifying authority ... instead of commenting about
any credential ... providing yes/no regarding the transaction in the
context of real-time and aggregated information.
In fact, to the extent that any financial institution using a
certificate .... it did go thru a period of being used because of
requirement by various off-the-shelf software on the
internet. However, because of privacy and liability reasons they
aborted the contents to just an account number for a
relying-party-only certificate. However, (other than requirement to
satisfy certain off-the-shelf software), it is trivial to show that
such relying-party-only certificates are redundant and superfluous
from a business process & flow perspective.
In general, there is almost nothing that you really want to put into
some document that is going to be sprayed all over the infrastructure
for everybody to examine. The original premise for X.509 was that
there would be some information in the contents of the certificate,
that a relying-party could take a look at for the basis of making a
decision w/o requiring anything more .. like online access or
previously obtained information. Given online access and/or previously
obtained information (prior/previous business relationship) .... it is
possible to show that stale, static information embodied in a
certificate is redundant and superfluous.
random past comments on relying-party-only certificates:
http://www.garlic.com/~lynn/subpubkey.html#rpo
http://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification
http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
http://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
Financial Privacy To Take The Floor
From: Lynn Wheeler
Date: 05/21/2003 06:14 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Financial Privacy To Take The Floor
http://www.banktech.com/story/enews/BNK20030519S0003
Financial Privacy To Take The Floor
Ivan Schneider
May 19, 2003
Congress has a lot of banking-related legislation on its plate. But
anything that doesn't take financial privacy into consideration may
get sent right back to the kitchen.
"Financial privacy, as an issue, will affect and overshadow all other
legislative issues this year," said Michael Flood, senior analyst for
banking in the regulatory advisory services group at KPMG LLP, during
its regulatory perspectives teleconference.
The primary battleground is the Fair Credit Reporting Act, which has
pre-approved credit provisions scheduled to lapse at the start of
2004. These provisions allow banks to share loan application data and
credit bureau reports with their affiliates, provided that the
customer has been given the chance to 'opt-out.' "If it isn't
reauthorized, states can enact their own privacy legislation, which
can lead to a miasma of 50 different regulations," said Flood, who
likened the possible result to the situation faced by the insurance
industry.
... snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Identity Theft Losses Expected to Hit $2 Trillion by 2005
From: Lynn Wheeler
Date: 05/22/2003 10:39 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Identity Theft Losses Expected to Hit $2 Trillion by 2005
http://itmanagement.earthweb.com/secu/article.php/2211101
Identity Theft Losses Expected to Hit $2 Trillion by 2005
May 22, 2003
By Sharon Gaudin
The financial damage caused by online identity theft is not only
mounting, it's exploding at a growth rate of about 300 percent a year,
according to Aberdeen Group, a Boston-based industry analyst firm.
Financial loss from identity theft is expected to reach $73.8 billion
in the United States by the end of this year -- $221.2 billion
worldwide, reports Aberdeen analysts in a study released this week.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: pgut001@xxxxxxxx (Peter Gutmann)
Cc: ericm@xxxxxxxx, iang@xxxxxxxx, bill.stewart@xxxxxxxx,
cryptography@xxxxxxxx, cypherpunks@xxxxxxxx,
ekr@xxxxxxxx, rsalz@xxxxxxxx, sguthery@xxxxxxxx
Subject: Re: Maybe It's Snake Oil All the Way Down
Date: Tue, 03 Jun 2003 14:46:27 -0600
On Tue, 2003-06-03 at 07:04, Peter Gutmann wrote:
That's a red herring. It happens to use X.509 as its preferred
bit-bagging format for public keys, but that's about it. People use
self-signed certs, certs from unknown CAs [0], etc etc, and you don't
need certs at all if you don't need them, <blatant
self-promotion>I've just done an RFC draft that uses
shared-secret keys for mutual authentication of client and
server, with no need for certificates of any kind</blatant
self-promotion>, so the use of certs, and in particular a
hierarchical PKI, is merely an optional extra. It's no more required
in SSL than it is in SSHv2.
the pk-init draft for kerberos allows public keys .... allowing both
cert & cert-less implementations
<blatant aads-promotion>
the scenario allows for public key registration in lieu of shared-secret registration. the benefit is that r/o access, divulging,
sniffing, etc doesn't result in compromise (as in shared-secret)
in the token form ....
http://www.garlic.com/~lynn/x959.html#aads
the key-pair is gen'ed in the chip and never leaves the chip.
as part of 3-factor authentication
* something you have
* something you know
* something you are
the chip in the token purely provides something you have
authentication ... and the digital signature done by the token is
purely to prove that you have that particular token. It doesn't prove
who you are, it just proves that you have a specific (extremely
difficult to counterfeit) token as part of something you have
authentication.
if the token is augmented with a pin/password for its correct
operation, then there can be 2-factor authentication. It doesn't
involve shared-secrets since the pin/password is purely between the
person and the hardware token.
A business process may validate that the token is of the type requiring
PIN and/or biometric for correct operation (in order to meet
particular business integrity constraints).
An ecdsa digital signature authentication protocol for kerberos,
radius, x9.59 for all retail financial transactions, or ssh can be
identical regardless of various additional business integrity
requirements.
The ecdsa digital signature authentication protocol can be ubiquitous
regardless of various additional business integrity requirements.
The business process (for specific integrity requirements) then can
require: sofware key-pair, hardware token key-pair, the level of
integrity of the hardware token, and/or the operational
characteristics of the hardware token (no-pin, pin, biometrics, etc)
w/o changing the protocol.
If the protocol is independent of much of the business process
integrity issue then either the business and/or the end-user may be
able to have personal choice about the level of integrity
required. Furthermore, the person might even have personal choice
whether they need a unique token per security environment, a single
token for all security environments, and/or a small number of tokens
selectively applied to specific security environments
the digital signature has nothing at all to do directly with the
person, it is purely related to demonstrating the possession of the
token (as part of something you have authentication) and
possibly the integrity level of the token.
The issue of the authentication protocol is getting the bits and bytes
for transmission correct but doesn't normally say what it means
... i.e. secret, shared-secret, one-factor
authentication, two-factor authentication, something you
have authentication, something you know authentication,
etc. ... even tho frequently the protocol is envisioned to be a
specific implementation of a specific kind of authentication and
trust/integrity level.
recent token discussions
http://www.garlic.com/~lynn/2003i.html#1 two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#2 two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
older token discussions
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002i.html#65 privileged IDs and non-privileged IDs
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
</blatent aads promotion>
Microsoft Ties Security to Verisign
From: Lynn Wheeler
Date: 06/03/2003 04:24 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Microsoft Ties Security to Verisign
http://www.internetnews.com/ent-news/article.php/2216571
June 3, 2003
Microsoft Ties Security to VeriSign, Certifications
By Thor Olavsrud and Mark Berniker
Microsoft Ties Security to VeriSign, Certifications By Thor Olavsrud
and Mark Berniker Microsoft (Quote, Company Info) moved to bolster its
code-securing effort called Trustworthy Computing Initiative by
announcing two security initiatives Tuesday. Microsoft and VeriSign
said they would jointly develop improved solutions for authentication
security, digital rights management (DRM) and other online security
enhancements. Financial terms of the deal were not disclosed.
.. snip ..
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
OASIS and RosettaNet Set Standards Alliance
From: Lynn Wheeler
Date: 06/03/2003 04:26 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: OASIS and RosettaNet Set Standards Alliance
http://www.internetnews.com/dev-news/article.php/2216641
June 3, 2003
OASIS and RosettaNet Set Standards Alliance
By Michael Singer
Cementing their casual relationship, industry standards consortia,
OASIS (Organization for the Advancement of Structured Information
Standards) and RosettaNet Tuesday said they are now working in tangent
to streamline Web services (define) specifications for supply chain
companies. The groups actively participate in the technical work of
the other but say the partnership (dubbed the "Standards
Development-to-Implementation Alliance") is a chance to advance
e-business standards without having to do double the work.
... snip ...
--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **
Date: Tue, 03 Jun 2003 17:29:44 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: pgut001@xxxxxxxx (Peter Gutmann),
bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, ekr@xxxxxxxx, rsalz@xxxxxxxx,
sguthery@xxxxxxxx
At 03:04 PM 6/3/2003 -0700, James A. Donald wrote:
I never figured out how to use a certificate to authenticate a
client to a web server, how to make a web form available to one
client and not another. Where do I start?
What I and everyone else does is use a shared-secret, a
password stored on the server, whereby the otherwise anonymous
client gets authenticated, then gets an ephemeral cookie
identifying him.. I cannot seem to find any how-tos or
examples for anything better, whether for IIS or apache.
As a result we each have a large number of shared-secret
passwords, whereby we each log into a large number of
webservers. Was this what the people who created this protocol
intended?
The issue is where does the authentication material come from.
<blatant aads promotion>
Basically, certificates were solution targeted for offline email from
the early '80s. you dial-up, connect, exchange email, hang-up. then
you read. some random person that you never, ever dealt with before
sends you something; they claim to be somebody .... the certificate is
signed by somebody you trust .... and is offered as proof that they are
who they claim to be.
the other approach in the online world &/or with previous
relations, is to have a directly accessable table of authentication
material (passwords, pins, public keys). the payment (debit/credit)
card world went from non-electronic, offline to electronic and online
(and skipped the step altogether that certificates represent ... the
electornic and offline).
note that even the certificate-based infrastructure are dependent on
this method .... basically the certificate-enabled infrastructures
everybody has a local table of "CA" public keys (i.e. those public
keys that they've previously decided to trust) ... then certificates
are validated with "CA" public keys (from their local table) and the
current message/document is validated with public key from
certificate. The primary difference between cert-based infrastructure
and certless-based infrastructure is that in the cert-based
infrastructure,, the CAs have their database of all public keys and
create these small R/O, stale, static copies of their database
records (called certificates) and spray them all over for use in
offline environments. Then relying parties just have abbreviated
CA-only public key tables and supposedly can't access the full tables maintained
at the CAs.
In the certless-based infrastructure the relying parties either
maintain their own full tables of all public keys and/or have direct
online access to the full tables. There is no need for these little
R/O, stale, static, redundant and superfluous copies of
somebody else's offline database entry (called certificates) since there
can be direct, online access to the original copy.
the generalized case can be hooking a web server to either radius or
kerberos for handling the authentication process. both radius and
kerberos support shared-secrets recorded in authentication
database (potentially along with various authorization material).
radius recording public key in lieu of shared-secret and
performing ecdsa digital signature authentication. pkinit for kerberos
also allows for public key recorded in lieu of shared-secret
with digital signature authentication (not that radius can determine
authentication method, authentication material, and authorization on
an account by account basis).
misc. radius public key authentication posts
http://www.garlic.com/~lynn/subpubkey.html#radius
misc. kerberos public key authentication posts
http://www.garlic.com/~lynn/subpubkey.html#kerberos
futher discussion specifically regarding stale, static,
redundant, superfluous certificates.
http://www.garlic.com/~lynn/subpubkey.html#rpo
slightly related discussions regarding SSL merchant comfort
certificates:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
</blatant aads promotion>
Maybe It's Snake Oil All the Way Down
Date: Tue, 03 Jun 2003 20:49:48 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: pgut001@xxxxxxxx (Peter Gutmann),
bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, ekr@xxxxxxxx, rsalz@xxxxxxxx,
sguthery@xxxxxxxx
some generic reasons for hooking radius (or one of the AAA
technologies) into your webserver for authentication are:
1) supports a variety of authentication mechanisms on an account by
account basis. day one, none of the users actually need to see any
difference (single administrative interface supporting all the client
authentication options that might be in use). existing
userid/password, challenge/response and in the referenced asuretee
url, ecdsa digital signature.
2) single administrative interface for both client authentication
options as well as all of their authorization and privilege options.
3) client database is accessable in real-time by the webserver,
real-time updates can occur to both authentication information as well
as authorization, permission and privilege information using single
consistent administrative operation
4) there is no disconnect between client administration and stale,
stale, redundant and superfluous certificates that are a
subset of a r/o administrative database entry. (RADIUS) Updates
can take place in real time and immediately reflected. The certificate
story (as mentioned previously, created for offline, disconnected
environment) basically would do something like a) invalidate
the old certificate, b) issue new CRLs, c) possibly
update a OCSP LDAP, d) update the master database permissions
entry for that client, e) generate a certificate that
represents a subset of the master information, f) distribute it
to the client and g) then have the client install the new
certificate. This of course becomes unnecessary if the certificate
doesn't actually contain any information and the webserver accesses
the authorization and permissions from an online database. However, as
has repeatedly been pointed out before, if the certificate doesn't
contain any information and the webserver is accessing an online
database for authorizations and permissions ... then the webserver can
access the online database for the authentication material also. The
certificate then is stale, static, redundant and
superfluous and you are back to a single online, real-time
comprehensive administrative facility (like radius) that supports
client/account specifics for authentication, authorization,
permissions, accounting, privileges, etc.
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 04 Jun 2003 10:12:04 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 12:02 PM 6/4/2003 +0100, Dave Howe wrote:
For that matter, our system here discards the CC after use (the pre-auth
step with the merchant bank agent gives us back a "fulfillment handle" that
can only be used to fulfill or cancel that individual transaction - but of
course Amazon want to keep your CC details so they can do their
fast-checkout patented thingy.
the ground rules given the x9a10 working group for the x9.59 standard
was to preserve the integrity of the financial infrastructure for
all electronic retail payments (credit, debit, stored-value, POS,
internet, non-internet, aka ALL). it was one of the things that
led us down the path of certless operation. We had previously done the
work on the original payment gateway and had to perform various kinds
of due diligence on all the major CA vendors .... which started to
dawn on us that stale, static certificates were actually
redundant and superfluous in the financial business process.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
sort of the next clinker was starting to do operational and
performance profile on any of the existing payment networks .... and
it was evident that there was a huge mismatch between the existing
payment transaction payload size and any of the commonly used
certificates (even the drastically simplified replying-party-only
certificates carrying only an account number and public key).
Two major characteristics of X9.59 was that it would provide 1)
end-to-end authentication (aka the consumers financial institution
would be the one responsible for performing authentication) and 2)
account numbers used in X9.59 transactions could not be used in
unauthenticated transactions.
Some of the '90s digitally signature oriented specifications had
authentication occurring at the internet boundary and stripping off
the certificate (avoiding the extreme certificate payload penalty in
the payment network). The downside was that the party performing the
authentication didn't necessarily have the consumer's interest in mind
and Visa subsequently presented statistics at a ISO standards meeting
on the number of transactions flowing through the network 1) with a
flag claiming to have been digitally signature authenticated and 2)
they could prove that no digital signature technology was ever
involved.
Evesdropping, sniffing or harvesting account numbers in the current
infrastructure (at any point in the process, by insiders or outsiders,
traditionally financial exploits have been 90 percent insiders) can
result in fraudulent transactions. As a result, existing account
numbers effectively become a form of shared-secret and need to be
protected. With the X9.59 business rule requiring the account number
to only be used in authenticated transactions, simple harvesting of a
X9.59 account number doesn't result in fraud. Issuing financial
institutions then can use existing business processes that support
mapping of different account numbers to the same account. A
discussion of the security proportional to risk with regard to credit
card transactions:
http://www.garlic.com/~lynn/2001h.html#61 Net banking, is it safe?
The issue with the use of SSL for protecting credit card transactions
isn't addressing all or even the major vulnerability to the
infrastructure. Eliminating the account number as a form of
shared-secret addresses all of the vulnerabilities, not just
the transaction-in-flight vulnerability addressed by SSL. As a
byproduct of addressing all of the shared-secret related
vulnerabilities, it also eliminates the need to use SSL for protecting
the shared-secret while being transmitted.
Detailed report of its use in the NACHA debit network trials can be
found at
http://internetcouncil.nacha.org/News/news.html
scroll down to "July 23, 2001: Digital Signatures Can Secure ATM Card
Payments"
More details of X9.59 standard:
http://www.garlic.com/~lynn/x959.html#x959
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 04 Jun 2003 20:58:47 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: "Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 04:25 PM 6/4/2003 -0700, James A. Donald wrote:
Everyone in America has several shared-secrets identifying them
-- the number of the beast to identify them to the state, and
their credit card numbers identifying them to various financial
institutions, plus a hundred passwords to login to their
email, their bank, their network provider, e-gold, etc.
The PKI idea was that we would instead use PK in place of
shared-secrets, but if an ordinary person had a private key,
what could he use it for?
The spam that seeks to get us to login to e-g0ld and the
BankOf4merica.com works because the logins are based on shared-secrets, not private keys, and the networks are setup to rely
on shared-secrets because there is no practical alternative.
one could claim that public-key is a practical alternative but it got
significantly sidetracked with independent business model that wanted
to extract huge amount of money out of existing infrastructures (say
totally brand new independent operations wanting $100/annum for every
person, extracted from the existing infrastructure for no significant
positive benefit ... aka say 200m people at @$100/annum is $20b/annum
... in return for some abstract bit vapor that doesn't change any core
business issue).
it is relatively trivial to demonstrate that public keys can be
registered in every business process that currently registers
shared-secrets (pins, passwords, radius, kerberos, etc, etc). the
issue then becomes one of cost to change/upgrade those infrastructures
to support digital signature authentication with the stored public
keys in lieu of string comparison (no new business operations, no new
significant transfer of wealth to brand new outside business entities,
etc).
however, think about even these simple economics for a minute
.... even for relatively modest technology changes that don't change
any of the business processes/relationships ... it still costs some
money ... and the beneficiary isn't the institution, it is the
individual. The individual has the paradigm changed from hundreds of
shared-secrets to a single key-pair ... however each institution
continues to see just as many individuals and account records. From a
very practical standpoint ... entities don't frequently fund things
that they don't benefit from ... and typically most success is
achieved when the entity that benefits from the change is also
driving/funding the change.
the issue is to find out how the individual pays for the change
.... or figure out how the institutions are going to benefit.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
To: EKR <ekr@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Date: Fri, 06 Jun 2003 13:34:41 -0600
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
pgut001@xxxxxxxx (Peter Gutmann),
bill.stewart@xxxxxxxx, cryptography@xxxxxxxx,
cypherpunks@xxxxxxxx, rsalz@xxxxxxxx,
sguthery@xxxxxxxx
At 04:42 PM 6/4/2003 -0700, Eric Rescorla wrote:
Nonsense. One can simply cache the certificate, exactly as one does
with SSH. In fact, Mozilla at least does exactly this if you tell it
to. The reason that this is uncommon is because the environments where
HTTPS is used are generally spontaneous and therefore certificate
caching is less useful.
there are actually two scenarios .... one is to pre-cache it (so that
its transmission never actually has to happen) and the other is to
compress to zero bytes. detailed discussion of certificate
pre-caching and certificate zero byte compression:
http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2
the typical use for HTTPS for e-commerce is to hide the account number
on its way to the financial institution. for the most part, the
merchant is primarily interested in the response from the consumer's
financial institution on whether or not the merchant gets paid. If it
weren't for the associated business processes, the merchant could get
by with never knowing anything at all about the consumer (the merchant
just passes the account number on ... and gets back what they are
really interested in .... the notification from the bank that they
will get paid).
So a HTTPS type solution is that the consumer pre-caches their bank's
certificate (when they establish a bank account). .... and they
transmit the account number "hidden" using the bank's public key. This
happens to pass thru the merchants processing .... but for purposes of
the authorization, the merchant never really has to see it. The
protocol would require minor issues of replay attacks .... and be able
to be done in a single round trip .... w/o all the SSL protocol
chatter. Actually, is isn't so much pre-caching their bank's
certificate .... as loading their bank's public key into a table
.... analogous to the way CA public keys are loading into tables (aka
using out-of-band processing .... the convention that they may be
self-signed and encoded in a certificate format is an anomoly of
available software and in no way implies a PKI). The primary purpose
of HTTPS hasn't been to have a secure channel with the merchant, the
primary purpose of the HTTPS is to try and hide the consumer's account
number as it makes its way to the consumer's financial institution.
The other solution is the X9.59 standard (preserve the integrity of
the financial infrastructure for all electronic retail payments,
not just internet, not just POS, not just credit, ALL; credit,
debit, stored value, etc) that creates authenticated transactions and
account numbers that can only be used in authenticated transaction.
The consumer's public key is registered in their bank account (out of
band process, again no PKI). X9.59 transactions are signed and
transmitted. Since the account number can only be used in
authenticated transactions .... it changes from needing encryption to
hide the value as part of a shared-secret paradigm to purely a
paradigm that supports integrity and authentication. As in the above,
scenario, the merchant passes the value thru on its way to the
consumer's financial institution; and is focused on getting the
approved/disapproved answer back about whether they will be paid. As
in the bank HTTPS scenario where the bank's pubilc key is pre-cached
at the consumer, the consumer's public key is pre-cached at the bank
.... involves no PKI business processes (although there may be some
similarities that the transport of the public key involves encoding in
a certificate defined format). misc. x9.59 refs:
http://www.garlic.com/~lynn/x959.html#x959
Both pre-caching solutions are between the business entities that are
directly involved; the consumer and the consumer's financial
institution based on having an established business relationship.
The invention of PKI was primarily to address the issue of an event
between two parties that had no prior business relationship and
possibly weren't going to have any future business relationship and
that they would conclude their business relying on some mutual trust
in the integrity of a 3rd party w/o actually having to resort to an
online environment. The e-commerce scenario is that there is
real-time, online transaction with the trusted 3rd party (the
consumer's financial institution) involving prior business
relationship. This negates the basic original assumptions about the
environment that PKIs are targeted at addressing.
Maybe It's Snake Oil All the Way Down
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Fri, 06 Jun 2003 17:45:35 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: Maybe It's Snake Oil All the Way Down
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 04:24 PM 6/6/2003 -0700, James A. Donald wrote:
I don't think so.
??? public key registered in place of shared-secret?
NACHA debit trials using digitally signed transactions did it with
both software keys as well as hardware tokens.
http://internetcouncil.nacha.org/News/news.html
in the above scroll down to July 23, 2001 ... has pointer to detailed
report?
X9.59 straight forward establishes it as standard .... with some
activity moving on to ISO
http://www.garlic.com/~lynn/x959.html#x959
pk-init draft for kerberos specifies that public key can be registered
in place of shared-secret.
various radius implementations have been done be a number of people.
in all of these cases, there is no change in the business process
and/or business relationship .... doesn't introduce totally unrelated
parties to the business activities. there is digital signing on the
senders side (actually a subset of existing PKI technology) and
digital signature verification on the receivers side (again a subset
of existing PKI technology). To the extent that there is impact on
existing business process ... it is like in the case of introducing
x9.59 authentication for credit transactions that have relatively
little authentication currently .... and as a result would eliminate
major portion of the existing credit card transaction related fraud.
The big issue isn't the availability of the technology ... although
there is a slight nit in the asuretee case being FIPS186-2, ecdsa
.... and having support in CAPI and related infrastructures. It not
working (easily) is like when my wife and I were doing the original
payment gateway .... with this little client/server startup in menlo
park (later moved to mountain view and have since been bought by AOL)
and people saying that SSL didn't exist ... misc ref from the past
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
An attack on paypal
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Sun, 08 Jun 2003 18:12:34 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 11:43 PM 6/8/2003 +0100, Dave Howe wrote:
HTTPS works just fine.
The problem is - people are broken.
At the very least, verisign should say "ok so '..go1d..' is a valid server
address, but doesn't it look suspiously similar to this '..gold..' site over
here?" for
https://pseudo-gold-site/
- but really, if users are going to
fill in random webforms sent by email, they aren't going to be safe under
any circumstances; the thing could send by unsecured http to any site on the
planet, then redirect to the real gold site for a generic "transaction
completed" or even "failed" screen
A world where a random paypal hack like this one doesn't work is the same as
the world where there is no point sending out a Nigerian as you will never
make a penny on it - and yet, Nigerian is still profitable for the con
artists.
in a world where there are repeated human mistakes/failures .... at
some point it is recognized that people aren't perfect and the design
is changed to accommodate peoples foibles. in some respects that is
what helmets, seat belts, and air bags have been about.
in the past systems have designed long, complicated passwords that are
hard to remember and must be changed every month. that almost worked
when i person had to deal with a single shared-secret. when it became
a fact of life that a person might have tens of such different
interfaces it became impossible. It wasn't the fault of any specific
institution, it was a failure of humans being able to deal with large
numbers of extremely complex, frequently changing passwords. Because
of known human foibles, it might be a good idea to start shifting from
an infrastructure with large numbers of shared-secrets to a
non-shared-secret paradigm.
at a recent cybersecurity conference, somebody made the statement that
(of the current outsider, internet exploits, approximately 1/3rd are
buffer overflows, 1/3rd are network traffic containing virus that
infects a machine because of automatic scripting, and 1/3 are social
engineering (convince somebody to divulge information). As far as I
know, evesdropping on network traffic doesn't even show as a blip on
the radar screen.
In the following thread on a financial authentication white paper:
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
http://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
http://www.garlic.com/~lynn/aepay11.htm#56 FINREAD was. Authentication white paper
there is point made that X9.59 standard doesn't directly address the
Privacy aspect of security (i.e. no encryption or hiding of
data). However, the point is made that it changes the paradigm so that
the financial account number no longer represents a shared-secret and
that it can be supported with two-factor authentication
i.e. something you have token and something you know PIN. The
something you know PIN is used to enable the token, but is not a
shared-secret. Furthermore, strong authentication can be justification
for eliminating the need for name or other identification information
in the transaction.
However, if X9.59 strong authentication is used with two-factor
authentication and no identification information is necessary
.... then it would make people more suspicious if privacy information
was requested. Also, since privacy information is no longer sufficient
for performing a fraudulent transaction, it might mitigate that kind
of social engineering attack.
The types of social engineering attacks then become convincing people
to insert their hardware token and do really questionable things or
mailing somebody their existing hardware token along with the valid
pin (possibly as part of an exchange for replacement). The
cost/benefit ratio does start to change since there is now much more
work on the crooks part for the same or less gain. One could also
claim that such activities are just part of child-proofing the
environment (even for adults). On the other hand, it could be taken as
analogous to designing systems to handle observed failure modes (even
when the failures are human and not hardware or software). Misc. identify
theft and credit card fraud reference:
http://www.consumer.gov/idtheft/cases.htm
http://www.usdoj.gov/criminal/fraud/idtheft.html
http://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion
http://www.garlic.com/~lynn/subintegrity.html#fraud
Slightly related in recent thread that brought up buffer overflow exploits
http://www.garlic.com/~lynn/2003j.html#4 A Dark Day
and the report that multics hasn't ever had a buffer overflow exploit
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation
somebody (else) commented (in the thread) that anybody that currently
(still) writes code resulting in buffer overflow exploit maybe should
be thrown in jail.
An attack on paypal
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Sun, 08 Jun 2003 20:00:40 -0600
To: "Dave Howe" <DaveHowe@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: "Anne & Lynn Wheeler" <lynn@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 02:09 AM 6/9/2003 +0100, Dave Howe wrote:
The problem is here, we are blaming the protective device for not being able
to protect against the deliberate use of an attack that bypasses, not
challenges it - by exploiting the gullibility or tendency to take the path
of least resistance of the user.
The real weakness in HTTPS is the tendency of certificates signed by Big
Name CAs to be automagically trusted - even if you have never visited that
site before. yes, you can fix this almost immediately by untrusting the
root certificate - but then you have to manually verify each and every site
at least once, and possibly every time if you don't mark the cert as
"trusted" for future reference.
that is why we coined the term merchant "comfort" certificates some
time ago. my wife and I having done early work for payment gateway
with small client/server startup in menlo park ... that had this thing
called SSL/HTTPS ... and then having to perform due diligence on the
major issuers of certificates .... we recognized 1) vulnerabilities in
the certificate process and 2) information hiding of transaction in
flight only addressed a very small portion of the vulnerabilities and
exploits.
lots of past discussions related to our use of merchant comfort
certificate term:
http://www.garlic.com/~lynn/subpubkey.html#sslcert
we concluded that a real issue is that way too much of the
infrastructure is based on shared-secrets and there was no realistic
way of providing blanket protection to all the exposures and
vulnerabilities of such shared-secret infrastructures. somewhat
related discussion in the security proportional to risk posting:
http://www.garlic.com/~lynn/2001h.html#61
so rather than trying to create a very thick blanket of encryption
covering the whole planet .... a synergistic approach was attempting
to provide alternatives to as much of the shared-secret paradigm as
possible. As in the referenced post:
http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper
strong encryption of identification and privacy (and shared-secret)
information is good ... but not having identification, privacy and
shared-secret information is even better.
there are all sorts of ways of obtaining shared-secret information
(and/or privacy and identification information prelude to identity
theft) .... including various kinds of social engineering.
as previously mentioned requirement for X9.59 standard was to preserve
the integrity of the financial infrastructure for ALL electronic
retail payments. As per previous notes, X9.59 with strong
authentication eliminates the account number as a shared-secret as
well as eliminating requirements for name, address, zip-code, etc as
part of any credit card authentication process (strong encryption of
vulnerable information is good, not having vulnerable information at all is
even better).
ALL in addition to referring to things like credit cards, debit cards,
atm transactions, stored-value transaction, over the internet, at
point-of-sale, face-to-face, automated machines, etc .... also refers
to ACH transactions. ACH information allows for unauthenticated push
or pull transactions. Social engineering requesting bank account
information so somebody can push tens of millions into your account
also allows for them to generate a pull transaction removing all the
money from your account. Part of the above posting on the
authentication white paper .... makes references to securing ACH
transactions:
http://www.asuretee.com/company/releases/030513_hagenuk.shtm
virus attack on banks (was attack on paypal)
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 10 Jun 2003 09:19:19 -0600
To: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: virus attack on banks (was attack on paypal)
Cc: "Dave Howe" <DaveHowe@xxxxxxxx>,
"James A. Donald" <jamesd@xxxxxxxx>,
"Email List: Cypherpunks" <cypherpunks@xxxxxxxx>,
"Email List: Cryptography" <cryptography@xxxxxxxx>
At 06:12 PM 6/8/2003 -0600, Anne & Lynn Wheeler wrote:
at a recent cybersecurity conference, somebody made the statement that
(of the current outsider, internet exploits, approximately 1/3rd are
buffer overflows, 1/3rd are network traffic containing virus that
infects a machine because of automatic scripting, and 1/3 are social
engineering (convince somebody to divulge information). As far as I
know, evesdropping on network traffic doesn't even show as a blip on
the radar screen.
virus attempting to harvest (shared-secret, single-factor) passwords
at financial institutions
http://www.smh.com.au/articles/2003/06/10/1055010959747.html
and somewhat related:
http://www.garlic.com/~lynn/aepay11.htm#53 authentication white paper
The real problem that https has conspicuously failed to fix
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 10 Jun 2003 21:33:37 -0600
To: Anonymous <cripto@xxxxxxxx>
Subject: Re: The real problem that https has conspicuously failed to fix
Cc: cryptography@xxxxxxxx
At 11:26 PM 6/10/2003 +0200, Anonymous wrote:
The problem to be solved is this. Spoofed sites can acquire user
credentials, especially passwords, and then use those to impersonate
the user on the real sites. With paypal and e-gold, this allows
stealing real money.
Using client certificates to authentic