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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

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


Subject: Re: Fwd: suggestion for holder of key profile


On Wed, Nov 19, 2008 at 10:24 AM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
>
>> Suppose the SAML issuer parses the X.509
>> certificate in its possession and binds the subject DN in the
>> certificate to the <saml:SubjectConfirmation> element.  Then the RP
>> must also parse the X.509 certificate and verify that the subject DN
>> in the certificate is the same as the DN bound to the assertion.  As
>> far as I can tell, it doesn't help to bind additional elements to the
>> <saml:SubjectConfirmation> element
>
> I am not talking about the subjectDN.

I was simply using that as an example.  The IdP is free to use the
subject DN from the certificate as an identifier for the subject.  It
would only do that, however, if it trusted the certificate issuer, so
that may or may not turn out to be typical.

> I am talking about other identities
> which
> happen to be somehow hidden in extensions. As we seem to agree in a parallel
> thread ;-);  the nameIds asserted by the id provider may be whatevr you
> want,
> they may or may not be in the certficate.

That is true.  The IdP chooses an identifier based on the requirements
of the RP and prevailing policy.

> It helps the application to just use the ids that are presented in the
> NameIds,
> the application does not need to look at the certificate at all (beyong
> maybe
> verifying that Issuerserial or subject are identical, or of the certificat
> is presented
> in the assertion, then a pure binary compare with the cert on the TLS can
> be performed.

I think you're confusing Subject/NameID with
Subject/SubjectConfirmation.  If the IdP chooses to use an identifier
from the certificate, this identifier becomes the NameID, not
SubjectConfirmation.  Including an identifier in SubjectConfirmation
as you've suggested doesn't make sense to me.  The SubjectConfirmation
element is supposed to tell the RP how to confirm the subject.  How
does putting an identifier in the SubjectConfirmation element affect
the confirmation of the subject?

> Ah, this reminds me to the point that in order to have a client/brower
> present
> a certificate, the service provider normally has to provide a list of CAs.

No, I don't think so.

> This should be mentioned somewhere in the text. The schemes doe not
> clearly indicate which "session" is in HTTPS, as far as I see, both, the
> one with the id provider and the one with the service provider.

Are we talking about the HoK Assertion Profile or the HoK Web Browser
SSO Profile?  Yes, the latter needs to do a better job of specifying
exactly when TLS is required and when it is optional.  (I have some
text in my sandbox that has not yet been submitted.)  On the other
hand, the HoK Assertion Profile doesn't depend on TLS (normatively).

>> There is nothing the SAML issuer can bind to the assertion (except the
>> entire certificate) that precludes the RP from parsing the X.509
>> certificate.
>
> I am not sure to understand the sentence. Do you mean prohibit?

Please read section 2.6.1 in draft-06.  If the SAML issuer binds a
<ds:X509Certificate> element to the assertion, the RP does not have to
parse the certificate to confirm the subject.  If, however, the SAML
issuer binds any other element, the RP MUST parse the certificate to
confirm the subject.

> An RP does whatever it wants with the certificate, but the rules of
> the game are that the application may only verifies the key, and all
> other information is taken from the SAML environment, i.e.,
> the id provider produces all necessary information for the
> application wherever are their sources.

No, the RP does whatever the SubjectConfirmation element tells it to
do.  See section 2.5 of draft-06.

>> Relating this to the HoK Web Browser Profile, if both the SAML issuer
>> and the RP obtain the same certificate via the TLS exchange, and the
>> presenter proves possession of the corresponding private key in both
>> cases, then the RP can conclude that one-and-the-same presenter was
>> involved in *both* transactions.
>
> I am not sure whether you want to say "That is how it works".
> The sentence seem ambiguous on the first 'if'. should it be 'since'?

I don't understand your comment, Peter.  If you would like to rewrite
the paragraph for clarity, that might help me understand your point.

Thanks,
Tom


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