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:
https://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 accessible from inside the corporation).

much longer (including technical) description of the online telephone directory effort:
https://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.
https://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
https://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET
https://www.garlic.com/~lynn/internet.htm#22 internal network's 1000th node
https://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.
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
https://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN

--
Internet trivia, 20th anv: https://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.
https://www.garlic.com/~lynn/aepay4.htm#dnsinteg1
https://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:
https://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
https://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories
https://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:
https://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):
https://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:
https://www.garlic.com/~lynn/2002d.html#8 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#24 Security Proportional to Risk (was: IBM Mainframe at home)
https://www.garlic.com/~lynn/2002d.html#25 Security Proportional to Risk (was: IBM Mainframe at home)
https://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:
https://www.garlic.com/~lynn/aadsm12.htm#40 In Brief: Anti-'Skimming' Guidelines Coming
https://www.garlic.com/~lynn/aadsm12.htm#57 eBay Customers Targetted by Credit Card Scam
https://www.garlic.com/~lynn/aadsm6.htm#pcards The end of P-Cards?
https://www.garlic.com/~lynn/aadsm6.htm#pcards2 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aadsm6.htm#pcards3 The end of P-Cards? (addenda)
https://www.garlic.com/~lynn/aepay10.htm#3 High-tech Thieves Snatch Data From ATMs (including PINs)
https://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
https://www.garlic.com/~lynn/aepay10.htm#44 Credit Card Skimming Rising In The US
https://www.garlic.com/~lynn/aepay6.htm#ccfraud2 "out of control credit card fraud"
https://www.garlic.com/~lynn/aepay9.htm#skim High-tech Thieves Snatch Data From ATMs (including PINs)
https://www.garlic.com/~lynn/2001f.html#40 Remove the name from credit cards!
https://www.garlic.com/~lynn/2002i.html#74 A Lesson In Security
https://www.garlic.com/~lynn/2002j.html#60 How to map a user account to a digital cert?
https://www.garlic.com/~lynn/2002j.html#63 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002l.html#20 Backdoor in AES ?
https://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:
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://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
https://www.garlic.com/~lynn/2001h.html#61 net banking, is it safe???
https://www.garlic.com/~lynn/aepay7.htm#netbank2 net banking, is it safe?? ... security proportional to risk

random refs to hardened sites:
https://www.garlic.com/~lynn/aadsm2.htm#risk another characteristic of online validation.
https://www.garlic.com/~lynn/2001.html#33 Where do the filesystem and RAID system belong?
https://www.garlic.com/~lynn/2002.html#44 Calculating a Gigalapse
https://www.garlic.com/~lynn/2002m.html#5 Dumb Question - Hardend Site ?
https://www.garlic.com/~lynn/2002m.html#6 Dumb Question - Hardend Site ?
https://www.garlic.com/~lynn/2002o.html#14 Home mainframes
https://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.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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.
https://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).
https://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement
https://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
https://www.garlic.com/~lynn/subpubkey.html#kerberos

--

Internet trivia, 20th anv: https://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

Refed: **, - **, - **
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:
https://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 synchronized).

random past discussion of float
https://www.garlic.com/~lynn/aadsmore.htm#eleccash re:The Law of Digital Cash
https://www.garlic.com/~lynn/aadsm6.htm#digcash IP: Re: Why we don't use digital cash
https://www.garlic.com/~lynn/aadsm6.htm#echeck Electronic Checks
https://www.garlic.com/~lynn/aadsm7.htm#idcard2 AGAINST ID CARDS

--
Internet trivia, 20th anv: https://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: https://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
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#27 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#28 How effective is open source crypto? (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#29 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#30 How effective is open source crypto? (aads addenda)
https://www.garlic.com/~lynn/aadsm13.htm#31 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#33 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#34 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#35 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#36 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm13.htm#37 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#2 Who's afraid of Mallory Wolf? (addenda)
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?

--
Internet trivia, 20th anv: https://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: https://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: https://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: https://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.
https://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.
https://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
https://www.garlic.com/~lynn/x959.html#x959
account record public key infrastructures
https://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 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
https://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki6 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm9.htm#cfppki7 CFP: PKI research worksho
https://www.garlic.com/~lynn/aadsm10.htm#limit Q: Where should do I put a max amount in a X.509v3 certificat e?
https://www.garlic.com/~lynn/aadsm10.htm#limit2 Q: Where should do I put a max amount in a X.509v3 certificate?
https://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II
https://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
https://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#39 Identification = Payment Transaction?
https://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:
https://www.garlic.com/~lynn/aadsmore.htm#biosigs biometrics and electronic signatures
https://www.garlic.com/~lynn/aepay2.htm#position AADS NWI and XML encoded X9.59 NWI
https://www.garlic.com/~lynn/aadsm2.htm#strawm4 AADS Strawman
https://www.garlic.com/~lynn/aadsm2.htm#activity AADS Activity
https://www.garlic.com/~lynn/aadsm5.htm#faith faith-based security and kinds of trust
https://www.garlic.com/~lynn/aadsm5.htm#spki3 Simple PKI

misc. certificate manufacturing refs:
https://www.garlic.com/~lynn/aadsm2.htm#scale Scale (and the SRV record)
https://www.garlic.com/~lynn/aepay2.htm#cadis disaster recovery cross-posting
https://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))
https://www.garlic.com/~lynn/aadsm5.htm#pkimort2 problem with the death of X.509 PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki10 Software for PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI)
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop

--
Anne & Lynn Wheeler https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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:
https://www.garlic.com/~lynn/subpubkey.html#rpo
https://www.garlic.com/~lynn/99.html#228 Attacks on a PKI
https://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
https://www.garlic.com/~lynn/2000b.html#40 general questions on SSL certificates
https://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format standard
https://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site.
https://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
https://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
https://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
https://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification
https://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#20 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002m.html#55 Beware, Intel to embed digital certificates in Banias
https://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: https://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: https://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 ....
https://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
https://www.garlic.com/~lynn/2003i.html#1 two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#2 two-factor authentication with SSH?
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
https://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation

