2003 Newsgroup postings (08/17 - 09/07) Lynn Wheeler

2003 Newsgroup Postings (08/17 - 09/07)

One big box vs. many little boxes
Digital signature and Digital Certificate
S/360 Engineering Changes
S/360 Engineering Changes
S/360 Engineering Changes
Multiple ECDSA signatures with the same random nonce
The Original Interlock Protocol (what is...)
One big box vs. many little boxes
14443 protocol information
how long does (or did) it take to boot a timesharing system?
how long does (or did) it take to boot a timesharing system?
how long does (or did) it take to boot a timesharing system?
Why are there few viruses for UNIX/Linux systems?
Cost of patching "unsustainable"
Cost of patching "unsustainable"
downsizing (euphemisms)
how long does (or did) it take to boot a timesharing system?
how long does (or did) it take to boot a timesharing system?
ARP cache for multicast & broadcast packets?
Secure OS Thoughts
Secure OS Thoughts
Secure OS Thoughts
Secure OS Thoughts
Why more than 1 hole in FW for IPSec
RSA vs AES
IBM Manuals from the 1940's and 1950's
Secure OS Thoughts
RSA vs AES
RSA vs AES
Offshore IT
Secure OS Thoughts
IBM Manuals from the 1940's and 1950's
RSA vs AES
RSA vs AES
Thoughts on Utility Computing?
RSA vs AES
Proposal for a new PKI model (At least I hope it's new)
Thoughts on Utility Computing?
Thoughts on Utility Computing?
Port Assignment- OT in a Small Way
The real history of computer architecture: the short form
Secure OS Thoughts
Thoughts on Utility Computing?
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
OSI not quite dead yet
IBM Manuals from the 1940's and 1950's
Thoughts on Utility Computing?
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Proposal for a new PKI model (At least I hope it's new)
Offshore IT ... again
Proposal for a new PKI model (At least I hope it's new)
Thoughts on Utility Computing?
Thoughts on Utility Computing?
Proposal for a new PKI model (At least I hope it's new)
Can you use ECC to produce digital signatures? It doesn't see
IBM Manuals from the 1940's and 1950's
Seven of Nine
Can you use ECC to produce digital signatures? It doesn't see
Strength of RSA with known plain-text

One big box vs. many little boxes

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One big box vs. many little boxes
Newsgroups: comp.arch
Date: Sun, 17 Aug 2003 15:50:56 GMT

"Christophe Lephay" <christophe-lephay@wanadoo.fr> writes:
This could be as well because TCP/IP was not designed in a separated layers model at first, and it would be rather a good exemple of how much difficult it is when you don't have layers at first glance...

arpanet had single homogeneous infrastructure .... in large part relying on IMPs. TCP was available ... but there was really no such thing as gateways and heterogeneous networking.

one of my assertions is that the internal network was larger than the arpanet/internet until sometime mid-85 ... in large part because the internal network nodes effectively had gateway function almost since the start .... which didn't show up until the "internet protocol" layer switch-over on 1/1/83.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Digital signature and Digital Certificate

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Digital signature and Digital Certificate
Newsgroups: comp.security.firewalls
Date: Sun, 17 Aug 2003 18:34:45 GMT

slightly related thread:
http://www-unix.gridforum.org/mail_archive/security-wg/2003/03/msg00002.html

original reference in above at:
https://www.garlic.com/~lynn/aadsm13.htm#20

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

S/360 Engineering Changes

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 Engineering Changes
Newsgroups: alt.folklore.computers
Date: Sun, 17 Aug 2003 20:03:02 GMT

ab528@freenet.carleton.ca (Heinz W. Wiggeshoff) writes:
Does anyone else agree that the Internet/WWW design is fundamentally flawed? Some piece of shit can take over command of YOUR computer and make it sing and dance. In all the years of connecting to IBM m/f remotely, (from APL\360 to VM in the 1990's), I never even heard of virus or worm infections. Perhaps the shit design work out of Redmond has a lot to do with SANlove, (or whatever it's called).

we shot/identified a vulnerability about 30 years ago on the internal network ... where somebody sent a CMS "exec" file as part of some email ... that had the same filename as a standard CMS command. The cms (shell) command lookup process did a search that involved synonym table, exec file, module file, and then internal kernel api (and files were searched for in prescribed order). In effect, it was possible to get a person to load an exec file (script file) ... with the name of a standard common command ... and have it executed automagically, the next time ther person typed in that command.

at that point (remember this was 30 years ago) ... it was concluded that you had to have procedures that avoided (automagically) executing scripts and/or binaries arriving over the network.

at a recent cybersecurity conference ... one of the panel claimed that currently about exploits:

1/3rd are buffer overflows (primarily result of programmers being encouraged to shoot themselves in the foot because of characteristics of c-language string handling semantics).

1/3rd are scripting/executing of files arriving over the network

1/3rd are social engineering

prior to the (latest) introduction of network-originating scripting/execution, the exploits were pretty evenly (c-language) buffer overflows and social engineering. there was a paper presented last year that claimed Multics has never had a known case of buffer overflow. It isn't so much that PL/I (multics) language was relying on range/bounds checking ... but the underlying semantics for handling strings is totally different (from C library routines). It wasn't so much that it was impossible to run over a buffer ... but the length related semantics made it much less likely to happen.

social engineering typically involves inducing a person to give up some shared-secret based piece of information .... aka some information and/or values that enables the crook to fraudulent perform some operation(s).

it is related to making rules that (shared-secre) password-based security demands that nobody uses the same password in multiple contexts (aka your employee login password shouldn't be the same as your local personal ISP login, shouldn't be the same as your home banking login). this gives rise to some people nominally having requirements for large tens or hundred plus (shared-secret) passwords. many of the human factors related to rules about re-using passwords and never divulging information (in social engineering scenarios) are similar; aka you can have all the rules you want and they still get violated.

One approach to both the social engineering and hundreds of passwords issue is to transition away from shared-secret based infrastructures (aka a paradigm where if a person doesn't know something ... then it can't be divulged and/or shared)

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

S/360 Engineering Changes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 Engineering Changes
Newsgroups: alt.folklore.computers
Date: Sun, 17 Aug 2003 20:11:03 GMT

oh yes, misc. past posts on automagic scripting
https://www.garlic.com/~lynn/aadsm14.htm#32 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/2001k.html#43 Why is UNIX semi-immune to viral infection?
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/2002d.html#16 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2002g.html#27 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)
https://www.garlic.com/~lynn/2003j.html#8 A Dark Day

lots of general fraud, exploits, and vulnerability discussions:
https://www.garlic.com/~lynn/subintegrity.html#fraud

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

S/360 Engineering Changes

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: S/360 Engineering Changes
Newsgroups: alt.folklore.computers
Date: Sun, 17 Aug 2003 22:23:23 GMT

"Glen Herrmannsfeldt" writes:
This reminds me (because it involves exec) of one of my early programs run under CMS. I was writing a PL/I program to sort some data, which used a SORT command that the version of PL/I had. It seemed to make sense that my program should be named SORT, both in its file name, and the name of the main procedure, SORT: PROC OPTIONS(MAIN).

I found a mysterious infinite loop that I couldn't find, so finally I tried changing both the file name and PROC name.

That was before I knew the rules for CMS executing programs. I don't believe that MVS would have the same problem, though I am not sure about that.

cms possibly inherited human factors from ctss ... allowing ultimate tailorability to the individual's desired environment (which doesn't mean that you couldn't shoot yourself in the foot); while MVS effectively demanded that the person adapt to the system.

original CMS ... all commands were svc202 with an 8byte symbolic name. typed in commands were translated to svc202 format .... programming api used svc202 format/api.

that name could be looked up in a synonym/abbreviation table ... that the user could specify entries in.

then filesystems were scanned in prescribed order for EXEC file with that name, then filesystems were scanned for MODULE (binary executable) file with that name. Finally, it looked to see if there was a kernel interface with that name. Later VM/370 added a fastpath to CMS for kernel API ... svc203 which specified a code that was specific for selecting kernel functions.

in effect, something like "script" could be developed in the users's own filesystem and invoked transparently the same as if it was a system command. at some point the program could be moved to the area with standard system commands ... and voila the whole community now has document formating routine.

this human factors useability feature appeared to contribute significantly to development and migration to more general availability of all sorts of feature/function in the cms environment (aka somebody could develop something for their own use and it could transparently be made available for wider use ... if found useful) ... aka a single, uniform, consistent interface for invoking all commands and programs.

misc. past posts on cms command lookup:
https://www.garlic.com/~lynn/2001c.html#88 Unix hard links
https://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003l.html#2 S/360 Engineering Changes

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Multiple ECDSA signatures with the same random nonce

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple ECDSA signatures with the same random nonce
Newsgroups: sci.crypt
Date: Sun, 17 Aug 2003 22:43:11 GMT

hei123@gamebox.net (Ruaide Berti) writes:
Sorry from this questions, but I don't understand the math behind encryption.

think along the lines of solving two equations in two unknowns ... if both private key and random number are constant. FIPS186 objective is to have the random number, never the same.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

The Original Interlock Protocol (what is...)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The Original Interlock Protocol (what is...)
Newsgroups: sci.crypt
Date: Mon, 18 Aug 2003 14:23:36 GMT

"John E. Hadstate" writes:
As I explained before, the protocol's advertised purpose was to defeat the MITM attack. But, a protocol that requires a shared-secret to be established out-of-band with respect to the protocol itself is not solving anything. It's merely relying on the out-of-band transfer to defeat MITM.

check on various MITM countermeasures involving some sort of out-of-band transfer. SSL certificates & public key operations .... rely on the certifying authority's public key to be locally registered ... requiring out-of-band transfer (common practice of building it into the browser and it is transferred as part of installing the browser). Essentially there is some atomic unit of trust that all the other pieces are scaffolded on top of (while the CA's public key isn't a shared-secret .... it is a basic trust building block that required out-of-band transfer).

slightly related:
https://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
https://www.garlic.com/~lynn/2003l.html#1 Digital signature and Digital Certificate

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

One big box vs. many little boxes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One big box vs. many little boxes
Newsgroups: comp.arch
Date: Thu, 21 Aug 2003 17:56:42 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
Furthermore, I have been told by senior representatives of all the major vendors that their policy is to use common components and designs whereever practical. I am fully aware that a company like IBM has many incompatible policies, but I can assure you that at least the IBM SP range uses a great many components in common with its RS/6000 workstation range.

similar subject in "downsizing" thread going on in real-time over in ibm-main ng/list ... some number making similar claims ... although one person who claims has seen lots of actual numbers under NDAs ... and can't repeat them.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

14443 protocol information

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 14443 protocol information
Newsgroups: alt.technology.smartcards
Date: Thu, 21 Aug 2003 18:00:34 GMT

"curok" writes:
Ummm, sorry if i misled you. I think i'm wrong about the ISO 7816. ISO7816 is for contact cards and ISO14443 is for contactless. Did you read the part 4 of ISO 14443 which states the transmission protocols? I don't know for sure but in part 4 of ISO7816, there are some commands that let you read, write data to the card. I don't know if it holds true for 14443.

14443 proximity standard actually has a couple of variations (effectively originating from different vendors). some vendors that have done combo-chips .... will have wrapped 14443 circuits around 7816 core ... so that applications developed on 7816 may find it somewhat transparent whether operating in 14443 or 7816.

big issue in 14443 can be power profile for anything very complex since the chip is drawing the power from the air.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

how long does (or did) it take to boot a timesharing system?

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Aug 2003 00:01:31 GMT

Lon Stowell writes:
I dimly remember one of the blurbs for a major VTAM release in the late 80's [V3R2] mentioning the reduction of bringup of a major SNA network complex to something on the order of 4 hours compared to pretty close to a day beginning at IPL of MVS. This was bringing up one or more MVS's, downloading all of the NCP's, etc. Don't recall that clearly but don't think it included bringing up any IMS or CICS on top of all this.

one of the issues that i remember was some issue with VTAM page thrashing as part of restart.

one of the characteristics of the pu4/pu5 emulator was that all the sessions and resources appeared to be owned someplace else (effectively it was a distributed packet, no-single-point-of-failure implementation ... on top of which pu4/pu5 were emulated).h

misc. refs:
https://www.garlic.com/~lynn/99.html#67 System/1 ?
https://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

how long does (or did) it take to boot a timesharing system?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Aug 2003 00:08:46 GMT

Larry__Weiss writes:
I'd like to hear accounts of how long it took to bring up some of the old timesharing systems. I was never a part of the "priesthood" behind the locked doors, so I don't know from experience (my initial timeshared system experience as a user was on a CDC-6600 at UT Austin).

cp/67 would nominally be on the order of 2-3 minutes .... vm/370 was similar. part of the issue in early cp/67 was to make it automated so that system could run unattended.

one of the supposedly justifications for the work on the multics fast/new filesystem ... was the comparison to cp/67 ... where somebody at mit introduced a bug ... which when a specific circumstance was encountered ... there was a system failure, a full system dump was automatically taken and the system automatically rebooted. this supposedly happened 26 times during the course of one day. by comparison, multics was taken an hour or more to reboot (there were enuf hours in the day for the system to fail and reboot and be back, up and running, providing service ... 26 times in one day).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

how long does (or did) it take to boot a timesharing system?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Sat, 23 Aug 2003 00:39:34 GMT

Lon Stowell writes:
The blurb I am thinking of was one of the semi-official IBM pubs for the release. Problem is there were so many of them, as this IIRC, was the big VTAM/NCP release to first support PU 2.1 with independent LU's. Not so much too lazy to dig it out, as that particular stack of yellow and red books is in an anonymous box stacked in an unknown location with a considerable number of other anonymous boxes in a pile dating back to prior to 1989 when I left Amdahl and mainframe networking more or less forever. There are probably creepy crawlies in the boxes by now.

this was early to mid 80s studies in conjunction with ims hot standby .... while IMS might be there "instantaneously" ... it could take 4-6 hours to get large number of VTAM sessions back .... there were lots of issues with VTAM non-linear slowdowns ... the first couple sessions came back relatively quickly ... but then things got progressively slower, very, very quickly.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Why are there few viruses for UNIX/Linux systems?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why are there few viruses for UNIX/Linux systems?
Newsgroups: comp.os.linux.security,alt.folklore.computers
Date: Sat, 23 Aug 2003 18:12:55 GMT

Tim Haynes <usenet-20030823@stirfried.vegetable.org.uk> writes:
I know of no native "layers of virtualisation" system in any M$loth OS, that's one of the problems. Around here, we have chroot() with GRsecurity patches for further security, jail() on BSE, ctx server patches and UML. Take your pick, how do you want it to be "not the real machine" running your services today?

MSware: VMware. Well, we got that too.

both cp/67 and vm/370 have had relatively good security records with their virtual machine approach. There has been some discussion that the B3(?) vax/vms rating was done by creating a virtual machine abstraction below vms ... for various security domain and isolation issues.

note that just about all of the mainframes now have flavor of vm/370 subset built into the hardware of the machine ... and just about all mainframe installations (MVS, VM, Linux, etc) now are run in these virtual machines aka virtual machine subset called LPARs (or logical partitions). LPARS essentially grew out of the expanding VM "microcode assists" that originally appeared on 370/158 (early 70s) .... until there was sufficient amount of virtual machine microcode assists embedded into the hardware of the machine ... that it was possible to provide virtual machine subset (LPARs) even when not running full blown virtual machine operating system.

The LPAR settings are typically setup under control of a "service processor" that provides interfaces, diagnostics, and control of many of the hardware features. However, service processors in their own right could also have operating systems. The mainframe 3090 had a pair of 4361s for service processors .... both running a highly modified version of VM/370 release 6 ... and all the service panels and interfaces were mostly implemented in IOS3270, an application running under CMS (in virtual machine under VM/370).

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Cost of patching "unsustainable"

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost of patching "unsustainable"
Newsgroups: comp.arch
Date: Sat, 23 Aug 2003 17:59:48 GMT

"Stpehen Fuld" writes:
Yes, IIRC that ws the one that the former IBM Federal System Division won the contract and got so far behind schedule and over budget that it was clear that it would never get done in any reasonably time and the program was canceled.

i believe that large percentage of federal agencies have had modernization projects starting (at least) in the '80s and extending thru the 90s. some of those modernization projects may be in the 4th or 5th generation ... with some set of the vendors the same every time ... but prime contractor may change from generation to generation. i've heard some wonder if the modernization activities haven't turned into modern version of public works projects that might not just go on forever.

i believe census was one of the better successes in the late '90s.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

Cost of patching "unsustainable"

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Cost of patching "unsustainable"
Newsgroups: comp.arch
Date: Sun, 24 Aug 2003 19:44:52 GMT

"del cecchi" writes:
Easily could have been FSD. IBM is not immune from biting off more than they can chew/ promising more than they can deliver/ totally screwing up a project, fer sure.

the "first" FAA project was FSD ... J.F., A.F., some of the others. At least some of the later "modernization" had a design that all failure modes could be masked by low-level hardware (& software) redundancy and recovery. Turns out that FAA had some number of failure modes that occur at the domain/application level. Telling a bunch of people that they don't have to design/implement in the application for failure/recovery ... because all such things will be automagically handled for them ... led to some number of problems.

By that time, FSD also had a very high precentage of contract & gov. business management people ... also large number of people very experienced in GML word-smithing for writing contracts, RFI/RFP answers, etc. There was no problem that couldn't be solved by applying the appropriate amount of business and management control.

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

downsizing (euphemisms)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: downsizing (euphemisms)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 26 Aug 2003 05:27:25 GMT

john_w_gilmore@MSN.COM (john gilmore) writes:
To ensure that IBM had't jacked up the acronym and put a new interpretation under it, as it sometimes does, I checked a very recent DB2 manual; and, yes, the 'S' in SQL does still mean 'structured'. As such it also means nothing. It is now empty of anything but notionally positive feeling tone, as 'unstructured' and 'anarchic' are empty of anything but negative feeling tone.

past references to sequel, sql, quel, qbe
https://www.garlic.com/~lynn/2002e.html#44 SQL wildcard origins?
https://www.garlic.com/~lynn/2002o.html#70 Pismronunciation
https://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?

--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
Internet trivia, 20th anniv: https://www.garlic.com/~lynn/rfcietff.htm

how long does (or did) it take to boot a timesharing system?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Aug 2003 19:23:47 GMT

sarr@timepilot.gpcc.itd.umich.edu (Sarr J. Blumson) writes:
Let me do a terminology check here. A former boss insisted that the system we were building had to boot in 30 seconds, because "that's what VM did." But the VM system we used for support actually took 20-30 minutes to get the supporting virtual machines started to where it could do useful work. I have to idea whether this was typical or because of local issues.

in old vanilla time-sharing .... it was time to a any user could log on; numerous types of service offerings could require require that they come up and initialize which might take arbritrary long period of time. normal cms had core-image saved just prior to writing the cms ready message. normal user login then invoked the "by name" saved image of cms and it was essentially almost instantaneous after the user logged on.

if there was a virtual guest operating system that needed to come up after VM was up ... most of the virtual guest operating systems could take tens of minutes, including possibly some amount of human interaction.

besdies that ... other types of "supporting" virtual machines (non-traditional guest operating systems) ... had lots of instances of applications ... where the application writers frequently did not pay as much attention to startup timeliness (as the work that went into original cp and cms)

some customers did experiment with saving core-images of os/360 MVT, essentially after nearly all its startup initialization had been performed ... so that it was accessible "by name" under cp with pretty timely startup.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

how long does (or did) it take to boot a timesharing system?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: how long does (or did) it take to boot a timesharing system?
Newsgroups: alt.folklore.computers
Date: Tue, 26 Aug 2003 20:04:25 GMT

Tom Van Vleck writes:
One reason that CP-67 could boot so quickly in the early days, 1969 or so, when I used it at MIT, was that it didn't salvage the file system(s). CMS users each had a simulated physical disk (P-disk) as part of their virtual machines. The CMS file system ran inside the VM and read and wrote files using a fairly conservative policy, such that interrupting execution rarely destroyed the whole file system. Users were responsible for backing up their own P-disks. After a crash, CP ran a salvager called the Buzzard that punched accounting cards for interrupted sessions, and then just restarted. People had to log in again and re-IPL CMS, and see if their files were OK. Usually they were.

Occasionally, a user would come to me in a panic, because something went wrong and all their files were lost. One way to cause this was to scramble low memory in the VM: in those days CMS and the user application ran in the same virtual memory space and an array bounds error could cause user data to overwrite the CMS system's tables including I/O buffers, and still let them be written to the P-disk. These users were astounded and furious that there was nothing I could do to retrieve their files.

CMS used shadowing for all its metadata updates for each filesystem. It would maintain the metadata for each filesystem in virtual memory and then on commit, write the (changed) metadata to new disk locations and then update the MFD record to indicate the new metadata position. If there was a failure before the MFD was updated .... a restart would see the previous/old metadata. If there was a bug ... that scrambled the metadata, but didn't abort CMS ... CMS would write the scrambled metadata to disk and update the MFD for that filesystem (note this was an individual's filesystem not other users' filesystems). Most CMS "system" filesystems were only accessible by normal users as read-only ... so they weren't able to affect other than their private filesystem(s).

There was a failure mode in IBM mainframe hardware where it was possible to have an unrecoverable write error at the same time as the power failure (lost the whole machine) ... which, if it occurred at the same time as the MFD record was being written ... that filesystem could be scrambled because the MFD was scrambled. One of the features in the "enhanced" (EDF) filesystem was that there were two alternating copies of the MFD. After writing all the filesystem's metadata (to new location), it would write a new MFD record with an updated version number to the alternate location (i.e. which made the alternate, the current active location). On restart, CMS would read both MFDs records, and take the valid one with the most recent version number.

Early CP/67 only came with DDR which was used by some shops to do periodic full-pack, disk image backups ... possibly only on a weekly basis.

In the '70s, I did a incremental file backup that was used at several internal locations and went thru a number of versions before it was made available as a product as Workstation Data Save (WDSF, when became ADSM and now TSM). misc. backup posts
https://www.garlic.com/~lynn/submain.html#backup

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

ARP cache for multicast & broadcast packets?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: ARP cache for multicast & broadcast packets?
Newsgroups: comp.protocols.tcp-ip
Date: Wed, 27 Aug 2003 14:00:55 GMT

Fernando Gont writes:
Go to http://www.rfc-editor.org, and search for the ARP specification. It might be updated by the Host Requirements RFC, so have a look at it, too.

and from
https://www.garlic.com/~lynn/rfcietff.htm
click on Term (term->RFC#) in RFCs listed by and then click on "ARP"
address resolution protocol (ARP )
see also address resolution
2835 2834 2625 2390 2320 2225 1868 1735 1577 1433 1390 1374 1293 1051 1027 903 826

clicking on the RFC number in the above brings up the summary in the lower frame:
826 S
Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware, Plummer D., 1982/11/01 (10pp) (.txt=21556) (STD-37) (ARP)

clicking on the ".txt" field retrieves the actual RFC.

also see ARP references in:
1122 S
Requirements for Internet hosts - communication layers, Braden R., 1989/10/01 (116pp) (.txt=289148) (STD-3) (Ref'ed By 2988)

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Secure OS Thoughts

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt
Date: Sat, 30 Aug 2003 01:00:38 GMT

mbealby@myrealbox.com (Martin Bealby) writes:
Objective:

To create a secure operating system suitable for use in highly security concious environments, with minimal risk of unauthorised access. Security is paramount, above all the system should be secure, even if this means a sacrafice in speed. [To quote Schneier: "We already have enough fast, insecure systems. We don't need another one."]

some related:
https://www.garlic.com/~lynn/2003j.html#4 A Dark Day
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

slightly related:
https://www.garlic.com/~lynn/2001i.html#55 Computer security: The Future
https://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia
https://www.garlic.com/~lynn/2001m.html#15 departmental servers
https://www.garlic.com/~lynn/2002p.html#6 unix permissions
https://www.garlic.com/~lynn/2003i.html#59 grey-haired assembler programmers (Ritchie's C)

EROS: The Extremely Reliable Operating System
http://www.eros-os.org/

and semi-related from eros discussion ...
http://eros.cs.jhu.edu/~shap/NT-EAL4.html

gnosis was the predecessor to keykos, and eros page lists keykos as the predecessor to eros; misc gnosis/keykos references:
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
https://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001n.html#10 TSS/360
https://www.garlic.com/~lynn/2002f.html#59 Blade architectures
https://www.garlic.com/~lynn/2002g.html#0 Blade architectures
https://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
https://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#75 30th b'day
https://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
https://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Secure OS Thoughts

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt
Date: Sat, 30 Aug 2003 03:52:51 GMT

dsr writes:
You could use google to search for terms such as "red black" emission security etc. pretty much SOP for sensitive installations.

merged security glossary at:
https://www.garlic.com/~lynn/secure.htm

sources listed at
https://www.garlic.com/~lynn/index.html#glosnote

from above:
Security: Terms merged from: AFSEC, AJP, CC1, CC2, CC21 (CC site), CIAO, FCv1, FIPS140, IATF V3 (IATF site), IEEE610, ITSEC, Intel, JTC1/SC27 (sc27 site), KeyAll, MSC, NIST 800-37, NCSC/TG004, NIAP, NSA Intrusion, NSTISSC/CNSS, online security study, RFC1983, RFC2504, RFC2647, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20021108 with terms from CIAO. Updated 20021205 with terms from 800-37 glossary.

some random information assurance references
http://www.sharp-ideas.net/ia/information_assurance.htm
http://www.thei3p.org/
http://www.thei3p.org/documents/analyses/Context_and_Pervasive_Issues_V1.0s.pdf
http://www.commoncriteria.org/
http://csrc.nist.gov/sec-cert/
http://www.nstissc.gov/html/library.html
http://www2.ni.din.de/sixcms/list.php?page=nani_redirect&alias=sc27
http://www.iatf.net/
http://www.ciao.gov/
http://niap.nist.gov/
http://csrc.nist.gov/publications/drafts.html
http://csrc.ncsl.nist.gov/publications/nistpubs/800-7/node276.html
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Secure OS Thoughts

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 31 Aug 2003 15:12:07 GMT

"Douglas A. Gwyn" writes:
Your list was well-intentioned, but neither necessary nor sufficient to obtain a high level of security, and it would all be subverted anyway in practice. What is truly needed is a nonsubvertible underlying mechanism. Capas (all the way down to instruction level) perhaps. The IBM System/38 was an interesting experiment that got some of the basics right, but it had no effect on the design of current sstems.

the folklore is that s/38 was born out of the canceled FS (future system) project ... multiple past post on FS:
https://www.garlic.com/~lynn/submain.html#futuresys

the follow-on to s/38 was the as/400 ... built on a cisc architecture. as/400 was moved to power/pc platform in the early 90s ... and still sells quite a number of power/pc boxes (along with apple, aix, and linux). misc. search engine results on os/400
http://www.as400guy.com/
http://www.common.org/
http://search400.techtarget.com/home/0,289692,sid3,00.html
http://search400.techtarget.com/featuredTopic/0,290042,sid3_gci921689,00.html
http://www-912.ibm.com/
http://www-132.ibm.com/content/home/store_IBMPublicUSA/en_US/eServer/iSeries/

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Secure OS Thoughts

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Sun, 31 Aug 2003 16:56:08 GMT

Anne & Lynn Wheeler writes:
gnosis was the predecessor to keykos, and eros page lists keykos as the predecessor to eros; misc gnosis/keykos references:

and two specific gnosis/keykos sites:
http://cap-lore.com/CapTheory/upenn/
http://www.agorics.com/Library/keykosindex.html
some number of other papers at the same web site:
http://www.agorics.com/library.html

in the late '60s there was some fundamental requirement for security at the major commercial time-sharing service bureaus. They had commercial customers ... and there were issues like protecting clients sensitive corporate information from other each other (as well as protecting the service from the clients).

in the late '60s there were two time-sharing service bureaus running CP/67 (IDC and NCSS) and by the early '70s ... they and Tymshare were offering virtual machine based commercial time-sharing service running on IBM 370 mainframe computers (based on IBM's standard virtual machine operating system product).

Gnosis/keykos referenced in previous post:
https://www.garlic.com/~lynn/2003l.html#19 Seucre OS Thoughts

Tymshare originated the Gnosis operating system effort in the '70s for IBM 370 mainframe to meet generalized commercial time-sharing service bureau requirements.

some of the earlier papers on security (copied from the above referenced agoric web page):
GNOSIS - A Prototype Operating System for the 1990's Provides a general introduction to some of the ideas in KeyKOS. This paper was presented at an IBM SHARE conference 52 in Chicago in 1979.

Note on the Confinement Problem (1973) An early statement by Bulter Lampson of security problems as yet unsolved by modern Operating Systems. Confinement is one of the features of KeyKOS.

The Confused Deputy (1988) A paper that explains the limitations of access control systems in many modern systems and explores how capabilities solve these problems.

Security in a Secure Capability-Based System (1989) This Operating Systems Review note corrects some misunderstandings about security requirements and capability-based systems.

A Note on "Protection Imperfect (1988) This Operating Systems Review note corrects a common misunderstaning about security requirements.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Why more than 1 hole in FW for IPSec

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why more than 1 hole in FW for IPSec
Newsgroups: comp.dcom.vpn,comp.os.linux.networking,comp.os.linux.security
Date: Sun, 31 Aug 2003 19:10:38 GMT

stephen@dino.dnsalias.com (Stephen J. Bevan) writes:
BTW it is not that I think IKE+IPsec is perfect by any means, it is just that it isn't clear to me that any of the alternative are better.

ipsec had been in progress for some time and not making much headway. vpn/firewall was introduced in router/gateway working group the fall 94 ietf meeting (san jose?). it caused somewhat of a problem with the ipsec group .... as well as some router vendors that didn't have processors with sufficient processing power to do the crypto operations. There were some number of VPN vaporware products announced following that meeting. Eventually most vendors introduced sufficiently powerful processors to perform various firewall and vpn crypto operations ... and some progress got made. The ipsec group also somewhat accommodated VPN by referring to it as "lightweight" ipsec (while the original, end-to-end ipsec got to be called heavyweight ipsec).

the ssl introduction by netscape ... basically an "end-to-end" (heavyweight ipsec) transport layer service ... was done in the application layer (browser and server) since real heavyweight ipsec was taking so very long.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA vs AES

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Sun, 31 Aug 2003 20:57:16 GMT

George Ou writes:
As for this quote. "2. Common Root certificate shared across millions of keys. The obvious think here is that the certificate, once broken, can be used to fabricate the identity of any one of the millions of people under the Common Root."

He's got that half right. Root CAs are not shared across keys. They are pre-distributed in everyone's CTLs (Certificate Trust Lists). If you manage to break the private key of the root CA, you can indeed forge identities of anyone, but once it is discovered that forged identities are being used the Root CA will immediately be revoked out of the CTL. You would be assuming it would be very easy to "break" a

that is assuming that you are dealing with a public key infrastructure ... where all possible relying parties have a mechanism for recognising revokation. Lets say that there are 100 million copies of browsers out there ... that have root CA keys installed. How often do those browsers check for revoked root CA keys? Every instance of a browser with installed root CA keys are relying parties for which there has been a trust relationship created between the relying party (the browswers) and the CA operations that have their root CA keys installed.

another scenario raised in similar threads is somebody buys one of the root CA operations (that have root CA keys installed in common browsers).

the scenario from ten years ago would be that possibly once a day there would be a CRL (certificate revokation list) distributed to each of the (100 million?) relying parties (browsers). Each relying party (100 million browsers in the world) would perform their daily update of the list of revoked certificates (either root CA keys and/or just straight identity specific keys). For high risk items, maybe there would be an updated CRL sent out every hour to all 100 million possible relying parties.

misc. past discussions of SSL certificate-based infrastructure:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IBM Manuals from the 1940's and 1950's

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sun, 31 Aug 2003 22:17:43 GMT

"John W. Kennedy" writes:
Doesn't anyone remember the spec sheet for the System/360 Model 69 anymore?

I don't know about 360/69 ... but the original module numbers were 360/30, 360/40, 360/50, 360/60, 360/62 (360/60 with virtual memory address relocation hardeware), 360/70.

The 360/60, 360/62, and 360/70 were to have 1mic memory. Somewhere along the line, 750ns memory came about and the 60, 62, and 70 were replaced/upgraded to 360/65, 360/67, and 360/75.

Somewhere, I still have a "blue card" for the 360/67. misc. past posts ref. 360/67 blue card
https://www.garlic.com/~lynn/99.html#11 Old Computers
https://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001.html#69 what is interrupt mask register?
https://www.garlic.com/~lynn/2001.html#71 what is interrupt mask register?
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)
https://www.garlic.com/~lynn/2001d.html#42 IBM was/is: Imitation...
https://www.garlic.com/~lynn/2002f.html#54 WATFOR's Silver Anniversary

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Secure OS Thoughts

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers,alt.os.multics
Date: Sun, 31 Aug 2003 22:39:06 GMT

Tom Van Vleck writes:
What I can't determine from the KeyKOS sites is how many sites actually ran KeyKOS in production. When I interviewed there in the 80s, I think they said there were some..

the following taken from:
http://www.agorics.com/Library/keykosindex.html
This documentation describes the design and implementation of the KeyKOS system. Initially developed at Tymshare, Inc., it was deployed in production in 1981 as a secure server processing credit card transactions while simultaneously supporting other applications. Agorics has licensed this system and the associated patents, and utilizes the fundamental ideas and technology in our ebusiness solutions.

production use for credit card transactions in 1981 .... it isn't clear whether than would have been on a "bare" 370 .... or running under VM in a virtual machine.

In 1985, M/D bought Tymshare and spun off a number of things ... Tymnet went to B/T(?). I was brought in to perform due diligence on gnosis before it was spun off to key Logic (and became KeyKOS). I still have some gnosis hardcopy.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA vs AES

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Sun, 31 Aug 2003 23:34:50 GMT

George Ou writes:
In the case of a simple stolen MS code signing certificate from Verisign, MS took the extra burden of issuing a critical patch to revoke that stolen cert. What do you think would happen if one of Verisign's root CA private key's were somehow miraculously compromised? Don't you think it would be all over the news? Would you be so foolish to think the security or PKI industry would simply rely on people checking the CRLs? No way! It would be all over the news and just about every security site would be telling you to revoke those stolen root CAs. MS would issue a patch for all windows OSes. It would be the biggest news item for weeks to come! Verisign would loose all credibility and the PR disaster could kill Verisign. It would be 1000 times more damaging than that stolen MS code signing cert!

the small caveate is that browsers have easily some fifty pre-loaded root CA keys .... in some cases for companies that may no longer be in business. It isn't clear how long it would take for anyone to notice if any of these other keys ever got compromised ... or even if somebody questionable bought all the corporate assets at a fire sale.

in the existing ssl browser scenario there is no differentiation regarding trust levels for preloaded root CA keys.

some old threads about what root CA keys may actually be preloaded into browsers:
https://www.garlic.com/~lynn/aepay4.htm#comcert14 Merchant Comfort Certificates
https://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates

netscape 7.1 & mozilla 1.4 cerificate managers don't allow cut & past .... so the hard way (following organizations have one or more public keys preloaded, list of public keys for 7.1 & 1.4 are the same):


Keywitness Canada Inc
ABA ECOM, Inc
AOL, Time Warner Inc
AT&T
AddTrust AB
American Online, Inc
American Express Company, Inc
BBN Certificate Services
Baltimore
BetSign NV
Canada Post Corporation
CertSign Certicadora
CyberTrust Japan
Deutsche Telecom AG
Digital Signature Trust
E-Certify
Entrust.net
Equifax
Equifax Secure
Equifax Secure Inc
GTE CyberTrust
GeoTrust Inc
GlobalSign nv-sa
IBM World Registry
Integrion Financial Network
MCI
RSA Data Security
RSA Security
TC TrustCenter for Security In Data Networks
Thawte
Thawte Consulting
Thawte Consulting cc
The USERTRUST Network
USPS
Uptime Group
VISA
ValiCert
VeriSign Trust Network
VeriSign, Inc
Xcert EZ
beTRUSTed
gc

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA vs AES

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Sun, 31 Aug 2003 23:58:48 GMT

... also the M/S case was an key that should have not had been issued and therefor the process was to distribute an update to ignore the erroneous key (since there is no real PKI and/or CRL in operation).

while it would also be possible to do something similar if a real key was compromised .... the resulting problem is that all things that might have depended on the real key ... now stop working. An update would be required to both ignore the compromised key as well as load a new valid key. This would need to get out to the 100 million or so browsers. Then the ten million or so servers with SSL certificates ... might have to all get new certificates created and installed.

Public key operation does greatly simplify key distribution issues compared to secret/symmetric key paradigms. However, some of the claims made for PKIs in the '90s were still pretty wide of the mark.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Offshore IT

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Offshore IT
Newsgroups: alt.folklore.computers
Date: Mon, 01 Sep 2003 05:09:15 GMT

somewhat topic drift:
http://www.kansascity.com/mld/kansascity/business/6656322.htm?template=contentModules/printstory.jsp

Toyota poised to become top car seller in U.S.

random past threads ... somewhat related:
https://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
https://www.garlic.com/~lynn/2003i.html#61 TGV in the USA?
https://www.garlic.com/~lynn/2003i.html#65 TGV in the USA?

misc references to IT:
http://www.informationweek.com/story/IWK20020531S0008
http://www.informationweek.com/story/showArticle.jhtml?articleID=8700345
http://www.eweek.com/article2/0,3959,1133176,00.asp
http://www.forbes.com/best/2002/1007/002.html
http://www.informationweek.com/story/showArticle.jhtml?articleID=6502198

--
Anne & Lynn Wheeler - https://www.garlic.com/~lynn/

Secure OS Thoughts

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Mon, 01 Sep 2003 14:07:49 GMT

"Douglas A. Gwyn" writes:
I always thought that it was a realization of Myer's SWARD architecture.

tss/360 had effectively one level store and other things for the 360/67 (360/65 with virtual memory). it was a fairly large project (had some 1200 people or so working on it at the peak), announced and early versions delivered to customers. It never really took off and was canceled. cp/67 (from the cambridge scientific center with virtual machine support) and MTS (michigan terminal system) were also developed for 360/67 using virtual memory. some of the cambridge science center references:
https://www.garlic.com/~lynn/subtopic.html#545tech

there was some hope that the 360/67 would have "won" the multics bid ... but didn't. some amount of the early ctss, multics, cp/67 history (both multics and cambridge science center were located at 545 tech sq). lots of early details can also be found in Melinda's paper:
http://www.leeandmelindavarian.com/Melinda#VMHist

FS (future system) was an extremely aggresive project that possible peaked at 2500 people ... that was in part was in response to plug compatible controllers .... something that I've been blamed for help originating when I was an undergraduate
https://www.garlic.com/~lynn/submain.html#360pcm

some specific Future System excerpts/references:
https://www.garlic.com/~lynn/2000f.html#16 [OT] FS - IBM Future System
including discussion at:
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm
and some discussion from the System R reunion (see "FS" in index):
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Index.html
minor reference:
http://www.cs.clemson.edu/~mark/acs_people.html

Future System was canceled before even being announced.

The lore is that several of the people that worked on FS migrated out to rochester and did S/38.

some s/38 and as/400 history at:
http://www.400times.co.uk/FrameData/history_of_the_38.htm
from the above:
On the large mainframe front, IBM had just canceled a project known as FS (Future Systems) that was going be a revolutionary replacement for the existing line of IBM mainframe computers. After several years of work, meetings, and more task force meetings and many train loads of paper specifications later the IBM management team determined the project was too ambitious even for IBM and IBM abandoned the project in 1975. (Does any one know the date this is a guess.)?

In the heart of the cornfields in Rochester, Minnesota the S/3 and its follow on systems S/32 and S/34 were nearing the end of a very successful life. The time for a replacement system was nearing. There was no hardware clone of the S/34 but the fear of a clone vendor replacing existing hardware was high on IBM managements concerns. The news of FS demise was slow to reach Rochester so the group of planners, engineers and programmers continued on an independent approach to design the system for the future at least for the small and medium business customer. Every one wanted bigger, better, faster, and cheaper than the now aging S/34 but just how that would be accomplished was still an unknown.

Early in 1975, I joined the core group of less than 25 people who were developing the vision of the replacement for S/34. This small group of talented people with came from varied backgrounds. Some from the design teams of the S/3, S/32 and S/34 while others had large S/360 and S/370 backgrounds.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IBM Manuals from the 1940's and 1950's

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Mon, 01 Sep 2003 17:52:02 GMT

"John W. Kennedy" writes:
Unfortunately, I can't put my hands on my copy of the special anniversary edition of IBM JRD, but I rather thought the semiconductor key store was unique to the 95. The 370/145 was, of course, the firs IBM production system with semiconductor main RAM. (But it waited a long time. I saw, at Poughkeepsie, the unique 360/145 prototype.)

somewhere along the way, I dumped 20 years of system journal and JRD. however, the journal home page is
http://www.research.ibm.com/journal

preface to the anniversary edition:
http://domino.research.ibm.com/tchjr/journalindex.nsf/f29b56f24a66cd0d8525681e007222fb/575145590bc3956a85256bfa0067f4d4?OpenDocumen

Padegs "System 360 and Beyond" from the anniversary edition:
http://domino.research.ibm.com/tchjr/journalindex.nsf/f29b56f24a66cd0d8525681e007222fb/575145590bc3956a85256bfa0067f4d4?OpenDocumen
the actual PDF file:
http://www.research.ibm.com/journal/rd/255/ibmrd2505D.pdf

Table 1 in the above gives model characteristics


Table 2 Announcement and shipment dates.
Model            Announced     First shipped
System/360
22                71-4-7          71-6
25                68-1-3          68-10
30                64-4-7          65-6
40                64-4-7          65-4
44                65-8-16         66-9
50                64-4-7          65-8
60                64-4-7          not shipped*1
62                64-4-7          not shipped*
65                65-4-22         65-11
67                65-8-16         66-5
70                64-4-7          not shipped*2
75                65-4-22         66-1
85                68-1-30         69-12
91                64-11-17        67-10
92                64-8-17         not shipped*3
95                                68-2
195               69-8-20         71-3

System/370
115               73-3-13         74-3
115-2             75-11-10        76-4
125               72-10-4         73-4
125-2             75-11-10        76-2
135               71-3-8          72-4
135-3             76-6-30         77-2
138               76-6-30         76-1I
145               70-9-23         71-6
145-3             76-6-30         77-5
148               76-6-30         77-I
155               70-6-30         73-4
158               72-8-2          71-1
158-3             75-3-25         76-9
165               70-6-30         71-4
168               72-8-2          73-5
168-3             75-3-25         76-6
195               71-6-24         73-8

System/370-compatible
3031              77-10-6         78-3
3032              77-10-6         78-3
3033              77-3-25         78-3
3033-N            79-11-1         80-1
3033-S            80-11-12
3081              80-11-12
4331-1            79-1-30         79-3
4331-2            80-5-7          80-8
4341-1            79-1-30         79-I1
4341-2            80-9-15

1 Replaced by Model 65
2 Replaced by Model 75
3 designated as Model 91

there is also "Amdahl" 360 article in jan/march 2000 RJD
http://domino.research.ibm.com/tchjr/journalindex.nsf/f29b56f24a66cd0d8525681e007222fb/575145590bc3956a85256bfa0067f4d4?OpenDocumen

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA vs AES

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Mon, 01 Sep 2003 19:45:25 GMT

George Ou writes:
Like I said, It isn't a perfect system and it could definitely be improved. My point is, that points out a flawed PKI implementation with a poorly designed CRL system. My only point is that one shouldn't just cavalierly say that PKI/PKC is fundamentally weak.

my issues have been that while asymmetric keys are technologies .... which offer some interesting advantages compared to symmetric keys .... fundamentally public and private keys, identity certificates, PKIs, CRLs, etc are all business processes.

Certificates are a form of credentials ... analogous to the plastic credit cards (before magstripes) and online POS terminals, or letters of credit in the days of sailing ships; basically originally targeted at an offline email environment (aka dial-up the local mail office, exchange email, hangup, process email).

The issue was that the certificates/credentials are business processes that substitute for having direct access to the actual certification authority because of a fragmented, disconnected and/or offline environment aka CAs are "certification authorities" ... but don't actually tend to be the authoritative agency for the information being certified, the CA business tends to involve verifying with the authoritative agency for the information being verified ... and then generating a certificate representing that business verification process. The certificate are stale, static representation of some business process.

Many of the CA/PKI business weaknesses are recognized as stale, static representation of information because the target environment is presumed to be offline and the target infrastructure isn't able to support online, timely, dynamic operation.

Given that you know that you haven't the capability of doing real online, timely and dynamic operation .... then the compromise is a CA/PKI for a disconnected, offline environment against not having access to any information (aka a stale, static certificate being considered better alternative to nothing at all).

This is the scenario of the letters of credit from the sailing ship days ... when remote financial infrastructures (relying parties) had no online connectivity alternative to the authoritative agency (aka financial institution issuing the letter of credit). It is also the pre-1970s scenario of the plastic cards in wallets before online access to timely, dynamic information became available (in some sense the financial PKIs of the 1990s were an attempt to roll back the technology clock for financial institutions to pre-1970 and the age of strictly offline operation).

There are significant CA/PKI business process deficiencies of stale, static operation when compared to modern business process with timely, dynamic operation. However the CA/PKI business process has several advantages for orignal offline, disconnected design point with stale, static operation when compared to an alternative of nothing at all.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA vs AES

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Mon, 01 Sep 2003 22:27:10 GMT

George Ou writes:
I think your somewhat trivializing the concept of PKI and PKC by comparing it to the "letter's of credit" in old sailing days. If those "letter's of credit" had the unique property of being tamper resistant and forge proof short of someone stealing well protected private keys, then you could make that comparison. To make the comparison in light of that fact is utterly insane and disingenuous. It is disrespectful to the most significant discovery in cryptography in thousands of years.

as i said at the start of the previous post .... asymmetric cryptography is technology .... certificates are business processes. they are analogous to the offline, stale, static letters of credit business process (independent of the technology used to make them tamper resistent).

let's say i have a letter of credit that says that I've got one million dollars in the bank ... written a year ago and absolutely tamper resistant. It is now a year later .... from a business process standpoint ... the letter of credit could be perfectly valid ... and still be incorrect.

for anything of importance ... given equal opportunity for timely, dynamic, online reference and stale, static, offline reference ... whether it refers to how much money i have in an account, whether i have an account at all, whether I'm an employee; all other things being equal, which would a business operation prefer:

1) timely, dynamic, online 2) stale, static, offline

the issue wasn't with regard to how great the tamper resistant characteristics were (aka asymmetric cryptography technology) ... and/or how easily things could be counterfeited .... from a business process perspective, it was given equal choice between timely, dynamic, and online vis-a-vis stale, static, and offline .... which would a business process prefer?

My assertion has been that given equal choice between timely, dynamic, and online or stale, static, and offline .... a business operation would always choose timely, dynamic, and online for anything of value (but might choose stale, static, and offline for things of no value).

Another observation about x.509 identity certificates from the early '90s, it was quickly determined that overloaded an identity certificate with lots of privacy and identification information (in part because it wasn't clear what future relying parties might require) represented significant privacy and liability exposures .... especially with the assumption that such certificates would be indiscriminately spread all over the world. As a result, you somewhat saw financial institutions in the mid-90s retrenching to relying-party-only certificates containing only an account number and the public key. However, it was trivial to show for relying-party-only certificates that they were redundant and superfluous in financial settings.
https://www.garlic.com/~lynn/subpubkey.html#rpo

Don't confuse my characterization of CAs and PKIs as a business process producing stale, static information for offline environments with anything about the strengths and advantages of using asymmetric cryptography. I don't believe the criticism of business processeses relying on stale, static information designed for offline paradigms (when they have alternatives for dynamic, timely information in an ubiquitous online environment) in any reflects on the technology used to make the stale, static information resistant to tampering.

I strongly believe that asymmetric cryptography can be applied to ubiquitous online environments without having to resort to business processes (CAs, PKIs, and certificates) that have a design point targeted at antiquated, offline, disconnected operations.

For instance, in the financial standards X9A10 working group, the requirement was for a standard that preserved the integrity of the financial infrastructure for all electronic retail payments (ALL as in credit, debit, stored-value, ACH, etc, ... and ALL as in internet, point-of-sale, face-to-face, automated, non-face-to-face, aka ALL). The resulting standard, X9.59 demonstrates that asymmetric cryptography (in the form of digital signatures) can provide very high integraty level, operating in a dynamic, timely online environment without resorting to any form of PKI and/or CA business paradigm (certificate-less):
https://www.garlic.com/~lynn/x959.html#x959

slightly related threads:
https://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
https://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to
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?
https://www.garlic.com/~lynn/aepay11.htm#71 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#1 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#2 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#3 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aepay12.htm#4 Confusing business process, payment, authentication and identification
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 02 Sep 2003 18:41:57 GMT

rachess@aol.com (Rachel) writes:
I am doing some research on utility computing and have been coming across conflicting information from parties I have talked to and material I have read.

Some sources say utility computing is nothing more than HP & IBM's way of creating a fad/trend/need that doesn't necessarily exist, basically because their companies are, relatively speaking, in trouble. Wall St. Journal reported that SSP (storage providers) are collapsing which has ramifications on utility adoption. They also cited that large organizations like Ford are going to create an "internal" utility model whereby their IT organization will provide the utility situation as opposed to outsourcing the utility model to a third-party like IBM. Others say, not only is this the future, but outsourcing to IBM, HP, is the means since this is core competency for them.

Been seeing activity like tradeshows on utility computing coming up and more articles as well.

So, I ask the field professionals - what is the deal here? Have you heard anything within your own organizations about adopting the utility computing model? Or is this a marketing effort by HP, IBM, etc. to get more $$$ (fad or reality)? And, if so, will it be an internal model or an outsourced model? What organizations are likely to buy into it?

Thanks for your thoughts or observations (in reality)!

is this "utility" as in "on demand" ... or is it "utility" as a "service" ... and whether or not it is "on demand" or "service" ... does it also imply "out-sourced"?

From a "service" standpoint ... computing service bureaus have been around for some time (for instance ibm selling off "service bureau corporation" to CDC in the early '70s as part of federal gov. settlement).

Another example is in 1969, Boeing formed BCS and (after some resistance) moved most of the computing centers and IT organizations into BCS. The idea was that BCS would be a "utility" and provide service to both internal organizations as well as be free to offer services externally. One of the first processors that went into BCS was a 360/67 running CP/67. This also sort of put BCS into the category of CP/67 time-sharing service bureau business along with IDC and NCSS that were also formed to provide commercial CP/67 based time-sharing services in 68/69.
https://www.garlic.com/~lynn/submain.html#timeshare

The university that I was at in the late '60s did something similar with its computing center ... although it had to go to the state legislature to get the necessary legistlative approval.

Part of the issue prior to the separation of computing service and the rest of the organization ... was that it was hard to value the computing service. Separating the organizations and creating explicit charges and book accounting for use and deliverables allowed the organizations to create value determination for the computing service (even if the internal corporate accounting was all done with funny money).

Some amount of the out-sourcing and on-demand, theoretically allows corporations to move to pay-as-you-go model; they may pay more in aggregate than compared with an in-house operation ... however there seem to be some amount of business moving to an immediate cash flow operation, not being able to bet on what their business and/or data processing technology will look like in even 18-36 months (eliminating capital expeditures that may have 2-5 year write-off periods).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

RSA vs AES

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA vs AES
Newsgroups: sci.crypt
Date: Tue, 02 Sep 2003 21:31:56 GMT

waldyrbenits@ip2.com.br (Waldyr) writes:
Now you perfectly solved my problem, because simply we cannot compare them.

Thank you very much and sorry for the problem I' ve caused on the web.

there is one reason for comparing them.

Say you have a SSL type system where a symmetric key is used to protect data, and an asymmetric key is used to protect the symmetric key.

If there is a requirement for a certain strength symmetric infrastructure to protect the data (algorithm, keysize, etc) ... then you also need to know that the asymmetric crypto protection is at least as strong as the symmetric crypto protection ... or the data could be vulnerable to attacks on the asymmetric operations ... even if it wasn't vulnerable to attacks on the symmetric operations.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Wed, 03 Sep 2003 01:09:40 GMT

"George Ou" writes:
DNS system where you would have a ".com" root CA that would assign your domain level root CA signing privileges for your domain only? Then the world would have no problem trusting your domain level PKI servers for just your domain. That trust is impossible under our current PKI system because they would have to trust your PKI servers to sign for everything under the sun. I believe that this lack of granularity grants an absurd monopoly to companies like Verisign, in addition to many other problems that make public PKI deployment pathetic. If a PKI system (like DNS) that delegates signing authority to the individual domains could be standardized, it would instantly allow PKI to realize it's original aspirations of vast global deployment to empower PKC everywhere! Just think, you will never need to purchase more than one certificate from Verisign for your entire domain once every 5 years!

I don't know if this concept is new and I can only hope it is, but I wrote the following original work which I hope you will enjoy reading.

we were working on this thing with this small client/server startup that wanted to do payment transactions:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

and as part of that had to perform due diligence on all these things that were supposedly PKI Certification Authorities. As part of that we coined the term certificate manufacturing to distinguish from actual PKIs.

it turns out that one of the reasons for the SSL server domain name certificates was because of perceived issues in the domain name infrastructure. However, it turns out that the authoritative agency for domain names is the domain name infrastructure and all the CAs issuing SSL server domain name certificates have to go to the authoritative agency for domain names in order to validate the information for placing in SSL server domain name certificates (the very same domain name infrastructure that integrity concerns about gave rise to the need for SSL server domain name certificates)

Now, it so happens that the SSL server domain name certificate industry is in something of a quandary ... they are dependent on the domain name infrastructure which has integrity issues that gave rise to the need for SSL domain name certificates.

So there have been some number of proposals to strengthen the integrity of the domain name instructure ... somewhat prompted by the SSL server domain name certificate industry ... so that they can rely on the integrity of the domain name infrastructure for their purposes. This creates something of a catch-22 for the SSL server domain name certificate industry since improving the integrity of the domain name infrastructure reduces the need for SSL server domain name certificates (compensating for integrity issues in the domain name infrastructure).

The other issue is that somewhat from the SSL server domain name certificate industry, one of the proposals for improving the integrity of the domain name infrastructure is that public keys be registered at the same time as domain names are registered. This also represents a catch-22 for the SSL server domain name certificate industry. If you have a trusted, timely, dynamic, online information distribution infrastructure and it also had public keys that were available for distribution, it would go a long ways towards eliminating all of the requirement for SSL server domain name certificates.

Rather than having stale, static, SSL server domain name certificates for being able to validate a server's public key .... the public key is distributed from the same trusted infrastructure that distributes the domain name to ip-address information (aka the existing domain name service implementations are actually able to distribute timely, dynamic, online information not restricted to ip-addresses).

So the SSL server domain name certificate industry is in a real catch-22, (effectively sowing the seeds for their own demise) they are

1) proposing that the integrity of the domain name infrastructure be fixed (so that they can trust it), but that means that everybody could trust it also, eliminating much of the requirement for SSL domain name certificates

2) part of the their proposal for improving the integrity of the domain name infrastructure involves registering public keys when domain names are registered. However, this sets up an infrastructure for timely, dynamic, online trusted information distribution of the public keys (in addition to the trusted distribution of the ip-address), eliminating the need for stale, static certificate-based distribution of public keys.

This also opens up the ancillary option of improving the SSL protocol, the domain name infrastructure can have the public key and the preferred crypto optionss registered. At the same time the client made a domain name infrastructure request for an ip-address, the system could optionally return the associated public key and preferred crypto options piggybacked in the same transfer. If the client is in agreement, then it could bypass all the certificate protocol chatter and just send the initial session key, encrypted with the server's public key as part of initial contacting the server. Assuming something like an XTP, 3 packet transaction protocol .... the actual encrypted session data could ride in the same packet. Assuming everything is perfectly valid on the server end ... the encrypted response and session tear-down could come back in the response.

Basically, for on online world, you eliminate the stale, static, offline PKI paradigm, and move to a modern, timely, dynamic, online (certificate-less)infrastructure.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Sep 2003 04:33:28 GMT

Robert Myers writes:
I'm not entirely certain I know what utility computing is supposed to do that, say, Boeing Computer Services didn't do, and using BCS did not mean outsourcing. It meant that most of your hardware and some of your software were not on site and that you bought the use of hardware and some software as you needed it. It was clumsy because data transmission was slow, and it was expensive because data storage costs were ridiculous.

The data storage problem may still be the killer. Data transmission is much better than it was in the days of BCS, but it's not so much better that you can afford to be shipping lots of data back and forth, and paying someone else for routine storage of your data is horrifyingly expensive--and a little scary.

But who knows what utility computing really means. If it means having a computer onsite with processors that you pay for only when you switch them on, then the data storage and transmission problems go away, but at that point the whole concept feels a little desperate, more like a marketing and pricing gimmick than anything else.

the on demand scenario may just mean a little more like the old days of leasing ... but with less up front commitment or like the tv adds for some of the long distance and mobile phone services ... you only pay for what you use when you use it ... and no upfront contract and/or commitment.

one of the processor economics seems to be extremely high upfront costs for development ... but with volume manufacturing ... relatively small incremental manufacturing costs per processor. Throwing in double the processors per box ... and the customer only turns extras on for peak processing ... may represent an attractive economic prospect.

The customer may find that they can gracefully grow into the extra capacity w/o huge incremental cost justifications for capital equipment. In some cases processor decisions were so significant that they only got made as part of yearly budget cycle. There can also be some chicken and egg ... can't justify the extra for large capital equipment w/o finer granularity of growth (and can't demonstrate growth w/o additional capacity). The customer tries out the extra capacity on a piece meal basis ... and then more gracely grows into the extra capacity. This is not so much a marketing/pricing gimmick .... but a much finer capacity growth management gimmick for the customer ... aka more of a case of "try it, you may like it"

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Sep 2003 13:11:56 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
A more realistic scenario is that the extra capacity is used to provide ample warm spares, thus reducing maintenance costs, and the extra power for peak loading is a bonus. Given the way that IBM and other vendors have cut back on their field support staff, I would place good money on this being the real reason.

it also doesn't require service people to come in and install the extra capacity.

note however, some of the presentations at SHARE in the '70s on vm/370 was that vm/370 customers had a lot larger computer demand growth (compared to mvs) ... customers that installed 370/135 initially, grew faster to multiple 168s. One of the case studies at SHARE was amoco research in tulsa ... they had an 1800 and installed a 370/135 with vm ... and relatively quickly grew to multiple 168s. One of the SHARE study issues was trying to determine what factors allowed/accounted for large increase in computing demand.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Port Assignment- OT in a Small Way

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Port Assignment- OT in a Small Way
Newsgroups: alt.computer.security,alt.hackers.malicious,comp.security.firewalls,comp.security.misc,microsoft.public.security,alt.2600.hackers
Date: Wed, 03 Sep 2003 13:56:07 GMT

Tracker <"snailmail(remove/valid)222000"@yahoo.com> writes:
Copyright 2003 by Debbie X. All rights Reserved. No part of this publication may be reproduced in any form or by any means, or stored in a data base or retrieval system, without prior written permission of the publisher.

I do a simple cross reference when the STD1 portocol name matches the port number name ... see
https://www.garlic.com/~lynn/rfcietff.htm
"Protocol" in the RFC's listed by section

The official list use to be "Assigned Numbers", RFC 1700

but as of RFC 3232, "Assigned Numbers: RFC 1700 is Replaced by on On-line Database", they are now just listed in an online file that gets updated.

The distinction is that RFCs are static documents, that once published are never changed. To change the contents of an RFC required releasing a new RFC.

See "Internet Assigned Numbers Authority" at:
http://www.iana.org/

and:
http://www.iana.org/numbers.html

The "Port Numbers" section under:
http://www.iana.org/numbers.html#P

specifically
http://www.iana.org/assignments/port-numbers

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

The real history of computer architecture: the short form

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The real history of computer architecture: the short form
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 03 Sep 2003 14:09:57 GMT

Robert Myers writes:
I wonder if IBM and HP ever developed a corporate strategy for computer games? I'll bet even Intel doesn't have a forward group looking at how Itanium will fit into the world computer games. Or do they?

I was able to obtain a copy of adventure source and distribute it internally within a couple months after it became available at stanford (even tho stanford was only 25 miles away, I got it via a round about network connection thru the UK).

Adventure reached crisis level at some labs ... with large number of people spending all their time playing it. It grew to one point at STL, the claim was that 30 percent of computer activity was taken up with adventure. STL lab director issued a moratorium that people were given 24 hour grace period and then adventure could no longer be played first shift.

There was some investigation into mandating that all games had to be removed from all computers. A couple of us successfully argued that a public game repository should be maintained to avoid the normal human reaction of lots of people keeping their own private copies (employing various cloaking techniques to get around the auditors searching for games).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Secure OS Thoughts

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Secure OS Thoughts
Newsgroups: sci.crypt,alt.folklore.computers
Date: Wed, 03 Sep 2003 21:49:07 GMT

westinnospam@graphics.cornell.edu (Stephen H. Westin) writes:
What I heard at Michigan was that after the Multics bid was lost, IBM became much more eager to cooperate with a university on a virtual-memory system, so Michigan got a lot of say in the 67 specification. They originally planned to run TSS/360 on it, but as that kept being delated, MTS was cobbled together as a stopgap that developed into a solid system that lasted 30 years.

in effect, cp/67 at the (ibm) cambridge science center was similar undertaking .... which evolved into vm/370 on the 370 (morphing into LPARS available on all mainframes, as well as the current z/VM). a lot of the ctss, multics, cp/67, etc. era details ... are described in some detail in melinda's (vm past, present and future) paper at:
http://www.leeandmelindavarian.com/Melinda#VMHist

also on the web site is Gribbin's "Development of 360/370 Architecture - A Plain Man's View"

some past threads that include some Mich. and/or MTS references:
https://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
https://www.garlic.com/~lynn/2000.html#89 Ux's good points.
https://www.garlic.com/~lynn/2000g.html#2 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2002l.html#22 Computer Architectures
https://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill

Along the way, the university MTS installations turned out to be prime marketing target for Amdahl.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 04 Sep 2003 02:41:56 GMT

cruff@ruffspot.net (Craig Ruff) writes:
At work (NCAR), I'm still struggling to get decent data rates for large scale cross country data transfer. Back in mid 1996, even with the VBNS and Hippi connected SGI systems, we could only manage to average 1.5 MBytes/sec between Boulder and Pittsburgh.

Today, with Abilene connections between Boulder and Purdue, we can get 10-12 MBytes/sec during some periods on the network, but it may easily be assymetric. However, once you get various TCP/IP stacks and file systems involved, we really haven't improved since 1996.

The stock TCP/IP stacks are not configured for medium to high latency, and there is still no good API to pass tuning information from a specialized application. The vendor supplied TCP/IP stacks do no automatic tuning (despite several research projects looking into it) on their own.

Thus, with these restrictions, the wide scale separation of data storage and computing is difficult to achieve. I still wonder about all the money being sunk into these grid computing initiatives, when much work still needs to be done on getting the average operating system and network stack to "do the right thing" in a wide variety of configurations. Most users can't be bothered to do any tuning, what so ever.

the supercomputer shows have been having bake-offs ... i think supercomputer 2001 in denver saw one contestent getting 500mbits per second sustained between the ??? and (tokyo or cern?) ...

i have a
http://sc2001.slac.stanford.edu/beamtree/
cube from the slac/fermi booth sitting on the top of my monitor.

One of the typical tcp issues had been windowing algorithms (like slow-start) for rate control. The problem is window control is somewhat orthogonal to rate control. My impression was that numerous tcp implementations had been done on platforms with poor timer facilities ... and therefor the possible fallback to windowing paradigm rather than direct rate control paradigm (needing minimally acceptable timer facilities).

a couple recent threads:
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2003j.html#46 Fast TCP

caltech-slac 2002 entry
http://www.sc2002.org
925Mbps single flow avg over 1hr 21TB in 6 hrs with 10 flows (8.6Gbps, 88 percent utilization)

this years
http://www.sc-conference.org/sc2003/
and
http://www.sc-conference.org/sc2003/newsletters/news4.html with note on the fourth annual high-performance bandwidth challenge

from above:
Last year, Lawrence Berkeley National Laboratory captured the competition for the "Highest Performing Application" with a wide area distributed simulation using Cactus, Globus, and Visapult software. The simulation reached a peak data transfer rate of 16.8 Gb/s nearly 25,000 times faster than a typical home broadband connection.

...
The judging criteria for 2003 have been expanded to include:

• Maximum top sustained TCP utilization
• Best entry for IPv6 (minimum of two entries needed)
• Best features of non-stock TCP implementations (i.e. Web 100)
• Applicability to the real world
• Most improved entry (compared to a previous entry)
• Best multi-continental entry
• Best first-time demonstration

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 03:42:10 GMT

Tom St Denis writes:
In reality PKI should be done with a web-of-trust model through auditors. That is say I trust Paul Rubin's public key. Say Paul has shopped at "booksrus.com". Paul likes the business so he signs their public key [like a vote of confidence]. Now I trust Paul to make a sound judgement so I too trust booksrus.com to not screw me.

two basic reasons for the SSL server domain name certificate:

1) is the server i'm talking to really the server I think it is? (because of perceived trust issues with the domain name infrastructure)

