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 had 
looked at the individual element formats which seem to be all PK formats. 
However, I concede it is possible to use a symetric key with 

 

KeyName

RetrievalMethod, or

MgmtData.

 

Note 
that using any of these will not result in interoperability without further 
agreeements.

 

Also 
note that you cannot use KeyValue, as its description says:  "The 
KeyValue element contains a 
single public key that may be useful in validating the 
signature."

 

Finally note that the examples under MgmtData are Public 
Keys.

 

Nobody 
was thinking about Kerberos when they wrote this stuff, shich makes sense since 
it is a signature standard. ;-)

 

Hal

  
-----Original Message-----
From: Mishra, Prateek 
  [mailto:]
Sent: Friday, April 05, 2002 3:31 
  PM
To: 'Hal Lockhart'; Mishra, Prateek; 
  ''
Cc: 
  
Subject: 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> 
    
>