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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: Re: [saml-dev] SAML Holder of Key Profile


On Fri, Jan 16, 2009 at 8:35 AM, Scott Cantor <cantor.2@osu.edu> wrote:
> Tom Scavo wrote on 2009-01-15:
>> I disagree, the RP must possess an X.509
>> certificate known to be associated with the attesting entity.  The RP
>> confirms the attesting entity before consuming the HoK assertion.  It
>> does this by comparing the X.509 data in the certificate to the X.509
>> data bound to the HoK assertion.
>
> He means in advance of receiving the assertion. I think the confusion is
> that because you're writing a protocol-neutral set of processing rules,
> you're assuming various things would have taken place ahead of time.

Yes, I know.  I'm realizing how hard it is to write a profile with no
protocol flow :-)  Even your choice of words above ("in advance of"
and "ahead of time") hint of a flow embedded in time.

> Perhaps
> it's necessary to state those assumptions, not as processing rules like
> before but just as "given".

Yes, maybe that's a good way to think about it:

At the issuer:

1) The issuer possesses an X.509 certificate known to be associated
with the intended attesting entity (who may or may not be present)
2) The issuer issues a HoK assertion

At the relying party:

3) The relying party possesses an X.509 certificate known to be
associated with the target attesting entity (who may or may not be
present)
4) The relying party confirms the target attesting entity and
therefore concludes that the target attesting entity and intended
attesting entity are one and the same

The temporal requirements are:

- Step 1 precedes step 2.
- Steps 2 and 3 precede step 4

Strictly speaking, step 3 need not follow step 2 (though the numbering
suggests otherwise).

So now all I have to do is convert that into readable prose :-)

>>> When the attesting party presents the SAML Assertion to the RP, the
>>> attesting party proves possession of the attesting party's cert.
>>
>>  This is where your argument breaks down.  There is no notion of
>> "presenter" or "proof of possession" in this profile.  Everything just
>> *is*.
>
> That's true within the scope of the profile, but once you embed the profile
> into an actual security protocol, both notions emerge as prerequisites
> simply because of the definition of subject confirmation. It only applies if
> both exist.

I agree, but exactly what are you proposing with respect to the HoK
Assertion Profile?  Are you suggesting that we provide a typical usage
scenario to help ground the reader (or mislead the reader, as the case
may be).

Tom


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