[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. JeffH
--- Begin Message ---
- From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
- To: "'reagle@w3.org'" <reagle@w3.org>, wss-comment@lists.oasis-open.org
- Date: Tue, 10 Sep 2002 10:41:23 -0700
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 design. 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 Signature Reference #ticket Encryption Reference #ticket We certainly do NOT want Security // K-Yucky Signature Token Encryption 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 required] If you are doing public key direct on the messages then you have a bunch of choices: Security // P-Consistent Token id=senderKey Token id=receiverKey Signature Reference #senderKey Encryption Reference #receiverKey Security // P-Direct Token id=senderKey Token id=receiverKey Signature Reference #senderKey Encryption Reference #receiverKey I think we also need to consider the likely general case: Security // P-Double Token id=ticket Signature Reference #ticket Reference #senderKey Encryption 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 ugly. 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. Phill > -----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