older token discussions
https://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
https://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
https://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
https://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
https://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
https://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
https://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
https://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
https://www.garlic.com/~lynn/2001g.html#1 distributed authentication
https://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
https://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
https://www.garlic.com/~lynn/2001k.html#61 I-net banking security
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
https://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
https://www.garlic.com/~lynn/2002i.html#65 privileged IDs and non-privileged IDs
https://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
https://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: https://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: https://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 accessible 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
https://www.garlic.com/~lynn/subpubkey.html#radius
misc. kerberos public key authentication posts
https://www.garlic.com/~lynn/subpubkey.html#kerberos
futher discussion specifically regarding stale, static, redundant, superfluous certificates.
https://www.garlic.com/~lynn/subpubkey.html#rpo

slightly related discussions regarding SSL merchant comfort certificates:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

</blatant aads promotion>

Maybe It's Snake Oil All the Way Down

Refed: **, - **, - **, - **, - ** 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 accessible 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.
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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:
https://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
https://web.archive.org/web/20070706004855/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:
https://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 https://www.garlic.com/~lynn/
Internet trivia 20th anv https://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:
https://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:
https://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.
https://web.archive.org/web/20070706004855/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
https://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
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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:
https://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#54 FINREAD was. Authentication white paper
https://www.garlic.com/~lynn/aepay11.htm#55 FINREAD ... and as an aside
https://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:
https://web.archive.org/web/20021017091112/http://www.consumer.gov/idtheft/cases.htm
http://www.usdoj.gov/criminal/fraud/idtheft.html
https://www.garlic.com/~lynn/aadsm14.htm#22 Identity Theft Losses Expect to hit $2 trillion
https://www.garlic.com/~lynn/subintegrity.html#fraud

Slightly related in recent thread that brought up buffer overflow exploits
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day

and the report that multics hasn't ever had a buffer overflow exploit
https://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation
https://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:
https://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:
https://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:
https://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:
https://web.archive.org/web/20030816180523/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:
https://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 authenticate would solve this, because even if the user got fooled and authenticated to the spoofed site, the attacker wouldn't learn the client cert secret key and so would not be able to masquerade as the user.

The problem (among others) is that this allows a virus to steal the client cert. If it is protected by a password, the malware must hang around long enough for the user to unlock the cert (perhaps because the malware sent a spoofed email calling for the user to visit the site, even the real site!). It can then read the user's keystrokes and acquire the password. Now it has the cert and password and can impersonate the user at will.


slight nit .... the solution is non-shared-secret in conjunction with something you have authentication implementing, digital signatures, public/private keys where the private key is never divulged .... even to the owner (the private key housing can be hardware token ... or something embedded in the computer).

it seems that certificates sometimes are considered synonymous with public/private key and digital signatures. however, certificates were originated to address a specific issue with key distribution and trust involving parties that 1) had no prior business relation, 2) were unlikely to have any future business relationship, and 3) didn't have online access to trusted 3rd party. however, it is actually much more natural in a standard business process setting that public key is registered in lieu of shared-secret authentication material when parties are involved that have established business relationship (aka for example a person with some sort of an account, especially in any sort of online paradigm). Trivial examples of certificate-less operation with public/private keys are radius, kerbers pk-init and x9.59 standard for all retail payment transactions (internet, non-internet, point-of-sale, debit, credit, ach, stored-value, etc).

Also note, a certificate tends to only contain the owners public key and some other information about the owner (and nominally is assumed to be freely distributable, somewhat in the same way the PGP keyserver information is published). The certificate doesn't contain the private key ... which tends to be either in a software encrypted file or an external hardware token.

for the various possible types of social engineering & virus exploits, eliminating shared-secrets is only a partial solution (although shared-secrets have a number of vulnerabilities and exploits, so eliminating shared-secrets is not a bad thing)., if the individual has direct access to the private key in any way, then it is possible to compromise that access. That is where some flavor of something you have authentication comes in with hardware that houses the private key and there is no way to divulge the private key, even to the owner. EU finread (financial reader) has an external reader with its own display and pin-pad. This addresses the issue (even with something you have hardware token) where a viirus can 1) display one value on the screen and send another value to the token for signing and 2) spoof keystroke entry with the correct PIN (perform fraudulent transactions w/o the owners knowledge).

If the

1) private key can never be directly physically accessed,

2) the digital signature is taken to represent a form of something you have authentication.

3) the display can be trusted to always display what will be signed

4) the keypad can't be spoofed and actually requires the person to hit the keys

5) hardware token never signs anything unless there has been (human) keypad entry

then the remaining types of fraud will tend to be no different than the phone scams, mail scams and the people coming to your door scams .... effectively no different than the types of fraud that has been going on for hundreds/thousands of years.

An attack on paypal

Date: Wed, 11 Jun 2003 12:42:50 -0600
To: Sunder <sunder@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 10:56 AM 6/11/2003 -0400, Sunder wrote:
In either case, we wouldn't need to worry about paying Verisign or anyone else if we had properly secured DNS. Then you could trust those pop-up self-signed SSL cert warnings.

actually, if you had a properly secured DNS .... then you could trust DNS to distribute public keys bound to a domain name in the same way they distribute ip-addresses bound to a domain name.

the certificates serve two purposes: 1) is the server that we think we are talking to really the server we are talking to and 2) key-exchange for establishing an encrypted channel. a properly secured DNS would allow information distributed by DNS to be trusted .... including a server's public key .... and given the public key .... it would be possible to do the rest of the SSL operation (w/o requiring certificates) which is establishing an agreed upon session secret key.

Keyservers and Spam

Refed: **, - **, - **, - **
Date: Wed, 11 Jun 2003 13:00:31 -0600
To: bear <bear@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: RE: Keyservers and Spam
Cc: Jill.Ramonsky@xxxxxxxx, dahonig@xxxxxxxx,
<cryptography@xxxxxxxx>
At 10:27 AM 6/11/2003 -0700, bear wrote:
I don't particularly like the commercial certs, but the thousand bucks or so ought to serve as a "bond", in that if people untrust the keys, there is real value that will be lost. That makes it require some expenditure of resources to grab a new nym. However, even when provoked - even when root certs have been SOLD - people still don't untrust them, because the news of the compromise doesn't propagate around triggering revokes on individual systems.

