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

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

Hal,

 

I disagree 
with you that <ds:KeyInfo> is limited to describing 
public-private

key pairs. It 
could very well be used to "name" a secret key. Here is the 

relevant text 
from http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo

 

<quote>

KeyInfo 
is an optional element that enables the recipient(s) to obtain the key needed to 
validate the signature.  KeyInfo may contain keys, names, 
certificates and other public key management information, such as in-band key 
distribution or key agreement data. 

</quote>

 

Please keep 
this in mind when reviewing the proposed text for Holder of 
Key.

 

- 
prateek

  
-----Original Message-----
From: Hal Lockhart 
  [mailto:]
Sent: Thursday, April 04, 2002 
  6:22 PM
To: 'Mishra, Prateek'; ''
Cc: 
  
Subject: 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> 
  
>