RE: [security-services] ISSUEs - on X509 replacing Assertions wit hPublic key

["Mishra, Prateek" <pmishra@netegrity.com>]

Mack,

I agree with your analysis of the proposed protocol. I think
there are fundamentally two cases here:

(1) sender = subject (this is the "strong case" - need a better
term for it)

BusinessMessage = {[Assertions with SubjectConf=HOK][Payload]}[Signature]

Assertions carry public key information (ds:KeyInfo) of the
sender; the entire assertion is also signed by the assertion
issuer. The recipient utilizes the <ds:KeyInfo> element found
in the subject element of the assertion to
verify only the integrity of the business message. The <ds:KeyInfo>
element thereafter plays no further role in the processing.
Finally,
the recipient relies on its trust relationship with the
assertion issuer to determine the context in which the
business message should be processed.

(2) sender =/= subject (this is the "weak case")

BusinessMessage 
= {[Assertions with SubjectConf=SenderVouches][Payload]}[Signature with
<ds:KeyInfo>]

Assertions do not carry public key information of the sender. The
entire assertion is signed by the assertion issuer. The recipient
utlizes the <ds:KeyInfo> *bundled with the signature* to ensure message
integrity. Thereafter, the recipient relies on its relationship
with the assertion issuer AND the sender to determine the context
in which the business message should be processed. As compared to (1)
the extra-step at the recipient corresponds to the following:

 (*) Does the recipient recognize the sender's public key and does the
 recipient accept that the sender is authorized to "vouch for" the  
 subject?

  Example: procure.com receives a business message from a server at
  Netegrity. Based on its policies it determines that the <ds:KeyInfo> 
  certificate is valid and authorized to vouch for Netegrity employees.
 
The remaining steps are exactly as in (1) (i.e. recipient relationship
with the assertion issuer).

- prateek


>>-----Original Message-----
>>From: Hicks, Mack [mailto:Mack.Hicks@bankofamerica.com]
>>Sent: Wednesday, October 17, 2001 6:42 PM
>>To: Mishra, Prateek
>>Cc: 'blakley@tivoli.com'; Hollowood, Larry
>>Subject: Re: [security-services] ISSUEs - on X509 replacing Assertions
>>with Public key
>>
>>
>>Prateek, Bob,
>>
>>I was not on the call, so pardon me please if I cover the 
>>same territory.
>>
>>If  [Signature] contains ds:Keyinfo - I read this to say that the 
>>receiver knows how to get/process the Sender's public key (or other 
>>keying material for verification / validation).  There is no need to 
>>send further references in the SAML message to such key information.
>>
>>So I am wondering what was meant in the first place by 
>>[Assertion with 
>>Sender Public Key] - if it just meant X509 - then why is that not 
>>already referenced by the ds:Keyinfo in the [Signature]?  
>>
>>I must be missing something - which is why this is not posted to the 
>>whole list.
>>
>>Mishra, Prateek wrote:
>>
>>><snip>
>>> 
>>>Pictorially:
>>> 
>>>BusinessMessage=
>>> 
>>>[{[Assertions about Subject] [Assertion with Sender Public 
>>Key][Payload]}
>>>[Signature]
>>> 
>>> 
>>><snip> becomes ...
>>> 
>>> BusinessMessage= {[Assertions about
>>>Subject][X509.Certificate][Payload]}[Signature] 
>>> 
>>>As before BusinessMessage integrity is guaranteed by the 
>>senders signature;
>>>instead of processing [Assertion with Sender Public Key] the 
>>recipient
>>>examines
>>>the [X509.Certificate] (this could be generalized to 
>><ds:KeyInfo>) and
>>>determines
>>>whether the sender is trusted to "vouch for" the subject.
>>> 
>>>Comments are invited on this proposed change.
>>> 
>>> 
>>>- prateek
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>
>>>----------------------------------------------------------------
>>>To subscribe or unsubscribe from this elist use the subscription
>>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>>
>>
>>-- 
>>---------------------------------------------
>>Mack Hicks, SVP     mack.hicks@bankofamerica.com
>>Bank of America  +1-415-241-3654
>>
>>