i've been told of the things that form the basis of contract/obligation is providing something in return for consideration. the certificate is sold to key owner, to the extent there is some obligation it is tetween the certificate issuer and the owner of the key.

there tends to not be any relationship between the relying party and the certification authority. i believe the federal gov. got around this by having GSA(?) be the certification authority .... with the certificate manufactures/issuers performing as agents of GSA .... and all the possible relying parties had some sort of contract with GSA.

That of course is a little awkward in the case of domain name server certificates .... having all the consumer relying parties in the world sign contracts with the major certificate vendors .... so it would establish some sort of obligation for relying on a certificate.

An attack on paypal (trivia addenda)

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 11 Jun 2003 17:23:52 -0600
To: David Honig <dahonig@xxxxxxxx>
Subject: Re: An attack on paypal (trivia addenda)
Cc: Sunder <sunder@xxxxxxxx>,
    "James A. Donald" <jamesd@xxxxxxxx>,
"Email List:  Cryptography" <cryptography@xxxxxxxx>
somewhat related to the early posting in this m.l. about distributed computing systems conference and possible interest from security and cryptography sections.

when my wife and I were doing ha/cmp
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
we were working with two people in the following meeting in ellison's conference room
https://www.garlic.com/~lynn/95.html#13

who the following year, left and joined a small client/server startup and were responsible for something called the commerce server (the company also had this thing called https/SSL). we then worked with these two people on the implementation for payments for the thing called the commerce server and well as the infrastructure regarding trusting online merchants (as part of promoting this whole thing that came to be called electronic commerce):
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

and more recent posting in the same thread that I had also posted about buffer overflows and the multics study:
https://www.garlic.com/~lynn/2003j.html#15 A Dark Day

in any case, one of the jokes has been there are actually only 200 people in the industry.

ok, reference to the recent related thread on distributed system operation:
https://www.garlic.com/~lynn/2003i.html#70 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003i.html#72 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003j.html#3 A few Z990 Gee-Wiz stats
https://www.garlic.com/~lynn/2003j.html#7 A few Z990 Gee-Wiz stats

and past posts discussing the BBB aspects for online electronic commerce:
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
https://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002
https://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?

An attack on paypal

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Wed, 11 Jun 2003 19:37:32 -0600
To: "Steven M. Bellovin" <smb@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: cryptography@xxxxxxxx
At 08:07 PM 6/11/2003 -0400, Steven M. Bellovin wrote:
Let me point folk at http://www.securityfocus.com/news/5654 for a related issue. To put it very briefly, real authentication is hard.

"real" authentication is not actually that hard; it is "identification" that tends to really get sticky. one of the reasons for simplified security taxonomy like PAIN or PAIIN ... aka
Privacy
Authentication
Identification
Integrity
Non-repudiation


3-factor authentication is
something you have (like a token)
something you know (like password)
something you are (like biometrics)


In the past, I've posted regarding proposals for implementing authentication techniques in association with various internet operation registries .... in part because they are currently relying primarily on identification which is easily spoofed.

the previous posts highlight the domain name take-over exploits .... using the same techniques used in the referenced article for ip-address take-over.

the issue for SSL domain name certificates .... and people concerned about the integrity of the domain name infrastructure .... is that the certification authorities aren't the authoritative reference for the information that they are certifying .... it is the domain name infrastructure (and similarly the ip-address registry). The domain name take-overs have been very similar to the described techniques in the article for ip-address take-over. Somewhat the CA industry proposal is for the registries to implement public key registration at the same time the domain name (or ip-address) is registered. The public key is registered in the registry account record .... and all future interaction is done via authenticated signed transactions (authenticated using the public key in the registry account record).

The claim regarding the operation of the internet operational registries is that they are effectively non-authenticated .... in much the same way that current credit card transactions are not authenticated. The x9.59 standard is for all electronic retail payments and are authenticated using a public key registered in the account record. This is effectively the some proposal (somewhat instigated by the certification authority industry) for transitioning the internet registries from non-authenticated transactions to authenticated transactions (by using digitally signed messages that are authenticated with public key registered in the corresponding registry account record).

as in previous observations .... having a domain name owner register their public key in the internet registry (domain name infrastructure or ip-address registery) starts to lesson the requirement for having SSL domain certificates.

random past posts regarding irony/catch22 for the CAs and SSL domain name certificates:
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
https://www.garlic.com/~lynn/2001l.html#22 Web of Trust
https://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
https://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
https://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
https://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
https://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
https://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003d.html#29 SSL questions
https://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
https://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic

The real problem that https has conspicuously failed to fix

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 12 Jun 2003 08:35:03 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
Subject: Re: The real problem that https has conspicuously failed to fix
Cc: cryptography@xxxxxxxx
At 08:20 PM 6/11/2003 -0700, James A. Donald wrote:
I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts.

or slightly more accurately doing authentication for accounts. the other is frequently confusing identification with authentication. the internet registries (both domain and ip-address) haven't been doing authentication ... but just some simple identification. there are situations where identification may be quite orthogonal to whether or not you are the owner of the account in question. identification also tends to open up the whole can of worms around protecting privacy. as periodically stated (in reference to x9.59) thick blanket of encryption protecting privacy information is good, the information not being there at all is even better.

certificates & the alternative view

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
Date: Thu, 12 Jun 2003 11:14:33 -0600
To: "James A. Donald" <jamesd@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: certificates & the alternative view
Cc: cryptography@xxxxxxxx
At 08:20 PM 6/11/2003 -0700, James A. Donald wrote:
I think you have put your finger right on the problem. Certificates, https, and the entire PKI structure were designed for an accountless world, but the problem is accounts.