2) trusted public key distribution for that server

since the authoritative agency for domain names is the domain name infrastructure, even the CA/PKIs that issue SSL domain name certificates have to check with the domain name infrastructure to see if somebody requesting a domain name certificate is associated with that domain name.

because of the original perceived trust issues with the domain name infrastructure, there are a number of proposal to improve the trust of the domain name infrastructure. One of them ... somewhat from the CA/PKI industry is that public keys be registered with the domain name ... eliminating some vulnerabilities that result in being able to obtain a valid SSL domain name certificate by thinks like a domain name "take-over" attack on the domain name infrastructure.

However,

1) improving the integrity of the domain name infrastructure improves the perceived trust in the domain name infrastructure ... mitigating the perceived requirement for SSL domain name certificates

2) registering public keys with the domain name infrastructure (as part of improving the perceived trust in the domain name infrastructure for use by the CA/PKI industry) enables the domain name infrastructure to distribute trusted public keys ... further eliminating the requirement for SSL domain name certificates

3) all the upfront certificate related chatter in the SSL protocol can be eliminated if public key distribution was piggybacked with IP-address distribution (by the domain name infrastructure).

Fixing the domain name infrastructure trust issues for use by the CA/PKI SSL domain name industry ... also can pretty much eliminate the need for SSL domain name certificates.

