OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: 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:pmishra@netegrity.com]
Sent: Friday, April 05, 2002 3:31 PM
To: 'Hal Lockhart'; Mishra, Prateek; 'Jeff.Hodges@sun.com'
Cc: security-services@lists.oasis-open.org
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:hal.lockhart@entegrity.com]
Sent: Thursday, April 04, 2002 6:22 PM
To: 'Mishra, Prateek'; 'Jeff.Hodges@sun.com'
Cc: security-services@lists.oasis-open.org
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:pmishra@netegrity.com]
> Sent: Thursday, April 04, 2002 4:59 PM
> To: 'Jeff.Hodges@sun.com'
> Cc: security-services@lists.oasis-open.org
> 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:Jeff.Hodges@sun.com]
> >>Sent: Thursday, April 04, 2002 4:54 PM
> >>To: security-services@lists.oasis-open.org
> >>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>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC