List of Archived Posts
2005 Newsgroup Postings (11/05 - 12/04)
- TTP and KCM
- Dangerous Hardware
- Dangerous Hardware
- Privacy issue - how to spoof/hide IP when accessing email / usenet servers ?
- Privacy issue - how to spoof/hide IP when accessing email / usenet servers ?
- Dangerous Hardware
- phishing web sites using self-signed certs
- 2nd level install - duplicate volsers
- 2nd level install - duplicate volsers
- phishing web sites using self-signed certs
- Dangerous Hardware
- Passwords
- Dangerous Hardware
- Dangerous Hardware
- Dangerous Hardware
- Best practice for TOD clock
- Dangerous Hardware
- winscape?
- Various kinds of System reloads
- What ever happened to Tandem and NonStop OS ?
- So what's null then if it's not nothing?
- What ever happened to Tandem and NonStop OS ?
- What ever happened to Tandem and NonStop OS ?
- So what's null then if it's not nothing?
- What ever happened to Tandem and NonStop OS ?
- Why does my address appear as part of my name?
- Dangerous Hardware
- RSA SecurID product
- RSA SecurID product
- AMD to leave x86 behind?
- AMD to leave x86 behind?
- Looking for Information on password systems
- RSA SecurID product
- What ever happened to Tandem and NonStop OS ?
- RSA SecurID product
- winscape?
- What ever happened to Tandem and NonStop OS ?
- What ever happened to Tandem and NonStop OS ?
- What ever happened to Tandem and NonStop OS ?
- FULIST
- FULIST
- FULIST
- FULIST
- FULIST
- FULIST
- FULIST
- winscape?
- What is written on the keys of an ICL Hand Card Punch?
- FULIST
- FULIST
- non ECC
- RSA SecurID product
- PGP Lame question
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: TTP and KCM
Newsgroups: netscape.public.mozilla.crypto
Date: Sat, 05 Nov 2005 15:58:37 -0700
this x.509, pki, etc was outgrowth of the iso x.400/x.50x stuff
... that was, in turn, continuation of the iso osi stuff.
i don't have a lot of references to the x.50x stuff from the 80s. i was
involved in trying to get hsp (high-speed protocol) standards work
accepted by x3s3.3 (iso chartered us standards group for networking
related stuff). remember that this iso osi stuff was being mandated
by a number of govs. (including us federal) along with mandates
eliminating tcp/ip and the internet.
now, i've stumbled across some old email from 85 era discussion public
key and digital signature technology ... but can't find any specific on
PKI and x.509. however the x3s3.3 stuff with relationship to iso was
interesting. iso had some mandate that standards work woujldn't be
accepted for stuff that violated the osi model.
http://www.garlic.com/~lynn/subnetwork.html#xtphsp
unfortunately, hsp
1) went directly from the level4/transport interface directly to
the LAN/MAC interface ... bypassing the level4/level3
(transport/network) interface. this violated osi model and so
couldn't be considered for iso standards work
2) support internetworking protocol ... aka the stuff that allowed
the internetworking of different networks. internetworking doesn't
exist in the osi model ... so supporting tcp/ip also violated
osi model and couldn't be considered for iso standards work
3) talked directly to the lan/mac interface. lan/mac definition
sits approx. in the middle of osi level 3 ... and violates the
osi model. so anything that supports lan/mac interface also violate
the osi model ... and therefor can't be considered.
now i had done some work on the original relational/sql database
http://www.garlic.com/~lynn/subtopic.html#systemr
and in the early 90s were producing the ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
which included doing some work on parallel scaleup. minor
meeting reference regarding parallel oracle scaleup
http://www.garlic.com/~lynn/95.html#13
so i think it was at the (92?) acm sigmod database in san jose
... that somebody was trying to explain the x.500/x.509 stuff
that was going on ... as ... a bunch of networking engineers
trying to reinvent 1960s database technology.
a couple years later were were doing some financial consulting
and were asked to work with a small client/server start up in
menlo park on doing payment transactions and something called
a payment gateway that was going to turn into something that is
frequently referred today as e-commerce. who turns up at this
startup responsible for this thing called a commerce server ...
but a couple of the people that were in the above mentioned
meeting looking at parallel scaleup
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
now, one of the things we had to do as part of this stuff that was
going to be called e-commerce was go around and do audits of some of
these new organizations that were calling themselves certification
authorities ... who would be issuing these things called ssl domain
name cerver certificates. misc. collected postings on ssl domain name
server certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
now x.500/dap has somewhat evaporated ("1960s database technollogy
being re-invented by network engineers")... being replaced with
something called ldap ... or leight-weight dap. and x.509 ... which
was going reference some amount of x.500 has taken on a life of its
own. however, the original design point for x.509 is still to provide
relying parties with information about the original entity performing
a digital signature ... when the relying party has no other recourse
to information about the originator (aka the first time communication
between complete strangers).
however, it can be claimed that the original target market segment for
first time communication between two strangers, where the
relying-party has no other recourse for information about the other
party (because of no previous contact or unable to directly contact
some certification authority and/or other authoritative agency about
the entity in question) is rapidly disappearing because of the
ubiquitous pervasive creep of the internet into all areas of the
world.
even the no-value market segment ... which some PKIs tried to move
into (aka online resources became readily available for relying
parties to obtain real time information about the stranger they were
interacting with ... there value of the operations couldn't provide
cost justification for doing real-time vetting) is also rapidly
disappear as the cost of online connectivity rapidly declines. as a
result, the market segments where PKIs have some valid justification
are rapidly shrinking.
pieces of past posts in this thread:
http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
it somewhat seemed that x.509 standards work was moving out of ISO and
into IETF when it started to appear that the various gov. mandates to
eliminate the internet and tcp/ip (and replace them with iso osi,
x.400, x.50x, etc) was not going to be succesful.
the original pk-init draft for kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos
i.e. allowing public keys to be registered in lieu of passwords and
performing digital signature validation for authentication was
originally straight-foward, simple authentication process ....
http://www.garlic.com/~lynn/subpubkey.html#certless
the specification was added later for the use of certificates as part
of the digital signature operation ... turning simple,
straight-forward authentication operation into a heavy-weight
identification operation. if it was a pure x.509 identification
implementation, total strangers would be allowed onto every system as
long as they were able to present a valid x.509 identity certificate.
note that even in a pure x.509 identity certificate environment
... the relying party still needs to have obtained and registered in
their trusted public key repository, the public keys for the
certification authorities (otherwise the relying parties would not be
able to validate the certification authorities digital signatures on
the digital certificates ... which is the root operation required for
PKI.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Sat, 05 Nov 2005 20:52:04 -0700
"Phil Weldon" writes:
I have a story not about a dangerous computer, but rather a computer
in a dangerous place.
chptr 19 of Coram's book on Boyd ("the fighter pilot who changed the
art of war") is titled "Spook Base" about boyd running nkp, including
a datacenter handling data from sensors seeded on the ho chi minh
trail (the "mcnamara line") ... and represented a $2.5b windfall for
ibm.
there have been jokes about there was a large number of air strikes on
elephants ... apparently elephants had similar signature to large
people movements.
misc. past postings mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
misc. boyd pages from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Sun, 06 Nov 2005 03:17:15 -0700
Bill Turlock <"Bill Turlock"@sonnic.net> writes:
===nkp?
Boyd, The Fighter Pilot Who Changed The Art Of War, by Robert Coram,
chpt. 19, Spook Base, pg. 266,
... In the Vietnam War that base was Nakhon Phanom Royal Thai AFB,
commonly known as NKP or, by the more irreverent, as Nakad Fanny.
Activities at NKP were so highly classified for the first three or
four years of its existance that it officially did not exist.
.. snip ..
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Privacy issue - how to spoof/hide IP when accessing email / usenet servers ?
Newsgroups: microsoft.public.outlook.general,alt.usenet.offline-reader.forte-agent,news.software.readers,24hoursupport.helpdesk,alt.privacy
Date: Sun, 06 Nov 2005 03:45:27 -0700
Paul Hantom writes:
I think you two must be referring to the design of IP. I don't
think the Internet was designed; it really just evolved.
business process and gateway operation foundation for the internet
were the two nsfnet backbone RFPs ... minor reference
http://www.garlic.com/~lynn/internet.htm#0
IP and the internet provided for internetworking of networks. the
change-over to the protocol (and internetworking gateways) was on
1/1/83 ... which helped remove limiting factors to connecting nodes.
from just about the beginning, the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
was larger than the arpanet/internet until approx. mid-85. I've
frequently asserted the one of the reasons that the internal network
was so much larger was that the majority of the internal networking
nodes had a form of gateway support from just about the beginning.
at the switch-over, the arpanet/internet had approx. 250 nodes ...
at the time when the internal network had nearly a 1000 nodes ... which
it passed later that same year
http://www.garlic.com/~lynn/internet.htm#22
the business of interconnecting networks and the required business
relationships and gateway operations evolved from the nsfnet backbone
work ... other past internet related postings
http://www.garlic.com/~lynn/subnetwork.html#internet
minor topic drift, recent posting referencing govs. mandating
elimination of tcp/ip and the internet and replacement with osi in the
late 80s and early 90s ... exactly during the period that commercial
networks were being connected into the backbones.
http://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
from my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
misc. other historical references about nsfnet backbone RFP
and award:
http://www.garlic.com/~lynn/rfcietf.htm#history
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Privacy issue - how to spoof/hide IP when accessing email / usenet servers ?
Newsgroups: microsoft.public.outlook.general,alt.usenet.offline-reader.forte-agent,news.software.readers,24hoursupport.helpdesk,alt.privacy
Date: Sun, 06 Nov 2005 03:57:30 -0700
oh ... and the business process of internetworking of networks can
still experience some burps; a few news item references from the last
week or so
Cogent, Level 3 Fight Severs Customers from Net
http://news.yahoo.com/s/nf/20051007/tc_nf/38547;_ylt=A9FJqYOK.0ZDYT4AwQsjtBAF;_ylu=X3oDMTBiMW04NW9mBHNlYwMlJVRPUCUl
Cogent-Level 3 Peering Spat Ends for Now
http://www.eweek.com/article2/0,1895,1868765,00.asp
Cogent, Level 3 in Standoff
http://www.crn.com/showArticle.jhtml?articleID=171204130
Level 3 Issues Statement Concerning Internet Peering and Cogent
Communications
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/10-07-2005/0004164041&EDATE=
Cogent's Standing Offer to Level 3: Turn the Connection Back On, Then
Negotiate
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/10-07-2005/0004163871&EDATE=
The Level 3 Communications - Cogent Situation takes a new twist!
http://www.geeknewscentral.com/archives/005012.html
ISP Dispute Over - For Now
http://www.betanews.com/article/ISP_Dispute_Over_For_Now/1128703803
Level 3, Cogent call time out on peering spat
http://www.infoworld.com/article/05/10/10/HNlevel3cogent_1.html
Level 3, Cogent call time out on peering spat
http://www.computerworld.com/networkingtopics/networking/story/0,10801,105279,00.html
Internet Access, Bandwidth | Level 3, Cogent Partners Shocked Internet
Disruption
http://www.crn.com/showArticle.jhtml?articleID=172300415
Customers Shocked By Level 3's Internet Disruption
http://www.informationweek.com/story/showArticle.jhtml?articleID=172300552
Major Disruption In Level 3 Network Slows Internet Traffic
http://www.informationweek.com/showArticle.jhtml?articleID=172303270
Major Disruption In Level 3 Network Slows Internet Traffic
http://forums.winxpcentral.com/showthread.php?t=15411
ISPs Back After Network Outages
http://www.internetnews.com/infra/article.php/3558226
Level 3 and Cogent Reach Agreement on Peering
http://slashdot.org/articles/05/10/28/1723250.shtml?tid=230&tid=187&tid=95
Level 3, Cogent Agree on Traffic Deal
http://forums.winxpcentral.com/showthread.php?t=15499
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Mon, 07 Nov 2005 02:08:33 -0700
Anne & Lynn Wheeler writes:
Boyd, The Fighter Pilot Who Changed The Art Of War, by Robert Coram,
chpt. 19, Spook Base, pg. 266,
... In the Vietnam War that base was Nakhon Phanom Royal Thai AFB,
commonly known as NKP or, by the more irrerevernt, as Nakad Fanny.
Activities at NKP were so highly classified for the first three or
four years of its existance that it officially did not exist.
.. snip ..
ref:
http://www.garlic.com/~lynn/2005t.html#1 dangerous Hardware
http://www.garlic.com/~lynn/2005t.html#2 dangerous Hardware
later in the same chpt there is a reference to the generals sending
Boyd to NKP because they knew he was the only one with the guts to go
on record that the Mcnamara line didn't work and would shut it down.
there have also been references to Boyd would never make general since
that tended to require doing the politically correct thing ... and
Boyd would do the right thing, which can be a career killer in any
bureaucracy
misc. collected boyd postings
http://www.garlic.com/~lynn/subboyd.html#boyd
misc. pages mentioning boyd from around the web
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: phishing web sites using self-signed certs
Newsgroups: netscape.public.mozilla.crypto
Date: Mon, 07 Nov 2005 02:53:16 -0700
there are periodic comments that OCSP fixes the offline
characteristics of digital certificate credentials.
some recent postings related to the subject:
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#32 More Phishing scams, still no SSL being used
basically around the time we were involved with this small
client/server startup that wanted to do payments and had this
technology called SSL ...
http://www.garlic.com/~lynn/subpubkey.html#sslcert
some number of the PKI aficionados were claiming that credit card
transactions could be modernized by upgrading the transactions with
PKI (adding a digital certificate to every credit card transaction).
our somewhat off-hand response was that would involved setting the
credit card transactions back 20-30 years. in the 60s, credit card
transactions had offline credentials and revokation lists ... monthly
booklets that were sent out to every merchant once a month. as credit
cards became more widely adapted ... the booklets got larger (since
the number of cards in play was dramatically increasing), the number
sent out dramatically increased (since the number of merchants were
increasing), and they were being sent out more frequently (since the
absolute number of invalid cards was reaching a risk threshold faster
... even if the percentage remained constant). the approach was on its
way to having to distribute tens of millions of booklets with hundreds
of thousands of entries, every couple hrs.
the introduction of online, electronic in the 70s allowed that
untenable paradigm to be eliminated. in theory, the online, electronic
approach could have taken the OCSP approach, preserving the offline
credential paradigm and simply upgrading the revokation business
process with a indication of whether the offline credential was still
valid or not. however, they actually transitioned to a real online,
electronic paradigm ... but changing the paradigm from offline
credential to an online transaction that actually told the merchant
whether they would get paid or not.
so everytime somebody would make the claim that PKI would make credit
card transactions more modern, we would started the refrain that PKI
would represent a 20-30 year regression in the business process. when
OCSP was introduced (could somewhat be considered as the result of our
heckling the revokation list process), we also heckled OCSP as going
to all the trouble of doing an online transactions ... but didn't
actually leverage the possible business process benefits of doing
online transactions ... but continued to preserve the offline
credential paradigm of PKI.
part of the issue was confusing the digital signature technology with
the PKI business process. While digital signature technology for
transaction authentication would represent a modernization effort,
reverting to an offline credential paradigm represented by the offline
PKI model would be a 20-30 year regression in the business model and
doing real online transactions.
This was also during the period that you found PKI aficionados making
statements about modernization driver's licenses with the PKI model.
However, in this period ... most infrastructure operations that made
serious reference to a driver's license was also migrating to real
online transactions; aka going to all the trouble of having a real
online transaction wasn't going to be crippled by following the OCSP
model and just checking to see simply whether the credential was still
valid or not ... if you are going to the trouble of doing a real
online transaction ... lets make it worth the trouble and respond with
all facts that might be of interest related to the official doing
their business. While driver's licenses can still work as an offline
credential ... they are more & more being used as part of a real
online transactions ... as opposed to trivially checking as to whether
the offline credential is still valid or not.
the other story from the period of possibly some interest with regard
to modernizing online, real-time credit card by appending stale,
static digital certificates ... was that even relying-party-only
digital certificates from the period
http://www.garlic.com/~lynn/subpubkey.html#rpo
could represent a 4k-12k byte payload burden.
the nominal iso8583 payment transaction is on the order of 60-80
bytes. the appending of a redundant and superfluous, stale, static
digital certificate to a payment transaction represents an enormous
payload bloat on the order of two orders of magnitude ... serving no
useful purpose.
now in the x9 financial standards body, the x9a10 working group was
given the task of preserving the integrity of the financial
infrastructure for all retail payments. the result was x9.59 standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
which would just need the inclusion of a digital signature as part of
an iso8583 payment transactions w/o requiring that digital certificate
payload bloat also be included (since the consumer would already have
an established relationship with their financial institutions). this
also had the characteristic of being a simple authentication operation
(using digital signature technology) w/o trying to convert it into a
heavy-weight identification operation with inclusion of digital
certificates.
there was some activity in some of the financial standards body to do
compressed certificates (because of the enormous payload bloat that
PKI would cause to payment transaction infrastructure) ... even
the limited relying-party-only certificates ... where all personal
information had been moved out of the certificate itself
http://www.garlic.com/~lynn/subpubkey.html#rpo
as an alternative to doing x9.59 w/o certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
we pointed out that a highly effective mechanism for compression was
to eliminate fields known to be in possession of the relying-party.
for payment transactions, we could show that the relying-party would
have all possible digital certificate fields and therefor we could
compress the certificates to zero bytes. so instead of doing
certificate-less digital signature payment transactions, we could do
digital signature payment transactions with zero byte appended digital
certificates.
a few past posts mentioning the technique of compressing digital
certificates to zero bytes
http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
misc. past postings mentioning the enormous payload bloat represented
by appending digital certificates to payment transactions:
http://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP
http://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
http://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
http://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
http://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions
http://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
http://www.garlic.com/~lynn/2004g.html#5 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
http://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 2nd level install - duplicate volsers
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Mon, 07 Nov 2005 03:43:24 -0700
"Jeff Gribbin, EDS" writes:
David,
Not sure if this might be OT - you did specify, "VM Function" - but
there were various constraints regarding using non-relocate-0
minidisks (that is, a minidisk whose virtual cylinder zero doesn't
correspond to a real cylinder zero) for OS guests 'way back when.
As a youth I was taught that non-relocate-0 OS packs should have one
track VTOCs and should not have ISAM files on them. I think that
ISAM is now no more than a fond(?) memory for all except Hercules
hobbyists and I'm pretty sure that the combination of modern
hardware and software has lifted the one track VTOC constraint - but
they definitely existed as issues to consider back in '370 days.
Maybe this'll be enough to tempt Mr Wheeler out of his shell with some
definitive explanations regarding the practical constraints and the
architectural basis for them (along, with, no doubt, a few anecdotes for
us all to enjoy) :-)
some number of collected past posts mentioning dasd architecture,
vtocs, pds directories, multi-track searches ... including stories of
shooting major performance problem for large national retailer
... that was purely mvs and didn't really involve vm at all. there are
also a couple examples of mvs multi-track search (vtoc and pds
directory) penalty in shared dasd environment between mvs system and
vm system (in one specific case, production environment at sjr in
bldg. 28)
http://www.garlic.com/~lynn/subtopic.html#dasd
basically vtoc & pds directory were disk resource trade-off against
real memory resource from the early 60s. multi-track search would
consume enormous amounts of I/O (channel, controller, disk) resource
at the saving of having to consumer real-storage caching the
information. however, by at least the mid-70s (if not early 70s) ...
that trade-off was no longer valid ... and i/o resources were more
constrained than real storage sizes.
ISAM was another such trade-off. ISAM could create enormously complex,
self-modifying CCW programs ... where the structure of the information
was resident on disk ... and CCWs could read CCHHR from various
disk-based structures, which would then be used in later in the
channel program. the virtual memory model (not just a characteristic
of vm) simulating real i/o paradigm required pre-translating channel
programs before actual activation. in cp67, ccwtrans would create a
"shadow channel program" from the CCWs in the virtual address space
... prefetching & fixing required virtual pages into memory,
converting virtual addresses to real addresses, etc. the channel
program that was actually executed was the translated shadow CCWs, not
the CCWs from the virtual address space.
note that for original os/vs2 prototype ... I have some recollection
of being in POK machine room 3rd shift ... where Ludlow(?) was
cobbling together an MVT system with a little bit of glue that laid it
out in a 16mbyte virtual address space (and handled page fault
interrupt) and was hacking CCWTRANS (from cp67) into the MVT
supervisor to do the required channel program translation (on a
360/67).
if the self-modifying channel program i/o ... actually modified
subsequent CCWs ... all bets were off ... since the modifications
would be done against the CCWs in virtual memory ... not the shadow
CCWs. however, there was a limited subset of self-modifying channel
programs that only involved the CCHHR information. nominally, shadow
channel program also involved shadow CCHHR to handle the case of
relocated minidisk cylinders (start and also not going past the end).
there was a special case made for full pack minidisk where the start
and end were the same was the real disk ... and therefor the CC fields
didn't need twiddling ... and there was no need to enforce checking on
I/O extending past the end of the user's allocated minidisk.
note that vm as well as the other mainframe operating systems that
evolved from real-memory heritage all made special channel program
case for V=R ... where the original CCWs could be directly executed
w/o translating and execution of shadow CCWs (vm added the additional
requirement for disk i/o that it required full pack minidisk ... to
eliminate both the starting cylinder relocation as well as the ending
cylinder verification check).
vtocs (& pds directories) should not have been an issue ... since they
just did normal multi-track searches ... but stayed on cylinder
boundaries. they became an enormous performance issue ... but wouldn't
represent an integrity issue as long as minidisks allocation was
restricted to cylinder boundaries (there were some customer
modifications that allowed for minidisk allocation that weren't on
cylinder boundary and integral number of cylinders).
isam was an issue (for other than full-pack minidisk) because the
channel program could read CCHHR information that would be used in
subsequent part of the same channel program (and wouldn't have been
modified by the initial channel program translation).
misc. past postings about the transition from real memory constrained
configurations to i/o constrained configurations:
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
http://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
http://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
http://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
http://www.garlic.com/~lynn/98.html#46 The god old days(???)
http://www.garlic.com/~lynn/99.html#4 IBM S/360
http://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
http://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
http://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
http://www.garlic.com/~lynn/2002.html#5 index searching
http://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
http://www.garlic.com/~lynn/2002b.html#20 index searching
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
http://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 2nd level install - duplicate volsers
Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers
Date: Mon, 07 Nov 2005 05:35:18 -0700
ref:
http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers
for a little drift on the subject of changing from a real memory
constrained environment and the uptake of rdbms:
http://www.garlic.com/~lynn/2005s.html#9 Flat Query
http://www.garlic.com/~lynn/2005s.html#12 Flat Query
http://www.garlic.com/~lynn/2005s.html#3 Flat Query
http://www.garlic.com/~lynn/2005s.html#4 Flat Query
http://www.garlic.com/~lynn/2005s.html#6 Flat Query
http://www.garlic.com/~lynn/2005s.html#8 Flat Query
now the original relational/sql implementation was done on vm370
http://www.garlic.com/~lynn/subtopic.html#systemr
and then there was tech transfer from sjr to endicott for sql/ds.
for a little more topic drift ... when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp
I've commented before that two of the people in the following
meeting
http://www.garlic.com/~lynn/95.html#13
later showed up in a small client/server startup responsible
for something called commerce server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
however, one of the other people in that same meeting had commented
that he had done most of the initial work for the tech transfer of
sql/ds from endicott back to stl for db2 (even tho bldg. 28 and
bldg. 90 were only ten miles apart).
another topic drift is the overhead of doing the channel program
translation to produce the shadow channel program. i've posted before
about doing a lot of early performance work on enhancing (in large
part mft & mft) performance on cp67 ... misc. past posts
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
after the above mentioned presentation at the '68 boston share
meeting, i had also done some amount of path length special case
optimization for cms filesystem disk i/o. however, i got strongly
admonished by adair that I had violated virtual machine architecture
and it needed to be morphed (using diagnose instruction) so as
to preserve achitecture purity. misc. past posts referencing converting
the cms filesystem disk i/o optimization to diagnose instruction:
http://www.garlic.com/~lynn/2003.html#60 MIDAS
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003k.html#7 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003p.html#9 virtual-machine theory
http://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE
http://www.garlic.com/~lynn/2005i.html#49 Where should the type information be?
http://www.garlic.com/~lynn/2005j.html#45 Where should the type information be?
http://www.garlic.com/~lynn/2005j.html#47 Where should the type information be?
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
somewhat in response, one of the things that I did in the early 70s at
the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
for cp67 cms was implement page mapped interface for cms filesystem
support ... which eliminated the whole paradigm of having to emulate
real i/o (and all the associated overhead gorp, at least for disks) in
a virtual memory environment
http://www.garlic.com/~lynn/subtopic.html#mmap
this was later ported to vm370 cms and deployed succesfully on
some number of internal systems.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: phishing web sites using self-signed certs
Newsgroups: netscape.public.mozilla.crypto
Date: Mon, 07 Nov 2005 06:45:43 -0700
Anne & Lynn Wheeler writes:
some number of the PKI aficionados were claiming that credit card
transactions could be modernized by upgrading the transactions with
PKI (adding a digital certificate to every credit card transaction).
ref:
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
the other thing going on in this period ... in addition to the
flailing around attempting to do something about all our harping about
payment card industry had proven something like 30 yrs earlier that
CRLs didn't scale (although most of the effort seemed misdirected in
attempting to still preserve the PKI offline credential paradigm w/o
having to actually move into real modern online transactions) ....
was the EU data privacy directive standard (EU-DPD).
i was one of the co-authors of the more recent x9 financial industry
privacy standard and took into account some amount of the EU-DPD.
some minor reference can be seen here with respect to the privacy
merged taxonomy and glossary (in support of the x9.99 work)
http://www.garlic.com/~lynn/index.html#glosnote
in any case, there were various statements that electronic retail
payments needed to be anonomous as cash. one practical implication was
that names would have to come off the payment cards and identification
procedures be eliminated from point-of-sale operation (hopefully
substituting stronger forms of authentication). applying that to
e-commerce implied that you had to avoid getting bollixed up with x.509
identity certificates and continually digging yourself into the hole
of confusing authentication and identification. this frequent
confusing of authentication and identification was constantly
compromising the ability to achieve any reasonable privacy objectives.
a few past posts on eu-dpd and retail payments w/o identification
http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm17.htm#21 Identity (was PKI International Consortium)
http://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Tue, 08 Nov 2005 07:16:01 -0700
"mensanator@aol.com" writes:
No wonder we lost.
Boyd has story about evaluating the air force air-to-air missile
and then its subsequent use in the conflict and the issue
of budget share.
http://www.garlic.com/~lynn/99.html#120 atomic History
collected post postings
http://www.garlic.com/~lynn/subboyd.html#boyd
and various Boyd references from around the web
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Passwords
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 08 Nov 2005 07:23:00 -0700
Phil Smith III writes:
Back at UofW -- this would have been SP3 or so -- I remember a
student (not me) being surprised to learn that his password, which
he thought was "I love KM" was really just "I". ISTR we fixed our
password processing to notice such things and reject them when this
was discovered, to avoid such easy passwords...
an old 4/1 corporate directive on passwords
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#53 April Fools Day
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Tue, 08 Nov 2005 12:35:33 -0700
"mensanator@aol.com" writes:
No wonder we're not winning now.
some number of people supposedly have been quoted that the biggest
problem going into the current conflict is that Boyd is no longer with
us (also attributing the battle plan in the previous conflict in the
region to Boyd).
look at some of the references in the following collection of
URLs (from around the web) mentioning Boyd beating the generals
http://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Tue, 08 Nov 2005 16:37:42 -0700
Boyd had another story about doing the initial design work on the
F16.this was when he was head of light-weight fighter plane design at
the pentagon ... the various Boyd books talk about him drastically
reducing the weight on the F15.
however M/D suspected that he was also doing design work on the F16
... and there was an effort to stop him, it involved getting him
arrested for stealing large amount of gov. resources .... since he
had to be using large amounts of (unauthorized) gov. supercomputers
for the work he was doing on the f16 design. he had a story about
extensive investigation into records of gov. supercomputer time to get
him on theft of gov. resources. they never did find out how he was
doing it or what supercomputers he was using.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Thu, 10 Nov 2005 13:34:09 -0700
D.J. writes:
U.S. Vice Presidents don't appoint Generals. Even the President
doesn't appoint them. The US Army promotes generals to that rank.
senate does confirmation of general and flag officers
http://www.npc.navy.mil/Boards/GeneralBoardInfo/Promotion+Board+Approval+Process.htm
from above ...
When a promotion selection board adjourns, the results from the board
are included in a package called the Board Record of Proceedings (or
ROP for short). This package is then sent up through an approval
process. The final approval authority varies depending on which board
it is. All active duty LCDR through CAPT boards must ultimately be
approved and 'confirmed' by the Senate Armed Services Committee (SASC
for short).
... snip ...
I think that there has been some amount in the press about
cheney/rumsfeld trying to stress special forces, quick reaction, etc
... at the expense of the big set pieces (which puts them at odds with
tradional army , industrial organizations, congressional districts,
etc.
Rumsfeld OKs expansion of commando forces
http://seattlepi.nwsource.com/national/1152AP_Special_Operations_Marines.html
Donald Rumsfeld
http://www.rotten.com/library/bio/usa/donald-rumsfeld/
Rumsfeld's New Man, The latest move to radically remake the Army
http://www.slate.com/id/2084212/
Rummy's New War, The secretary of defense invades the Army.
http://www.slate.com/id/2082932/
from above:
As Donald Rumsfeld gears up for his war on the U.S. Army, the Army is
preparing to fight back. I noted here two weeks ago Rumsfeld's opening
May Day fusillade, in which he let it be known that his new secretary
of the Army would be James Roche.
... snip ...
Secretary of Enron Exits
http://www.thenation.com/blogs/thebeat?mm=4&yr=2003
Blasting the Crusader
http://www.cnn.com/ALLPOLITICS/time/2001/01/15/crusader.html
The Big Guns; The White House wants to kill the Army's Crusader
artillery system.
http://www.capitaleye.org/inside.asp?ID=18
from above:
It's an annual rite of passage that has often prompted military brass
to butt heads with members of Congress and the administration and, in
some cases, with each other, as different branches of the nation's
defense fight to preserve budget dollars that in turn pay for
big-ticket weapons.
... snip ...
SELECTED ACQUISITION REPORT
http://www.d-n-i.net/fcs/comments/c448.htm
from above:
The Army's Crusader self propelled howitzer is in play. Secretary of
Defense Donald Rumsfeld told the Army to cancel it, but members of
Congress moved quickly to save it by inserting protective language in
the draft defense authorization legislation. The stage is now set for
a classic Versailles food fight
... snip ...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Best practice for TOD clock
Newsgroups: bit.listserv.ibm-main
Date: 10 Nov 2005 06:46:36 -0800
Charles Mills wrote:
I'm engaged in an internal dispute about best practice for the TOD
clock: should it be set to universal time (or whatever GMT is now
called) with the appropriate local offset, or alternatively, to local
time (with an offset of zero)?
The argument for local time I guess is that it's more simple and
convenient -- why complicate life? You don't set your clocks at home
to GMT and remember what the offset is to local time.
I'm on the other side of the argument. My gut feeling is that GMT is
what the platform designers had in mind -- but as I have said before
in this forum, I have no credentials as an ops guy, and I am getting
nowhere with this argument.
Can anyone venture a concise statement on why it is best practice to
do it one way or the other?
One specific question: which time goes into a DB2 program bind
timestamp? If one is compiling on one machine and executing on
another, and the machines are in two different local time zones, would
setting the hardware clock on both machines to GMT make the error
essages go away?
there was a tod timer task force in the early 70s (that ran on &
off for period of something like 3 months). the two big issues i
remember being discussed was what was the first day of the century
(and how to explain it to people) and what to do about leap seconds.
one of the problems was that MVT(?) started shipping with the epoch at
1970 instead of start of the century (this was initial 370s which were
announced and shipped with TOD, a couple new instructions, but virtual
memory hadn't been announced yet). gmt was taken as a given.
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Thu, 10 Nov 2005 19:55:35 -0700
"Rostyslaw J. Lewyckyj" writes:
A misunderstanding! I do not mean to say that Chaney promotes people
to general rank. I mean that he gets to appoint the generals of his
choosing to various positions and duties. Also, he gets to decide
which groups within the military are favoured etc. i.e. who gets
sent to seek glory for the US in Iraq and who gets sent to THule Air
Base in Greenland.
this refers to 1983 congressional hearing
http://www.pbs.org/now/politics/spinney.html
for various reasons the congressional hearing was manuvered to friday
afternoon ... in a small hearing room (in the hopes that it never make
the press ... there was a much more famous hearing that was held in
the same room). ploy wasn't succesful, monday morning, time had 18pg
article on the testimony.
there is story that secdef suspected who had engineered it and tried
to have boyd banned from ever entering the pentagon as well as
reassigned to a post in alaska (neither were succesful).
there was a joke that after the testimony, the pentagon created a new
unclassified document category ... and started stamping such documents
"NO SPIN" (not to be made available to chuck).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Newsgroups: alt.folklore.computers
From: lynn@garlic.com
Date: 11 Nov 2005 20:44:07 -0800
Local: Fri, Nov 11 2005 11:44 pm
Subject: Re: winscape?
Greg Menke wrote:
I'm pretty happy with 2.6 as well. I haven't tried raid stuff on it
yet since our server investment is on Solaris. OTOH when I scrounge
equipment- disk arrays, etc.. I usually work them up with a Linux
box. My own workstation is a tricked out G4 w/ Gentoo on
it... pretty nice machine too after a few fixes. Linux's
portability to different architectures just keeps getting better.
i've got a dell poweredge 2400 (gbyte of memory, two 1ghz processors,
raid controller, six scsi drives) that originally shipped with redhat
7.0. i updated with various redhat releases and then tracked fedora.
after fc4 kernel 1276 .... all the smp kernels started sporadically
hanging (sometimes during boot, but usually within no more than hr or
two) .... although uniprocessor kernel would work ok. move to 2.6.14
seems to improved things a little ... it may be a day or two before
smp kernel hangs and has to reset/rebooted. it seems to be some
interaction with scsi raid controller ... processes that are in memory
and doing pure ip operation will continue to run for some time after
other processes that have accessed disk have hung. it appears that
once something has hung accessing disk ... then anything else
attempting to access disk will also hang. as noted, uniprocessor
kernel appears to not have from the problem
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Various kinds of System reloads
Newsgroups: alt.folklore.computers
Date: Wed, 16 Nov 2005 17:16:40 -0700
Peter Flass writes:
An OS SYSGEN was quite a bit more than a monitor build. In "Stage
1" the user selected the options for the system, not only the OS
nucleus (kernel in today's terms, probably about the same as your
monitor) but also the other software to be installed: Assembler,
compilers, Link Editor, JES etc., and the I/O for the system. I
think I mentioned that Stage 1 punched out a large JCL deck.
Someone with a better memory than mine can comment, but I think it
was about a tray of cards.
Stage 2 built a complete set of tailored libraries for the system,
assembling and linking, or copying files to the target libraries.
The nucleus was only a small part of it.
at least in the release 9.5-18 time-frame ... stage2 was more than a
box (2000) but would fit in a tray (card trays held more than a box,
but less than two boxes of cards, 3000?).
typical customer operation was to code up the stage1 sysgen deck
... maybe 60-100 cards. these were macro statements that then got
"assembled". the macros ... instead of generating real machine
language ... were a bunch of "punch" statements ... which produced the
stage2 cards.
stage1 tended to be relatively quick (modulo the actual punching of
the cards) ... but stage2 could take an 8hr shift to run (or
more). stage2 was a single "job" with possibly 100 "EXEC" (job) steps
... composed mostly of iehmove/iebcopy commands ... but also some
linkedit and other misc. stuff.
starting with release 11, i would take the stage2 sysgen ... generate
"JOB" cards for each of the steps (in part so i could run it in a
production system ... rather than with the starter system). I also
reodered various steps as well as iehmove/iebcopy statements ... as a
means of careful placement/ordering of files and data on disk ... to
improve disk arm motion.
I gave talks at share about both the work on optimal disk arm motion
as well as doing sysgen in a production system. after i started also
doing work on cp67 ... i talked about both the work on os/360, the
work on cp67, as well as running os/360 under cp67 in a virtual
machine.
references to talk i gave at aug. '68 share meeting in boston
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
http://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
http://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
http://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
http://www.garlic.com/~lynn/2001f.html#26 Price of core memory
http://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
http://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
http://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
http://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 20 Nov 2005 07:51:56 -0700
Bill Pechter <pechter-at-gmail-dot-com> writes:
Why -- bad marketing and Unix Wars politics.
Ultrix-> OSF/1->Digital Unix->Tru64.
Ultrix ran on VAX and MIPS and was to be replaced by OSF/1 on Alpha and
MIPS -- but the MIPS OSF/1 kind of was dropped (DEComitted) I believe
was the term back in DEC Professional and on the NET.
OSF/1 was a NON-AT&T Unix done from Posix specs as a response to the Sun
AT&T alliance (HP IIRC was in both camps and had status in both groups).
OSF/1 became Digital Unix (marketing and DEC got SVID certification if I
remember correctly so they could use the Unix name...). This begame
Tru64 at some point.
These prodects were really not competing against each other and DEC
should've had one name and plan... but they were DEC. 8-)
i believe some amount of hp's osf/1 involvement was because of apollo
.. which HP had purchased. part of osf involved looking at a non-sun
distributed environment (aka nfs alternative). osf meetings involved
discussions around apollo's technology, cmu's afs, ucla's locus, ibm's
dfs, etc. there were also discussions on mit's (project athena)
kerberos.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: So what's null then if it's not nothing?
Newsgroups: comp.databases.theory
Date: Sun, 20 Nov 2005 08:00:25 -0700
"JOG" writes:
Even hearing the word "null" is starting to sound embarrassing now,
never mind postulating a definition for it. Surely the field has
reached the point where we all know there are better ways of handling
missing data, but given the tech we have when we get up tomorrow, and
the job at hand, we have to make do. What more is there to say.
old post referring to even older article on nulls and 3-value
logic
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 20 Nov 2005 10:57:35 -0700
Bill Pechter <pechter-at-gmail-dot-com> writes:
The only IBM PC stuff as well built as the DEC stuff was the rock
solid PS/2 line... The PS/2 85-95 stuff reminded me of the MicroVax.
Solid. Reliability beyond most of the competition -- but expensive.
i used to post qty-1 prices from the sunday sjmn to internal newsgroup
... as counter to some business analysis about the direction of pc
prices ... a few previous postings here
http://www.garlic.com/~lynn/2001n.html#79 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2001n.html#80 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002k.html#56 Moore law
http://www.garlic.com/~lynn/2004b.html#1 The BASIC Variations
at one pt. boca hired dataquest (since bought by gartner) to do a
study of what was going to happen to the pc business over the next
5-10 yrs. the research contract called for a couple hr face-to-face
roundtable with 10-12 silicon valley experts (video taped and
transcribed). i was approached by dataquest to be an "anonymous"
person at the roundtable ... which i cleared with my immediate
management. i never found out whether boca ever realized that they had
an employee helping feed the dataquest study.
slightly related postings on PCs market and terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation
which then drifts into the subject of SAA, some collected posttings
on 3-tier architecture and/or SAA
http://www.garlic.com/~lynn/subnetwork.html#3tier
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 20 Nov 2005 14:31:45 -0700
Bill Pechter <pechter-at-gmail-dot-com> writes:
Actually the Kerberos authentication stuff is pretty widespread and
built into the current Windows server stuff...
Kerberos hasn't been replaced by sftp. There's also a lot of other
authentication systems like the keyfobs sold from RSA to do dual
factor authentication... Opie and stuff are also slick.
kerberos started with userid/password authentication as an
infrastructure function ... and then handed out tokens/credentials
regarding what authentication had been done. some number of
applications that previously required their own user/password ... got
kerberized to honor kerberos tokens.
the original pk-init draft for kerberos added an option where
public key could be registered in lieu of password and simple
digital signature authentication be performed
http://www.garlic.com/~lynn/subpubkey.html#kerberos
w/o requiring PKIs, digital certificates, etc.
http://www.garlic.com/~lynn/subpubkey.html#certless
somebody (periodically sends email apoligzing for having done it), was
responsible for getting the kerberos pk-init draft upgraded to also
allow PKI operation and digital certificate operation.
the theoritical PKI design point is that somebody can submit a digital
signature for authentication with an appended digital certificate for
identification ... and the digital certificate would also specify the
privileges granted the entity ... aka w/o requiring the entity to have
been separately registered to any system (i.e. a perfect stranger,
having presented a valid digital certificate would be allowed access
to your system w/o any additionly processes).
what happens tho, is that typical systems still require some sort of
independent registration of valid entities .... in which case, it is
perfectly acceptable to include the entity's public key registration
as part of the process ... making any appended digital certificate
redundant and superfluous (as well as the PKI and associated
certification process also redundant and superfluous).
fundamentally, the PKI design point was for first time communication
between complete stangers ... that both parties then could rely on a
trusted third party to provide introduction (aka the letters of
credit/introduction from the sailing ship days). one of the reasons
that for PKI being redundant and superfluous in environments which
have pre-existing relationships, is that such pre-existing relationships
negate the original design point for PKIs.
in any case, there have been a number of processes for doing the
initial kerberos authentication as upgrades to the origina;
userid/password paradigm ... certificate-less digital signature,
certificate-based digital signature, hardware token digital signature,
other kinds of hardware token technology.
from 3-factor authentication
http://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
... the kerberos original userid/password is a something you know
authentication. the hardware token based operations typically are
technologies that attempt to assert the person is in possession of a
unique something you have hardware token. many of the digital
signature based operations are either directly something you have
authentication (i.e. business process that embodies a unique private
key in a hardware token) ... or a simulated something you have
authentication (i.e. business process that attempts to emulate in
software a hardware container for unique private key).
many of the userid/password operations are also shared-secret
http://www.garlic.com/~lynn/subintegrity.html#secret
where the something you know password is registered at the
authenticating entity.
hardware tokens can be used to implement two-factor authentication,
where the hardware token is certified to required a pin/password for
correct operation ... aka the relying party infers from the operation
of the hardware token that the correct pin/password was entered
... w/o the relying party needing to know what the pin/password is.
one might claim that one of the reasons for ssh (sftp, scp, etc)
uptake ... is that it continued to support the trivial certificate-less
public key registration and digital signature authentication ... while
kerberos pk-init got all bollixed up requiring PKIs, digital
certificates, etc ... as part their basic (redundant and superfluous)
operation ... over and above also typically requiring the user to be
registered.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: So what's null then if it's not nothing?
Newsgroups: comp.databases.theory
Date: Mon, 21 Nov 2005 10:41:25 -0700
ref
http://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
aka ... one of the big hang ups from an operational standpoint
... isn't so much the nulls themselves ... it is that the results of
3-value logic query operations frequently aren't what people would
have expected ... aka not being able to predict how a tool will behave
frequently limits the usefullness of the tool.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Mon, 21 Nov 2005 10:53:52 -0700
greymaus writes:
Boca hired consultants, which in turn hired boca employees
(anonymously) to give boca advice?...
ref:
http://www.garlic.com/~lynn/2005t.html#21 What ever happened to Tandem and NonStop OS ?
different business unit ... there was more than just boca in the
company ... it was a world-wide operation with hundreds of thousands
of employees and large number of different products (not just PCs).
for instance ... one of my hobbies was building hone (for nearly
15 years) ... which was the online world-wide marketing, sales
and field support service ... and had support for all sorts of
products
http://www.garlic.com/~lynn/subtopic.html#hone
minor topic drift about even conflict between boca and other
business units
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
http://www.garlic.com/~lynn/2002g.html#9 IBM MIcrochannel??
http://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
http://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
http://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
http://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005q.html#21 Ethernet, Aloha and CSMA/CD -
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
there was also the SAA issue which was somewhat trying to contain
PC use to terminal emulation
http://www.garlic.com/~lynn/subtopic.html#emulation
which we really got in conflict with when we starting pitching
our 3-tier architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why does my address appear as part of my name?
Newsgroups: alt.folklore.computers
Date: Mon, 21 Nov 2005 11:52:39 -0700
rpl writes:
In the hardware sense, if you have a device which driver includes a
<something> wrapper, it is somewhat wasteful since the device's
language has to be translated.
Putting something in HTML when plaintext will do is a waste.
one of the original gml issues (precursor to sgml, html, xml, etc)
http://www.garlic.com/~lynn/subtopic.html#sgml
was that tagging the data might provide long-term benefits ... long
past the immediate use for the current operation.
slightly analogous to dbms technology ... enabling multiple different
application/operations use of common repository; in the past,
frequently difficult to justify for single point solutions ... matter
of trade-offs.
http://www.garlic.com/~lynn/subtopic.html#systemr
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Dangerous Hardware
Newsgroups: alt.folklore.computers
Date: Tue, 22 Nov 2005 15:29:24 -0700
here is a different thread drift related to boyd
The Enterprise Personality Profile; Taking this Gartner assessment is
one way to determine your corporate weaknesses
http://www.line56.com/articles/default.asp?articleID=7102&TopicID=7
from above ...
Research group Gartner has expanded its existing enterprise
personality profile (EPP), making several changes to the underlying
methodology in a quest to steer away from the qualitative and towards
the quantitative.
... snip ...
and something from slightly earlier
Dashboard Success; Getting a view of business events as, or shortly
after, they happen is a big part of how you can win competitive
advantage; a dashboard primer
http://www.line56.com/articles/default.asp?articleID=6344&TopicID=4
and of course:
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2
and a total off-the-wall reference ... the original Basel-II draft
attempted to also add a section for qualitative as part of measuring
risk adjusted capital for international financial institutions.
http://www.bis.org/publ/bcbs118.htm
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA SecurID product
Newsgroups: bit.listserv.vmesa-l
Date: Wed, 23 Nov 2005 16:57:50 -0700
Thomas Kern writes:
Management is looking at having ALL system administrators use 2 part
authentication. One product that is prominent in their discussions
is RSA's SecurID. Their website lists components for Windows,
Solaris, AIX and Intel-based Linux. My boss is going to ask them if
they support systems on IBM zSeries platforms.
two-factor authentication is from the 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
• something you have
• something you know
• something you are
where a hardware token is something you have authentication.
typically in electronic authentication, a token will generate and
transmit some value that is considered as only having originated from
that specific token (the receiver or relying party can infer as having
originated from a unique token).
something you know authentication can be done as either a
traditional shared-secret aka pin or password
http://www.garlic.com/~lynn/subintegrity.html#secret
in such a situation, the shared-secret is transmitted along with the
token's information.
it is also possible to have a secret-based something you know (as
opposed to shared-secret) where the hardware token is certified as
requiring the correct pin/password for correct operation. the receiver
(or relying party) receives the hardware token validation and based on
having certified the token as requiring the correct pin/password (for
correct operation), can infer two-factor authentication (as opposed to
actually having two independent, separate factors).
in a hardware token scenarion, the use of two-factors is typically
using the something you know authentication as a countermeasure to a
lost/stolen token threat/vulnerability.
similarly you can have something you are authentication involving
some biometric value (frequently in lieu of something you know
authentication). similarly to pin/passwords, biometrics can be
implemented as either shared-secret (aka the biometric is stored at
some central repository and matched) or as "secret" (the biometric
matching is part of the certified hardware token operation).
again, when biometrics is used in conjunction with a hardware token
for two-factor authentication, the biometric is a countermeasure for
lost/stolen token threat/vulnerability.
one of the issues with biometric shared-secret implementions (as
opposed to a biometric secret implementation) is security breaches
associated with the repository, in the case of pin/password
shared-secret repository compromise, it is possible to replace the
compromised pin/passwords. the issue with compromise of biometric
shared-secrets is being able to issue replacements.
disclosure .... we have a bunch of patents (granted and pending) on
various aspects of authentication operations (and there is a product
that incorporates some of the features):
http://www.garlic.com/~lynn/x959.html#aads
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA SecurID product
Newsgroups: bit.listserv.vmesa-l
Date: Thu, 24 Nov 2005 10:25:24 -0700
ref:
http://www.garlic.com/~lynn/2005t.html#27 RSA SecurID product
part of the issue with authentication techniques is there pervasive
use in electronic environments.
one of the issues with something you know shared-secrets, is that a
unique shared-secret was required for every different security domain
... as a countermeasure to entities in one security domain
compromising a different security domain (aka the students hired for a
local neighborhood garage ISP accessing the online bank accounts of
ISP customers).
as electronic environments proliferated ... the number of different
security domains proliferated and some people now have requirement for
scores of shared-secret passwords. the early guidelines also were that
shared-secret passwords be impossible to quess and memorize and also
changed frequently. an old april 1st password corporate directive from
the early 80s
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#53 April Fools Day
the inability of humans to keep track of scores of impossible to guess
and memorize shared-secret passwords that change frequently led them
to recording passwords in various ways ... which opens up new
vulnerabilities (the combination of password proliferation and
difficult, "secure" passwords results in the creation of new
vulnerabilities).
another way of looking at hardware tokens ... is that they are a
physical object that acts as a countermeasure to simply guessing (or
capturing recorded) passwords (nominally you have to capture the
physical object).
however, some of the token technology in the past just produced static
data as proof of their possession. however, static-data possession
proof is vulnerability to evesdropping/skimming. furthermore, in
two-factor authentication, the basic premise is that the different
factors have unique and different vulnerabilities. unfornately all
static-data authentication technologies may have common
evesdropping/skimming vulnerabilities, aka a token that generates
static-data as proof of its possession and the entering of a
shared-secret password might have a common evesdropping/skimming
vulnerability (an attacker inserts a skimmer and captures both token
static data as well as an entered pin/password). even shared-secret
biometrics may be vulnerability to evesdropping/skimming threat.
the following is discussion of form of evesdropping/skimming attack on
one-time-password standard specificed by internet standard RFC 2289
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
which includes discussion of a form of man-in-the-middle attacks.
misc. collected postings on mitm-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm
part of hardware token authentication should be technology that
generates unique values for each authentication operation .... as
countermeasure to evesdropping/skimming attacks.
and as previously noted, hardware token technology may also be used to
move from shared-secret paradigm to a secret paradigm ... where the
person effectively authenticates themselves to the token (pin/password
or biometrics) and the token is certified to only operate properly
when provided with the proper authentication. The relying party when
presented with token authentication, then may assume two-factor
authentication based on previously obtaining details of the token
certification.
if the token authentication technology for generating unique
authentication is sufficiently robust ... then there is the
possibility that you could actually have a single token (aka
person-centric) that is acceptable for multi-factor authentication in
multiple different security domains (since there is no knowledge in
the possession of one security domain that could be used for attacking
another security domain).
misc. past postings on the subject of person-centric vis-a-vis
institutional-centric authentication technologies
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2005m.html#37 public key authentication
http://www.garlic.com/~lynn/2005p.html#6 Innovative password security
http://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD to leave x86 behind?
Newsgroups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch
Date: Thu, 24 Nov 2005 11:26:14 -0700
"Dean Kent" writes:
Unfortunately, that doesn't explain why some companies have recently
moved to mainframe solutions, and why others came back after
attempting to use other platforms - and not to run 'legacy'
applications. In 2003, IBM mainframe revenues increased 33% over
2002. In 2004 they increased 15% over 2003. They have decreased
for the first three quarters of 2005, but that may be at least
partially due to the anticipation of the z9, released at the end of
July this year. A similar trend occured just before the release of
the z990, which was introduced in 2003. It is also noteworthy that
while revenues for Q3 2005 were down 4% from the previous quarter,
the 'compute power' (MIPS) shipped increased by 18%, so the 'cost
per MIP' is apparently dropping due to competition from other
platforms.
there were several mainframe issues from the 80s.
on the customer side ... mainframe datacenters were frequently
considered a cost-center ... and many organizations didn't understand
how to value/justify such (frequently) single item, large budget
cost-centers. moving away from mainframe datacenters tended to
disguise and obfuscate computational budgets in individual
departments.
on the vendor side, large mainframes had product cycles similar to the
american automobile industry ... one the order of 7-8 years (both
industries would sometimes disguised the fact by running parallel
efforts offset by 3-4 years). as the rate of technology change
increased, having product design cycles that took nearly a decade came
under extreme pressure (I remember attending some of the automobile
industry meetings where they discussed the problems with 7-8 year
design cycles ... and some of the hi-tech vendor "advisors" were from
organizations that still had the identical problem).
the upside for mainframes is that they have long history evolving as a
large shared resource ... which includes recognition of the fact that
multiple competing entities may be sharing the same resource. since
the impact of single outages is much more wide-spread with large
shared resource ... there has been a much larger history of focusing
on RAS (reliability, availability, serviceability). in addition, the
aspect that there may be multiple competing entities ... as a much
longer history and resources given to isolation and protection
mechanisms.
collected past posts on time-sharing support from the 60s & early 70s
needing ras, high-integrity and isolation designed in from the ground
up.
http://www.garlic.com/~lynn/subtopic.html#timeshare
one of the issues with large shared resource was the transition for
many into world-wide 7x24 operation staring in the mid-70s ... and
there no longer being any really convenient time to take the machines
down for any kind of service.
in contrast, some of the mainframe alternative platforms have their
fundamental design originating from a product that sits on the kitchen
table, is totally unconnected, and allows games to take over the whole
machine. there is extreme product pressure to take such a product,
preserve its original market niche and at the same time use the same
product in a widely-connected environment that has known competitive
and adversarial forces.
furthermore, attempting to disguise the (former datacenter) capital,
operational, maintenance, and serviceability budgets by shifting them
to individual departments or to the individuals themselves ... has
been shown to have (and sometimes caused) numerous infrastructure
problems (aka requiring inexperienced users to perform their own
system service and maintenance as well as the large proliferation in
the number of items requiring frequent service and maintenance).
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: AMD to leave x86 behind?
Newsgroups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel,comp.arch,alt.folklore.computers
Date: Thu, 24 Nov 2005 15:47:51 -0700
ref:
http://www.garlic.com/~lynn/2005t.html#29 AMD to leave x86 behind
also in play in the late 80s was the whole installed terminal emulation
product base:
http://www.garlic.com/~lynn/subnetwork.html#emulation
by the mid-80s, there was a big uptake in pcs in the terminal
emulation market. for about the same price as an existing mainframe
terminal, it was possible to replace it with a pc that had effectively
the same desk footprint, the same cost, and could not only perform the
existing mainframe terminal functions but also could provide some
local personal processing.
as you moved into the late 80s, it was turning out that the mainframe
RAS culture had frequently created an extremely inflexible and
slow-to-change/adapt mainframe service environment. as a result there
was some big increase in new personal business applications that could
be used at the desktop (which might take years to be deployed from the
datacenter). as this application segment evolved ... they also had a
bigger and bigger appetite for cororate data (stored back in the
datacenter) ... and were rapidly outgrowing the data feed capability
provided by terminal emulation paradigm.
as a result, there was a big upswing in the hard disk requirements at
the desk. there was quite a bit of customer turmoil ... frequently the
data represented the jewels of the corporation and having that data
migrated out of the high-RAS, disaster/recovery, etc datacenter to
people's desktops could create enormous corporate business risk
.... which was a trade-off against having new and more valuable
business applications.
the mainframe disk division created and tried to announce some number
of new products that would provide desktops with nearly local disk
performance access to datacenter resident data. this put the mainframe
disk division in direct conflict with mainframe communcation division
which now had an enormous install base of terminal emulation
products. the communication division was constantly fighting to have
such new products killed ... viewing them as a threat to their
terminal emulation market.
it was during this period that the communication division floated the
SAA strategy .... which, in many respects, was an attempt to try and
cram the client/server genie back into the bottle. the discored
between the disk division and the communication division got so
bad. that one year, at the annual, world-wide, internal communication
division conference, a senior person from the disk division (as
opening to his talk on distributed data access) began with a quote
about the head of the mainframe communication division was going to be
directly responsible for the death of the mainframe disk division; aka
that the migration of some number of applications to the destops were
inevitable, but it was still possible to provide datacenter data
access (sort of early day nas/san technology) for those appolications;
if only things could move beyond the severe limitations imposed by
terminal emulation paradigm (the alternative which was in play, was
the wholesale migration of corporate data out of the datacenter to
desktop machines).
it was also during this period that we had created 3-tier architecture
and were out doing some number of customer executive presentations.
http://www.garlic.com/~lynn/subnetwork.html#3tier
this put us on the receiving end of the wrath from forces associated
with SAA and preserving the terminal emulation paradigm.
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Looking for Information on password systems
Newsgroups: comp.security.unix
Date: Thu, 24 Nov 2005 16:56:10 -0700
bk.paradox writes:
Ok I had an idea, no idea if it exists or not.
But Would it be possible to have a device with a microcontroller and
lcd which displays a constantly changing password (changes every min or
w/e) and the computer also changes based on an algorithim and time as a
random seed or w/e..
So the two devices need to be synced obviously..
Basically I want the password to change every say for example 5 mins..
in unix the password changes every 5 mins and on my device it changes
every 5 mins and displays.. so if sum1 gets the password file they have
5 mins to use it Which seems highly unlikely..
not exactly time-change ... but use-change ... is one-time-password
(otp) that changes on every use; internet standard RFC 2289
past thread discussing RFC 2289:
http://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
http://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
more recent related thread with some subject drift:
http://www.garlic.com/~lynn/2005t.html#27 RSA SecurID product
http://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA SecurID product
Newsgroups: bit.listserv.vmesa-l
Date: Sun, 27 Nov 2005 03:54:46 -0700
Alan Altmark wrote:
RSA SecurID is normally integrated into the network access controls. That
is, authentication and host access authorization decisions are made at the
[VPN] network boundary (a la firewall), not on each host.
That said, I have heard other requests for two-part authentication,
typically requiring X.509 user certificates for SSL/TLS, plus a
userid/password at the target service.
the technology is asymmetric key cryptography, i.e. what one key
encodes, the other key decodes (as opposed to symmetric key cryptography
which uses the same key for both encoding & decoding).
a business process is public key ... where one key is designated as
public and made readily available, the other key is designated as
private, kept confidential and never disclosed.
a business process is digital signature ... where the hash of a
document/message is calculated, and a private key encodes the hash.
the sender transmits the document/message along with the digital
signature. the recipient recalculates the hash on the
document/message, decodes the digital signature with the appropriate
public key and compares the two hashes. if they are the same, then the
recipient can assume:
1) the message/document hasn't been modified since digital signature was
calculated
2) something you have authentication, aka the sender has access to and
use of the corresponding private key.
there was a business process developed called PKI and digital
certificates ... to handle the situation corresponding to letters of
credit/introduction from the sailing ship days for first-time
communication between strangers. in the early 90s, x.509 identity
certificates were formulated and proposals that x.509 identity
certificates should be attached to every digital signature .... in
order to turn EVERY (even the most light weight) authentication
operation into heavy weight identification operations.
Note that user certificates aren't needed for SSL/TLS. Server
certificates are used for SSL/TLS ... as part of key exchange for
encrypted communication (separate from authentication) as a
countermeausre to evesdropping and snooping (i.e. harvesting user
confidential information like passwords). misc. collected posts on ssl
server certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
one of the issues from the early 90s with x.509 identity certificates
was that PKI operations didn't necessarily know all possible
identification information that recipients (relying partys) might be
interested in ... so there was some directly to grossly overload the
certificates with enormous amounts of personal information.
Going into the mid-90s, some institutions were starting to realize that
x.509 identity certificates, grossly overloaded with personal
information represented significant privacy and liability issues. As a
result, you saw some effort creating relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo
which contained little more than some sort of account number or other
repository lookup/index and a public key. However, it is trivial to
demonstrate that such relying-party-only certificates are redundant and
superfluous. In some of these scenarios, the repository lookup/index is
a "userid".
In the simple case for entities with existing relationships, it is
possible to upgrade password-based systems with public keys and digital
signature authentication; basically the public key is registered in lieu
of a password .... and the digital signature is transmitted in lieu of
transmitting the password. No digital certificate is required as part of
first-time communication between total strangers. misc. collected
postings on simple digital signature authentication
http://www.garlic.com/~lynn/subpubkey.html#certless
one of the prevailing authentication mechanisms on the internet is
radius .... originally a userid/password based implementation. However,
there have been a number of (certificate-less) public key enhancments for
RADIUS implementations
http://www.garlic.com/~lynn/subpubkey.html#radius
another common authentication infrastructure that was originally
userid/password is kerberos. the original pk-init draft for upgrading
kerberos passwords to digital signature didn't even mention certificates
http://www.garlic.com/~lynn/subpubkey.html#kerberos
one of the possibilities for upgrading to straight public key and
digital signature .... is that a server-side digital signature
authentication infrastructure can be used regardless of the integrity of
the user-side operation. basically the digital signature operations
are something you have authentication. however, there can be a wide
variation in the integrity of that something you have.
The lowest integrity is a software container that contains the private
key. the sender has possession of the software container. there is a big
integrity difference between have a private key in a straight software
container and having it contained in some form of hardware token.
the software container may be encrypted by default. for the owner to
perform a digital signature, a decryption key must be supplied. this
effectively now is two-factor authentication (the encrypted software
container for the private key is something you have and the decryption
key is something you know) .... however, it wouldn't normally be
considered extremely robust or high integrity two-factor authentication.
for higher integrity two-factor authentication, the server-side might
want to know that the private key is contained in a certified hardware
token, possibly was generated inside the token and has never been
outside the token.
in any case, simply registering public keys in lieu of passwords has
advantage over password mechanism since the public key can be used to
verify the digital signature but can't be used to create a digital
signature i.e. a password is used for both verification and origination
... which leads to impersonation vulnerability and the requirement that
passwords be kept secret, be impossible to guess and memorize, have to
be change frequently, and a unique password is required for each
security domain.
however, because of the wide-variety of possible private key
environments, infrastructures that register public keys .... should also
register the characteristics and integrity level of the associated
private key environment (software, hardware, encrypted, single-factor,
multiple factors, integrity level of the hardware, etc). this then leads
to the security proportional to risk theme ... where a common digital
signature environment can support a wide-variety of integrity levels ...
and different permission levels be associated with different levels of
private key integrity.
misc. recent postings on possibly confusing authentication and identification
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#14 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#32 How many wrongs do you need to make a right?
http://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#2 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28
http://www.garlic.com/~lynn/aadsm21.htm#17 continuity of identity
http://www.garlic.com/~lynn/aadsm21.htm#19 mixing authentication and identification?
http://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
http://www.garlic.com/~lynn/2005p.html#32 PKI Certificate question
http://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005s.html#10 NEW USA FFIES Guidance
http://www.garlic.com/~lynn/2005s.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
http://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
http://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
http://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005t.html#9 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2005t.html#22 What ever happened to Tandem and NonStop OS ?
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Sun, 27 Nov 2005 11:30:12 -0700
jmfbahciv writes:
Yup. What that saleman didn't know is that not having a pattern
is a pattern. This is similar to reading between the lines.
I've always used absence of data as information.
you could have a marvelous time over in comp.database.theory in the
thread discussing NULLs. most of the problem actually doesn't come for
having a defined something called NULLs, it frequently comes when
people are applying 3-value logic ... and the results aren't what they
would have expected.
piece of the thread
http://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#23 So what's null then if it's not nothing?
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: RSA SecurID product
Newsgroups: bit.listserv.vmesa-l
Date: Mon, 28 Nov 2005 03:21:31 -0700
Alan Altmark wrote:
RSA SecurID is normally integrated into the network access controls. That
is, authentication and host access authorization decisions are made at the
[VPN] network boundary (a la firewall), not on each host.
That said, I have heard other requests for two-part authentication,
typically requiring X.509 user certificates for SSL/TLS, plus a
userid/password at the target service.
there is something of a trust disconnect with the SSL/TLS model that
has some things in common with the current password model.
a couple recent posts that had topic drift on authentication technology
http://www.garlic.com/~lynn/2005t.html#27 RSA SecureID product
http://www.garlic.com/~lynn/2005t.html#28 RSA SecureID product
http://www.garlic.com/~lynn/2005t.html#32 RSA SecureID product
original password model had some something you know static data
recorded and the person needed to reproduce this static data for
authentication. as the need for authentication proliferated, the
importance of some of the authentication uses increased and the number
of different authentications increased. because it was static data,
there was a requirement for unique password for every different
security boundary/domain. for the important uses, there was
requirements for impossible to guess/remember passwords that changed
frequently ... and people were saddled with scores of impossible to
guess/remember passwords. the proliferation of password use became the
basis for fundamental password vulernability (in addition to other
vulnerability characteristics of passwords). misc. collected postings
on shared-secret authentication (& their vulnerabilities)
http://www.garlic.com/~lynn/subintegrity.html#secrets
long ago and far away, we were asked to consult with this small
client/server startup that wanted to do payment transactions on
their server(s)
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and as noted in the above ... some topic drift relationship
http://www.garlic.com/~lynn/95.html#13
to our work on producing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
which has some small relationship to having done some work
on the original relational/sql dbms
http://www.garlic.com/~lynn/subtopic.html#systemr
in any case, the startup had this new technology that they called SSL
that could be leveraged to secure the payment transaction information
(again, shared-secret static data ... that effectively is used for
authentication of the payment transaction). as part of the work we
went around and audited some of these brand new organizations called
certification authorities
http://www.garlic.com/~lynn/subpubkey.html#sslcert
the issue is that the ssl digital certificate binds a public key to a
domain name for a URL that the user/client types in. the server
provides the digital certificate, the client software checks the
validiity of the digital certificate, and then checks that the digital
certificate domain name matches the domain name URL typed in. the
client then generates a random (symmetrical) encryption key, encrypts
it with the public key from the certificate and sends it back to the
server. the client and server now only communicate using an encrypted
channel. there is an implied something you have authentication of
the server, since only the server should have access to and use of the
corresponding private key (and therefor able to decrypt and use the
client's randomly generated symmetric encryption key).
the issue analogous to the proliferation of passwords ... is that the
use of URLs have so widely proliferated that they happen at every
blink and twitch and users rarely type them in any more (or even pay
any attention to the domain name in URLs). ssl operation
vulnerabilities now include attackers having valid ssl domain name
certificates that correspond to supplied URL domain name ... which
users rerely, if ever pay any attention to or even look at. in part,
because URLs have become so ingrained as part of every WWW twitch and
blink ... they are incorporated into the substance of the
operation. Users see a word like "bank" that may be clicked on ... and
a URL is automatically transmitted that the user never typed or even
looked at (and can have perfectly valid SSL authenticatin ... which
now can carry with it almost no real security meaning).
the situation has put the trusted-third certification authorities in
somewhat of a bind.
the basic digital signature model has the client validating public
keys before loading them into their local repository. In the PGP email
case, senders digitally sign their email and can provide a public key.
the recipients go thru some validation process before loading any
supplied public key into their local trusted public key repository.
the PGP email digital signature process takes the displayed email
"FROM" address to find a public key in the client's trusted public key
repository for validating the email's digital signature. there now is
a completely understandable, and direct relationship between the
"FROM" (sender), the digital signature, and the client's validation of
the supplied public key.
The SSL TTP digital certificate model has obfuscated this original
model through several layers of indirection that can result in it
almost being meaningless.
First off, the client's trusted public key repository used for
validating the digital signatures on the "messages" produced by
certification authorities (aka digital certificates) have typically
been preloaded by the application vendor. most users probably aren't
even aware that the foundation of ALL digital signature
infrastructures are based on local client trusted public key
respository ... whether they involve digital certirficates or are
certificate-less
http://www.garlic.com/~lynn/subpubkey.html#certless
next, the process by which public keys are validated as part of
loading into the client's trusted public key repository is frequently
obfuscated (especially compared to the PGP process).
the use of URLs occuring at ever twitch and blink ... that the user is
frequently unaware of the actual URL ... pretty throughly obfuscates
the domain names in the URLs. therefor any security that comes from
matching the domain name in the URLs and the domain name in SSL
digital certificates is significantly depreciated. in part this led to
the series of past postings about "comfort certificates" included in
some of the earlier postings on ssl certificate.
http://www.garlic.com/~lynn/subpubkey.html#sslcert
so, the digital certificate model is also somewhat of an electronic
analog to identification credentials (aka the theme that any
requirement for the attachment of identification digital certificates
to every operation turns even the most trivial authentication event
into heavy duty identification operation). the user needs to validate
the identification credentials before trusted the party they are
dealing with. however, the use of the SSL digital certificates with
URL domain names, and the prolificate ingraining of URLs into the very
fabric of web infrastructures has resulted in the process becoming
authomatic ... and as a result, depreciating much of its original
security meaning.
by contrast, in the PGP model, the public key is directly associated
with the email "FROM", which is always displayed (as opposed to the
domain name in a URL, which users rarely, if ever see or pay any
attention to). Furthermore, the user performs some sort of validation
once, as part of adding the public key to their local, client trusted
public key repository. From then on, the users can be assured of that
binding between the visiable FROM, the digital signature validation,
and the loaded public key (which can be done automatically from then
on). PGP systems also support various levels of integrity checking
associated with loaded public keys. However, there retains a very
simple and observable trust chain between the email "FROM", the email
digital signature, the loaded public key, and the process involved in
loading that public key. That trust chain isn't throughly obfuscated
as has happened with the SSL domain name certificate imfrastructure
that it looses almost all security significance.
this creates something of a dilemma for the SSL domain name
certification authority industry. Any change that results in the user
being more involved in verifying the binding of a public key with some
entity ... would appear to depreciate the value of the certification
authority usefulness and their digital certificates ... aka some PGP
analogous mechanism where some value that is known to be user visiable
(on a web page) is used for looking up a public key locally stored
public key ... which is then used for authentication process.
so there are a number of increased security operations being developed
... which involve operations around things known to be displayed on
the web page for the user. however, they've tended to avoid chaning
the user's perception of digital signatures, public keys and the
requirement for digital certificates issued by certification
authorities. so a trivial scenario marrying PGP model and SSL is for
the user to click on some static data on a web page (logo, image,
text, etc) that then looks up a public key from a local client trusted
public key repository. then the rest of the SSL operation is performed
with the server based on that public key (rather than a public key
opbtained from some supplied digital certificate ... and the URL might
even be taken from the entry associated with the public key
... instead of from the web page).
so there are some administrative functions that are needed to make it
easy and simple for users to maintain their local public key
responsitory (analogous to the PGP implementation). part of the issue
is not to make those events so frequent that they require so much
automation that the security issues are throughly obfuscated and
become meaningless ... as has essentially happened for much of the SSL
domain name certificate use.