the other view ... is using a little information theory .... is that certificates are stale, static, read-only copy of information in the certificate authority's account record .... targeted for offline environments where the relying party has no access to the real authoritative agency responsible for the information.

one of the things from the '90s, in the transition from offline to the start of a pretty much ubiquitous online world was trying to come up with things to put into certificates to justify their price. One of the attempts was extreme overloading of the certificate with large amounts of identity and privacy information, and furthermore you convince the public that they should pay for the privilege of having huge amounts of their privacy information sprayed all over the world.

The fallback is to attempt to reduce as much as possible any information of actual value in a certificate and to not go around confusing identification with authentication. This was sort of the relying-party-only certificates from the financial community in the later part of the 90s .... don't put any information of any value what-so-ever in a certificate; just create these huge, very large bit patterns that were one hundred times larger than a typical payment transaction and require that these extremely large bit patterns had to be attached to every payment transactions sent back to the financial institution (which already had the original copy of all the information). From this it was possible to demonstrate a PKI infrastructure where every certificate was compressed to zero bytes. The horrible payload penalty and information/privacy leakage problem was ultimately addressed with zero byte certificates. They contained zero byte, stale, static, read-only copy of the information in the certificate authority's account record.

An attack on paypal

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Thu, 12 Jun 2003 11:26:57 -0600
To: David Honig <dahonig@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: Anne & Lynn Wheeler <lynn@xxxxxxxx>,
David Honig <dahonig@xxxxxxxx>,
Sunder <sunder@xxxxxxxx>,
    "James A. Donald" <jamesd@xxxxxxxx>,
"Email List:  Cryptography" <cryptography@xxxxxxxx>
At 05:34 PM 6/11/2003 -0700, David Honig wrote:
When I buy $20 of gas with non-bearer credentials (ie, credit card), the vendor does a real-time check on me. Seems fair/useful to be able to do same on them. I suppose eBay's feedback suffices... if their last N "feedbacks" are negative, I might go elsewhere.

we sort of tried that ... however the financial justification sort of fell apart. the big thing about BBB is being able to trust some merchant that you have absolutely no knowledge about. However, the actual buying patterns are extremely skewed ... with well over 80 percent of the transactions either repeat or with some organization that there is other avenues of trust propagation .... and involving a very small number of very large merchants. The BBB model tends to work with higher value, infrequent transaction. The remaining online, merchant market segment not covered via other trust processes, tended to represent a small percentage of total transactions, spread over a very large population of very small merchants, and frequently low value.

eBay is an attempt to provide an alternative delivery for such market segment .... and the issue is how does eBay operations break even financially on a BBB like offering. The first filter is to quickly catch major scamming operations ... and differentiate between the one-off transactions.

PKI "not working"

Refed: **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/12/2003 12:07 PM
To: "todd glassey" <todd.glassey@xxxxxxxx>
cc: "el-sign: electronic signatures - open discussion"
<EL-SIGN@xxxxxxxx>, ietf-pkix@xxxxxxxx
Subject: Re: PKI "not working"
something similar in threads on https (and other online) failings from the cryptography mailing list
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates and an alternative view


https://www.garlic.com/~lynn/aadsm14.htm#5 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#9 "Marginot Web" (SSL, payments, etc)
https://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#32 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#34 virus attack on banks (was attack on paypal)
https://www.garlic.com/~lynn/aadsm14.htm#35 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm14.htm#36 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm14.htm#40 The real problem that https has conspicuously failed to fix
https://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal



todd glossary <todd.glossary@xxxxxxxx on 6/12/2003 8:28 am wrote:
This is a cross posting from the ISC's mailing lists of the Bar Association.

Why it is important here is that it documents perceived problems in the PKI marketplace and I perceive that a number of these issues are failures in the IETF's and potentially the ETSI standards processes, since they allow processes that are at best incomplete from a deployment stance to be elevated into standards status IMHO.

My concern is that the value of the IETF and ETSI is growing less and less with these types of realizations in the marketplace.

Todd

To: <ST-ISC@xxxxxxxx>
Sent: Thursday, June 12, 2003 7:00 AM
Subject: UK: PKI "not working"

PKI is 'not working'

Inadequate technology for online transactions is a 'huge problem' for those in charge of e-government, admits a leading Whitehall official The e-envoy's office has started searching for new ways to authenticate the users of e-services as the existing technology being used is "not working", a senior Government official revealed on 11 June 2003. Although PKI (public key infrastructure) and digital certificate technology has played a major role in leading projects such as the Government Gateway, there is now growing recognition that it is unsuited for wider public use. While digital certificates would not be scrapped, and would be retained as an option for e-service users, one possible alternative being suggested is that employers, banks, the voluntary sector and other "trusted organisations" would verify a person's identity before transacting online for services. Speaking on condition of anonymity, the official said the Government is now looking at "radical ways" of solving the authentication problem. "Trust and authentication has been a huge problem for us. We haven't got a solution for authentication. We've been trying with PKI for about 10 years now and its not working because it's a pain to implement and to use. We've been looking to take the pain out of PKI. What we are saying with authentication is that if another trusted organisation such as a bank can provide proof saying you are who you say you are that should take the need away for digital certificates." The move comes as the e-envoy's office is acutely aware that it needs to step up the pace of e-government leading up to the 2005 target.

http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?OpenDocument

Michael Power

Partner & Chief Privacy Officer
Gowling Lafleur Henderson LLP
Barristers & Solicitors
Patent & Trade Mark Agents
Suite 2600
160 Elgin Street
Ottawa, Ontario, CANADA
K1P 1C3


--
Internet trivia, 20th anv: https://www.garlic.com/~lynn/rfcietff.htm

PKI not working

Date: Thu, 12 Jun 2003 13:10:55 -0600
To: <cryptography@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: PKI not working
picked up from a ietf pkix mailing list posting:
https://www.garlic.com/~lynn/aadsm14.htm#43

http://www.kablenet.com/kd.nsf/Frontpage/2FBC229CDE8C5A1680256D43004176EA?OpenDocument

Keyservers and Spam