As part of the original SSL domain name stuff for what is now called electronic commerce ... we actually looked at pursuing certificates that were related to the quality of the merchant .... as opposed to whether it was really the specific merchant (aka good housekeeping seal of approval or BBB type certificates).

It turned out that it wasn't possible to come up with a business model that met anything. Two of the issues were:

1) the consumers are the relying-parties .... there is essentially no determination before hand on how many times a merchant might use the certificate with relying-parties ... as a result it was difficult to estimate potential liability to the issuing party based on the number of times that a certificate would be relied upon.

2) the reputation certificate tended to be a very small niche market. electronic commerce transactions are highly skewed ... the majority of transactions are done with either 1) well-known merchants and/or 2) merchants that the person has dealt with before. The need for reputation certificates tended to be very small percentage that involved transactions with a merchant that the consumer had no prior contact and had no basis for knowing anything about.

3) the emerging ubiquitous, online world tended towards commercial reputation similar to BBB, call up and get the current, real-time, dynamic information (not stale, static information that could be several years old). If it was important enough for a person to check on reputation, given equal choice between real-time and several year old, stale, static information ... a person would prefer some sort of real-time, online check.

So stale, static SSL domain name certificates are totally subsumed by online, dynamic, trusted domain name infrastructure that is able to distribute public keys in addition to ip-addresses.

