[Pgi-wg] [gridshib-user] comments regarding a VOMS-SAML token--ANY plan to make VOMS SAML assertion be compatible with WS-Security SAML Token profile?

[weizhong qiang]

hi,

On Tue, Mar 31, 2009 at 12:15 AM, Tom Scavo <trscavo at gmail.com> wrote:

> On Mon, Mar 30, 2009 at 1:16 PM, weizhong qiang <weizhongqiang at gmail.com>
> wrote:
> >
> > On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo at gmail.com> wrote:
> >>
> >> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang
> >> <weizhongqiang at gmail.com> wrote:
> >> >
> >> > 3. <saml:SubjectConfirmation> element contains a <ds:X509Certificate>
> >> > element, but it probably be better to just contain a <ds:KeyValue>,
> >> > since
> >> > the certificates chain of the "subject" is already supposed to be
> >> > verified
> >> > by the third-party authority (in this case, it is voms saml service),
> >> > and
> >> > then this public key is used to sign the soap message afterwards.
> >>
> >> I don't see what the certificate chain has to do with the use of the
> >> <ds:X509Certificate> element in this case.  The latter requires the
> >> presenter to prove possession of the private key corresponding to the
> >> public key bound to the certificate.  What does that have to do with
> >> the presented certificate chain?
> >
> > two types of verification here:
> > 1. verify that "possession of the private key corresponding to the public
> > key bound to the certificate"
>
> Which is required for holder-of-key subject confirmation, yes.
>
> > 2. verify that "possession of the private key corresponding to the public
> > key bound to the certificate" + verify that the certificate is signed by
> > trusted authority (in this case verification of certificates chain is
> > needed.)
> >
> > What I meant is for SAML Token profile, step 2 is not needed.
>
> Okay.
>
> >> > <ds:KeyValue> is also convinient for proxy certificate, in my opinion.
> >>
> >> I don't see what <ds:KeyValue> gains you in this case, but I may be
> >> missing something.  Unless you can provide a good reason for using
> >> <ds:KeyValue>, I recommend <ds:X509SubjectName> or <ds:X509SKI>, in
> >> that order.  The <ds:X509SubjectName> element is simplest for proxy
> >> certificates, I think.  It is equivalent to the subject confirmation
> >> implied in VOMS proxies, in fact.
> >
> > Probably <ds:KeyValue> can not gain more than <ds:X509Certificate>
> (formerly
> > I supposed the <ds:KeyValue> should be standarlized) . But by using
> > <ds:X509SubjectName>,  what is the way to get the public key, which is
> > required when verifying the signature to SOAP message.
>
> Suppose that the presenter authenticates to the relying party


Here in my understanding the presenter (requester) does not need to
authenticate to relying-party (resource) by using its credential, because
the presenter has already authenticated to IdP (STS, secure token service,
or whatever other names), and the authentication result (a SAML Token with
<saml:SubjectConfirmation> inside) is supposed to be trusted by relying
party (if there is trust relationship between IdP and resource).
So the preseter is not supposed to use it credential to authenticate against
Resource once more (here I am talking in the contex if SOAP message is
protected by SAML Token, by using the presenter's private key to make
signature for SOAP message).


Weizhong Qiang


> using a
> proxy credential signed by the same X.509 end-entity credential used
> to request the assertion from the IdP in the first place.
> (Authentication can be by transport-level or message-level as you
> mentioned earlier.)  By proving possession of the private key
> associated with the proxy, the presenter has proven that it is the
> subject given by the subject DN in the end-entity certificate of the
> presented proxy certificate chain.  Thus any holder-of-key SAML
> assertion containing that DN is automatically confirmed.
>
> >> In any event, I should point out that the SAML V2.0 Holder-of-Key
> >> Assertion Profile is now in its formal Public Review period, and it
> >> does not profile <ds:KeyValue>, so if you think that's an error of
> >> omission, it would be good if you could submit a public comment to
> >> that effect.
> >>
> >>
> http://lists.oasis-open.org/archives/security-services/200903/msg00062.html
> >
> > Is any of the draft you mentioned in this link supposed to update/replace
> > the WS-Security SAML Token 1.1 profile?
>
> No, the WSS Technical Committee is closed so I don't anticipate any
> changes to be made to the WSS token profiles.
>
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/pgi-wg/attachments/20090331/11e6c527/attachment.html