Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

This page is powered by Blogger. Isn't yours?


Trusted Computing Group: Home.  This is a very interesting organization. The FAQ emphasizes complete support for the autonomy of the owner of a system.  This seems very interesting in terms of operating a "trust stack" in software, maybe even for something like a Miser system. It does not do anything differently about what trust is or what it requires.  It does support for technical elements that might be valuable in supporting the securing of trust structures.

Testing information systems during development will prevent problems.  This public release is about grouping the 350+ metrics for OO Systems and determining where they are best applied to have the maximum impact on delivery and reliability. The full paper is available in ACM Computing Surveys.


Don Box's Spoutlet.  Oh my, Don Box has his own Blog (called Spoutlet) on various topics. No recent rants though. C'mon Don, let your hair down a little.

Dr.Bob Examines... #41: C# Web Services with only the .NET Framework SDK.  This is an interesting article that does the Web Services job without anything but the basic .NET Framework SDK. It is interesting that the support is that complete.

XML Files: WSDL, Web Services, and More -- MSDN Magazine, December 2002.  This article discusses available tools and also illuminates what can be found in the .NET SDK that supports WSDL.

SearchWebServices.com, the source for information on Web services and application integration.  Another interesting site, with more of a portal and newsy flavor.  Worth looking at more deeply.

alphaWorks : Emerging Technologies Toolkit : Requirements.  Important preparation for download of some of these tools.  Setting the JAVA_HOME environment variable seems especially important and I should set thet up permanently anyhow.

developerWorks: Web services : Emerging Technologies Toolkit.  IBM has a toolkit that supports Web Services and other tracks in the Emerging Technologies area.

Cover Pages: Web Services Description Language (WSDL).  Here are the cover pages on WSDL that are important in the informing of discusssion in this week's Web Applications discussions.

www.xmethods.net.  A place where try-outs of Web Services can be found. There is also security capability.  This illustrates what a good brokerage might look like.  The XSpace can be accessed by a number of these functions.

Systinet - the web services software and infrastructure company making it easy to build, deploy, secure and manage SOAP Web services.  The home page for these folks. There is interesting material on WS Security and how it is supported.  Also, WASP supports SOAP 1.2 as well.

Utility Web services Panel.  A systinet page that describes WASP Server for Java.

ALTOVA - XML Development, Data Mapping, and Content Authoring Tools.  The xmlspy folk have some ideas about other applications of XML, including WSDL, etc.

http://www.capescience.com/resources/wsindex.shtml.  This is a great site for some free utilities and very nice resources and links.  Courtesy of Frank Cook, the instructor for our Web Applications class.


Spoofing.  More on internet security and the kinds of attacks that are carried out against packets on the net.


OpenSSL: The Open Source toolkit for SSL/TLS.  I need to dig up the SSL specifications, and OpenSSL is an useful way to dig into it. There are apparently nice tools for working with X.509 certificates, once you get the hang of it. My associate, Bill Anderson, is struggling with them. Meanwhile, I am looking because of its relationship to SOAP-SEC with SOAP HTML Binding.

IETF rfc2828: Informational: Internet Security Glossary.  This looks like a valuable too. It is a large file (204 pp) with comprehensive information.  It is cited by the SOAP-SEC document.

SOAP Security Extensions: Digital Signature.  This is a W3C Note (06 February 2001) that describes the SOAP-SEC extensions. These use XML Digital Signatures and create a SOAP Header Block and a namespace for the necessary additions.  This material is out of date, and should be updated for SOAP 1.2.  Also, the Security considerations deserve a very careful review and understanding.

SOAP security extensions: digital signature.  Here's an article by Satoshi Hada at IBM, the proponent of SOAP-DSIG.  This article (from August 2001) is valuable in that it relates how SOAP-DSIG works with SSL when the SOAP HTML Binding is used. The XML Digital Signature work has been completed since this article was written. SOAP-DSIG remains pertinent.

The article explains how SSL can be used to "authenticate" a client or a server, but client authentication is fairly rare. That could be used on behalf of SOAP security, however.  The part that I find off in this article is that it assumes that SSL provides sender/receiver authentication (that is, as to identity), and it doesn't do that. It is more about the path to the URL that is being authenticated.  It has not dealt with that actual authentication of the parties engaged in the transaction.

So there seems to be more involved.

PRIVACY Forum Archive Document - (priv.09.15).  This issue features Real Networks tireless efforts to collect data about something from us, no matter how often they get caught at it.  In the context of our class discussion of SOAP, I guess it is more about the wormy nature of much automatically-downloaded software "helpers." It would be good to find ways to block those outgoing requests and reports in creative ways.  And not do business with people who don't respect your sovereignty and think you machine is there's to do themselves some good with.

Counterpane: Crypto-Gram: June 15, 2000.  This is Bruce Schneier's newsletter where he questions the advisability of the SOAP HTTP Binding: "SOAP (Simple Object Access Protocol) is a proposed standard for linking Internet applications running on different platforms, using XML messages. SOAP is designed to connect together programs running on different machines, without regard to what OS/CPU is on each. It's basically remote procedure calls (RPC) implemented via HTTP with XML content. Because no security is required in either HTTP, XML, or SOAP, it's a pretty simple bet that different people will bungle any embedded security in different ways, leading to different holes on different implementations. SOAP is going to open up a whole new avenue for security vulnerabilities. "

Classmate John Walker Stewart cites this in our discussions of SOAP security this week. I think that Scheier's reminder of human foibles, and especially the foibles of software developers attempting interoperable solutions to security for an open protocol standard, are important.

Schneier also promotes the idea of ductility in security systems (as well as transparency). I don't know what ductility might be in this case, but using the SOAP RPC inside of the SOAP HTTP Binding may well be disqualified.  More to study, more to learn ...

The Atlantic | September 2002 | Homeland Insecurity | Mann.  I love articles about Bruce Schneier as much as I enjoy articles by him. This one, by Charles Mann, is long and packed, along with the usual respect for Schneier the restaurant seaker.

Here is the end of this great article, that I found following links from classmate John Walker Stewart: "When I asked Schneier why Counterpane had such Darth Vaderish command centers, he laughed and said it helped to reassure potential clients that the company had mastered the technology. I asked if clients ever inquired how Counterpane trains the guards and analysts in the command centers. 'Not often,' he said, although that training is in fact the center of the whole system. Mixing long stretches of inactivity with short bursts of frenzy, the work rhythm of the Counterpane guards would have been familiar to police officers and firefighters everywhere. As I watched the guards, they were slurping soft drinks, listening to techno-death metal, and waiting for something to go wrong. They were in a protected space, looking out at a dangerous world. Sentries around Neolithic campfires did the same thing. Nothing better has been discovered since. Thinking otherwise, in Schneier's view, is a really terrible idea. "

SANS / FBI The Twenty Most Critical Internet Security Vulnerabilities.  We're talking about SOAP in our on-line Web Applications module, and we all just love to talk about security.  Here's a great link offered up by classmate John Walker Stewart. I need to go through every one of these for my Windows systems and establish that all appropriate protections are in place.

Hard Hat Area

an nfoCentrale.net site

created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 10-04-05 22:20 $
$$Revision: 4 $