Requirements for reputation referral is a small niche market since it it tends to be solely first time transactions with totally unknown merchant (no previous direct and/or indirect knowledge of the merchant). This is significantly better served by timely, online information than it is by some stale, static certificate.

You don't particularly mind seeing a BBB sticker in store window (a form of stale, static credential) ... it may or may not bring some comfort (thus our coining the term merchant comfort certificate). However, if it tends to be any issue of importance and significant value there is a tendency to want to call up the BBB and possibly other agencies to get real-time information.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 05:12:19 GMT

"George Ou" writes:
Bottom line, what do you think of my new proposed PKI model? And please keep the response within 100 lines :-). A simple thumbs up or thumbs down would also do.

bottom line ... at rsa conference ... i once told the ceo of baltimore that i'm on a mission to eradicate certificates from the face of the earth, it was somewhat facetious joke.

bottom line .... certificates were invented as a solution for trust in a fragmented, disconnected, offline, model where two parties had no prior knowledge of each other (aka the pre-magstripe plastic cards or letters of credit in days of sailing ships).

fundamentally that is rapidly vanishing niche ... in a ubiquitous, online, all the time, connected environment.

from an information theory point-of-view ... a certificate contains a stale, static copy of some information recorded some place.

Certificates are attached at the end of some electronic message in lieu of the parties having prior knowledge of each other and/or in lieu of having a online, timely, dynamic access to the trusted, authoritative agency. In financial infrastructure, certificates represent pre-1970s paradigm (prior to online deployment).

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 15:45:04 GMT