Date: Fri, 13 Jun 2003 16:50:20 -0600
To: John Kelsey <kelsey.j@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: RE: Keyservers and Spam
Cc: bear <bear@xxxxxxxx>, Jill.Ramonsky@xxxxxxxx,
dahonig@xxxxxxxx, <cryptography@xxxxxxxx>
At 11:56 AM 6/13/2003 -0400, John Kelsey wrote:
The thing that strikes me is that the PGP web of trust idea is appropriate for very close-knit communities, where reputations matter and people mostly know one another. A key signed by Carl Ellison or Jon Callas actually means something to me, because I know those people. But transitive trust is just always a slippery and unsatisfactory sort of thing--the fact that Jon Callas trusts Fred Smith trusts John Jones to sign a key doesn' t really tell me whether or not I should trust him--by the time we're about three hops away, you'd have to be God to know enough to have your signature mean anything.

PGP .... or other similar account-based mechanisms provide trust between parties that have established relationship .... on a purely pair-wise, bilaterial basis. It does allow some direct trust operations to diffuse out to other parties. It isn't so much a close-knit community .... it is how far every specific entities's trust operation diffuse out across other individuals.

If the entity is called a certification authority .... and it provides an online service ... then the diffusing of specific trust operation might propagate out to a wide community. The issue of course is what trust attributes are propagating/diffusing and the diligence that the entity used in establishing the information to be trusted.

If the entity is called a certification authority, and it manufactures certificates (basically stale, static copies of some CA internal account record) then those certificates will presumably contains some information that is bound to the public key ... where there is some degree of confidence (aka trust) with regard to the binding between the information and the public key.

One issue is what meaning is there between having absolute certainty between something like an email address and a public key. Let's say it is an email address. Typically, email addresses at random are meaningless to me unless they are part of some specific context .... like somebody I have an established relationship with. However, if I have an established relationship with the entity, then it is back to the PGP scenario. In a broad context, businesses run on established relationships; aka financial institutions. The whole existing payment infrastructure effectively has the PGP scenario without needing certificates, and not exactly being considered a very close-knit community.

The primary difference between a financial institution actiing as an entity in a PGP web-of-trust paradigm (say payment cards, credit, debit, etc) and individual .... is the typical scope of the reputation of the financial institution is larger than an individual, and therefor the propagation/diffusing of trust is likely to have a much further reach. To a larger degree ... the trust radius of an entity is somewhat independent of whether it is operating in the PGP manner w/o certificates or in certificate paradigm.

The primary difference in the certificate paradigm is not the scope of the entity's trust .... it is the design point of delivering the trust. The certificate paradigm of trust delivery was targeted at an offline environment for relying parties that had no previous relationship (and had no online and/or direct recourse to the trust entity.

The payment card industry established a certificate-less nearly world-wide scope of trust, in part by providing an extensive online network.

The certificate-based design point was to be able to provide an infrastructure for trust propagation between relying parties that had no previous relationship, were unlikely to need future relationship, and had no online or direct recourse to the trust entity.

An attack on paypal

Date: Thu, 19 Jun 2003 08:56:50 -0600
To: iang@xxxxxxxx
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: An attack on paypal
Cc: cryptography@xxxxxxxx
At 08:15 PM 6/18/2003 -0400, Ian Grigg wrote:
Certificate caching is a far more powerful idea than, say, CA-signed certs. If it were added to browsers, and servers initialised with self- signed certs, then the security of the net would go up immensely. Integrated with some of the ideas that people have suggested concerning WoT, publically distributed certs, and individualised displays (amounting to local secrets keyed on the cert), we could actually start to see people using secured browsing when they wanted to rather than when they were forced to.

typically certificates have had two characteristics .... 1) asn.1 encoding for network interoperability distribution and 2) trusted third party binding of some information to the public key

self-signed certificate caching is really loading public key into a locally maintained table.

in principal there is no need to maintain asn.1 encoding format in a locally maintained table since it eliminates having to decode it on every use .... and the asn.1 encoding is only useful if you 1) are planning on redistributing somebody else's public key and 2) need the original bit format for validating the self-signed signature. The validating of the self-signed signature can be done on initially acquiring the certificate .... and then it can be decoded, and the decoded values loaded into the table. the table/database just becomes entries of public keys and the associated attributes (which might be a combination of the original plus any additional that you might want to add along the way).

in that sense it becomes more of authentication management .... along the lines of kerberos, radius, and/or the AAA RFCs, aka authentication, authorization, and accounting.

in previous posts about BBB, it is possible that it would be used in combination with online trusted references .... i.e. analogous to real-time call to BBB and obtaining referrels and any complaint information ... and then possibly remembering it by recording it in the table (aka online trust propagation as opposed to the offline trust propagation represented by TTP certificates).

Part of the issue with the offline TTP stale, static certificate model was that it periodically tried to overload the contents of the certificate .... trying to justify the expense of the ceritifcate to the public key owner .... but having little or no idea what might be the future requirements of a broad range of relying parties. A locally maintained relying-party table/database would allow the relying party to dynamically adapt the trust characteristics that they were interested in.

Decoding the self-signed certificate before loading into the local table .... helps highlight that the recorded trust characteristics don't have to be restricted to just those that happen to exist in the stale, static certificate (created at some time in the past by entities that had no anticipation regarding your specific trust requirements).

past discussions of online & offline trust propagation:
https://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II)
https://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP
https://www.garlic.com/~lynn/aadsm14.htm#38 An attack on paypal (trivia addenda)
https://www.garlic.com/~lynn/aadsm14.htm#42 An attack on paypal
https://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
https://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#4 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#7 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm5.htm#shock2 revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps
https://www.garlic.com/~lynn/aepay11.htm#7 FTC says incidence of ID theft jumped in 2002
https://www.garlic.com/~lynn/aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
https://www.garlic.com/~lynn/2000f.html#72 SET; was Re: Why trust root CAs ?

