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

On Mon, Mar 30, 2009 at 1:16 PM, weizhong qiang <weizhongqiang@gmail.com> wrote:
>
> On Mon, Mar 30, 2009 at 6:46 PM, Tom Scavo <trscavo@gmail.com> wrote:
>>
>> On Mon, Mar 30, 2009 at 12:06 PM, weizhong qiang
>> <weizhongqiang@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