George Ou writes:
1. How is it stale if the CRLs can now be real-time because the work load is distributed and delegated under my proposal. Under this proposal, it is online and it is dynamic. Before you start any transaction, you first check with the root CA if the Domain cert you're looking for or any other cert has been revoked. Then you check with the domain's CA if a certain user or host has been revoked.

2. What is your solution in place of PKI and certificates? You can be online all you want, but if you're meeting someone you've never met before, you have to have some kind of trusted 3rd party to help you decide if you trust the other party. Are you suggesting that you contact the trusted 3rd party each and every time? Don't you think they're start dinging you per transaction that way? What the hell difference does it make? I'm proposing a delegated PKI and distributed real-time CRL model.

3. Again, you keep comparing certificates to "sailing orders". You keep trivializing the significance PKI and PKC. Don't you understand that "sailing orders" weren't tamper proof nor where their signatures tamper proof nor were they encrypted? You can't possibly make that comparison. Under a new PKI model, you would call HQ to see if any "sailing orders" were revoked since you last checked. If the answer is no, you know you're good to go. You sound like a broken record in your opposition to digital certificates and you keep repeating the word dynamic. How in the world is that any different from real-time CRL checks.

Anyways, you seem to be on a vendetta against digital certificates. I don't buy the "sailing orders" comparison, because that is ludicrous.

