RE: Following up on XML Security

I think that there are issues that have to be fixed in both groups, but that
the bulk of the work should be done in XKMS. Otherwise I agree with Stephen,
except to say that if the work is going to take place in W3C it is going to
have to start very, very soon.

We need to add handling of kerberos keying material to the KeyInfo element
which is probably best addressed in XML Encryption (see below for
explanation). The Security and SecureConversation issues have already been
addressed in XKMS insofar as they relate to problems that any secure web
service must address.

XKMS is very largely complete, but the issue of layering on a common web
services security framework or not inevitably introduces delay. Already
there is an expectation that at some point in the future there will be an
XKMS layered on whatever becomes of the GXA in whatever forum. So it is
likely to be difficult to convince people that a non gxa layered XKMS
represents a stable industry standard consensus.

Given that the GXA/Whatever work in those areas is going to delay XKMS until
it is complete the WG might as well begin addressing the issue.

There are other security issues that have to be considered of course. The
ws-policy and ws-privacy components of the GXA for example, however these
are going to have a dependence on WSDL while implementers of application
specs such as XKMS and SAML can implement without those layers being
completed and so they could be safely left to the July security group. This
is also an area that will progress beyond pure security work and so
chartering a new group night make sense for that reason.


1) Kerberos
	One of the points that has been raised in the discussion of
ws-Security is the manner of binding to Kerberos tickets which several
people have pointed out makes Kerberos a second class citizen to the PKI
based approaches supported by KeyInfo.

	Logically it should be possible to use a Kerberos ticket for any XML
Signature or XML Encryption operation, even when Web Services are not
involved. So we should specify a KeyInfo element for Kerberos.

	This would have additional benefits when a key agreement mechanism
is available. For efficiency reasons it is generally preferable to use a
symmetric key for authentication of actual transactions unless one actually
wants non-repudiation and is prepared to archive the transaction
information. So some form of key agreement to get from public keys to
authenticate the principles to a symmetric key is used. Whether or not one
uses the kerberos protocols for this purpose, Kerberos tickets are likely to
be a pretty good way to package the session key.

	One can even think of cases where one would pair a digital signature
and a kerberos keyed MAC, particularly to prevent DoS conditions, the
service then checks the MAC to see whether it should spend the compute
cycles checking the digital signature



> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@baltimore.ie]
> Sent: Friday, May 31, 2002 6:19 AM
> To: reagle@w3.org
> Cc: w3c-security-ig@w3.org; www-xenc-xmlp-tf@w3.org; hugo@w3.org;
> asirv@webmethods.com; pbaker@verisign.com; Shivaram.Mysore@Sun.COM;
> fallside@us.ibm.com; dturner@microsoft.com; xme
> Subject: Re: Following up on XML Security
> 
> 
> 
> Joseph,
> 
> Its good to see this progressing.
> 
> I'd argue for avenue #1 for tackling the immediate requirement though
> clearly care is needed to ensure that the scope isn't too broad.
> 
> I think avenue #2 still needs to be followed regardless of how the
> immediate requirement is handled since there will (IMO) be a need
> for a much broader view of web services security that can encompass
> e.g. anti-DoS approaches. 
> 
> Having xenc or xkms provide the mechanism and a ws wg write up how 
> and when to use the mechanism sounds about right.
> 
> Also, I'd be surprised if avenue #2 could really get started 
> in July (but
> great, if so!), and when they start one thing they'll have to tackle
> is the relationship with the xrml/xacml/saml and other work in oasis
> which might delay things 'till the end of the summer all by itself;-)
> 
> Finally, I could argue either way as to whether xenc or xkms is the
> better wg, but on balance I'd lean toward xkms since I see xkms as
> being between xenc and soap in the stack, so maybe the xkms interested
> parties are more likely to interested. One option would be to 
> poll the 
> two wgs and see which is the more enthusiastic.
> 
> Stephen.
> 
> Joseph Reagle wrote:
> > 
> > After the discussion regarding the "XML Security Horizon" (at the AC
> > meeting and elsewhere) the obvious question is how to best 
> satisfy the
> > immediate requirement for integrating dsig, xenc, and SOAP. 
> This *should*
> > be straightforward and I've encouraged discussion but 
> evidently absent this
> > work being explicitly part of a chartered activity there 
> won't be much
> > progress because of IPR concerns.
> > 
> > There are two potential avenues.
> > 1. Expand the charter of an existing WG. xenc and xkms have 
> been offered as
> > potential candidates. The charters for xenc, xmldsig, and 
> xkms are all due
> > a revision... If we pursue this path, I favor enlarging the 
> scope of xenc
> > since it is already concerned with working with xmldsig in 
> scenarios like
> > SOAP, and if there are any difficult parts of the work, it 
> probably will be
> > related to the attachment/detachment of payloads under 
> signature, which is
> > something the xenc folks are tackling with respect to [1].
> > 2. I understand the WS Arch WG should be proposing a charter for a
> > full-blood web service security WG. I understand they are 
> aiming for end
> > July.
> > 
> > Anyone with thoughts on which specific option you prefer, 
> or expectations
> > regarding the timing of option 2?
> > 
> > [1] http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html
> > 
> > --
> > 
> > Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
> > W3C Policy Analyst                mailto:reagle@w3.org
> > IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
> > W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:stephen.farrell@baltimore.ie
> Ireland                             http://www.baltimore.com
>

Received on Friday, 31 May 2002 11:54:39 UTC