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 -0700this 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.
https://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
https://www.garlic.com/~lynn/submain.html#systemr
and in the early 90s were producing the ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
which included doing some work on parallel scale-up. minor
meeting reference regarding parallel oracle scale-up
https://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 doing some financial consulting
and were asked to work with a small client/server start up in
silicon valley 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 scale-up
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://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:
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2005s.html#49 phishing web sites using self-signed certs
https://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 successful.
the original pk-init draft for kerberos
https://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 ....
https://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 | https://www.garlic.com/~lynn/
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:
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
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. boyd pages from around the web
https://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Dangerous Hardware Newsgroups: alt.folklore.computers Date: Sun, 06 Nov 2005 03:17:15 -0700Bill Turlock <"Bill Turlock"@sonnic.net> writes:
--
Anne & Lynn Wheeler | https://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 -0700Paul Hantom writes:
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
https://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
https://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
https://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.
https://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
from my rfc index
https://www.garlic.com/~lynn/rfcietff.htm
misc. other historical references about nsfnet backbone RFP
and award:
https://www.garlic.com/~lynn/rfcietf.htm#history
--
Anne & Lynn Wheeler | https://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 -0700oh ... 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 | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Dangerous Hardware Newsgroups: alt.folklore.computers Date: Mon, 07 Nov 2005 02:08:33 -0700Anne & Lynn Wheeler writes:
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
https://www.garlic.com/~lynn/subboyd.html#boyd
misc. pages mentioning boyd from around the web
https://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700there are periodic comments that OCSP fixes the offline characteristics of digital certificate credentials.
some recent postings related to the subject:
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#1 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#31 More Phishing scams, still no SSL being used
https://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 ...
https://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 every time 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, reverything 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
https://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
https://www.garlic.com/~lynn/x959.html#x959
https://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
https://www.garlic.com/~lynn/subpubkey.html#rpo
as an alternative to doing x9.59 w/o certificates
https://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
https://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information
https://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary
https://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F
https://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
https://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
https://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))
https://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))
https://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
https://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
https://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
https://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI
https://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aepay11.htm#68 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
https://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
https://www.garlic.com/~lynn/aadsm15.htm#33 VS: On-line signature standards
https://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:
https://www.garlic.com/~lynn/aadsm13.htm#10 X.500, LDAP Considered harmful Was: OCSP/LDAP
https://www.garlic.com/~lynn/aadsm17.htm#4 Difference between TCPA-Hardware and a smart card (was: examp le: secure computing kernel needed)
https://www.garlic.com/~lynn/aadsm17.htm#41 Yahoo releases internet standard draft for using DNS as public key server
https://www.garlic.com/~lynn/aadsm17.htm#54 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#5 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
https://www.garlic.com/~lynn/aadsm18.htm#27 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#31 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#52 A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)
https://www.garlic.com/~lynn/aadsm19.htm#11 EuroPKI 2005 - Call for Participation
https://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
https://www.garlic.com/~lynn/aadsm19.htm#40 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#17 the limits of crypto and authentication
https://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda)
https://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
https://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
https://www.garlic.com/~lynn/2003g.html#47 Disk capacity and backup solutions
https://www.garlic.com/~lynn/2003k.html#66 Digital signature and Digital Certificate
https://www.garlic.com/~lynn/2004g.html#5 Adding Certificates
https://www.garlic.com/~lynn/2004h.html#51 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004i.html#18 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
https://www.garlic.com/~lynn/2004m.html#23 Help! I'm trying to understand PKI - especially CA's role
https://www.garlic.com/~lynn/2005e.html#22 PKI: the end
https://www.garlic.com/~lynn/2005e.html#38 xml-security vs. native security
https://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
https://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#45 Maximum RAM and ROM for smartcards
https://www.garlic.com/~lynn/2005h.html#25 couple more Q's on basic public key encryption techniques
https://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
https://www.garlic.com/~lynn/2005i.html#4 Authentication - Server Challenge
https://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005l.html#7 Signing and bundling data using certificates
https://www.garlic.com/~lynn/2005l.html#12 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#23 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
https://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#36 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005l.html#37 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005m.html#15 Course 2821; how this will help for CISSP exam ?
https://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
https://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
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:
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/94.html#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360
https://www.garlic.com/~lynn/2001d.html#66 Pentium 4 Prefetch engine?
https://www.garlic.com/~lynn/2001f.html#62 any 70's era supercomputers that ran as slow as today's supercomputers?
https://www.garlic.com/~lynn/2001l.html#40 MVS History (all parts)
https://www.garlic.com/~lynn/2001l.html#61 MVS History (all parts)
https://www.garlic.com/~lynn/2002.html#5 index searching
https://www.garlic.com/~lynn/2002b.html#11 Microcode? (& index searching)
https://www.garlic.com/~lynn/2002b.html#20 index searching
https://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
https://www.garlic.com/~lynn/2002e.html#9 What are some impressive page rates?
https://www.garlic.com/~lynn/2004p.html#39 100% CPU is not always bad
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700ref:
for a little drift on the subject of changing from a real memory
constrained environment and the uptake of rdbms:
https://www.garlic.com/~lynn/2005s.html#9 Flat Query
https://www.garlic.com/~lynn/2005s.html#12 Flat Query
https://www.garlic.com/~lynn/2005s.html#3 Flat Query
https://www.garlic.com/~lynn/2005s.html#4 Flat Query
https://www.garlic.com/~lynn/2005s.html#6 Flat Query
https://www.garlic.com/~lynn/2005s.html#8 Flat Query
now the original relational/sql implementation was done on vm370
https://www.garlic.com/~lynn/submain.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
https://www.garlic.com/~lynn/subtopic.html#hacmp
I've commented before that two of the people in the following
meeting
https://www.garlic.com/~lynn/95.html#13
later showed up in a small client/server startup responsible
for something called commerce server
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://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
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
https://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
https://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
https://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
after the above mentioned presentation at the '68 Atlantic City 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:
https://www.garlic.com/~lynn/2003.html#60 MIDAS
https://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
https://www.garlic.com/~lynn/2003k.html#7 What is timesharing, anyway?
https://www.garlic.com/~lynn/2003p.html#9 virtual-machine theory
https://www.garlic.com/~lynn/2004d.html#66 System/360 40 years old today
https://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS
https://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE
https://www.garlic.com/~lynn/2005i.html#49 Where should the type information be?
https://www.garlic.com/~lynn/2005j.html#45 Where should the type information be?
https://www.garlic.com/~lynn/2005j.html#47 Where should the type information be?
https://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
https://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
https://www.garlic.com/~lynn/submain.html#mmap
this was later ported to vm370 cms and deployed successfully on some number of internal systems.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700Anne & Lynn Wheeler writes:
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)
https://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
https://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues
https://www.garlic.com/~lynn/aadsm17.htm#21 Identity (was PKI International Consortium)
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?
--
Anne & Lynn Wheeler | https://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:
collected post postings
https://www.garlic.com/~lynn/subboyd.html#boyd
and various Boyd references from around the web
--
Anne & Lynn Wheeler | https://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 -0700Phil Smith III writes:
--
Anne & Lynn Wheeler | https://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:
look at some of the references in the following collection of
URLs (from around the web) mentioning Boyd beating the generals
https://www.garlic.com/~lynn/subboyd.html#boyd2
--
Anne & Lynn Wheeler | https://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 -0700Boyd 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 | https://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 -0700D.J. writes:
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 | https://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 -0800Charles Mills wrote:
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:
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 successful, 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 successful).
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 | https://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:
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 -0700Peter Flass writes:
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 fall '68 share meeting in Atlantic City
https://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14
https://www.garlic.com/~lynn/94.html#20 CP/67 & OS MFT14
https://www.garlic.com/~lynn/97.html#22 Pre S/360 IBM Operating Systems?
https://www.garlic.com/~lynn/98.html#21 Reviving the OS/360 thread (Questions about OS/360)
https://www.garlic.com/~lynn/2001f.html#26 Price of core memory
https://www.garlic.com/~lynn/2001k.html#37 Is anybody out there still writting BAL 370.
https://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
https://www.garlic.com/~lynn/2002m.html#3 The problem with installable operating systems
https://www.garlic.com/~lynn/2002n.html#29 why does wait state exist?
https://www.garlic.com/~lynn/2003d.html#72 cp/67 35th anniversary
https://www.garlic.com/~lynn/2004f.html#6 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2005m.html#16 CPU time and system load
--
Anne & Lynn Wheeler | https://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 -0700Bill Pechter <pechter-at-gmail-dot-com> writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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:
--
Anne & Lynn Wheeler | https://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 -0700Bill Pechter <pechter-at-gmail-dot-com> writes:
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
https://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
https://www.garlic.com/~lynn/subnetwork.html#3tier
--
Anne & Lynn Wheeler | https://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 -0700Bill Pechter <pechter-at-gmail-dot-com> writes:
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
https://www.garlic.com/~lynn/subpubkey.html#kerberos
w/o requiring PKIs, digital certificates, etc.
https://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
https://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
https://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 | https://www.garlic.com/~lynn/
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 -0700ref
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 | https://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 -0700greymaus writes:
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
https://www.garlic.com/~lynn/subtopic.html#hone
minor topic drift about even conflict between boca and other
business units
https://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2001n.html#55 9-track tapes (by the armful)
https://www.garlic.com/~lynn/2002g.html#9 IBM MIcrochannel??
https://www.garlic.com/~lynn/2002q.html#40 ibm time machine in new york times?
https://www.garlic.com/~lynn/2004p.html#59 IBM 3614 and 3624 ATM's
https://www.garlic.com/~lynn/2005h.html#12 practical applications for synchronous and asynchronous communication
https://www.garlic.com/~lynn/2005q.html#20 Ethernet, Aloha and CSMA/CD -
https://www.garlic.com/~lynn/2005q.html#21 Ethernet, Aloha and CSMA/CD -
https://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
https://www.garlic.com/~lynn/subnetwork.html#emulation
which we really got in conflict with when we starting pitching
our 3-tier architecture
https://www.garlic.com/~lynn/subnetwork.html#3tier
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700rpl writes:
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.
https://www.garlic.com/~lynn/submain.html#systemr
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Dangerous Hardware Newsgroups: alt.folklore.computers Date: Tue, 22 Nov 2005 15:29:24 -0700here is a different thread drift related to boyd
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:
https://www.garlic.com/~lynn/subboyd.html#boyd
https://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 | https://www.garlic.com/~lynn/
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 -0700Thomas Kern writes:
• 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
https://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):
https://www.garlic.com/~lynn/x959.html#aads
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700ref:
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
https://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
https://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.
https://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
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://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
https://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
https://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
https://www.garlic.com/~lynn/2005m.html#37 public key authentication
https://www.garlic.com/~lynn/2005p.html#6 Innovative password security
https://www.garlic.com/~lynn/2005p.html#25 Hi-tech no panacea for ID theft woes
--
Anne & Lynn Wheeler | https://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 Date: Thu, 24 Nov 2005 11:26:14 -0700"Dean Kent" writes:
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 "advisers" 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.
https://www.garlic.com/~lynn/submain.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 | https://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 -0700ref:
also in play in the late 80s was the whole installed terminal emulation
product base:
https://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.
https://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 | https://www.garlic.com/~lynn/
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 -0700bk.paradox writes:
past thread discussing RFC 2289:
https://www.garlic.com/~lynn/2003m.html#50 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#0 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#1 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#2 public key vs passwd authentication?
https://www.garlic.com/~lynn/2003n.html#3 public key vs passwd authentication?
more recent related thread with some subject drift:
https://www.garlic.com/~lynn/2005t.html#27 RSA SecurID product
https://www.garlic.com/~lynn/2005t.html#28 RSA SecurID product
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700Alan Altmark wrote:
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
https://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
https://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
https://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
https://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
https://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
https://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#5 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for Europe-wide biometric ID card
https://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#14 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm20.htm#32 How many wrongs do you need to make a right?
https://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#2 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm21.htm#12 Payment Tokens
https://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
https://www.garlic.com/~lynn/aadsm21.htm#16 PKI too confusing to prevent phishing, part 28
https://www.garlic.com/~lynn/aadsm21.htm#17 continuity of identity
https://www.garlic.com/~lynn/aadsm21.htm#19 mixing authentication and identification?
https://www.garlic.com/~lynn/2005o.html#6 X509 digital certificate for offline solution
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
https://www.garlic.com/~lynn/2005p.html#24 Hi-tech no panacea for ID theft woes
https://www.garlic.com/~lynn/2005p.html#32 PKI Certificate question
https://www.garlic.com/~lynn/2005q.html#13 IPSEC with non-domain Server
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
https://www.garlic.com/~lynn/2005s.html#10 NEW USA FFIES Guidance
https://www.garlic.com/~lynn/2005s.html#24 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2005s.html#42 feasibility of certificate based login (PKI) w/o real smart card
https://www.garlic.com/~lynn/2005s.html#43 P2P Authentication
https://www.garlic.com/~lynn/2005s.html#52 TTP and KCM
https://www.garlic.com/~lynn/2005t.html#0 TTP and KCM
https://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2005t.html#9 phishing web sites using self-signed certs
https://www.garlic.com/~lynn/2005t.html#22 What ever happened to Tandem and NonStop OS ?
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 -0700jmfbahciv writes:
piece of the thread
https://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
https://www.garlic.com/~lynn/2005t.html#23 So what's null then if it's not nothing?
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
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 -0700Alan Altmark wrote:
a couple recent posts that had topic drift on authentication technology
https://www.garlic.com/~lynn/2005t.html#27 RSA SecureID product
https://www.garlic.com/~lynn/2005t.html#28 RSA SecureID product
https://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)
https://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)
https://www.garlic.com/~lynn/aadsm5.htm#asrn2
https://www.garlic.com/~lynn/aadsm5.htm#asrn3
and as noted in the above ... some topic drift relationship
https://www.garlic.com/~lynn/95.html#13
to our work on producing ha/cmp product
https://www.garlic.com/~lynn/subtopic.html#hacmp
which has some small relationship to having done some work
on the original relational/sql dbms
https://www.garlic.com/~lynn/submain.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
https://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
https://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 occurring 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.
https://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.
for some slight drift, one of the most prevalent use of ssl domain name infrastructure is the securing of electronic commerce and the vulnerable static data associated with online, electronic payment transactions. so one of the requirements given the x9a10 standards working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments.
part of the issue has been that the transaction static data isn't just
vulnerabile to capture while in transit, but also when it is at rest
in large repositories of transaction information ... related post on
security proportional to risk
https://www.garlic.com/~lynn/2001h.html#61
so x9.59 standard defines
https://www.garlic.com/~lynn/x959.html#x959
https://www.garlic.com/~lynn/subpubkey.html#x959
1) all x9.59 transactions are authenticated. this can be with digital signatures which are validated with (certificate-less) public keys registered and stored in the account record at the individual's financial infrastructure.
2) static data in x9.59 transactions can't be used in non-authenticated, non-x9.59 transactions.
the second part eliminates much of the existing fraud that comes from
either transaction evesdropping and/or data breaches of transaction
repositories. with the elimination of transaction fraud from the
capture of transaction static data, there is a much reduced security
requirement for protecting such information (with encryption and/or
other security means, which, in turn, reduces much of the existing
need for ssl domain name certificate infrastructures) ... various. posts
related to account number harvesting:treats & vulnerabilities
https://www.garlic.com/~lynn/subintegrity.html#harvest
of course, there are all the past postings about another ssl domain
name certificate catch-22 ... that leads down another path to
certificate-less use and obsoleting the necessity for ssl domain name
certificates:
https://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
https://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
https://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
https://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
https://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
https://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
https://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
https://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
https://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
https://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
https://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
https://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
https://www.garlic.com/~lynn/aadsm20.htm#42 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet security hall of shame
https://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
https://www.garlic.com/~lynn/2001l.html#22 Web of Trust
https://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
https://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
https://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
https://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
https://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
https://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
https://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
https://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
https://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
https://www.garlic.com/~lynn/2003d.html#29 SSL questions
https://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
https://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
https://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
https://www.garlic.com/~lynn/2004b.html#41 SSL certificates
https://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
https://www.garlic.com/~lynn/2005e.html#22 PKI: the end
https://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
https://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
https://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
https://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
https://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
https://www.garlic.com/~lynn/2005i.html#3 General PKI Question
https://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
https://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
https://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
https://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
https://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally be forced to sign a document etc - Tax Declaration etc etc etc
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: winscape? Newsgroups: alt.folklore.computers Date: Mon, 28 Nov 2005 07:34:42 -0700Elliott Roper writes:
this was (quickly) changed to a much simpler two level structure by somebody at lincoln labs ... in part because all the level movements were consuming significant processor overhead (on the order of 10-15 percent of total cpu with 30-35 users).
i then redid that with the initial version of dynamic adaptive fair
share (fair share, in part because the default policy was fair share
... but it allowed other policies also, able to support mixed-mode,
interactive, batch, etc). it also further significantly reduced
required pathlength at the same time and made everything much more
predictable (late '60s, while still undergraduate). misc. past posts
on fair share
https://www.garlic.com/~lynn/subtopic.html#fairshare
somewhat related posts on commercial time-sharing operations using the
stuff for service offerings
https://www.garlic.com/~lynn/submain.html#timeshare
twenty some years later, i observed similar in some systems that also had scheduling thing that woke up once a second to adjust things. I always wondered if some of it dated back to having common heritage thread to CTSS.
--
Anne & Lynn Wheeler | https://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, 28 Nov 2005 07:41:21 -0700Morten Reistad writes:
in part, because it sat in the guts of the kernel ... and the majority of the code all around it involved very cleanly defined state transitions ... then along comes a little bit of code with multiplies, divides and sorting ... and it was a totally different paradigm compared to all the state transition stuff surrounding it (and the little bit of multiplies & divides could approx. hundreds of various kinds of state tests).
--
Anne & Lynn Wheeler | https://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, 28 Nov 2005 08:01:55 -0700Morten Reistad writes:
for a little drift on the subject:
https://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
https://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
--
Anne & Lynn Wheeler | https://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, 28 Nov 2005 10:18:32 -0700Greg Menke <gregm-xyzpdq@toadmail.com> writes:
,,, that, and iso mandating that it would only entertain protocol
standards work for stuff that conformed to osi model. lots of posts
about high-speed protocol work
https://www.garlic.com/~lynn/subnetwork.html#xtphsp
and ISO not being able to consider because:
1) it violated OSI model because it went directly from transport to LAN interface (skiiping transport/network interface)
2) it supported internetworking (aka tcp/ip, internetworking and internet doesn't exist in the OSI model)
3) it went directly to LAN interface ... LAN inteface sits in the middle of network layer ... violating OSI, and therefor supporting LAN interface would also violate OSI.
one of the early (real) "networking" issues was intermediate node congestion ... which is actually a "rate" related problem (i.e. the arrival rate of stuff is higher than intermediate node can handle).
one of the things you saw was that adapting the windowing/ack paradigm ... which had been developed for latency compensation in communication point-to-point links ... to also handling the intermediate node congestion problem in networks. to the extent that there was also a end-to-end latency issue in networks, it had paradigm carry-over ... but to the extent that congestion was a rate issue ... rather than a latency issue ... it was attempting to use a control mechanism that only indirectly affected congestion.
for instance, one of the problems with intermediate node congestion is some sequence of multiple back-to-back packets. a rate-based control mechanism wouldn't have allowed transmission of multiple back-to-back packets. however, one of the ways that the windowing/ack protocol was inappropriate was that returning acks could bunch in real-world bursty network traffic. the result is delay when the "window" is totally full ... and then when bunch of multiple acks arrive essentially all at once, the window is opened wide and multiple back-to-back packets would be transmitted until the window is full. in theory, you could get into negative feedback control environment ... with multiple back-to-back packets filling the window, congestion and lost packets result, back-off to less aggresive window size, retransmission of lost packets and then quickly growing window size until the congestion repeats itself.
recently i ran across some paper that showed that it only takes relatively light amount of congestion dropped packets to significantly reduce effective network thruput ... not so much because of the dropped packets themselves ... but because the congestion control mechanism then could get into these negative oscillations ... in part because the control mechanism paradigm used doesn't have direct correlation with the operations it is suppose to be controlling (allowing things to get out-of-sync, resulting in inefficiencies).
misc. past rate-based postings.
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/2000b.html#11 "Mainframe" Usage
https://www.garlic.com/~lynn/2001h.html#44 Wired News :The Grid: The Next-Gen Internet?
https://www.garlic.com/~lynn/2002.html#38 Buffer overflow
https://www.garlic.com/~lynn/2002i.html#45 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002i.html#57 CDC6600 - just how powerful a machine was it?
https://www.garlic.com/~lynn/2002k.html#56 Moore law
https://www.garlic.com/~lynn/2002p.html#28 Western Union data communications?
https://www.garlic.com/~lynn/2002p.html#31 Western Union data communications?
https://www.garlic.com/~lynn/2003.html#55 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003.html#59 Cluster and I/O Interconnect: Infiniband, PCI-Express, Gibat
https://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
https://www.garlic.com/~lynn/2003g.html#54 Rewrite TCP/IP
https://www.garlic.com/~lynn/2003g.html#64 UT200 (CDC RJE) Software for TOPS-10?
https://www.garlic.com/~lynn/2003j.html#1 FAST - Shame On You Caltech!!!
https://www.garlic.com/~lynn/2003j.html#19 tcp time out for idle sessions
https://www.garlic.com/~lynn/2003j.html#46 Fast TCP
https://www.garlic.com/~lynn/2003p.html#15 packetloss bad for sliding window protocol ?
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2004k.html#8 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#12 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#13 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#16 FAST TCP makes dialup faster than broadband?
https://www.garlic.com/~lynn/2004k.html#29 CDC STAR-100
https://www.garlic.com/~lynn/2004n.html#35 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#62 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2004q.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2004q.html#57 high speed network, cross-over from sci.crypt
https://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005g.html#4 Successful remote AES key extraction
https://www.garlic.com/~lynn/2005q.html#22 tcp-ip concept
https://www.garlic.com/~lynn/2005q.html#28 tcp-ip concept
https://www.garlic.com/~lynn/2005q.html#37 Callable Wait State
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers Date: Mon, 28 Nov 2005 19:46:01 -0700Jim Bohnsack writes:
somewhere along the way some employee did a version for the ibm/pc released under the productivity family of personally developed software.
archaic trivia ... the service processor for 3090 was a pair of 4361s running a highly customized version of vm370 release 6 and all the service screens were done in ios3270.
earlier i had redone the fulist, browse, and ios3270 source code so that i could reside in shared segment (early 1979). this was returned to Theo and integrated into standard release and shipped later in 1979.
from somewhere long ago and far away:
Date: 10/12/79 17:02:16
To: Users of FULIST/BROWSE (5785-HAB)
Subject: DCSS version of FULIST/BROWSE
You will shortly be receiving 20 class S DISK DUMP files.
This files comprise the latest levels of FULIST and BROWSE
released by Theo Alkema.
File SHIPHAB EXEC contains a list of all files being sent to you.
Note that no modules are included in this list. You will have
to generate the modules from the appropriate TEXT decks.
Please read files 5785HAB MEMO and SHIPHAB EXEC for instructions
on how to create the new modules. You may create either DCSS or
non-DCSS versions of FULIST and BROWSE.
As usual, please send comments, problem reports, and sugguestions
directly to Theo Alkema at UITHONE(MAINTCMS).
... snip ... top of post, old email index
the full shared segment stuff i had done internally which was part of
set of updates that also included memory mapped filesystem support
https://www.garlic.com/~lynn/submain.html#mmap
originally on cp67 and then ported to vm370. a small subset of the
full shared segment stuff was released as "DCSS" in vm370 release 3.
misc. collected postings related to the full shared segment segment
implementation
https://www.garlic.com/~lynn/submain.html#adcon
which included being able to load shared segment images from "MODULE" executable files located on cms paged map filesystem.
misc. past postings referecing fulist, browse, and/or Theo:
https://www.garlic.com/~lynn/2001f.html#8 Theo Alkema
https://www.garlic.com/~lynn/2001f.html#9 Theo Alkema
https://www.garlic.com/~lynn/2001f.html#21 Theo Alkema
https://www.garlic.com/~lynn/2002o.html#25 Early computer games
https://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?
https://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004q.html#63 creat
https://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l Date: Tue, 29 Nov 2005 08:48:22 -0700Jim Bohnsack writes:
one of the edgar arguments was the up/down commands. the frame of reference for edgar was the program ... the metaphor is the file is a scroll and the screen is a window on the scroll; the edgar up/down was with respect to the program pulling the scroll up/down i.e. "up" met moving the scroll "up" (moving window towards the bottom of the file) and "down" met moving the scroll "down" (i.e. moving window towards the top of the file). the others had a human frame of reference ... rather than the program frame of reference ... the windows were an extension of the eyes ... where moving "up" met moving the window up (moving towards the top of the file).
the red&ned arguments vis-a-vis xedit were because both red&ned had extensive scripting and macro capabilities (which edgar lacked) and were a number of years more mature than xedit (while xavier was in endicott vm group while both red & ned were developed by individuals at different internal datacenters). someplace, i might even have stuff from the period on the red/ned/xedit discussions.
one of the big ISPF difficulties (shared by some number of other well
known mvs software products) was the difficulty in transitioning from
free software to priced software ... and the ground rules for
calculating price based on true internal costs vis-a-vis market
forecast. for some topic drift ... collected posts on the resource
manager being the first kernel priced software (and other posts
related to transition to priced software after the unbundling
announcement on 6/23/69)
https://www.garlic.com/~lynn/submain.html#unbundle
the really big cms battles were with the vspc/pco group; misc.
past posts mentioning vspc/pco.
https://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
https://www.garlic.com/~lynn/2002h.html#51 Why did OSI fail compared with TCP-IP?
https://www.garlic.com/~lynn/2002q.html#26 LISTSERV Discussion List For USS Questions?
https://www.garlic.com/~lynn/2003k.html#0 VSPC
https://www.garlic.com/~lynn/2004.html#4 TSS/370 source archive now available
https://www.garlic.com/~lynn/2004g.html#47 PL/? History
https://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
https://www.garlic.com/~lynn/2004n.html#0 RISCs too close to hardware?
https://www.garlic.com/~lynn/2004n.html#17 RISCs too close to hardware?
https://www.garlic.com/~lynn/2005d.html#74 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005p.html#38 storage key question
https://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
all sort of past posts mentioning edgar, rexx, and/or xedit:
https://www.garlic.com/~lynn/94.html#11 REXX
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/95.html#00 old mainframes & text processing
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000b.html#30 20th March 2000
https://www.garlic.com/~lynn/2000b.html#31 20th March 2000
https://www.garlic.com/~lynn/2000b.html#32 20th March 2000
https://www.garlic.com/~lynn/2000b.html#33 20th March 2000
https://www.garlic.com/~lynn/2000c.html#41 Domainatrix - the final word
https://www.garlic.com/~lynn/2000d.html#17 Where's all the VMers?
https://www.garlic.com/~lynn/2001.html#27 VM/SP sites that allow free access?
https://www.garlic.com/~lynn/2001b.html#14 IBM's announcement on RVAs
https://www.garlic.com/~lynn/2001b.html#30 perceived forced conversion from cp/m to ms-dos in late 80's
https://www.garlic.com/~lynn/2001e.html#60 Estimate JCL overhead
https://www.garlic.com/~lynn/2001f.html#10 5-player Spacewar?
https://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
https://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
https://www.garlic.com/~lynn/2001i.html#1 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#17 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#18 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001i.html#22 History of Microsoft Word (and wordprocessing in general)
https://www.garlic.com/~lynn/2001j.html#26 Help needed on conversion from VM to OS390
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#44 3270 protocol
https://www.garlic.com/~lynn/2001k.html#46 3270 protocol
https://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370?
https://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS
https://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
https://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
https://www.garlic.com/~lynn/2001n.html#11 OCO
https://www.garlic.com/~lynn/2001n.html#26 Open Architectures ?
https://www.garlic.com/~lynn/2001n.html#36 Movies with source code (was Re: Movies with DEC minis)
https://www.garlic.com/~lynn/2002e.html#45 REXX and its designer (was: IBM 7090 instruction set)
https://www.garlic.com/~lynn/2002f.html#29 Computers in Science Fiction
https://www.garlic.com/~lynn/2002g.html#27 Security Issues of using Internet Banking
https://www.garlic.com/~lynn/2002g.html#57 Amiga Rexx
https://www.garlic.com/~lynn/2002g.html#58 Amiga Rexx
https://www.garlic.com/~lynn/2002g.html#59 Amiga Rexx
https://www.garlic.com/~lynn/2002g.html#60 Amiga Rexx
https://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002j.html#3 HONE, Aid, misc
https://www.garlic.com/~lynn/2002j.html#83 Summary: Robots of Doom
https://www.garlic.com/~lynn/2002j.html#85 Summary: Robots of Doom
https://www.garlic.com/~lynn/2002k.html#9 Avoiding JCL Space Abends
https://www.garlic.com/~lynn/2002k.html#18 Unbelievable
https://www.garlic.com/~lynn/2002k.html#38 GOTOs cross-posting
https://www.garlic.com/~lynn/2002k.html#52 Dump Annalysis
https://www.garlic.com/~lynn/2002l.html#39 Moore law
https://www.garlic.com/~lynn/2002m.html#24 Original K & R C Compilers
https://www.garlic.com/~lynn/2002n.html#71 bps loader, was PLX
https://www.garlic.com/~lynn/2002o.html#51 E-mail from the OS-390 ????
https://www.garlic.com/~lynn/2002p.html#2 IBM OS source code
https://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet (fwd)
https://www.garlic.com/~lynn/2003.html#62 Card Columns
https://www.garlic.com/~lynn/2003b.html#19 Card Columns
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003c.html#43 Early attempts at console humor?
https://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard?
https://www.garlic.com/~lynn/2003c.html#78 The relational model and relational algebra - why did SQL become the industry standard?
https://www.garlic.com/~lynn/2003d.html#22 Which Editor
https://www.garlic.com/~lynn/2003d.html#25 Which Editor
https://www.garlic.com/~lynn/2003e.html#29 MP cost effectiveness
https://www.garlic.com/~lynn/2003e.html#75 History of project maintenance tools -- what and when?
https://www.garlic.com/~lynn/2003f.html#3 Alpha performance, why?
https://www.garlic.com/~lynn/2003f.html#4 Alpha performance, why?
https://www.garlic.com/~lynn/2003g.html#46 death of Edgar F. (Ted) Codd
https://www.garlic.com/~lynn/2003g.html#52 Mercury News 04-20-2003 Computer pioneer, dead at 79,
https://www.garlic.com/~lynn/2003g.html#67 death of Edgar F. (Ted) Codd
https://www.garlic.com/~lynn/2003i.html#58 assembler performance superiority: a given
https://www.garlic.com/~lynn/2003k.html#2 Rexx vs. Batch
https://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
https://www.garlic.com/~lynn/2003m.html#14 Seven of Nine
https://www.garlic.com/~lynn/2003p.html#23 1960s images of IBM 360 mainframes
https://www.garlic.com/~lynn/2004b.html#30 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004b.html#33 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004c.html#2 Oldest running code
https://www.garlic.com/~lynn/2004c.html#9 TSS/370 binary distribution now available
https://www.garlic.com/~lynn/2004c.html#34 Playing games in mainframe
https://www.garlic.com/~lynn/2004c.html#35 Computer-oriented license plates
https://www.garlic.com/~lynn/2004c.html#61 IBM 360 memory
https://www.garlic.com/~lynn/2004d.html#17 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#19 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#20 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#21 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#26 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#41 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004d.html#42 REXX still going strong after 25 years
https://www.garlic.com/~lynn/2004e.html#10 What is the truth ?
https://www.garlic.com/~lynn/2004e.html#35 The attack of the killer mainframes
https://www.garlic.com/~lynn/2004e.html#37 command line switches [Re: [REALLY OT!] Overuse of symbolic
https://www.garlic.com/~lynn/2004g.html#42 command line switches [Re: [REALLY OT!] Overuse of symbolic constants]
https://www.garlic.com/~lynn/2004g.html#47 PL/? History
https://www.garlic.com/~lynn/2004g.html#49 Adventure game (was:PL/? History (was Hercules))
https://www.garlic.com/~lynn/2004h.html#10 Possibly stupid question for you IBM mainframers... :-)
https://www.garlic.com/~lynn/2004h.html#39 SEC Tests Technology to Speed Accounting Analysis
https://www.garlic.com/~lynn/2004k.html#34 August 23, 1957
https://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#35 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#47 IBM Open Sources Object Rexx
https://www.garlic.com/~lynn/2004m.html#53 4GHz is the glass ceiling?
https://www.garlic.com/~lynn/2004m.html#54 Shipwrecks
https://www.garlic.com/~lynn/2004o.html#12 some recent archeological threads in ibm-main, comp.arch, & alt.folklore.computers ... fyi
https://www.garlic.com/~lynn/2004o.html#36 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2004p.html#3 History of C
https://www.garlic.com/~lynn/2004q.html#63 creat
https://www.garlic.com/~lynn/2005.html#8 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#45 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#50 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#72 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005d.html#74 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005e.html#0 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005f.html#14 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#15 Where should the type information be: in tags and descriptors
https://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005h.html#37 Software for IBM 360/30
https://www.garlic.com/~lynn/2005h.html#41 Systems Programming for 8 Year-olds
https://www.garlic.com/~lynn/2005h.html#42 Systems Programming for 8 Year-olds
https://www.garlic.com/~lynn/2005h.html#43 Systems Programming for 8 Year-olds
https://www.garlic.com/~lynn/2005j.html#41 TSO replacement?
https://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
https://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
https://www.garlic.com/~lynn/2005n.html#45 Anyone know whether VM/370 EDGAR is still available anywhere?
https://www.garlic.com/~lynn/2005n.html#47 Anyone know whether VM/370 EDGAR is still available anywhere?
https://www.garlic.com/~lynn/2005o.html#38 SHARE reflections
https://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2005p.html#19 address space
https://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
https://www.garlic.com/~lynn/2005r.html#29 Job seperators
https://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
https://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l Date: Tue, 29 Nov 2005 09:47:03 -0700Jim Bohnsack writes:
very early on, i wanted to demonstrate that rexx could be used as an application development language. the vm/cms dump processing facility was a few score k-lines of assembler with a dept. in endicott supporting it. i wanted to demonstrate that working half time over three months, i could use rexx to re-implement the facility from scratch with ten times the function and ten times the performance .... neat trick by itself for an interpreted language compared to pure assembler ... turns out part of the trick was a 120 line assembler stub routine used by dumprx for the actual interfacing to dump files.
misc. collectes posts on the subject
https://www.garlic.com/~lynn/submain.html#dumprx
eventually, at one point it was in use by nearly all internal vm locations as well as vm PSRs.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l Date: Tue, 29 Nov 2005 12:53:43 -0700Jim Bohnsack writes:
the talk was in the heyday of the oco arguments and i got the satisfaction of pointing out that if dumprx would have shipped as a product, nearly all of the source code would have had to ship with it (since it was source code interpreted rexx).
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers Date: Wed, 30 Nov 2005 08:02:15 -0700Alan Ackerman writes:
big thing about fulist, browse, ios3270, ... were that they were small, compact, and extremely efficient. early on fulist & browse would fit in 8k. this contributed to making early ports to ibm/pc environment so easy. by the time filelist came around, fulist had gained some amount of maturity and it was straight-forward for people to do a fulist clone in the filelist implementation (as well as rdrlist).
this is analogous to my comments about doing dumprx as a dumpscan
clone ... using rexx (and eventually offering both line-mode and
xedit-mode) ... although offering 10-times the function and 10-times
the performance (some slight of hand to get significant increased
efficiency in interpreted rexx over hard coded assembler). past
references
https://www.garlic.com/~lynn/submain.html#dumprx
small, compact and extremely efficient used to be a lot more important than it is now. i frequently now work in gnuemacs ... and regularly use dir (and nobody will claim that gnuemacs is small, compact, and extremely efficient).
at one point i had done a green/blue/yellow card implementation in
ios3270 ... these days it would be done in html and use a browser
(again significantly more bloated implementation than ios3720).. blue
card was for 360/67 and had the virtual memory add-ons to base 360,
but there was a lot of spare ... so it threw in detailed sense
information for various devices) ... minor past reference:
https://www.garlic.com/~lynn/99.html#60 Living legends
it isn't so much an either/or regarding FULIST and FILELIST ... modulo the compact/efficiency issues. FULIST was relatively mature by the time people started making clones of it, like FILELIST (the old line about imitation being the sincerest form of flattery).
another example is vmsg. vmsg was one of the early email clients (and all assembler implementation). . something like a version 0.6 of the code was borrowed by the PROFs group and used as the guts of PROFs mail handling. Later when an issue was raised as to the origin of the PROFS code ... it was pointed out that every PROFS message in the world had the initials of the VMSG author as a comment addenda out at the end of the tag field. in any case, after some years, I did a VMSG-clone implemented in REXX and XEDIT. Later, I added SMTP/RFC822 input/output processing.
misc. past postings w/vmsg reference:
https://www.garlic.com/~lynn/99.html#35 why is there an "@" key?
https://www.garlic.com/~lynn/2000c.html#46 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#39 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2001k.html#40 Newbie TOPS-10 7.03 question
https://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
https://www.garlic.com/~lynn/2002h.html#58 history of CMS
https://www.garlic.com/~lynn/2002h.html#64 history of CMS
https://www.garlic.com/~lynn/2002j.html#4 HONE, ****, misc
https://www.garlic.com/~lynn/2002p.html#34 VSE (Was: Re: Refusal to change was Re: LE and COBOL)
https://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem structure (long warning)
https://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
https://www.garlic.com/~lynn/2003j.html#56 Goodbye PROFS
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l,alt.folklore.computers Date: Wed, 30 Nov 2005 08:45:27 -0700Anne & Lynn Wheeler writes:
Jim Gray and I (and others) were sitting around drinking one
friday night (before he left for tandem) ... back in the days
of system/r (original relational/sql)
https://www.garlic.com/~lynn/submain.html#systemr
talking about what silver-bullet application could we come up with that would tempt a lot of non-computer literate employees to start using online computing (besides the quickly emerging email application) ... and came up with the idea of a highly efficient online corporate telephone book. so the ground rules were two fold ... it had to be blazingly fast, the application had to take less than one-week to implement and the administration processing gorp for keeping all the data up-to-date and distributing it ... had to take less than one-person day per month.
so the online phone book routine used radix search on sorted cms files ... which gave a noticeable improvement over binary search (we actually calcualted letter frequency distribution for names and used that for a modified radix search).
so what does this have to do with implementing a vmsg-clone in rexx & xedit? well default vmsg was to do sequential scan of nickname files ... and this was starting to be somewhat more time-consuming when you had a 25,000 entry nickname file (which was much smallter than the aggregate number of entries in the collected online corporate telephone directories). so a trivial addition to vmsg-clone implemented in rexx ... was to do a modified radix-search ... similar to the implementation done for the corporate telephone directories.
misc. past posts mentioning the online telephone directories and/or
modified radix search (using calculate letter frequency):
https://www.garlic.com/~lynn/94.html#31 High Speed Data Transport (HSDT)
https://www.garlic.com/~lynn/2001c.html#88 Unix hard links
https://www.garlic.com/~lynn/2002e.html#33 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2004c.html#0 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004p.html#13 Mainframe Virus ????
https://www.garlic.com/~lynn/2005c.html#38 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#43 History of performance counters
https://www.garlic.com/~lynn/2005s.html#3 Flat Query
https://www.garlic.com/~lynn/2005s.html#4 Flat Query
this helped contribute to a different problem. at the time, there was supposedly an issue with the availability of 3270 terminals ... and there was requirement for division vp sign-off for internal 3270 requests and associated delays could be six months. there was this point in time when middle-management discovered that higher level executives were starting to use online email ... and all of a suddened, every middle manager in the company seemed to demand an immediate 3270 terminal on their desk. this, in turn, pre-empted the whole six month 3270 terminal provisioning process for those programmers that actually needed 3270 for things like development (effectively six months of internal 3270 terminal deliveries were pre-empted).
to help breakup that log-jam, we put together a business analysis that 3-year fully depreciated 3270 capital costs turned out to be less than monthly phone expense ... and nobody was suggesting that it should require division vp approval whether an employee got a phone on their desk or not.
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l Date: Wed, 30 Nov 2005 09:56:45 -0700Jim Bohnsack writes:
i added sense information to it ... including sense for HYPERchannel A220 adapters ... this started when IMS developers were being relocated to remobte bldg. from STL ... and they hated the idea of putting up with remote 3270 slowness. I did the drivers for HYPERchannel to use it as channel extension over high-speed m'wave link supporting "local" 3270s at the remote bldg (to the datacenter in stl). turns out the overall performance was actually better with 3270s over HYPERchannel channel extension than when they were directly attached.
later i did the rfc1044 A220 driver for the original ibm tcp/ip
support. The standard tcp/ip (with 8232) would get about 44kbytes/ sec
and consume a 390 proceessor. With a little tuning at cray research
between a cray and a 4341 ... we got full (4341) channel speed
(1mbyte/sec) sustained, using only a modest amount of the 4341
processor
https://www.garlic.com/~lynn/subnetwork.html#1044
in any case, i somehow managed to loose my original copy of gcard and would like a copy ... i'm wondering how easy it will be to convert to html and put on garlic.
yes, i would like a copy (does it still have a220 and other device sense information?)
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: winscape? Newsgroups: alt.folklore.computers Date: Wed, 30 Nov 2005 10:38:29 -0700jmfbahciv writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: What is written on the keys of an ICL Hand Card Punch? Newsgroups: alt.folklore.computers Date: Thu, 01 Dec 2005 07:49:00 -0700"Charlie Gibbs" writes:
for a little drift, there has been recent thread in vmesa-l n.g.
about fulist, browse, and ios3270 ... all (early) 3270 full-screen
applications. i brought up having done some stuff on gcard (greencard)
3270 application from the late 70s ... and somebody kindly set me an
old copy. yesterday, i've done an initial quick & dirty conversion to
html
https://www.garlic.com/~lynn/gcard.html
the original ios3270 was much more 24x80 screen formated with some scroll functions on each screen. things were also light pen selectable .. which i've loosely converted to hrefs. while real green card gives the punch card values for each hexadecimal values ... this was left off the ios3270 version of greencard.
I had added sense data to gcard ... which was from 360/67 blue card.
I then included sense data for HYPERchannel A220 adapter ... having
done a couple A220 drivers for various projects related to HSDT
https://www.garlic.com/~lynn/subnetwork.html#hsdt
as well as rfc1044 support for an early mainframe tcp/ip product
https://www.garlic.com/~lynn/subnetwork.html#1044
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: FULIST Newsgroups: bit.listserv.vmesa-l Date: Thu, 01 Dec 2005 07:50:56 -0700Anne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | https://www.garlic.com/~lynn/
From: lynn@garlic.com Subject: Re: FULIST Date: Sat, 03 Dec 2005 11:49:18 -0800 Newsgroups: bit.listserv.vmesa-l,alt.folklore.computersjmfbahciv@aol.com wrote:
From: lynn@garlic.com Subject: Re: non ECC Date: Sat, 03 Dec 2005 21:19:20 -0800 Newsgroups: alt.folklore.computersararghmail512NOSPAM@NOW.AT.arargh.com wrote:
so far:
2301 fixed-head/track (2303 but r/w four heads in
parallel)
2303 fixed-head/track r/w single head (1/4th rate of
2301)
Corinth 2305-1 fixed-head/track
Zeus 2305-2 fixed-head/track
2311
2314
2321 data-cell "washing machine"
Piccolo 3310 FBA
Merlin 3330-1
Iceberg 3330-11
Winchester 3340-35
3340-70
3344 (3350 physical drive simulating multiple 3340s)
Madrid 3350
NFP 3370 FBA
Florence 3375 3370 supporting CKD
Coronado 3380 A04, AA4, B04
EvergreenD 3380 AD4, BD4
EvergreenE 3380 AE4, BE4
3830 disk controller, horizontal microcode engine
Cybernet 3850 MSS (also Comanche & Oak)
Cutter 3880 disk controller, jib-prime (vertical) microcode
engine
Ironwood 3880-11 (4kbyte/page block 8mbyte cache)
Sheriff 3880-13 (full track 8mbyte cache)
Sahara 3880-21 (larger cache for "11")
?? 3880-23 (larger cache for "13")
>
collected past posts mentioning bldg. 14 (disk engineering lab) and
bldg. 15 (disk product test lab) during the period that 3350s, 3380s,
3880s, etc. were being developed
later in the mid-80s, working on hsdt ...
https://www.garlic.com/~lynn/subnetwork.html#hsdt
in the mid-80s, we did some work with company in berkeley called
cyclontics that got bought up by kodak. they specialized in
reed-solomon fec and were involved in the encoding for cdrom standard
https://www.garlic.com/~lynn/2001.html#1 4M pages are a bad idea (was Re: AMD 64bit Hammer CPU and VM)
https://www.garlic.com/~lynn/2002p.html#53 Free Desktop Cyber emulation on PC before Christmas
https://www.garlic.com/~lynn/2003e.html#27 shirts
https://www.garlic.com/~lynn/2004f.html#37 Why doesn't Infiniband supports RDMA multicast
https://www.garlic.com/~lynn/2004o.html#43 360 longevity, was RISCs too close to hardware?
https://www.garlic.com/~lynn/2005n.html#27 Data communications over telegraph circuits
misc. other posts mentioning reed-solomon fec:
https://www.garlic.com/~lynn/93.html#28 Log Structured filesystems -- think twice
https://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
https://www.garlic.com/~lynn/99.html#210 AES cyphers leak information like sieves
https://www.garlic.com/~lynn/2000c.html#38 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2001b.html#80 Disks size growing while disk count shrinking = bad performance
https://www.garlic.com/~lynn/2001k.html#71 Encryption + Error Correction
https://www.garlic.com/~lynn/2002e.html#53 Mainframers: Take back the light (spotlight, that is)
https://www.garlic.com/~lynn/2003h.html#3 Calculations involing very large decimals
https://www.garlic.com/~lynn/2003j.html#73 1950s AT&T/IBM lack of collaboration?
https://www.garlic.com/~lynn/2004h.html#11 Mainframes (etc.)
https://www.garlic.com/~lynn/2005k.html#25 The 8008
https://www.garlic.com/~lynn/2005r.html#52 Go-Back-N protocol?
From: lynn@garlic.com Subject: Re: RSA SecurID product Date: Sun, 04 Dec 2005 10:44:17 -0800 Newsgroups: bit.listserv.vmesa-lVin McLellan wrote:
for some topic drift ... RSA crypto stuff (being done by rsa) was
independent of the securid stuff (being done by security dynamics) ...
then security dynamics acquired rsa (and eventually consolidated the
different products under a single corporate name)
http://www.crn.com/sections/breakingnews/dailyarchives.jhtml;jsessionid=JTYYQIECDT3VYQSNDBOCKHSCJUMEKJVN?_requestid=497268
on the crypto and digital certificate side ... recent thread in
cryptography mailing list
https://www.garlic.com/~lynn/aadsm21.htm#22 Broken SSL domain name trust model
https://www.garlic.com/~lynn/aadsm21.htm#23 Broken SSL domain name trust model
https://www.garlic.com/~lynn/aadsm21.htm#24 Broken SSL domain name trust model
https://www.garlic.com/~lynn/aadsm21.htm#25 Broken SSL domain name trust model
From: lynn@garlic.com Subject: Re: PGP Lame question Date: Sun, 04 Dec 2005 18:06:22 -0800 Newsgroups: sci.cryptAri Silverstein wrote:
the technology is asymmetric key cryptography ... what one key encodes, the other key decodes (to distinguish from symmetric key where the same key is used for encoding and decoding).
there is public key business process which defines one key to be public and made freely available; the other key is identified as private, kept confidential and never divulged.
there is digital signature business process, where the hash of some message/document is calculated and then encoded with the private key producing the digital signature ... the originator then can transmits the message/document along with the digital signature.
the recipient recalculates the hash of the message/document, decodes the digital signature with the appropriate public key and compares the two hashes. if they are identical, then the recipient can assume:
1) the message/document has not been modified since it was digitally signed
2) something you have authentication ... i.e. the sender had access to, and use of the appropriate private key.
... aka from three factor authentication
https://www.garlic.com/~lynn/subintegrity.html#3factor
1) something you have
2) something you know
3) something you are
the confidence that a recipient has in the authentication process may be proportional to the integrity of the infrastructure protecting the private key ... i.e. is it kept in encrypted emulated software container requiring a password for use ... is it kept in hardware token (and what are the integritry characteristics of the hardware to token).
the additional requirement for a pin/password to make use of the private key (either for decrypting a software file or activiating a hardware token) can contribute to two-factor authentication ... aka something you have (the private key) and something you know (the pin/password) .... nominally such pin/passwords are countermeasure to having the something you have being lost/stolen.
in some non-pgp digital signatures that involve PKIs and x.509 digital certificates ... things drift in a different direction ... which has nothing particularly to do with the integrity of the authentication part of the operation.
in the pki scenario with x.509 digital certificates .... the sender appends a x.509 identity certificate to the original message/document and digital signature (as described above). The purpose of the appended x.509 identity certificate is to convert all authentication events (even the most trivial and simplest) into heavy duty identification events. This has contributed to a lot of confusion being able to differentiate authentication and identification.
some of the pki efforts have also contributed to confusing the different between an authentication digital signature and a human signature which implies read, understood, agrees, approves, and/or authorizes (including some of the efforts that included definition of non-repudiation characteristic in digital signature standardization efforts). i highlighted some of this in a discussion about dual use attack .... where simple authentication operation involves a server sending some random data (as countermeasure to replay attacks), and the recipient digital signs the random data as simple authentication (returning the digital signature of the random data). If this was an attacker, they could have substituted some valid transaction information in lieu of random data ... and then claim that the digital signature is proof of read, understood, agrees, approves, and/or authorizes.
collection of some past posts that touch on the significant gap between
authentication digital signatures and read, hunderstood, agrees,
approves, and/or authorizes human signatures
https://www.garlic.com/~lynn/subpubkey.html#signature
the enromous privacy invasive characteristics of x.509 identity digital
certificates were somewhat recognized in the mid-90s and contributed to
the creation of relying-party-only digital certificates
https://www.garlic.com/~lynn/subpubkey.html#rpo
some number of past posts on the topic of confusing authentication and
identification (and enormous privacy invasive characteristics when even
trivial authentication digital signature operations are required to
include x.509 identity digital certificates).
https://www.garlic.com/~lynn/aepay11.htm#69 Confusing Authentication and Identiification?
https://www.garlic.com/~lynn/aepay11.htm#72 Account Numbers. Was:Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay11.htm#73 Account Numbers. Was: Confusing Authentication and Identiification? (addenda)
https://www.garlic.com/~lynn/aepay12.htm#0 Four Corner model. Was: Confusing Authentication and Identification? (addenda)
https://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
https://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
https://www.garlic.com/~lynn/aadsm15.htm#38 FAQ: e-Signatures and Payments
https://www.garlic.com/~lynn/aadsm18.htm#32 EMV cards as identity cards
https://www.garlic.com/~lynn/aadsm18.htm#38 How to store the car-valued bearer bond? (was Financial identity...)
https://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID?
https://www.garlic.com/~lynn/aadsm20.htm#9 the limits of crypto and authentication
https://www.garlic.com/~lynn/aadsm21.htm#17 continuity of identity
https://www.garlic.com/~lynn/2002m.html#19 A new e-commerce security proposal
https://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', how curruptable are they to
https://www.garlic.com/~lynn/2003j.html#47 The Tao Of Backup: End of postings
https://www.garlic.com/~lynn/2003l.html#33 RSA vs AES
https://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
https://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#9 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
https://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
https://www.garlic.com/~lynn/2005f.html#20 Some questions on smart cards (Software licensing using smart cards)
https://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
https://www.garlic.com/~lynn/2005i.html#24 The Worth of Verisign's Brand
https://www.garlic.com/~lynn/2005j.html#64 More on garbage
https://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Siganture (PKI/OCES - or what else they're called)
https://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance
https://www.garlic.com/~lynn/2005s.html#10 NEW USA FFIES Guidance
https://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product