Re: [security-services] Drafts for review: Kerberos & SAML profiles

[Josh Howlett <josh.howlett@gmail.com>]

> Josh Howlett wrote on 2009-08-11:
>>>> That's an interesting idea. It certainly seems simpler than  
>>>> grafting
>>>> Kerberos onto the HoK AP. Are there are any reasons why we would  
>>>> not
>>>> want to do this?
>>>
>>> I think it relates more than anything else to the WSS SAML token  
>>> profile,
>>> and given that I think that document probably needs to be revisited
>>> anyway,  I'm not sure I care at this point.
>>
>> You've lost me... How does this relate to the WSS SAML token profile?
>
> The WSS profile, last I read it, sort of bakes in an awareness of a  
> pair of
> confirmation methods, HoK and sender-vouches (the latter being  
> essentially
> meaningless). It's not clear to me whether you can actually use other
> methods and still follow the profile.

I asked the question on the WSS mailing list a few days ago, but have  
received no response so far.

My own interpretation (FWIW) of the WSS SAML token profile is that the  
absence of text concerning the use of other confirmation methods did  
not imply that other confirmation methods were not permitted.

It also seems to me that the use of a Kerberos-based HoK is also  
compatible with the processing rules set out in sections 3.5.1.1 and  
2.5.1.2 of that specification, because this is left fairly open-ended.

Is the absence of clarity in this respect likely to be problematic?

In the absence of any statements to the contrary, I am inclined to  
lean towards the HoK approach although uncomfortably perched on the  
fence because I'm still contemplating your earlier observation  
concerning the appropriateness of using the Kerberos principal name as  
an identifier that names a key.

I suppose we could define a new type ('KerberosData'?) for KeyInfo  
whose semantics were less ambiguous, but I'm wary of unnecessary  
invention.

best regards, josh.