[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [egov] Missing Securty: Update Working Draft for Workflow Standards
Dear Joe & Monica I believe that you did not read the head-line on page two of my document. The key-word is "end-2-end security". This is the foundation of the Federal PKI. It among many things means that the sender encrypts a message for the _ultimate_ recepient. If there is a three- or four-letter acronym making this compatible with information system servers, like solving question #2 and #3 in my document, you have in some way apparently broken the RSA algorithm! There is something fishy going on here. regards Anders R ----- Original Message ----- From: "Monica J. Martin" <Monica.Martin@Sun.COM> To: "Chiusano Joseph" <chiusano_joseph@bah.com>; "Anders Rundgren" <anders.rundgren@telia.com> Cc: "OASIS eGov list" <egov@lists.oasis-open.org> Sent: Tuesday, October 05, 2004 16:21 Subject: Re: [egov] Missing Securty: Update Working Draft for Workflow Standards >Chiusano: Anders, thanks for this document. I've glanced over it, and I believe >that it's highly possible that the issues raised in this document can be >satisfied not only by SAML (as mentioned earlier), but possibly by a >combination of OASIS Web Services Security (the now "official" full name >of WS-Security, aka "WSS") and W3C XKMS (XML Key Management >Specification), whose version 2.0[1] is currently a Candidate >Recommendation as of April 2004. That is, XKMS would be employed to >manage (distribute and register) the PKI certificates that are >referenced/placed within WSS headers. > >I know that there was discussion within the XKMS committee sometime in >2003 regarding a white paper to this end, but as of late 2003 I was told >that there had been no movement on it past discussion. You may want to >present your document to the XKMS committee for their feedback. > >[1] http://www.w3.org/TR/xkms2/ > mm1: We may have multiple types/levels of requirements here: * Transport security: Agree with Joe that SAML, WSS, + provide controls at the messaging level. * Discovery (if a registry used): Process artifacts may be stored and discoverable; ebXML Reg/Rep for example is planned (soon) to use SAML and provides access controls. * Process artifacts (in addition to above): Some process artifacts could be 'packaged' and made available to partners, customers, communities, etc. I would envision that messaging level security could handle this. However, I also refer back to my original comments about how the process 'provides guidance' about the underlying infrastructure based on the business requirements (see: http://www.oasis-open.org/archives/egov/200410/msg00009.html). There are then two facets (at a minimum): 1) making the artifacts available for review and use and 2) inferring business requirements on their use. * Process execution: Environment may provide the security. That's not to say that the executing or processes being monitored may not require some level of security. I'll think more about that and would encourage any comments. One final (for this round) comment, in this world of loose-coupling, allowing the process to be independent of the underlying infrastructure provides quite a bit of flexibility. That's not to say the use of the process will unconstrained and, as noted, may place conditions on execution. The process itself may evidence QoS properties related to auditability, persistence, etc. Thanks.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]