Re: [emergency-if] INTERIM SECURITY STANDARD

[RCarlton@eteam.com]

Hi Art,

 

All great points. Let me address each individually below in blue.

 

R

* I'm wondering whether the extra level of indirection created by 
referencing third-party documents as quasi-normative might create 
some potential problems.  The obvious one, of course, would be what 
happens if a link goes bad at some point in the future.  A less 
obvious one might be the need to disambiguate in any areas of overlap 
between these documents.  Also, some of the recommendations mentioned 
in these documents exist at this time, but it appears that others are 
still in development.  Might we be wise to refer directly to the 
normative documents for the specific security standards we're 
recommending?

As you rightly point out, the additive reference material could cause confusion depending on the ultimate recipient. I was unsure of the specifics regarding the focus of your intended distribution, therefore, wanted to include some general material for those who might not be fully up to speed on XML security processes. On the matter of broken links, yes, that could be a problem but the documents were all produced in the FY 2000-2001-2002 timeframe and were still easily accessed through various search engines (I checked) so I don't believe we'll have an issue with stale dating going forward. 

* Also, I'm a tiny bit concerned about the licensing terms for BPEL 
(<http://dev2dev.bea.com/technologies/webservices/standards_license_BPEL.jsp>)... 
are they really amenable to an open-standards effort like ours?  I'm 
thinking specifically about the patent grant-back requirement, which 
seems like it might trouble some potential implementers.  Since all 
Section 17 of the BPEL document does, really, is recommend rigorous 
use of WS-Security, might we avoid any unnecessary complications by 
simply pointing directly to WS-Security ourselves?

Frankly, this was an initial concern for me as well. However, on reflection not all of the standards components under review are devoid of patient and/or other commercial constraints. As a standards setting entity it is my sense that we have a responsibility to define and recommend a "family" of components predicated on best practices, regardless of whether or not the particular platform originated as a commercial, or public domain offering. Having said that, with the various infrastructures EMIF is currently validating, and the obvious cross-pollination between them, I believe that there will be "something for everyone" in the final recommendation. On the other hand if a simple adoption of the term "Web Services Standards" is an appropriate solution to your problem then that's okay as well.          

* The direct reference to SAML seems appropriate (although personally 
I could benefit from some annotation as to where and how SAML might 
be applied.)

OASIS-SAML is a self-contained markup language oriented to the specifics of systems security. Therefore, both defacto and dejure, it is being proffered as OASIS' standard security language component. 

* The "Getting Started with XML Security" article is a fine tutorial, 
but I'm wondering whether it might create confusion if offered in a 
quasi-normative context.  Again, it seems to point toward 
WS-Security, but it seems to mention various other standards and 
tools.  Are we recommending them all?  Maybe it would make sense to 
specify in our own document which items we're prepared to recommend 
at this early stage, and point to this article as an informative (but 
non-normative) reference.

I chose that particular article as a general reference primer since it was validated and, to varying degree authored by IBM, Oracle and Microsoft in collaboration, thereby providing a common thought framework for considering development issues associated with system security. Since by default the "big three" are "...all of them," and they generally agree on the tenets as defined in the published material, then I guess the short answer would be "yes - start here." On the other hand if you think it confuses the effort, then lets delete it, or I can certainly reference the specifics of each collaborator easily enough. 

* The IBM/Microsoft "roadmap" is also a good overview, but it seems 
to generally come to the same points.  If this is the framework we 
recommend, might we be able to simply point to this document and not 
require the implementer to triangulate it against the other 
documents?  (Maybe even get reprint rights so we could make it part 
of our own record and serve it direct from the OASIS server?)  Or 
else just summarize the key normative recommendations that we're 
embracing (for now, this being only an interim recommendation anyway) 
and not cast our net as wide as this whitepaper?

Again, I included this as a comparative tool to encourage recognition that issues of web security development are, by and large, following a common path and there are little substantive differences in schema regardless of what platform one develops on. Again, however, if you think it's distracting then lets delete it. At the end of the day, my intent was to further substantiate that WS security protocols utilize fairly common processes regardless of "flavor."

All told, the common core of all these documents seems pretty clear: 
SOAP using WS-Security, which incorporates XML Signature,  XML 
Encryption, XML Key Management, SAML and a couple of other 
"accessory" recommendations.  So I wonder whether just saying that 
might be enough for now.

Given that you're the "customer" at this point, if that's your feeling then that's the way we should do it. Having said that, however, I have to wonder at the usefulness of EMIF producing a formal statement to that effect. Wouldn't it be better to simply offer the information anecdotally rather than, to paraphrase your characterization, "publishing the obvious?" Or, is there some political, or other driver, behind the format of response? 

Outstanding research, Rick!  Thanks!

- Art

PS - Much of WS-Security appears to assume the availability of a 
public key infrastructure.  As far as I'm aware, no PKI exists for 
the EM/PS/HS community at this time, although there are some 
potentially related and/or leveragable efforts underway... for 
example, the Emergency Provider Access Directory (EPAD) project. 
Have I missed something?  If not, is this a concern we should 
consider addressing in some fashion? - ACB

Actually, I am following the work of the OASIS-PKI SC with an eye toward that issue. Additionally, the DCTS (Defense Collaboration Tool Suite) you've heard me mention, also embodies PKI/SSL/SSO components that may be applied in this area. So, yes EMIF is aware of the necessity of focus, yes EMIF is considering various deployable solutions, and yes we'll take a look at the EPAD project going-forward.  

Later,

Rick