[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
This approach allows one assertion to contain all the necessary information, at the expense of 2 signatures required by the attester: one to sign the assertion which contains the invocation identity as subject of assertion, and one to sign the message to bind it to the invocation identity. The recipient, by trusting the signing key of the attester now simply has to verify 2 signatures which happen to be signed by the same signer. In the hk case 2 sigs also need to be verified by the recipient by different signers chained thru the SubjectConfirmation/KeyInfo. In the sv case the chaining is implicit since the attester replaces the subject as the signer of the content. The only loose end in all this I believe is a distinction between the attester and the assertion authority. If this level is required then we would have another level of chaining, whereby we would need subject->attester->assertion authority. In this case the assertion authority would need to put the attester's key in an hk assertion as the current example shows. The attester would then sign the sv assertion as described above, and then sign the message. Since we now have 3 levels involved, we need the 2nd hk assertion that the recipient needs to confirm the attester, assuming the recipient ultimately trust the assertion authority. Rich -----Original Message----- From: Ron Monzillo To: Levinson, Richard Cc: wss@lists.oasis-open.org Sent: 1/30/2004 7:06 PM Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded Levinson, Richard wrote: >Replies interspersed below (this discussion gets >quite detailed, but I have made a sincere effort to >try to stay on point and narrow rather than broaden >the scope): > >Again, I think the bottom line is that using a BST to >contain the attester cert in the sender-vouches scenario >is a better (cleaner and simpler) option than using a 2nd >saml assertion to contain the attester cert. > > Rich, I expect to use sender-vouches approximately as follows: An attesting entity uses its key binding to secure a message containing a request to invoke a web service. The identity(s) under which the web service is to be invoked is represented in the subject statements of the sender-vouches confirmed assertion. The holder of key confirmed security token of the attesting entity carries the key used to sign the message, but the receiver must be able to recogise that the vouched for assertion contains the invocation identity. Whether or not the key confirmed security token used to sign the message and assertion is itself a BST or a SAML assertion, has little impact on the message reciever's ability to recognize the proper invocation identity for the message. As the spec is currrently written, it is unclear how the the msg receiver can establish the correspondence between the SOAP msg and the vouched for subject statments. The only clue that the receiver has that such a correspondence should be established is the fact that SignedInfo references (i.e. digests) a sender-vouches confirmed assertion. That is my point, and the reason why I suggested that proper interpretation of impersonation scenarios, including those accomplished using sender-vouches confirmed assertions could be more direct and consistent with how other profiles establish what I refer to as the invocation identity, if Signature/keyInfo (always) points to a security token containing the invocation identity. In non-impersonation scenarios the signer and invocation identities are presumably the same. I included other comments below, but I'd like to focus on the representation of impersonation and its interpretation by receivers. Sender vouches is on such formulation of which we have been dicussing two different approaches; 1 curently in the spec, and another based on chaining. Another form of impersonation would be assertion issuer authorized assertion. >>-----Original Message----- >>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >>Sent: Friday, January 30, 2004 12:49 PM >>To: Levinson, Richard >>Cc: wss@lists.oasis-open.org >>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded >> >> >> >>Levinson, Richard wrote: >> >> >> > > > > >>>Ron, >>> >>>First I will recount where I think we are in this discussion >>> >>> >>and what >> >> >>>the potential outstanding issues are and then I provide a suggestion >>>for addressing the situation. >>> >>>(bottom line (to avoid reading all the details): suggestion >>>is to have STR2 point to a BinarySecurityToken with the attester >>>cert (similar to section 3.3.2 of the X.509 profile, except in >>>our case the sig ref points to the assertion and the sig keyinfo >>>points to the BST): >>> >>> >>> > > > > >>Rich, >> >>Unless I am misunderstanding you, >>This is what the example in the spec currently does, except >>STR2 points to a SAML assertion acting as the attester cert, >>and the sig ref points to the subject assertion and the sig >>keyinfo points to STR2, and thus the attester cert. Other >>than the example using only SAML ST's, I think it analogous >>to what you propose. Maybe you are focusing on the token >>combination we should demonstrate by interop. >> >> >> > >Yes, functionally I guess it is equivalent. I was a little >confused with the actual "sender-vouches" assertion not >being shown because it is externally accessed, and the >on message assertion being holder-of-key. I understand it >now but think that readers who are not intimately familiar >with all the options may have difficulty with it. > >And you are correct that I am focussing on putting together >a self-contained scenario for the interop, and I think that >having the signature point to a 2nd saml assertion is not >necessary since the recipient is trusting the public key >of the signer/attester, not the fact that the public key is >obtained in an assertion backed up by a trusted saml authority. >My sense is that recipients will probably populate their >key stores with certificates from well known issuers rather than >self-generated certificates backed up by saml assertions. >So, for the interop, I think I am going to go with the >BinarySecurityToken as the holder of the attester cert. > I view a SAML holder of key confirmed assertion as an XML certificate. The attesting entity could either use ists XML certificate or its X509 XSN.1 certficate, they are logically equivalent. >>Anyway, I think there is a problem with the existing >>approach, especially when STR 2 does not either have a >>"usage" attribute to inform the actions of the receiver. >>Without such a cue, The receiver has to recognize that this >>is a SAML profile msg, as aposed to an X509 profile msg, to >>be able to properly determine the authentication identity >>that should be associated with the msg. >> >> >> > >If we use a BinarySecurityToken here, I think things are >simplified since there is no ambiguity about identity of >the attester. I think the main point of saml sender-vouches >is that the attester is vouching for the subject of the >saml assertion, and there is not really a need for the >attester to also be represented by a saml assertion, and >as you have shown that leads to issues regarding whether the >requester is depending on the signer of the message or the >authority that issued the saml assertion that contains >the cert the attester used to sign the message. i.e. it >seems to be implicitly forcing a chaining mechanism to >be defined for saml assertions similar to certs which is >not currently a practice to my knowledge. > I hope I clarified this above, I am interested in being able to tell when the invocation identity should be the vouched for subject. >>To do this, the receievr has to infer from the fact that a >>SAML assertion was signed, and that its confirmation method >>was satisfied, that the identity of the signed assertion >>should be applied to the msg, as apposed to the identity >>bound to the attester's security token; which if refactored >>as you suggest would be an x509 cert. Such messages will >>look a lot like conventional x509 confirmed msgs. The fact >>that this is an impersonation scenario is not easy to recognize. >> >> >> > >I'm not sure if I totally follow you here, especially the phrase >"the identity of the signed assertion should be applied to the msg". >I think what you are saying is from the receiver's point of view, >who is actually accountable for this message. If that is the case, >then the receiver needs to have a way to recognize the attester, >and this would be thru the attester's signing cert, which the >receiver would have in a key store and can be used to verify >the signature on the message components. As I indicated above, >if this cert is backed by a saml assertion rather than conventional >PKI then we have kind of a new use case that I think is outside >of the current scope of common practice even in the saml domain. >So, from that point of view I don't think we would want the >attester identity to be defined by the saml assertion but >by the attester cert. > > SAML assertions are perhaps a bit more flexible than x509 identity certs, in that x509 identity certs typically need to be long lived; but other than that, I try to view them as interchangeable. Maybe this is an oversimplification on my part. >>> Recount of discussion: >>> >>>I believe we are in agreement on the "unsigned assertion" >>>case where the attester signs both the assertion and the >>> >>> >>message body >> >> >>>and the basis of trust from the receiver perspective is the >>> >>> >>public key >> >> >>>of the attester with which the attester may verify the signature >>>covering both the body and the assertion and based on the >>> >>> >>recipient's >> >> >>>trust in the attester's certificate all the relevant information >>>is trusted. >>> >>>In addition, in the above case we put the attester's >>> >>> >>certificate in the >> >> >>>saml:SubjectConfirmation/saml:SubjectConfirmationData/ >>>ds:KeyInfo element using the SCD element to contain the >>> >>> >>KeyInfo rather >> >> >>>than the SC element which is intended for the subject >>> >>> >>certificate info. >> >> >>> >>> >>> >>> > > > > >>I was suggesting somnething like what you describe above, >>leaving aside for the moment the ConfirmationData vs KeyInfo >>distinction you have since made, as an alternative to what >>is ]currently being done in the spec. I don't think we would >>do both. This is sort of a backpointer to the cert of the >>attesting entity, since >>the front >>pointer in the signature keyinfo is to the attester's cert. >>The problem as I see it, is it is difficult for the receiver >>to know when to apply SAML token profile semantics, unless >>the front pointer points to a SAML assertion. >> >>At a high level, I was proposing that the KeyInfo reference >>in the Signature point to a Subject assertion because it >>would make it easy for the receiver to recognize that the >>message was signed using the SAML token profile, and that the >>indended authentication entity was the Subject of the >>Assertion. This is already how we profile hold-of-key. >> >> >> > >From my perspective the signature does not need to convey any >context about how the signature should be interpreted. It simply >signs message elements and it is up to the recipient what meaning >to attach to the validity of such a signature. The fact that the >KeyInfo in the sig leads to a saml assertion as currently in the >profile spec does not imply anything about sender-vouches, it is >just pointing to a key container. And, in fact, in the profile spec >it actually points to a holder-of-key assertion. So, I think that >if this points to a BinarySecurityToken instead will not >impact any sender-vouches semantics. > > The signature is being used to bind an identity to content; aka to do data origin authentication. In the sender vouches case, it is the vouched for identity that is being bound to the content (by the attesting entity). >The sender-vouches semantics comes from the fact that the recipient >after verifying the signature determines that one of the references >signed by the signature is, in fact, a sender-vouches assertion, > My point is that it is hard for the receiver to recognize that it is expected to do this. >which in the current profile spec is off-message, but once obtained >by the receiver provides the context required to evaluate whether >the message should be trusted or not. But the trust in the message >is not due to the fact that there is anything in particular about >the attester contained in the assertion, only the fact that it is >a sender-vouches assertion and that the attester signed it. > Actually I would expect the receivr to determine if it trusts the attesting entity to vouch for the invocation identity. >Similarly, in the holder-of-key profile, the recipient again trusts >the assertion issuer's signature on the assertion (i.e. it is the >signer of the assertion who is trusted ultimately, not the >subject of the assertion) which contains the >holder-of-key's certificate which in turn is used to verify the >message content. > >Analytically, I believe the holder-of-key scenario degenerates to >the sender-vouches case if the holder-of-key also is the signer >of the assertion. Sender-vouches then optimizes this by pulling >the assertion signature out of the assertion and combines it >with the content sig. > > > >>>Furt2her, I agree that if we apply the same procedure as >>> >>> >>above to the >> >> >>>"signed assertion" case that we would break the signature on the >>>assertion, and as you indicate using some kind of transform that >>>doesn't include the attester KeyInfo element is probably not >>> >>> >>feasible. >> >> >>>However, I think the signed assertion case raises some fundamental >>>issues about the basis of trust the receiver has on request. If the >>>signed assertion is not re-signed by the attester, then the >>> >>> >>recipient >> >> >>>effectively must now establish two bases of trust: one with the >>>attester and one with the assertion issuer. This may be fine >>> >>> >>for some >> >> >>>use cases, but, in general I think that a recipient would prefer to >>>keep their basis of trust as simple as possible and make one >>> >>> >>agreement >> >> >>>with the attester and let the attester be responsible for all the >>>relevant info in the request. >>> >>> Here is a suggestion that I think might address all the >>> above considerations: >>> >>>That being said, an alternative means for the attester to >>> >>> >>sign both the >> >> >>>assertion and the content without breaking the signature on >>> >>> >>the signed >> >> >>>assertion would be to have the STR in the attester's >>> >>> >>Signature/KeyInfo >> >> >>>element (wsu:Id="STR2") point to a BinarySecurityToken which would >>>contain the attester's certificate used to verify the >>> >>> >>signature. This >> >> >>>approach could be used for both the unsigned assertion and signed >>>assertion cases without interfering with the signature if it >>> >>> >>exists on >> >> >>>the assertion. >>> >>> >>> > > > > >>As noted above, unless I am missing something, and modulo the >>substitution of a holder of key confimed assertion for the >>BST, I think this is what the sender-vouches example in the >>spec is currently demonstrating. >> >> >> > >Yes, now that I see the structure with the off message sender-vouches >assertion, they are effectively the same. But as discussed above >I think using STR2 to point to a 2nd saml assertion containing the >attester's cert is raising some issues that don't appear to me >to be critical path for smooth operability. In particular, if it >is the attester cert that is ultimately trusted why go to the >trouble of wrapping it in a saml assertion? Why not simply use >a BST and have that the end of the trust path? > > The SAML assertion is the attester's certificate. In fact, in the example we have been discussing, it contains the attester's keyValue. > > >>I reading back through the thread, and I found a couple of >>points that you raised that I think we should call attention to. >> >>1. As you point out, the SAML Core's description of KeyInfo >>within SubjectConfirmation; precludes the use of this field >>to specify a a key held by the attesting entity, not the >>subject. This has come up before. We need to determine what >>latitude we have in this area. IMO the SAML spec has been >>overly prescriptive. I would prefer that it say something >>like "that specifies a crytographic key held by an entity >>authorized to act as the subject. >> >> >> > >As discussed above I think that by using a BST for the attester >cert we can avoid dealing with this issue. > > > >>> An XML Signature [XMLSig] element that specifies a >>> >>> >>cryptographic >> >> >>> key held by the subject." >>> >>> >>> > > > > >>2. You point out that even if an assertion is signed, the attesting >>entity must >>sign it. I think you are concerned about the case of a signed >>sender-vouches confirmed assertion without a contained and >>protected key binding. In which case I agree the attesting >>entity is defining the key binding, and this >>must sign >>the asertion and the message content. >> >> > >It sounds like we agree there. i.e. a signed assertion in >and of itself does not protect anything but itself. In order > Yes, but the issue is whether it embodies an authority protected key binding. >to bind such an assertion to external content, we have >2 cases: sender-vouches whereby the attester signs both >the assertion and the content, and holder-of-key where the >signed assertion contains the holder-of-key's public key >or cert and it is the holder-of-key's signature on the >content that binds the content to the assertion thru >hk's public key bound in the assertion which can be used >to verify the content signature. > > > >>I am not sure how close to being on the same page we are, so >>I hesitate to raise another problem, but it seems to me that >>section 3.3.4 of of the >>WSS STP, >>"SAML assertion referenced from SubjectConfirmation" (by STR) >>is prone to substitution problems, if the refererences do not >>(at least) unambiguouly identify the intended security token. >> >>We defined the STR Dereference transform to be able to digest >>assertion contents when they are referenced by STR, we would >>likely need to require that a similar transform be applied in >>the calculation >>of the >>signatures of assertions with STR's within >>SubjectConfirmation/KeyInfo. >> >>I guess this could be argue against complex key references in >>SubjectConfirmtion/KeyInfo. >> >> >> > >As I mentioned in an earlier email my concern with 3.3.4 is that >we have a potential infinite loop where the STR in the KeyInfo >in the assertion points to the assertion itself, and we never >actually seem to find the key in question. > Maybe this could be a problem. I am concerned about the substitution properties of KeyInfo inside SubjectConfirmation. Ron > > Rich > > > >>Ron >> >> >> >>> Rich >>> >>>-----Original Message----- >>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >>>Sent: Thursday, January 29, 2004 10:16 PM >>>To: Levinson, Richard; wss@lists.oasis-open.org >>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded >>> >>> >>>Rich, >>> >>>In the sender-vouches case, we proposed that the attesting entity >>>define (by putting a reference to a key in subject confirmation) and >>>protect(by signing the assertion) the key binding. >>> >>>We have described how such an assertion would be used in the >>> >>> >>KeyInfo of >> >> >>>a Signature to bind the assertion to message content. >>> >>>One problem with this approach is that the asertion cannot >>> >>> >>be signed by >> >> >>>an assertion authority (other than the attesting entity). >>> >>>Perhaps the keyInfo element of the assertion's subjectConfirmation >>>element could be left out of the calculation of the on assertion >>>signature. This would allow the attesting entity to change >>> >>> >>it without >> >> >>>invalidating the signature. >>> >>>I don't know if something like this would be feasible, although I >>>suspect not. >>>In which case, it would seem that the only easy way to allow >>> >>> >>the attesting >> >> >>>entity to define the key binding within the assertion (as >>> >>> >>proposed) would be >> >> >>>to require that sender-vouches assertions be unsigned until >>> >>> >>the attesting >> >> >>>entity signs them. >>> >>>Ron >>> >>> >>>-----Original Message----- >>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] >>>Sent: Thursday, January 29, 2004 6:00 PM >>>To: Levinson, Richard >>>Cc: wss@lists.oasis-open.org >>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded >>> >>> >>>Rich, >>> >>>The assertion must always be protcted (in addition to the >>> >>> >>message), but >> >> >>>sometimes it is the attester that protects the assertion (i.e >>>sender-vouches), and >>>sometimes(holder-of-key) it is a third party (i.e the assertion >>>authority) that >>>potects the assertion. >>> >>>In both cases the attesting entity binds the assertion to the message >>>content. >>> >>>In the protected (e.g.signed) assertion case, the attesting entity >>>need not protect the assertion, because it can only bind a different >>>assertion to the message, if it can demonstrate knowledge of the >>>confirmation key in this different assertion. Similarly the >>> >>> >>attesting >> >> >>>entity cannot change the content of the assertion, without >>> >>> >>invalidating >> >> >>>the protection of the assertion. >>> >>>Ron >>> >>> >>>Ron Monzillo wrote: >>> >>> >>> >>> >>> >>>>Thanks Rich, >>>> >>>>I'd hope others will comment on this as well. >>>> >>>>The attester is both authorizing the subject assertion and >>>> >>>> >>attesting >> >> >>>>for the presence of the subject. >>>> >>>>It authorizes the assertion contents , by signing the >>>> >>>> >>assertion, which >> >> >>>>it had previously configured to authorize it as proxy for >>>> >>>> >>the subject. >> >> >>>>As I mentioned previously, this only makes sense if the >>>> >>>> >>assertion was >> >> >>>>not signed by the assertion authority. If the assertion was >>>> >>>> >>signed by >> >> >>>>the assertion authority, >>>>then the same logic can be applied, except the signature >>>> >>>> >>done by the >> >> >>>>attesting >>>>entity need only digest the msg body. >>>> >>>>Ron >>>> >>>>Levinson, Richard wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Ron, >>>>> >>>>>I will try to consolidate our 2 email threads where I was trying to >>>>>clarify how to use the V9 spec to implement sender-vouches for the >>>>>interop spec and post to the wss list for additional input >>>>> >>>>> >>from any >> >> >>>>>who are willing to delve into the details and provide further >>>>>comment. >>>>> >>>>>I think we are in total agreement in your alternative >>>>> >>>>> >>paragraph (from >> >> >>>>>email 1 below): >>>>> >>>>>"As an alternative, maybe the assertion referenced from keyInfo >>>>>should be the sender-vouches confirmed assertion, and it could >>>>>contain in its subject >>>>>confirmation, a reference to a key confirmed security token of the >>>>>attesting >>>>>entity. The attesting entity would put this reference in the >>>>>sender-vouches >>>>>confirmed assertion." >>>>> >>>>>as compared to my suggestion (from email 2 below): >>>>> >>>>> "Since we are doing sender-vouches, the subject >>>>> >>>>> >>confirmation >> >> >>>>>may be done using the sender's key. >>>>> i.e. since the subject doesn't actually sign >>>>> anything and the sender is the one confirming >>>>> that the info in the assertion can be used by >>>>> the receiver, then it makes sense that the >>>>> >>>>> >>sender's key be in >> >> >>>>>the KeyInfo of the SubjectConfirmation." >>>>> >>>>>Also, I believe that the WS-SAML Profile spec is the only >>>>> >>>>> >>place where >> >> >>>>>a definitive explanation of how to implement sender-vouches and >>>>>holder-of-key exists. So, to some degree, that spec has >>>>> >>>>> >>flexibility >> >> >>>>>to clarify the details of these protocols. >>>>> >>>>>Also, referring back to the SAML 1.0 core spec, the >>>>> >>>>> >>relevant elements >> >> >>>>>within the assertion are defined as follows: >>>>> >>>>> "The <SubjectConfirmation> element specifies a subject by >>>>>supplying data that allows the subject to be authenticated. It >>>>>contains the following elements in order: >>>>> >>>>> <ConfirmationMethod> [One or more] >>>>> >>>>> A URI reference that identifies a protocol to be used to >>>>> authenticate the subject. URI references identifying >>>>>SAML-defined confirmation methods are currently >>>>> >>>>> >>defined with >> >> >>>>>the SAML >>>>>profiles in the SAML Binding and Profiles specification >>>>>[SAMLBind]. Additional methods may be added by >>>>> >>>>> >>defining new >> >> >>>>>profiles or >>>>>by private agreement. >>>>> >>>>> <SubjectConfirmationData> [Optional] >>>>> >>>>> Additional authentication information to be used by a >>>>>specific authentication protocol. >>>>> >>>>> <ds:KeyInfo> [Optional] >>>>> >>>>> An XML Signature [XMLSig] element that specifies a >>>>>cryptographic key held by the subject." >>>>> >>>>>As I read the above, if we want to do this with one assertion >>>>>(instead of having an in message and off message assertion >>>>> >>>>> >>in the V9 >> >> >>>>>example), I think >>>>>we could put the sender (attester) cert in ds:KeyInfo, but >>>>> >>>>> >>to keep to >> >> >>>>>the >>>>>letter of the spec this really would not be accurate, because that >>>>>element >>>>>explicitly says the corresponding key is held by the >>>>> >>>>> >>"subject", who is >> >> >>>>>not the attester, but the attestee. >>>>> >>>>>Therefore, I think to be compliant with the above we could put a >>>>>KeyInfo element containing the attester/sender cert in the >>>>>SubjectConfirmationData element. >>>>> >>>>>I suggest that makes sense because we are defining the >>>>>"sender-vouches" protocol in this document and we could >>>>> >>>>> >>say that for >> >> >>>>>the sender-vouches protocol that >>>>>the attester cert or ref to such cert MAY be placed in the >>>>>SubjectConfirmationData >>>>>element. >>>>> >>>>>It seems to me that this is a perfectly good way to implement >>>>>sender-vouches since the SubjectConfirmation element is >>>>> >>>>> >>intended to >> >> >>>>>"supply data that allows >>>>>a subject to be authenticated" and that is exactly what we >>>>> >>>>> >>are doing by >> >> >>>>>supplying the sender cert which can be used to verify the >>>>> >>>>> >>signature >> >> >>>>>covering >>>>>the assertion which identifies the subject and binds the >>>>> >>>>> >>assertion to >> >> >>>>>the content which is also included in the sig. And since >>>>> >>>>> >>the receiver >> >> >>>>>implicitly >>>>>trusts the sender/attester by some out of band agreement, >>>>> >>>>> >>this procedure >> >> >>>>>effectively >>>>>authenticates the subject as far as the receiver is concerned. >>>>> >>>>>Therefore, to move forward with the example in the interop >>>>> >>>>> >>document, >> >> >>>>>that is the approach I propose to take, which will allow >>>>> >>>>> >>the interop >> >> >>>>>to work on the basis of self-contained messages that do >>>>> >>>>> >>not rely on >> >> >>>>>external methods to obtain assertions or certificates. >>>>> >>>>> Rich >>>>> >>>>> >>>>> >>>>> >>>>>!*********** >>>>> >>>>> email 1: >>>>> >>>>>******************! >>>>> >>>>>-----Original Message----- >>>>>From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] Sent: >>>>> >>>>> >>Thursday, >> >> >>>>>January 29, 2004 11:56 AM >>>>>To: Levinson, Richard >>>>>Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded >>>>> >>>>> >>>>>Rich, >>>>> >>>>>There may be a problem with the example, or perhaps with the >>>>>sender-vouches approach, but I think in general the example is >>>>>structured appropriately. In >>>>>the example, the on-msg assertion, is referenced by STR2, >>>>> >>>>> >>and used by >> >> >>>>>the >>>>>attesting entity" to sign both the message body and a >>>>> >>>>> >>"sender-vouches >> >> >>>>>confirmed assertion (referenced via STR1). >>>>> >>>>>I changed this example to not include the sender-vouches confirmed >>>>>msg in the assertion, and such that the attesting entity uses a >>>>>holder-of-key confirmed assertion (as apposed to a key in >>>>> >>>>> >>some X509 >> >> >>>>>cert) to protect the >>>>>vouched for message content and assertion (as required by section >>>>>3.4.2.1). >>>>> >>>>>I tweaked the example in this way to give us a better look at how >>>>>sender-vouches is currently being profiled, and to bring to light >>>>>some potential weaknesses in the current use modle for >>>>> >>>>> >>sender-vouches >> >> >>>>>confirmed >>>>>assertions: >>>>> >>>>>For example, without an appropriate usage attribute value >>>>> >>>>> >>on STR1 and >> >> >>>>>without the sender-vouches confirmed msg being present in >>>>> >>>>> >>the msg, it >> >> >>>>>may not be easy for the receiver to understand the header. >>>>> >>>>>As an alternative, maybe the assertion referenced from >>>>> >>>>> >>keyInfo should >> >> >>>>>be the sender-vouches confirmed assertion, and it could contain in >>>>>its subject confirmation, a reference to a key confirmed security >>>>>token of the attesting >>>>>entity. The attesting entity would put this reference in the >>>>>sender-vouches >>>>>confirmed assertion. >>>>> >>>>>[I realize that statements not assertions have >>>>> >>>>> >>confirmation methods, >> >> >>>>>but I am purposely glossing over this level of detail] >>>>> >>>>>Such an approach would rekindle our discussion >>>>>about whether sender-vouches confirmed assertions must be signed by >>>>>an issuing authority, while on the other hand, it would >>>>> >>>>> >>allign better >> >> >>>>>with the chained approach suggested for using holder of >>>>> >>>>> >>key confirmed >> >> >>>>>assertions to >>>>>authorize proxies; in which case the authority would sign >>>>> >>>>> >>the top level >> >> >>>>>holder-of-key assertion containing a reference in its >>>>>subject-confirmation >>>>>to a key confirmed assertion authorizing a proxy. >>>>> >>>>>Ron >>>>> >>>>>Levinson, Richard wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Ron, >>>>>> >>>>>>This is a more explicit comment on the sv scenario >>>>>>in section 3.4.2.3 that looks to me like it needs >>>>>>a couple things fixed. >>>>>> >>>>>> 1. line 745 the ConfrimationMethod is holder-of-key. >>>>>> shouldn't it be sender-vouches? >>>>>> >>>>>> 2. line 727, AssertionID ends with "...ebdfc", >>>>>> and on line 769 KeyIdentifier refers to >>>>>> >>>>>> >>AssertionID >> >> >>>>>>ending with "...ebdbe" which is >>>>>> different from line 727. (As explained below >>>>>> I think this might be more than a simple typo) >>>>>> >>>>>> 3. line 806 the STR in the Signature/KeyInfo refers >>>>>> >>>>>> >> to >> >> >>>>>>"...ebdfc" which is the Assertion on line 727, >>>>>> which presumably contains the key used to verify >>>>>> this signature in the SubjectConfirmation/KeyInfo >>>>>> element. >>>>>> >>>>>>A possible problem I see with this setup is that the signer is >>>>>>signing an assertion of which the signer itself appears to be the >>>>>>subject of the assertion, since the SubjectConfirmation/ KeyInfo >>>>>>indicates a key to verify the subject of the assertion, not the >>>>>>attester of the subject of the assertion. >>>>>> >>>>>>It would seem to me in this case that STR2 should point to the >>>>>>signer's key, not the assertion subject's key as it seems to now, >>>>>>although I am not sure at this point if the key in the >>>>>> >>>>>> >>assertion is >> >> >>>>>>intended to be the signer's or the subject's, since your original >>>>>>intention might have been to include 2 assertions which would >>>>>>explain the presence of the 2 different AssertionIDs. >>>>>> >>>>>>To locate the signer key we could either have a simple STR2 to a >>>>>>cert in the wsse header, or to a 2nd saml assertion, also in the >>>>>>message, containing the attestor's key. >>>>>> >>>>>>Please let me know what you think, since I am trying to make the >>>>>>interop example as consistent as possible with the profile. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Rich >>>>>> >>>>>> >>>>>> >>>>>>-----Original Message----- >>>>>>From: ronald.monzillo@sun.com [mailto:ronald.monzillo@sun.com] >>>>>>Sent: Tuesday, January 27, 2004 1:55 AM >>>>>>To: wss@lists.oasis-open.org >>>>>>Subject: [wss] Groups - WSS-SAML-09.pdf uploaded >>>>>> >>>>>> >>>>>>The document WSS-SAML-09.pdf has been submitted by ronald monzillo >>>>>>(ronald.monzillo@sun.com) to the OASIS Web Services Security TC >>>>>>document repository. >>>>>> >>>>>>Document Description: >>>>>>SAML token Profile >>>>>> >>>>>>Update of STR ValueTypes to use URIs as apposed to Qnames (issue >>>>>>196). Changed use of STR to carry saml:AuthorityBinding element. >>>>>>Many edits to examples, including change to >>>>>> >>>>>> >>Sender-Vouches example >> >> >>>>>>to user STR Dreference Transfrom. >>>>>> >>>>>>Download Document: >>>>>>http://www.oasis-open.org/apps/org/workgroup/wss/download. >>>>>> >>>>>> >>php/5177/W >> >> >>>>>>SS-SAML >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>- >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>09.pdf >>>>>> >>>>>>View Document Details: >>>>>>http://www.oasis-open.org/apps/org/workgroup/wss/document. >>>>>> >>>>>> >>php?docume >> >> >>>>>>nt_ >>>>>>id=51 >>>>>>77 >>>>>> >>>>>> >>>>>>PLEASE NOTE: If the above links do not work for you, your email >>>>>>application may be breaking the link into two pieces. You may be >>>>>>able to copy and paste the entire link address into the address >>>>>>field of your web browser. >>>>>> >>>>>> >>>>>> >>>>>>To unsubscribe from this mailing list (and be removed from the >>>>>>roster of the OASIS TC), go to >>>>>>http://www.oasis-open.org/apps/org/workgroup/wss/members/l >>>>>> >>>>>> >>eave_workg >> >> >>>>>>rou >>>>>>p.php >>>>>>. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>!********************* >>>>> >>>>> email 2: >>>>> >>>>>************************! >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Levinson, Richard Sent: Thursday, January 29, 2004 11:37 AM >>>>>To: 'ronald.monzillo@sun.com' >>>>>Subject: RE: [wss] Groups - WSS-SAML-09.pdf - question on >>>>>Sender-vouches scenario >>>>> >>>>> >>>>>Ron, >>>>> >>>>>I have done a little more thinking on this and maybe we >>>>>can use things as they are if we interpret things in >>>>>the following context: >>>>> >>>>> Since we are doing sender-vouches, the subject >>>>> >>>>> >>confirmation >> >> >>>>>may be done using the sender's key. >>>>> i.e. since the subject doesn't actually sign >>>>> anything and the sender is the one confirming >>>>> that the info in the assertion can be used by >>>>> the receiver, then it makes sense that the >>>>> >>>>> >>sender's key be in >> >> >>>>>the KeyInfo of the SubjectConfirmation. >>>>> >>>>>If you agree with this then the only thing I think needs >>>>>to be changed in the text is: >>>>> >>>>> 1. line 745 change "holder-of-key" to "sender-vouches" >>>>> >>>>> 2. line 769 change "ebdbe" to "ebdfc" >>>>> >>>>>This way the SignedInfo ref covers STR1 which transforms to the >>>>>assertion. And STR2 in the Signature/KeyInfo now refers to the >>>>>assertion and is interpreted as meaning: use the KeyInfo in the >>>>>SubjectConfirmation as the key to verify this signature. >>>>> >>>>>For now I will work on this assumption and proceed with >>>>> >>>>> >>updating the >> >> >>>>>interop spec. >>>>> >>>>>Please let me know if you think this all makes sense, >>>>> >>>>> Thanks, >>>>> >>>>> Rich >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Levinson, Richard Sent: Wednesday, January 28, 2004 5:56 PM >>>>>To: 'ronald.monzillo@sun.com' >>>>>Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded >>>>> >>>>> >>>>>Ron, >>>>> >>>>>This is a more explicit comment on the sv scenario >>>>>in section 3.4.2.3 that looks to me like it needs >>>>>a couple things fixed. >>>>> >>>>> 1. line 745 the ConfrimationMethod is holder-of-key. >>>>> shouldn't it be sender-vouches? >>>>> >>>>> 2. line 727, AssertionID ends with "...ebdfc", >>>>> and on line 769 KeyIdentifier refers to >>>>> >>>>> >>AssertionID >> >> >>>>>ending with "...ebdbe" which is >>>>> different from line 727. (As explained below >>>>> I think this might be more than a simple typo) >>>>> >>>>> 3. line 806 the STR in the Signature/KeyInfo refers to >>>>>"...ebdfc" which is the Assertion on line 727, >>>>> which presumably contains the key used to verify >>>>> this signature in the SubjectConfirmation/KeyInfo >>>>> element. >>>>> >>>>>A possible problem I see with this setup is that the signer is >>>>>signing an assertion of which the signer itself appears to be the >>>>>subject of the assertion, since the SubjectConfirmation/ KeyInfo >>>>>indicates a key to >>>>>verify the subject of the assertion, not the attester of >>>>> >>>>> >>the subject >> >> >>>>>of the >>>>>assertion. >>>>> >>>>>It would seem to me in this case that STR2 should point to the >>>>>signer's key, not the assertion subject's key as it seems to now, >>>>>although I am not sure at this point if the key in the >>>>> >>>>> >>assertion is >> >> >>>>>intended to be the signer's or the subject's, since your original >>>>>intention might have been to include 2 assertions which >>>>> >>>>> >>would explain >> >> >>>>>the presence of the 2 >>>>>different AssertionIDs. >>>>> >>>>>To locate the signer key we could either have a simple >>>>> >>>>> >>STR2 to a cert >> >> >>>>>in the wsse header, or to a 2nd saml assertion, also in >>>>> >>>>> >>the message, >> >> >>>>>containing the attestor's key. >>>>> >>>>>Please let me know what you think, since I am trying to make the >>>>>interop example as consistent as possible with the profile. >>>>> >>>>> Thanks, >>>>> >>>>> Rich >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: ronald.monzillo@sun.com >>>>> >>>>> >>[mailto:ronald.monzillo@sun.com] Sent: >> >> >>>>>Tuesday, January 27, 2004 1:55 AM >>>>>To: wss@lists.oasis-open.org >>>>>Subject: [wss] Groups - WSS-SAML-09.pdf uploaded >>>>> >>>>> >>>>>The document WSS-SAML-09.pdf has been submitted by ronald monzillo >>>>>(ronald.monzillo@sun.com) to the OASIS Web Services Security TC >>>>>document repository. >>>>> >>>>>Document Description: >>>>>SAML token Profile >>>>> >>>>>Update of STR ValueTypes to use URIs as apposed to Qnames (issue >>>>>196). Changed use of STR to carry saml:AuthorityBinding >>>>> >>>>> >>element. Many >> >> >>>>>edits to examples, including change to Sender-Vouches >>>>> >>>>> >>example to user >> >> >>>>>STR Dreference Transfrom. >>>>> >>>>>Download Document: >>>>> >>>>> >>>>> >>>>> >>>>> >>>http://www.oasis-open.org/apps/org/workgroup/wss/download.php >>> >>> >>/5177/WSS- >> >> >>>SAML- >>> >>> >>> >>> >>> >>>>>09.pdf >>>>> >>>>>View Document Details: >>>>>http://www.oasis-open.org/apps/org/workgroup/wss/document.p >>>>> >>>>> >>hp?documen >> >> >>>>>t_id=51 >>>>> >>>>>77 >>>>> >>>>> >>>>>PLEASE NOTE: If the above links do not work for you, your email >>>>>application may be breaking the link into two pieces. You may be >>>>>able to copy and paste >>>>>the entire link address into the address field of your web browser. >>>>> >>>>> >>>>> >>>>>To unsubscribe from this mailing list (and be removed from >>>>> >>>>> >>the roster >> >> >>>>>of the OASIS TC), go to >>>>> >>>>> >>>>> >>>>> >>>>> >>>http://www.oasis-open.org/apps/org/workgroup/wss/members/leav >>> >>> >>e_workgrou >> >> >>>p.php >>> >>> >>> >>> >>> >>>>>. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>To unsubscribe from this mailing list (and be removed from >>> >>> >>the roster >> >> >>>of the OASIS TC), go to >>>http://www.oasis-open.org/apps/org/workgroup/wss/members/leav >>> >>> >>e_workgrou >> >> >>>p.php. >>> >>> >>> >>> >>> > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup .php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]