I'm on a vendetta against trying to use something designed for purely offline operation in an online world .... it is like trying to fit a round peg into a square hole ... it is bad business practice. It is something like trying to use a 2.5 ton flat bed truck for hauling concrete ... a flat bed truck was not designed to haul concrete. I can imagine that if all somebody understood was flatbead trucks, they would try and design some rube golberg contraption to use it for hauling concrete ... say, wooden sides lined with multiple layers of plastic tarp ... and hopefully it doesn't set up before arriving at the destination.

So the first thing that low-value offline certificates came face to face with was that if the information was no longer valid ... what do you do? Well the pre-70s, credit card model was you maintain an accurate list of all the relying parties ... and once a month you would mail out a paper booklet of revoked credit card numbers to every merchant. So that is exactly what several of the original low-value offline certificate infrastructures came up with .... they would absolutely know all possible relying parties ... and mail then a electronic list of revoked certificates and they called it a revoked certificate list and the infrastructure was called a PKI.

So the next scenario from the early '90s ... was what if you were dealing with higher value situations ... the solution was to send out the CRL more frequently or send out the CRL proportional to the value involved in the infrastructure. Identified problems

1) contractual relationship is between the certification authority and the public key owner. there is no contractual relationship between the relying party and the certification authority

2) the value of the operation is known by the relying party, not the certification authority ahead of time, so unless you were dealing with an absolutely homogeneous value infrastructure ... the value of the transaction and therefor the timeliness needed for the CRL interval is established by the relying party ... not by the certification authority.

3) the CRL needs to be sent out by the certification authority, but the identification of the relying parties is selected by the public key owner, not the certification authority.

So the worst case scenario from the mid-90s ... was that all certification authorities had to send out CRLs once every 30 seconds to all possible relying parties (numbered in the millions), and there had to be contractual relationship established between all possible relying parties and all possible certification authorities prior to use of certificates.

So, a partial kludge is the current Federal GSA PKI ... where all possible relying parties have contracts signed with GSA ... and all possible certification authorities have a contract with the GSA where they issue certificates as agents of the GSA (creating the legal appearance that relying parties have legal contract with certification authorities). This doesn't address the mailing out of CRLs to all possible relying parties every 30 seconds.

The CRL frequency proportional to value, was established as a relying party determined value not a CA determined value. Furthermore, large number of hypothetical PKI models was such that the CA would never know all possible relying parties. In the credit card model, the merchants were the relying parties ... and had to be preregistered with the credit card infrastructure ... so it was knowable who to mail the credit card revokation booklets to. In the SSL domain name certificates, all possible clients in the world are the relying parties ... which is pretty unknowable (although the spammers are trying). The suggestion was that for SSL domain name certificate infrastrucutre to graduate from certificate manufacturing to PKI, the CRLs would have to be mailed to all possible internet users in the world at least once a day (some of the large scale spammers are trying to accomplish). Then there is an issue of being able to reliably determine if all possible relying parties (all internet users in the world) actually received and processed their daily CRL list.

So the credit card industry in the '70s were interested in doing trusted transactions and moved to a paradigm of online transaction verification. The certification authority industry is interested in selling certificates designed for an offline paradigm; as a result rather than moving to an online paradigm for an online environment; the certification authority industry tries to force fit a flat-bed truck into use for hauling concrete (my uncle somewhat did the reverse, he bought up some number of concrete hauling trucks at auction that were without the rotating tank ... and put fifth wheels on them and used them as semi-tractors for pulling trailers).

So some of the scenarios are relying-party-only certificates for purely closed environments ... where the relying party is also the certification issuing authority. Then the certificates are stale, static copies of information on file with the certification authority. However since the relying party is also the certification authority, the relying party then has access to the timely, dynamic, online information. But if the relying party has access to the timely, dynamic, online information, then the existing of the stale, static relying-party-only certificates are redundant and superfluous.

Anothor scenario that could be considered to grow out of this period was OCSP. Now back to the credit card industry, if the point of the industry was trusted transaction, there is no vested interest in how you get trusted transactions. If you have a purely offline environment, you can go with a form of stale, static credentials designed for the offline world. If you have an online environment, you can design online transactions designed for an online world. The issue in the PKI and certification authority industry is the focus is on selling (stale, static) certificates. So if you have an online environment, but a solution for an offline world ... rather than converting to a paradigm for an onlne world; an attempt is made to cobble together lots of online features wrapped around a solution designed for offline environment.

One of the problems with the rube golberg cobbling is that if you really make the online features wrapped around the offline infrastructure too sophisticated, then it becomes trivially apparent to everybody that the offline, stale, static certificate piece is redundant and superfluous (as in the relying-party-only certificate scenario). So the online "fixes" to the offline solution, have to just be marginally sufficient, but not sufficient enough to make it grossly apparent to everybody that the stale, static offline certificates are redundant and superfluous.

At some point in transition from the offline paradigm to the online paradigm, it becomes terribly obvious that stale, static certificates designed for a offline environment and redundant and superfluous when everything is timely and dynamic. This transition is much simpler when the infrastructure is primarily interested in the execution of trusted transactions rather than in the sale of trusted credentials.

The assertion was that it was immediately obvious in the payment card industry (both credit and debit) to use magstripe for transition to trusted, dynamic, timely, online transations ... being able to eliminate the kludges that they were wrapping around an offline paradigm.

Such a transition is much more difficult for some parts of the public key industry, because their vested interest is not in the use of public key for trusted transactions ... but in the use of public key attributes as marketing support for selling their certificates. There is lots of interest in making transition to dynamic, timely, modern, online environment with trusted transactions .... but if the vested interest is selling stale, static certificates designed for solving a problem in the offline world ... that transition becomes much more difficult because it requires recognizing that the stale, static certificates are redundant and superfluous.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 15:54:21 GMT

Tom St Denis writes:
No you missed my point. Say I buy "TOM.COM" [which is owned by someone else actually but ignore that) and I get a key assigned to that. What does that mean? That means there is a key assigned to TOM.COM. Does that mean that people can trust the services TOM.COM offers?

no, when my wife and I were assigned to do this thing with small client/server startup that wanted to do payments on their server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