UK: PKI "not working"

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 06/24/2003 09:47 AM
To: "Anders Rundgren" <anders.rundgren@xxxxxxxx>
cc: ietf-pkix@xxxxxxxx
Subject: Re: UK: PKI "not working"
anders.rundgren@xxxxxxxx on 6/23/2003 1:44 am wrote:
I fully agree with Mitchell's conclusions of what PKI is good for as it stands today. To be able to serve millions of citizens at thousands of independent e-government portals, either requires TTP identity-portals (using SAML etc.), or client-side PKI using TTP CAs. No other methods have proven to be technically or economically feasible.

I cannot verify any major 100000-foot legal problems, but quite a bunch of down-to-earth (zero-foot?) problems like "lousy browsers", and the lack of ubiquitous, secure, and mobile key-containers. IMO, it is really only the latter that hampers enterprise-PKIs as a userid/password-replacement on a wider scale. This problem is neither a standards problem, nor a technical ditto. It is rather an example of blatant stupidity among "certain manufacturers".

Regarding "legally binding", virtually anything that offers reasonable technical integrity is likely to be applicable as evidence in a court trial in most countries. Examples of this are phone-operators' call-lists that may prove "association" or DNA-fingerprints that may prove "It wasn't me". What is a bit puzzling is that non-PKI e-solutions never seem to be questioned regarding their.merits in courts...

A "legal" aspect that though really is an issue, is TTP CA liability. However, this is mostly a US issue where suing people is a part of the system. I believe this will have a negative impact on PKI usage in the US, unless there is a way to automatically accomplish what Identrus et al "achieves" by requiring relying parties to sign agreements freeing the issuer from liability. Here I would like to address the PKIX WG with a request for some kind of remedy.

Anders


============

I believe it is the electronic signature act ... and there are other parts of the same bill. it allows various kinds of electronic marks .... but the main issue for a legal signature (& non-repudiation) is demonstration of some sort of intent, agreement, etc. The EULAs that require clicking in various places after reading variouis directions meet more of the criteria of demonstrating intent & agreement than does almost all of the CA PKIs that effectively don't enforce any process after the certificate has been returned to the key owner.

The main issues addressed by the vairous public key digital signatures are message authentication and integrity ..... as been repeated in numerous past threads involving non-repudiation ... there is still an enormous gap between message authentication/integrity and non-repudiation.

The big issue of TTP CA PKI and legaly issue is that almost all legal relationship (like contracts) are between two parties where one has paid money and received something in return. That describes the relationship between the TTP CA PKI entity and the key owner. The legal objective seems to be to create some legal fiction that involves a relationship between the TTP CA PKI and the relying-party. The traditonal legal relationship doesn't apply to anything between the TTP CA PKI and the relying-party. As been mentioned in numerous, repeated threads on this subject in the past, GSA manufactured such a relationship by some sort of contract between GSA and the TTP CA PKI's ... and GSA and the relying-parties .... so that the facade of legal relationship between the relying parties and the TTPs. For the most part, the traditional TTP CA PKI's enforce little or no process after the certificate has been returned to the key-owner.

Note that the GSA model is similar to the business/legal relationships established as part of the online debit/credit infrastructures. The debit/credit infrastructure used to be an offline, manual process. Starting in the mid-70s, they skipped over the TTP CA PKI paradigm of offline, electronic process and went directly to an online, electronic process. For the debit/credit infrastructure the paradigm represented by TTP CA PKI represents a 30 yuear old technology option that they decided to skip.

somewhat related is the recent thread on confusing authentication and identification:
https://www.garlic.com/~lynn/aepay11.htm#66 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#67 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?

past threads with mention of pair-wise GSA contracts with both TTPs and relying-parties created some sort of legal relationship between relying-parties and TTPs:
https://www.garlic.com/~lynn/aadsm12.htm#22 draft-ietf-pkix-warranty-ext-01
https://www.garlic.com/~lynn/aadsm12.htm#41 I-D ACTION:draft-ietf-pkix-sim-00.txt
https://www.garlic.com/~lynn/aadsm12.htm#42 draft-ietf-pkix-warranty-extn-01.txt
https://www.garlic.com/~lynn/aadsm14.htm#37 Keyservers and Spam

misc. past threads that reference non-repudiation as well listing other threads on non-repudiation:
https://www.garlic.com/~lynn/aadsm12.htm#37 Legal entities who sign
https://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/2001g.html#61 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001g.html#62 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
https://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#36 Net banking, is it safe???
https://www.garlic.com/~lynn/2001i.html#57 e-commerce security????
https://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2003h.html#38 entity authentication with non-repudiation
https://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation

basic question: semantics of "map", "tie", etc in PKI

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Date: Tue, 08 Jul 2003 11:40:29 -0600
To: Fritz Schneider <fritz@xxxxxxxx>
Subject: Re: basic question: semantics of "map", "tie", etc in PKI
Cc: cryptography@xxxxxxxx
At 08:45 AM 7/8/2003 -0700, Fritz Schneider wrote:
This is possibly a silly question, but here goes.
Reading something PKI-related the other day I was wondering about the semantics of different kinds of certificates. One usually says that traditional id certs "map names to keys" or "tie keys to names"[1]. This is usually written:

name -> key

Other certs have similar semantics (they "map" and "tie"). For example, in order to achieve authorization one could keep an ACL which "maps permissions to names" ("ties names to permissions"):

permission -> name

Given these two mappings its then possible to get the mapping:

permission -> name -> key

which authorizes the key for the permission.
I actually have two questions.
The first is what exactly does "mapping" mean in this sense? I'm not sure that it means "mapping" in the sense of the algebraic definition because for each x that is mapped, there should only be only one value to which x is mapped, and I think of an ACL or SPKI cert as incompatible with this notion. "Tie" and "bind" seemed to be used in to indicate both a mapping or that something is mapped to. My second question is, in mappings like:

permission -> name -> key

why do we think of it as mapping permission to a key and not the other way around? The way I typically think about the task of reasoning about authorization seems to work in the opposite direction.

-- fritz

[1] RFC2693, for example


basic authentication taxonomy is something like:

