RE: [egov] Missing Securty: Update Working Draft for Workflow Standards

["Chiusano Joseph" <chiusano_joseph@bah.com>]

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.
> 
>