(now frequently referred to as electronic commerce), we tried to see both happen. Going around to all the operations selling certificates we made some amount of suggestions as to how they should operate for issuing SSL domain name certificates. To distinguish the SSL domain name certificate operations from the PKI descriptions in the literature, we coined the term certificate manufacturing. We also, repeatedly pointed out to everyone the similarity between proposed CRL operations and the pre-70s revokation list paper booklets in the credit card industry ... and brought up some of the dynamic, timely issues with transactions that might involve real value.

the other thing we spent some time looking at and trying to do the business case for was reputation certificates ... not just that the relying party know that they were talking to the server they thought they were talking to (browser matches the URL it used to contact the server with the URL in the presented SSL domain name certificate), but also that the customer could have some trust in the merchant (from an electronic commerce standpoint). This was somewhat the BBB, Visa, Mastercard, etc stickers you see in store windows. Turns out that it wasn't possible to come up with a viable business case for reputation and/or operational trust; just simply the standard SSL domain name certificates that you are talking to the server that you think you are talking to.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

OSI not quite dead yet

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OSI not quite dead yet
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 16:05:25 GMT

Bruce Stephens <bruce+usenet@cenderis.demon.co.uk> writes:
OSI is still at that stage. It could well be that PKI will stay there for decades too, with companies finding new niches. Well, let's be honest, selling bits annually to vast numbers of web shops is a pretty big niche.

OSI had another problem. In IETF, there is a requirment that two interoperable implementations are needed before standard progress. There is no such requirement in ANSI/ISO. To some extent it is entirely possible to have standards that have nothing to do with reality.

So in x3s3.3 (ansi, iso chartered organization responsible for standards affecting osi level 3&4), we tried to get high speed protocol, something that went from transport, level 4 interface directly to LAN/MAC interface. The problem was that there was an ISO requirement that networking standards bodies couldn't consider standards that violated OSI. LAN/MAC basically combines OSI level 1, OSI level 2, and part of OSI level 3 into a single layer with an interface that sits someplace in the middle of the OSI level 3. By definition, any standard that interfaces directly to LAN/MAC interface violates OSI and therefor could not be considered for standardization by x3s3.3. misc. past musings on the subject:
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

it wasn't so much that OSI got to standardization without any "rubber meets the road", reality test ... but that they also turned it into a religious issue that it was not possible to come up with anything that deviated from the one and only true path.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IBM Manuals from the 1940's and 1950's

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Fri, 05 Sep 2003 18:49:18 GMT

"John W. Kennedy" writes:
TOD clock; MVCL and CLCL; ICM, CLM, and STCM; SRP (I think -- the 91 and 95 didn't have decimal at all, but I think the 195 did); CLRIO; STIDP. Were there any others in the first iteration of the 370? There wasn't much in it, since, like the 85, it already had the 370 features of unaligned operands, extended-precision floating point, block-multiplexor channels, and the HDV op-code. I'm not sure about SIOF. I suppose they also removed the never-used ASCII feature.

They later surveyed 195 owners about the possibility of upgrading to virtual memory, but there wasn't enough interest.

i remember being told (when working with some of the 195 engineers on idea of dual i-stream 195) that possibly the biggest 360->370 transition for 195 was instruction retry.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

Refed: **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch
Date: Fri, 05 Sep 2003 14:52:08 GMT

jlsue writes:
Not sure what you mean. It's not an US vs THEM thing. Done right, there's a partnership where the IT alignment with the business is very tight, and it's the business managers who help justify IT's budgets - because they more fully understand the value that's being provided via those good ol' service level agreements.

1) business managers may not know or care anything outside their own direct relm of responsibility ... they may just want the best they can get for the lowest possible cost

2) intra-corporate SLAs may not have good ol' enforceable contractual penalties; sometimes business units like dealing with external organizations because they know that they'll have legal recourse which they wouldn't have when dealing with an internal organization.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 18:56:01 GMT

Anne & Lynn Wheeler writes:
bottom line ... at rsa conference ... i once told the ceo of baltimore that i'm on a mission to eradicate certificates from the face of the earth, it was somewhat facetious joke.

some associated with the PKI industry have made off-hand comments about my wife and I being devil incarnate. It isn't so much because we are anti-PKI .... it is because we examine the business requirements and then propose a solution ... rather than the typical PKI industry kneejerk reaction which is certificates are the solution, ... now what is the requirement?

so to paraphrase the TV ad ... we aren't really the devils incarnate, but sometimes we play one for the PKI industry.

They do have a slight issue of over playing the devil incarnate issue since we can come back and play the "we were instrumental in helping establish the current PKI business infrastructure" card:
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 19:43:11 GMT

Tom St Denis writes:
I mean if you move PKI to the DNS servers it's just as useless as it was before. Just now it's cheaper.

My claim has always been the CA SSL domain name certificates have always been tightly intertwined with the domain name infrastructure

1) a premise for the existance of SSL domain name certificates has been perceived integrity weakness in the domain name infrastructure.

2) since the domain name infrastructure is the authoritative agency for domain names, any business operation wishing to certify domain names has to check with the domain name infrastructure; to the extent that the CA industry does that for SSL domain name certificates is possibly obscured by a whole bunch of intermediate business steps and crypto mumbo jumbo.

3) fixing the domain name infrastructure integrity issues so that the CA industry can rely on it for authoritative certification of domain name ownership, also goes a long way to eliminating business requirement for SSL domain name certificates (see #1)

4) one of the proposals somewhat from the CA industry to improve the domain name infrastructure integrity issues involves registering public keys along with domain names registration (in a sense this is much more similar to how PGP works). Making the domain name infrastructure

a) a real-time, online, dynamic trusted information distrubtion operation and

b) providing the domain name infrastructure with registered public keys

then enables the domain name infrastructure to be a trusted, real-time dynamic distributor of public keys w/o having to resort to a PKI certificate infrastructure.

You have trusted, online, dynamic, real-time, distribution of public keys without CAs, PKIs, and certificates.

However, the CA industry has a vested interest in seeing that stale, static certificates are sold, regardless of whether or not they are redundant and superfluous and/or serve any useful business purpose.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 23:37:33 GMT

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
The cert issuing infrastructure doesn't have to be humongous. It's not even really humongous now, though it's more complicated than it needs to be. What it DOES need to do is check real-world credentials, which the DNS registry system does NOT, and which the cert system does sort of half-assedly.

lets say that it is $300/annum for something like 200,000 certs ... that is maybe $60m ... just to support the scenario that it might possibly be of use when the internet is donw and you can still use the cert offline.

So we say that only the guys that really want to have to support the offline option buy certs .... and everybody else goes with the good ol online domain name infrastructure public keys ... maybe that is 200 total (tenth of a percent of the current).

The CA guys have some fixed costs to maintain their infrastructure, security boundaries, security hardware, etc. .... say that they still need $24m/annum to get buy. That means the 200 or so that still want certificates to handle the offline case when the internet is down will need to pay $120,000/certificate/annum.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 23:45:17 GMT

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
Not at all. DNS registrars make no attempt whatsoever to authenticate the registrant. This is a good thing. Most sites don't need authentication and there's no reason to make them pay for it.

they don't have to authenticate the registrant when they sign up ... it just needs to be like a swiss bank account ... the person that opened the domain name is the owner of the domain name. that owner of the domain name can establish some online reputation ... w/o having to actually disclose who he is ... as long is he is the one that opened the domain name. That basically is part of the suggestion (by the CA industry) for public keys to be registered at the same time as the domain name .... the person then does digitally signed transactions with the domain name infrastructure (which can be verified with the public key registered in the domain name account record). This somewhat is countermeasure against domain name takeover fraud where an imposter can take over the domain name owndership.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Fri, 05 Sep 2003 23:48:09 GMT

"George Ou" writes:
Ah, but this is what my proposal would make possible. Since you're effectively reducing the number of verifications to 1 per domain, you can go out of your way to make sure that the real world information including photo and finger print (for corporations) to make it work well. There is no way you could do that now when Verisign is trying to micromanage each and every email and host entry for you. Additionally, my proposed infrastructure would provide some checks and balances for the Internic and vice versa.

the business issue is that most of the SSL domain name certificate use right now is possibly getting somewhat close to one per domain already. The vast majority of transactions are electronic commerce transactions with online merchants that don't have a broad range of servers requiring multiple certificates.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Sat, 06 Sep 2003 00:14:47 GMT

"George Ou" writes:
Please pardon my ignorance. But would secure DNS provide everything that I'm talking about? Where you can put up your own CA PKI that is trusted globally to sign for just your domain? Does it go to the extreme of verifying the owner of a domain if it were needed for a large corporation?

SSL domain name certificates proove nothing about who you are ... they just proove that the domain name in the browser URL matches the domain name in the server provided certificate. Anything done about the operator of the server, the relying-party (client) has to do out of band and has nothing at all to directly with the characteristics of the domain name owner.

Right now, the CAs basically do a little checking if it is any validly registered company and if the registration of the company matches what is on file with the domain name infrastructure. This has a number of vulnerabilities since it is relatively trivial to create a company that has some valid registration someplace. If the domain name infrastructure has been compromised with respect to who is on file as to the owner of the domain name, the CA infrastructure is at risk.

So the SSL domain name certificates were never about the characteristics of the domain name owner ... just is to is it the entity that owns the domain name.

That is where the public key registration comes in ... and can be analogous to swiss bank accounts. The person registring a domain name also presents a public key. All subsequent transactions have to have a digital signature that can be verified with the public key on file (this is a step up from the traditional scenario where what is on file is a secret ... as opposed to a public key).

With SSL domain name certificates, clients visiting the website can be assured that the website they are visiting is the website that they intended to visit (that is what the current SSL domain name certificate provides). SSL provides no representation regarding the owner/operator of the website.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Offshore IT ... again

Refed: **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Offshore IT ... again
Newsgroups: alt.folklore.computers,bit.listserv.ibm-main
Date: Sat, 06 Sep 2003 03:06:42 GMT

slightly related: Indian EEs show you can go home again.
http://www.eetimes.com/sys/news/OEG20030905S0038

from some posting about the possibility some time ago
https://www.garlic.com/~lynn/2002k.html#41 How will current AI/robot stories play when AIs are real?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Sat, 06 Sep 2003 15:21:56 GMT

George Ou writes:
But I don't want to use just one portal or a wild card. I want to be able to issue an unlimited number of hosts and email addresses for my domain. I want to be able to use SMTP-AUTH and SMTP-TLS. I want to enable secure XML transactions. I don't want to buy just one host certificate. I want to buy one master certificate for my root PKI server. There is a huge difference.

Companies buy so few because they can only afford one or two certs. Take away the cost factor and watch PKI deployment go up.

majority of the internet are using SSL domain name certificates when they have trust issues with the domain name infrastructure and they are doing something of value (certificates represent a patch on perceived trust shortcomings of the current domain name infrastructure, as opposed to directly fixing the turst shortcomings ... they are being coated over with SSL domain name certificates).

In the early days of SSL, the original discussions were assuming that SSL would be used for all shopping related activities going on over the internet ... until it was determined that there is something like a five-fold difference between SSL sessions capacity and non-SSL session capacity. As a result, instead of seeing SSL being default for everything that went on the internet .... yoo saw it being cut back to only the phase involving entering the credit card number ... and frequently the credit card number processing being handed off to a dedicated credit card processing server (for the ten large guys they are probably doing their own ... for the small to medium tier sites, you find many are outsourcing ... where a single processor actually may handle hundreds of shopping sites). This limited deployment wasn't because of the cost of the certificates ... which is trivial compared to the cost of the additional infrastructure for running the actual SSL operation (and which doesn't go away, even if SSL domain name certificate costs totally disappear).

So, as I've repeated numerous times before ... if you fix the underlying domain name infrastructure ... it almost totally eliminates any possible demands for SSL domain name certificates (of any kind) ... and would still allow SSL type public key sessions ... with little additional cost. However, the cost issue of operating SSL (or SSL-like) sessions still appears to dominate.

A current issue is that the domain name infrastructure has to be fixed in any case (since its difficiencies also put the SSL domain name CA business at risk). Part of the current CA cost is that they need a totally different business operation, staff, training, and their own operation which needs an independent revenue flow is need to support. Making public key distribution part of the standard domain name operation eliminates almost all that additional infrastructure costs and just merges it into the existing dynmamic, timely information distribution business operation.

So there are a couple of infrastructures that have deligated trust of the type you are proposing (not the technical mechanics ... but the process that one business will deligate certificate trust operations to another certification business operation). The scenario is that the deligated agent has to have processes in place that they follow all of the business processes followed by the root trust operations (for establishing the validity of the information being placed in the certificate) or the resulting sub-certificates don't mean anything. They require the sub-agent to have totally separated computer operations in secured facilities and the cost of the deligation certificate frequently is in the tens of thousands or hundreds of thousands of dollars.

Another way of looking at this ... is if they don't require such processes and costs they would be severely diluting their brand name to the point that it would mean little more than any randomly self-signed certificate. In effect, the sub-agent signed certificates would have significantly lower trust unless they implemented all the processes (and costs). The only thing that such CA operations would then uniquely have is that they had undergone the costs to have their root certificate preloaded into major browsers and they would be franchising out access to that browser pre-loaded root certificate with possibly little or no control over the franchised operations.