1) something you have (like a hardware token)
2) something you know (like a pin/password)
3) something you are (like biometrics)

frequently PKIs talk about certifying (aka CA's are certification authorities, certificates represent some certification by a certification authority) some binding between something and a public key.

one could claim that the choice of vocabulary was trying to elevate something from straight-forward authentication to something like identification and non-repudiation ... which would represent much more value and therefor the public key owner buying the certificate might pay more. Note, however, identification and non-repudiation is primarily of benefit to the relying-party that receives the certificate .... but the standard TTP business model has the private key owner paying for the certificate (not the relying party .... which is receiving the primary benefit).

There has been lots of discussion that PKIs don't actually do identification or non-repudiation which requires lots of additional processes.

Certification authorities basically have an entity prove that it can generate a digital signature that can be validated with the supplied public key ..... basically a form of something you have authentication ... the entity can prove it has the private key. The certification authority then validates some other piece of information (like the entity's email address); stores the public key and the certified information in a database and then creates a credential/certificate as to the binding between the certified information and the certified public key.

Originally, x.509 specification was thought of as heavily overloading a certificate with lots of identity related information as well as privilege/permission related information ... bound to a public key in a certificate. It pretty quickly became apparent that a credential/certificate heavily overloaded with identity and permission information and indiscriminately broadcast all over the world created enormous privacy problems.

Financial institutions in the mid-90s dropped back to relying-party-only certificates which basically contain only account number and the public key because of the enormous privacy and liability problems. However, a standard business process involving certificate has the key-owner 1) creating a transaction/message, 2) appending a digital signature, 3) appending the certificate ... and transmit the "triple" to the bank.

The bank extracts the account number from the transaction/message, reads the account record and validates the digital signature using the public key stored in the account record. The relying-party-only certificate containing only an account number and public key (because of the enormous liability and privacy issues) is never used. It was subsequently observed that such relying-party-only certificates were redundant and superfluous.

The original purpose of certificates were to provide various certified associations for an offline world (something analogous to letters-of-credit from the days of sailing ships). These certificates were a stand-in/substitute for situations where it was not possible to directly access the real information. Most of them are quickly loosing any reason for existence given the extensive proliferation of internet and wireless technologies around the world. It is becoming more and more unlikely that there wouldn't be some form of connectivity .... especially for transactions or authentication events involving anything of value or importance.

The semantics of private key is basically something you have .... however given the vagaries of software computing systems, the private key can be stored in a hardware token or in a software encrypted file on a general purpose computer. The software encrypted file is unlocked with a PIN/password ... given some of the characteristics of general purpose computers (like personal computers), any kind of file might be considered publicly copy'able by anybody in the world. As a result, such an encrypted file .... might actually be considered something you know authentication (as opposed to something that you "uniquely" have). A hardware token that generates the key in the chip and never allows the private key to leave the chip .... might be considered more representative of something you have authentication.

A hardware token that requires a PIN/password to operate can be considered two-factor authentication (something you have and something you know). Note that in this situation, the business processes of the token and digital signature technology creates an environment that can be used to establish something you have (aka the hardware token). The digital signature technology is not an end in itself ... just a method of proving that you posses a specific hardware token (and possibly have knowledge of a specific PIN/password).

As previously noted .... sometimes there is PKI documentation that attempts to grossly exaggerate the meaning of a digital signature and obfuscate the underlying business processes and procedures .... possibly as part of a sales technique to convince public key owners to purchase the certificates (obfuscation that attempts to establish certificates as an end in themselves).

misc. past about relying-party-only certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo

replay & integrity

Date: Thu, 10 Jul 2003 07:03:13 -0600
To: "Zooko" <zooko@xxxxxxxx>
From: Anne & Lynn Wheeler <lynn@xxxxxxxx>
Subject: Re: replay & integrity
Cc: iang@xxxxxxxx, "EKR" <ekr@xxxxxxxx>,
"tom st denis" <tomstdenis@xxxxxxxx>, cryptography@xxxxxxxx
At 02:19 PM 7/9/2003 -0400, Zooko wrote:
I'll try to make this concrete. My thesis is different than Ian's -- rather than saying that those apps need less than what TLS offers, I say that they need more! (So that each app need no longer implement the added features itself.)

we did two kinds of replay countermeasures ... one for AADS RADIUS
https://www.garlic.com/~lynn/subpubkey.html#radius

and a different kinds for x9.59 (for all electronic payments in all environments)
https://www.garlic.com/~lynn/x959.html#x959

in the aads radius there is this (real-time) protocol chatter; client contacts server, server returns message with unique value, client includes unique value in signed message that is returned to server. server validates the signature and makes sure the client's message returns the previously transmitted unique value.

for x9.59 to work in all environments ... it had to operate in single round trip (as per many of existing financial messages). the client creates a complete signed message and sends it to the server (financial institution), the message has some possibly unique values ... but not necessarily guaranteed, including time. the server uses current time and message time to bracket checking of previously processed messages for replay.

the radius implementation requires two round-trips to establish the unique value as part of replay countermeasure.

the x9.59 implementation (in order to meet one of the requirements for the protocol; perform completely in single round trip) uses a log and a sort of fuzzy time implementation (at the server). this is in part because the client end can be considered somewhat unreliable ... not necessarily being able to reliably remember previous value and/or keep synchronized time. highly synchronized time could eliminate the log check. having reliable client that was guaranteed to remember previous transaction could get by with the log elimination by using a take off on the single password scheme .... where both the server and the client reliably remembers just the previously used value, this rmemory doesn't get out of sync ... and the iteration to the next value is non-obvious.

and of course the overall requirement given the x9a10 working group for x9.59 was to preserve the integrity of the financial infrastructure for all electronic payments in all environments.

E-banking is board-level Issue, Says Basel Committee

Refed: **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/22/2003 05:02 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: E-banking is board-level Issue, Says Basel Committee  ... fyi

http://www.banktech.com/story/enews/BNK20030722S0003
E-Banking Is Board-Level Issue, Says Basel Committee
Ivan Schneider
Jul 22, 2003

