Re: [security-services] SAML2 Holder-of-Key Assertion Profile

["Tom Scavo" <trscavo@gmail.com>]

Hi Frederick,

On Wed, Aug 20, 2008 at 10:46 AM, Frederick Hirsch
<frederick.hirsch@nokia.com> wrote:
>
> Since SAML 2.0 has been standardized [1] the W3C has released a new edition
> of XML Signature, the Second Edition [2]. This is a maintenance release that
> incorporated errata, updated references, and added XML Canonicalization 1.1
> as a required algorithm, addressing potential issues with xml:id and
> xml:ibase [3].

This is the first I've heard of [2], thanks for pointing that out.  I
just skimmed [2] and noticed the following differences relevant to the
profile we are discussing here: 1) [2] refers to RFC4514 in lieu of
RFC2253, and 2) the DN encoding rules have been overhauled.  The
latter, in particular, are very much appreciated!

> I note that the Holder-of-Key Assertion Profile draft references the
> original XML Signature recommendation. Should it reference the Second
> Edition? I would expect it to be compatible with both the first and second
> editions of XML SIgnature.

I will review {2] but my initial read suggests we should indeed refer
to it from here on out.  Thanks for the pointer!

>>  Indeed, this is what we have in [XMLSig] yet everyone agrees that that's
>> not adequate.
>
> Do you mean is that the semantics and details regarding use of ds:KeyInfo
> are not fully described in XML Signature, or did I misinterpret what you are
> saying ?

Exactly.  I wonder, is that by design?  Regardless, will this error of
omission be addressed in [4]?

>> There's no way to extend [XMLSig] without introducing some process (at
>> least, I don't see how to do it).
>
> Are you asking about the process of improving XML Signature in general, or
> about whether XML Signature schema has extension points?

Well, no, when I say "extend [XMLSig]," I'm talking about the missing
details regarding ds:KeyInfo as noted above.  Whether those details
can be specified without considering relevant use cases is still an
open question in my mind.  (Scott seems to think so.)

> Regarding the former, there is a new W3C XML Security Working Group actively
> working on a new version of XML Signature. I encourage bringing issues and
> requirements to that group [4], whose mailing list is public [5]. There are
> a few members of the SSTC active in that group. I  would like to understand
> any issues that you feel are important related to XML Signature and make
> sure that they are known to that Working Group.

Thank you, Frederick.  As you know, my primary interest is in
ds:KeyInfo as it relates to saml:SubjectConfirmation.  As we work
through the Holder-of-Key Assertion Profile, hopefully the issues and
the requirements will become clear.

Tom Scavo
NCSA

> [1] http://www.oasis-open.org/apps/org/workgroup/security/#samlv20
>
> [2] http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/
>
> [3] http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/explain
>
> [4] http://www.w3.org/2008/xmlsec/
>
> [5] http://lists.w3.org/Archives/Public/public-xmlsec/
>
> On Aug 14, 2008, at 1:41 PM, ext Tom Scavo wrote:
>
>> Okay, I changed the name of the "Holder-of-Key Subject Confirmation
>> Profile" to "Holder-of-Key Assertion Profile" and uploaded to kavi as
>> draft-02:
>>
>> http://wiki.oasis-open.org/security/SAMLHoKSubjectConfirmation
>>
>> I also removed all references to samlp: elements and trimmed the
>> presentation as much as I could.  If you think the profile is
>> confusing in some way, please let me know what you think is confusing
>> and I'll fix it.  If you'd rather make the edits directly, please do
>> so.
>>
>> All that said, I don't think calling this an "assertion profile" makes
>> much difference.  I don't believe HoK subject confirmation can be
>> profiled from a purely structural point of view.  Indeed, this is what
>> we have in [XMLSig] yet everyone agrees that that's not adequate.
>>
>> There's no way to extend [XMLSig] without introducing some process (at
>> least, I don't see how to do it).  There's a process that results in a
>> HoK <saml:SubjectConfirmation> element in the first place.  Then
>> there's another process that consumes such an element.  I don't see
>> how you can profile HoK subject confirmation without describing those
>> processes.
>>
>> Now if you claim that every profile should describe this process in
>> its own words, I have to disagree.  If the presenter is the subject,
>> and the subject presents a SAML request and an X.509 certificate to a
>> SAML issuer, I can (and have) restricted the actions of the SAML
>> issuer to a small set (4) of well-defined operations.  Moreover, if
>> that subject turns around and presents a HoK assertion and an X.509
>> certificate to a relying party, the RP knows exactly what it has to do
>> to confirm the subject.
>>
>> The foregoing is a process, not a structure.  So this profile is not
>> an assertion profile, it's a protocol-based profile.  The question is
>> whether or not the process can be sufficiently generalized to be
>> useful across a set (n > 1) of protocol-based profiles.  I claim it
>> can.  This profile can be applied to Nate's HoK Web SSO Profile,
>> Scott's SSOS Profile (which I haven't read), and my Self-AuthnRequest
>> SSO Profile (which I haven't submitted yet).  That's n >= 3.
>>
>> Tom
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>