[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
Anders, Thanks for the additional information. I'm looking at p.2 of your document now, and I believe that this can/should be handled through some type of contract between the two organizations, with a certain level of mutual trust specified. I see this as more of an operational issue. Please let me know if there are more specifics either within our outside your document that may factor in, that I have not taken into account. We can also keep in mind that end-to-end security is much more than PKI, and in fact may not even involve PKI at all (as described in the WSS specifications). I know this is something you definitely know - I'm just choosing to point it out for purposes of the thread. Kind Regards, Joe Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World > -----Original Message----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Tuesday, October 05, 2004 10:50 AM > To: Monica J. Martin; Chiusano Joseph > Cc: OASIS eGov list > 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]