Unprecedented speed of change, increased dependence on systems architecture, more complex operations, and magnified importance of security -- such are the fruits of e-banking in financial services.

While it does not bring "inherently new risks," electronic banking has changed the overall industry risk profile, according to the Basel Committee on Banking Supervision in a July 2003 report. Therefore, the Committee recommends, banks' senior management and boards of directors should review and modify existing risk policies where necessary, and take a more active role in setting the strategic direction of e-commerce initiatives.


... snip ...

Feds, industry warn of spike in ID theft scams

Refed: **, - **, - **
From: Lynn Wheeler
Date: 07/22/2003 05:06 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Feds, industry warn of spike in ID theft scams
http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,83282,00.html?SKC=security-83282
Feds, industry warn of spike in ID theft scams
A new report shows a dramatic increase in incidents of identity theft
By Paul Roberts, IDG News Service
JULY 21, 2003

The U.S. federal government and EarthLink Inc. warned today of a surge in unsolicited e-mail and scam Web sites that are designed to steal the identity of unsuspecting Internet users.

The Atlanta-based Internet service provider has seen a spike since the beginning of the year in e-mail linked to so-called "phisher" Web site scams, which use spam to lure victims to Web sites that look like legitimate retail or corporate sites, according to company spokeswoman Carla Shaw.


... snip ...

Committee calls for better e-banking security management

Refed: **, - **, - **, - **, - **, - **, - **
From: Lynn Wheeler
Date: 07/23/2003 03:58 PM
To: Committee calls for better e-banking security management
Subject: Committee calls for better e-banking security management
http://www.infoworld.com/article/03/07/23/HNebanking_1.html
Committee calls for better e-banking security management
Report lists 14 "best practices" for financial institutions
By Paul Roberts, IDG News Service
July 23, 2003

An influential international banking committee issued a report Tuesday calling for better security and management of electronic banking (e-banking) by the world's financial institutions.

The report, "Risk Management Principles for Electronic Banking," was released by the Basel Committee on Banking Supervision and published on the Web.

The rapid growth of e-banking in recent years has created a wealth of new banking products and services, but has also increased banks' exposure to financial and legal risks, the committee said.


... snip ...

IT Managers Critical Front in War on Identity Theft

From: Lynn Wheeler
Date: 07/23/2003 04:00 PM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: IT Managers Critical Front in War on Identity Theft

http://itmanagement.earthweb.com/ecom/article.php/2239211
IT Managers Critical Front in War on Identity Theft
July 23, 2003
By Sharon Gaudin

A steady rise in online identity theft should be signaling IT managers to shore up customer information before they face any further deterioration in consumer confidence


... snip ...

Draft E-Authentication Policy for Federal Agencies

From: Lynn Wheeler
Date: 07/25/2003 07:28 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Draft E-Authentication Policy for Federal Agencies

https://web.archive.org/web/20030716055158/http://www.estrategy.gov/eapolicydraft.cfm
Draft E-Authentication Policy for Federal Agencies SUMMARY:  The General Services Administration, in coordination with the Office of Management and Budget (OMB) request comments on the attached draft policy on E-Authentication for Federal Agencies.  GSA has coordinated this draft policy with OMB and will work closely with OMB in reviewing comments and issuing the final policy.  In this draft policy, GSA is requiring that agencies implement this E-Authentication Policy, which establishes four assurance levels to create a Governmentwide standard framework for determining what is required to access a particular Government transaction online.
DATES:  To ensure consideration of comments, comments must be in writing and received by GSA no later than August 11, 2003. ADDRESSES:  Comments on this notice should be addressed to Ms. Von Harrison, General Services Administration; Office of Electronic Government and Technology (MEI), Washington, DC 20405.  You are encouraged to submit these comments by facsimile to (202) 501-6455, or by electronic mail to egov.taskforce@xxxxxxxx FOR FURTHER INFORMATION
CONTACT:  Ms. Von Harrison, General Services Administration, Office and Electronic Government and Technology (MEI), Washington, DC 20405; or by phone at (202) 273-0721.


The Best ID Plan? Wait and See

From: Lynn Wheeler
Date: 07/25/2003 07:59 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: The Best ID Plan? Wait and See

http://www.eweek.com/category2/0,3960,1184404,00.asp
The Best ID Plan? Wait and See

Tech Analysis: The major players in the ID management arena are still far enough apart to warrant that IT managers proceed with caution in plotting courses toward managing identity.


... snip ...

IT Security to be added to FAR

From: Lynn Wheeler
Date: 07/25/2003 08:02 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: IT Security to be added to FAR

https://web.archive.org/web/20040512164032/http://www.washingtontechnology.com/news/1_1/daily_news/21287-1.html
07/24/03
IT security to be added to FAR
By William Jackson
PostNewsweek Tech Media

The General Services Administration is drafting a Federal Acquisition Regulation addition to integrate security into IT buys.

Joan Hash, director of security management assistance in the National Institute of Standards and Technology’s Computer Security Division, made the announcement today during a discussion of government cybersecurity requirements at the GOVSEC security conference in Washington.


... snip ...

Kinko's spy case: Risks of renting PC's

From: Lynn Wheeler
Date: 07/25/2003 08:05 AM
To: epay@xxxxxxxx, internet-payments@xxxxxxxx
Subject: Kinko's spy case: Risks of renting PC's

https://web.archive.org/web/20030726051209/http://www.cnn.com/2003/TECH/internet/07/23/cybercafe.security.ap/index.html
Kinko's spy case: Risks of renting PCs
Wednesday, July 23, 2003 Posted: 9:08 AM EDT (1308 GMT)

NEW YORK (AP) -- For more than a year, unbeknownst to people who used Internet terminals at Kinko's stores in New York, Juju Jiang was recording what they typed, paying particular attention to their passwords.

Jiang had secretly installed, in at least 14 Kinko's copy shops, software that logs individual keystrokes. He captured more than 450 user names and passwords, and used them to access and open bank accounts online.


... snip ...


AADS Postings and Posting Index,
next, previous - home