There is nothing stopping any entity from going to the major browswer venders and going through the necessary steps to get a brand new root certificate preloaded into browsers ... and establish whatever business procedures they want to for managing delegated trust.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 06 Sep 2003 17:31:32 GMT

Robert Myers writes:
Bottom line: people are making WAN connectivity at a price so high that no one wants to buy it, and big players like IBM and HP seem to be ignoring that fundamental reality and betting the ranch on utility computing.

seems almost the same as 20 years ago; lots of dark fiber, existing bandwidth charges, etc. there was somewhat of a chicken and egg .... if they seriously dropped the bandwidth charges w/o a corresponding serious increase in bandwidth demand ... they couldn't cover their run-rate ... significant bandwidth price reductions would cannabolize their existing revenue flow; ... aka in order to reduce the bandwidth charges by a factor of ten, they needed ten times more bandwidth utilization ... since they had significant infrastructure and fixed costs.

my perception was they did significant tax-deductable donations of (dark fiber) bandwidth to infrastructures like NSFNET in an attempt to jumpstart bandwidth intensive applications ... and not impacting their existing tariffs. Later, I believe some amount of the fixed costs were just written off (aka cost for the trenching, etc for laying the fiber bundle is somewhat fixed cost, independent of the number of fiber strands in the bundle).

Internet applications then started spike in bandwidth utilization .. and started doubling every X(?) months ... which kicked off new round to infrastructure buildout. However, the bandwidth doubling started to slow down as market became saturated. They still have to figure out how to recover the fixed costs based on per use pricing.

In some sense, some amount of the whole utilizity computing issue is similar .... the data processing resources represent significant fixed costs that have to be recovered. The issue is how to recover those fixed costs in an environment where whole populations want to go to per use pricing.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Thoughts on Utility Computing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Thoughts on Utility Computing?
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 06 Sep 2003 23:46:33 GMT

Pascal Bourguignon writes:
Whooah! You need a supercomputer to process 500 milli bits per seconds now?

That makes one bit every two seconds!

here is some bulk file transfer numbers from slac run on sun:
http://www-iepm.slac.stanford.edu/monitoring/bulk/bbcp.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Proposal for a new PKI model (At least I hope it's new)

Refed: **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Proposal for a new PKI model (At least I hope it's new)
Newsgroups: sci.crypt
Date: Sun, 07 Sep 2003 00:29:14 GMT

Bryan Olson writes:
Whoever registers a domain name is the authority for the subdomain rooted at the name. In any case, I tend to be sceptical of various proposals to do twice over what we haven't yet succeeded in getting done once.

part of the problem is typically that the need is to authenticate the entity that supposedly owns the domain. The real "problem" in the CA/PKI scenario for SSL domain name certificates ... is that the original registration of the domain name failed to provided an adequate authentication mechanism.

SSL domain name certificates attempt to do an after the fact fixup of the authentication difficiency (the fixup itself then results in a number of shortcomings). The domain name infrastructure has some information that can be used to establish a real world identification. Somebody comes to the CA and requests a SSL domain name certificate that can be an aid in (SSL) authentication processes (as opposed to identification processes). The CA has to check that the requester is the same as the entity that owns the domain name. Since there is no authentication information, the CA needs to map the information from the domain name infrastructure to some external identification ... and then establish that the certificate requesting entity also can map to the same external identification.

To improve/simplify the CA's job for SSL domain name certificates, the CA industry wants the domain name infrastructure to register a public key as part of the domain name registration. Then when somebody is asking for a certificate (actually any domain related activity) ... the CA can retrieve the public key from the domain name infrastructure ... and perform an authentication operation ... w/o going thru all the difficult identification gorp. However, if a CA can retrieve the public key from the domain name infrastructure for authentication ... then presumably anybody can retrieve the same public key for authentication .... significantly negating the need for a CA signed certificate in order to perform authentication operations.

Now comes the issue of delegation. The current infrastructure has CA "root" public keys preloaded into browsers and a convention that SSL domain name certificates can be authenticated by any preloaded root key.

So it is possible to go one of two ways:

1) all SSL servers can also have domain name infrastructure entries with their corresponding public keys. There is no trust delegation and/or trust hierarchy (in the client process), every server that wants to do SSL has their public key registered in the domain name infrastructure. The purpose of the domain name ownership public key is to authenticate all transactions with the domain name owner. One such transaction, is a digital signed transaction (by the domain name owner) for the registration of public keys for each SSL server. There is a trust hierarchy involved with the registration of the additional public keys ... but it doesn't need to be visible in the client SSL operation (no stale, static certificates).

2) for those that want a domain-related trust hierarchy with certificates ... rather than requiring that domain-related hierarchy certificates be signed by CA root that has been preloaded into some software ... just require that all domain-related hierarchy certificates be signed by a private key corresponding to a public key registered in the domain name infrastructure (for that domain). NOTE: from an information theory standpoint, if a CA is willing to accept a domain name public key as the authoritative authentication reference for generating certificates, then that key is the "root" in the real trust hierarchy (even if it doesn't show up in PKI trust hierarchy visible to clients). If it is logically the "real" trust root, then the claim can be made that the CA "intermediate" root key can be eliminated w/o impacting the trust hierarchy.

For offline operation, some set of such keys can be precashed/preloaded locally. Trivial in the DNS implementation to even tag domain ownership public keys as to signatures only, encryption only, signatures+encryption, certificate signatures (as opposed to transaction/message signatures).

#1 has the advantage that it can be timely and dynamically updated without needing to worry about old, stale, static mappings floating around all over the world.

dns web site, including drafts in progress for DNSEXT (subsumes DNSSEC and DNSIND)
http://www.dns.net/dnsrd/docs/id.html including significant update to RFC2535.

somewhat related is IETF authorization, authentication and accounting
http://www.aaaarch.org/index.html

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Can you use ECC to produce digital signatures? It doesn't see

Refed: **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can you use ECC to produce digital signatures?  It doesn't see
 so.
Newsgroups: sci.crypt
Date: Sun, 07 Sep 2003 05:09:18 GMT

George Ou writes:
The thing is, it doesn't appear to me that you can use ECC cryptography for digital signatures even though it is a form of Public Key Cryptography. From what I understand, it takes two parties secret key EC-multipling an initial point P on the elliptic curve to produce a session key. It's not like RSA keys where you have a private and public key where you simply use your own private key as the encryption key on a SHA-1 hash of the message to produce a digital signature.

The signature component in cryptography is as important as the encryption component. Is there is a way to use ECC for digital signatures that I don't know of?

NIST FIPS186-2 ecdsa (also x9.62):
http://csrc.nist.gov/cryptval/dss.htm

white paper at certicom
http://www.certicom.com/pdfs/whitepapers/ecdsa.pdf

RFC3278, Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS), discusses ecdsa

ecdsa in project corvallis:
http://security.ece.orst.edu/corvallis/concepts.html

mapping of x9.59 to iso 8583 using ecdsa signatures:
https://www.garlic.com/~lynn/8583flow.htm
more on x9.59
https://www.garlic.com/~lynn/x959.html#x959

also discussion of AADS chip strawman that only does ecdsa:
https://www.garlic.com/~lynn/x959.html#aads

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

IBM Manuals from the 1940's and 1950's

Refed: **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Manuals from the 1940's and 1950's
Newsgroups: alt.folklore.computers,comp.lang.pl1
Date: Sun, 07 Sep 2003 15:16:56 GMT

Joe Morris writes:
Speaking of (un-)aligned operands, the hardware of the 3705 required that instructions be on a halfword (2-byte) boundary, and the instruction counter didn't even gate the low bit to the I-address register. The low bit in the address field of the instructions was used for other purposes.

I have a vague recollection that the assembler was the only place where a reference to an odd instruction address could be diagnosed. I don't recall if there was a hardware trap if a calculated branch address was odd.

3705 was a uc.5 microprocessor, also used in (at least) the 8100 and the service processor for the 3081. while there wasn't a pli for the 3705 ... i believe i remember somebody talking about working on cobol and possibly pli compiler for the 8100.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Seven of Nine

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Seven of Nine
Newsgroups: alt.folklore.computers
Date: Sun, 07 Sep 2003 19:20:26 GMT

eddie writes:
My question to all you old-timers and hardcore high-level bit deities is - is this normal ? Is it really the case that ability in the technical sense is but a poor second-best to the ability to speak manager-ese and wear the right clothes and, if so, what are the right words/look/dress to use for these things. Failing a response alomg those lines I'd be interested to hear some details/stories about times you've interviewed or been interviewed and how you made your decisions about who to employ or why you think the PHBs rejected you if you were the poor sod under- going interview.

if you take it from the myers-briggs personality perspective ... one of the spectrum is values, valuing people at one extreme end and valuing ideas at the other extreme. there is some evidence that HR people would tend towards the people end of the spectrum ... and that technical excellence is skewed towards the idea end.

the HR training courses and executive training courses (at least used by many of the larger corporations here in the US) seem to try and have mixed groups and give the m/b test and then have discussions about how different kinds of personalities relate to other personality types.

junior HR people w/o a lot of training could be totally biased towards personality types that match theirs.

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Can you use ECC to produce digital signatures? It doesn't see

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can you use ECC to produce digital signatures?  It doesn't see
 so.
Newsgroups: sci.crypt
Date: Sun, 07 Sep 2003 20:03:58 GMT

George Ou writes:
I think 2 phase is important because it allows you to keep the initial phase in a smart card for it's little 8 bit processor to handle only once. This allows you to protect the private key inside an HSM where the host computer never needs to know what the private key is. The last thing I want to do is keep my private key on my computer's harddrive using a general purpose OS.

in the past, one of the reason for doing RSA with 8bit processors and not any of the DSA or ECDSA implementations ... is that both DSA and ECDSA require a high quality random number as part of the signature generation (in conjunction with the private key); and none of the 8bit processors provided reasonably acceptable random source.

RSA-based signature infrastructures tended to have a message with an embedded random number (nonce, generated by the infrastructure that generated the message), calculate the SHA-1 ... and then pass the SHA-1 to the card. For much the same reason (lack of random source), the cards tended to have random public/private RSA keys generated externally and then injected on the card.

Some of the newer generation of chips now have qualified source of random numbers .... enabling both on-chip keygen as well as supporting DSA & ECDSA operation. ECDSA signatures on these chips use much less circuit area, much less power, and can be performed in much less time than equivalent RSA signatures (once a qualified random source was available). They can provide nearly HSM-level integrity. The biggest integrity difference (from a FIPS standpoint) ... is there are some extreme physical attacks against powered off chips ... a combination battery/chip can provide zeroization for these scenarios ... where a chip that was not "always on" couldn't. The battery is an issue for various ISO 7816 & ISO 14443 form factors .... but it is possible to take the same chip .... package it with a battery and get effectively HSM-level integrity.

The issue in the AADS chip strawman was as close as it could come to magstripe cost ... and still provide highest possible level of integrity.

Misc. tamper resistant discussion:
http://www.cl.cam.ac.uk/users/rja14/tamper.html

the follwoing has short note on the IBM ABYSS:
http://www.cs.virginia.edu/~jones/cs551S/slides/presentation_smart_cards.ppt
with 4 layer wrapping of 40 gauge nichrome wire surrounding chip and battery embedded in hard, opaque expoxy filled with silica

Part of the issue is security proportional to risk ... part of past security proportional to risk thread:
https://www.garlic.com/~lynn/2001h.html#61

An AADS chip provides significantly higher integrity than a magstripe (and x9.59 in conjunction with aads closes the major exploits that show up in the press). In the aads, x9.59 case, the chip is protecting the account (which is currently protected by a magstripe). The particular chip being used in the AADS chip instantiation has gotten an EAL5+ rating.

Obviously if you have either a global shared-secret or a global secret paradigm; exposing the infrastructure secret creates a systemic risk for the whole infrastructure. An example is the CA certificate signing private key and systemic risk. The AADS operation doesn't have single points of failures.

x9.59 reference:
https://www.garlic.com/~lynn/x959.html#x959
aads reference:
https://www.garlic.com/~lynn/x959.html#aads

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

Strength of RSA with known plain-text

Refed: **, - **, - **, - **

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Strength of RSA with known plain-text.
Newsgroups: sci.crypt
Date: Sun, 07 Sep 2003 23:37:51 GMT

George Ou writes:
I'm curious to know what application in the real world uses RSA to encrypt the actual payload.

I'm not talking about for academic research where you do it for the sake of research and because you can, I want to know what practical application is RSA used in encrypt actual data.

they thot it was a practical application ... try SET (the secure electronic transaction specification). recent SET reference:
https://www.garlic.com/~lynn/aadsm15.htm#2 Is cryptography where security took the wrong branch?

--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
Internet trivia 20th anv https://www.garlic.com/~lynn/rfcietff.htm

next, previous, index - home