OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wss] Fwd: RE: [wss-comment] Easy Question: Why not useds:RetrievalMethod

These issues should probably be discussed here 'mongst us'ns. 

--- Begin Message ---
I think that Joseph has hit on one of the hardest parts of WS-Security to
spec, the difficulty being due to the fact that you are forced to chose
between consistency constraints and there is no forcing function - i.e.
unless it is done this way something will break.

Regardless of which side is right or even whether there is a 'right' answer
we certainly need to improve the presentation and explanation of the current

The problem with 'just use KeyInfo' comes as I see it when you use a
Kerberos ticket with encryption and signature simultaneously. You end up
with using the same token in two places which indicates that it is a design
element that should be factored out and promoted to the top level.

This issue will come up with any symmetric token.

If one applies only asymmetric processing then the issue can be finessed.
However I very much doubt that in the long term any Web Services will use
Public Key based authentication on its own. What I expect to be the norm for
any high value transaction is to pre-exchange a shared secret and combine a
shared secret message authentication with a digital signature. The shared
secret being used for denial of service protection prior to performing the
signature verification. This architecture also allows for signature
verification to be suspended in cases of sudden use spikes (c.f. Xmas
shopping effect on VISAnet).

As I see it there are a bunch of options arround this, none of which is
perfect and none of which is unworkable:

Kerberos is the easy one:

Security			// K-Good
	Token id=ticket
		Reference #ticket
		Reference #ticket

We certainly do NOT want

Security			// K-Yucky
		Token		// Again...

[NB here I am using Kerberos as a synonym for a shared secret since I
strongly suspect that any future Web Services key agreement mechanism is
likey to be spitting out Kerberos tickets whenever an identifier for a
private key that incorporates an encrypted version of that private key is

If you are doing public key direct on the messages then you have a bunch of

Security			// P-Consistent
	Token id=senderKey
	Token id=receiverKey
		Reference #senderKey
		Reference #receiverKey

Security			// P-Direct
	Token id=senderKey
	Token id=receiverKey
		Reference #senderKey
		Reference #receiverKey

I think we also need to consider the likely general case:

Security			// P-Double
	Token id=ticket
		Reference #ticket
		Reference #senderKey
		Reference #ticket

The debate needs to also recognize the distinction between a KeyInfo block
and a token:

	* A KeyInfo element identifies a key
	* A Security Token identifies a key bearer

We should also ask the questions:

	A: Should we constrain WS-Security so that there is a requirement to
place a particular type of key bearer information

	B: Should we help others to define such constraints?

So there might be a WS-Security/Restricted specification that stated
something like

	* The key reference shall be an Xlink pointer
	* All keying material is to be identified in a security token block
	* Signature and Encryption blocks contain only a retrieval method
link to the security token block
	* The C18N algorithm is ExclusiveSchemaCentricPackedWithComments
	* Perhaps even cipher suites

On the second point of just using the retrieval method to perform the
linkage, the issue here I guess is that retrieval method does have some
pretty implicit 'retrieval' semantics and at this point I think it is
probably justified to ask what effect this would have on the various
implementers of XML Signature and whether the result would be unjustifiably

As a matter of policy I do not like any situation that requires me to use
XPath to navigate within the same document to an element that I knew I had
to navigate to when the document was created.

It may well be that re-use of the retrieval method element is cleaner for
existing implementations since then we don't have an escape into ANY and
lose the ability to parse.


> -----Original Message-----
> From: Joseph Reagle [mailto:reagle@w3.org]
> Sent: Tuesday, September 10, 2002 6:34 AM
> To: wss-comment@lists.oasis-open.org
> Subject: [wss-comment] Easy Question: Why not use ds:RetrievalMethod
> In the 1.2 Example, for exampe:
> 1. Why is the token in the header, and not a child of 
> KeyInfo? Is this 
> because the header is necessary for demonstrating the order 
> of processing? 
> (The actual key could still be in a KeyInfo even if you indicated a 
> processing step in the header...?)
> 2. Within the KeyInfo, why not use a ds:RetrievalMethod instead of:
>   (023)        <ds:KeyInfo>
>   (024)            <wsse:SecurityTokenReference>
>   (025)             <wsse:Reference URI="#MyID"/>
>   (026)            </wsse:SecurityTokenReference>
>   (027)        </ds:KeyInfo>
> -- 
> 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/
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
--- End Message ---

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC