RE: [security-services] HolderOfKey and SenderVouches are slippin gthru the cracks(!)

Title: RE: [security-services] HolderOfKey and SenderVouches are slippin	g thru the cracks(!)

I agree with Prateek. I think a confirmation method should be defined in the Profile that uses it. 

BTW, I made this comment some time ago, but I will repeat it. The description of Holder-of-Key is wrong. If you look up ds:KeyInfo you will see thaat it is not "Any cryptographic key", it is specifically a Public Key. I think the description should read something like:

"The subject of the assertion is the party that can demonstrate that it knows the value of the private key that corresponds to the Public Key specified in <ds:KeyInfo> of the enclosing <SubjectConfirmation> element, by means of the procedures implied by the particular KeyInfo format chosen." 

The reason is that an X.509 cert implies X.509 processing, a PGP key ring implies PGP processing and so forth.

Hal

> -----Original Message-----

> From: Mishra, Prateek [mailto:]

> Sent: Thursday, April 04, 2002 4:59 PM

> To: ''

> Cc: 

> Subject: RE: [security-services] HolderOfKey and SenderVouches are

> slippin g thru the cracks(!)

> 

> 

> Jeff,

> 

> one reason I had not included these identifiers was that the 

> SOAP Profile

> document is now available. My own preference (given that 

> these identifiers

> only make sense in the context of a particular

> profile construction) would be to include them in the next 

> rev of the the

> SOAP

> profile document. 

> 

> - prateek

> 

> >>-----Original Message-----

> >>From: Jeff Hodges [mailto:]

> >>Sent: Thursday, April 04, 2002 4:54 PM

> >>To: 

> >>Subject: [security-services] HolderOfKey and SenderVouches 

> >>are slipping

> >>thru the cracks(!)

> >>

> >>

> >>An apparent side-effect of our placing the responsibility 

> for defining

> >>ConfirmationMethod identifiers with SAML profiles and 

> >>bindings is having the

> >>HolderOfKey and SenderVouches ConfirmationMethods sort of 

> disappear. 

> >>

> >>The are not mentioned in Prateek's proposed changes to 

> >>bindings-model-13...

> >>

> >>Proposed changes to bindings-13 to includedefinition of SAML 

> >>Confirmation

> >>Method identifiers

> >>http://lists.oasis-open.org/archives/security-services/200204/

> >>msg00013.html

> >>

> >>Note that we explicitly listed them among the four 

> >>ConfirmationMethods we felt

> >>we wanted to retain..

> >>

> >>Minutes for Focus Group Telecon Tue 2-Apr -2002

> >>http://lists.oasis-open.org/archives/security-services/200204/

> >>msg00007.html

> >>

> >>

> >>> Presently defined & employed ConfirmationMethods (and attendant

> >>> SubjectConfirmationData values) will be defined in 

> >>appropriate places in the

> >>> subsequent version of bindings-model-xx, and it'll also 

> >>have a (sub)section

> >>> summarizing the presently defined & employed 

> ConfirmationMethods...

> >>>  holderOfKey

> >>>  bearer

> >>>  sender vouches

> >>>  artifact

> >>

> >>

> >>This situation is likely due to there not being an obvious place in

> >>bindings-model-13 to define holderOfKey and SenderVouches. 

> >>

> >>Additionally, we'd agreed that there ought to be a summary 

> >>section (appendix?)

> >>that lists all the ConfirmationMethods defined in the spec. 

> >>

> >>A proposal to solve this is to concot a short, specific 

> >>subsection of section 3

> >>"Bindings" (3.2, say) along the lines of..

> >>

> >>

> >>3.2 ConfirmationMethod Identifiers 

> >>

> >>Assertions returned by SAML responders in response to any 

> >>SAML requests MAY

> >>contain ConfirmationMethod identifiers defined in this 

> >>subsection, or MAY

> >>contain ConfirmationMethod identifiers defined elsewhere in 

> >>this specification

> >>(e.g. in profiles), or MAY contain ConfirmationMethod 

> >>identifiers defined in

> >>other specification or by private agreement. Use and 

> interpretation of

> >>ConfirmationMethod identifiers is profile- or 

> >>application-specific. See 

> >>

> >>

> >>3.2.1 Holder of Key: 

> >>

> >>  URI: urn:oasis:names:tc:SAML:1.0:cm:Holder-Of-Key

> >>

> >>  <ds:KeyInfo>: Any cryptographic key

> >>

> >>  The subject of the assertion is the party that can 

> >>demonstrate that it 

> >>  is the holder of the private component of the key specified 

> >>in <ds:KeyInfo>

> >>  of the enclosing <SubjectConfirmation> element. 

> >>

> >>

> >>3.2.2 Sender Vouches: 

> >>

> >>  URI: urn:oasis:names:tc:SAML:1.0:cm:sender-vouches

> >>

> >>  Indicates that no other information is available about the 

> >>context of 

> >>  use of the assertion. The Relying party SHOULD utilize 

> >>other means to

> >>  determine if it should process the assertion further. 

> >>

> >>

> >>

> >>...and add this appendix near the end of the spec....

> >>

> >>

> >>

> >>X Appendix: ConfirmationMethods summary 

> >>

> >>These confirmation methods are defined in this specificaiton:

> >>

> >>  Identifier                                         See section

> >>  ----------                                         -----------

> >>

> >>  urn:oasis:names:tc:SAML:1.0:cm:Holder-Of-Key        3.2.1

> >>

> >>  urn:oasis:names:tc:SAML:1.0:cm:sender-vouches       3.2.2

> >>

> >>  urn:oasis:names:tc:SAML:1.0:cm:Artifact-01          4.1.1.1

> >>

> >>  urn:oasis:names:tc:SAML:1.0:cm:Bearer               4.1.2.1

> >>

> >>

> >>

> >>

> >>-----

> >>JeffH

> >>

> >>----------------------------------------------------------------

> >>To subscribe or unsubscribe from this elist use the subscription

> >>manager: <http://lists.oasis-open.org/ob/adm.pl>

> >>

> 

> ----------------------------------------------------------------

> To subscribe or unsubscribe from this elist use the subscription

> manager: <http://lists.oasis-open.org/ob/adm.pl>

>