Skip to Content.
Sympa Menu

shibboleth-dev - Re: Encryption key strategies

Subject: Shibboleth Developers

List archive

Re: Encryption key strategies


Chronological Thread 
  • From: "Tom Scavo" <>
  • To:
  • Subject: Re: Encryption key strategies
  • Date: Thu, 22 Jun 2006 09:01:14 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rqdHjrNfrxAiV+KQ7LHlE2nlt7hW10EZLfcJAbHX95WyenIhPJAhN8QAp8DgCNgCoPhQc/2cKn2a7F3ricCid03d2c2VIKaNfkb73ylJznH1NWh2Y0n8+81IDttiet/p+mp5a8bJrQjUKxc2nTIABYl0KVzAwrk1Q+fDbw7PZv8=

On 6/22/06, Chad La Joie
<>
wrote:

Tom Scavo wrote:
> On 6/22/06, Scott Cantor
<>
wrote:
>>
>> I asked around a little and determined that in SAML (or Liberty) land,
>> nobody's pushing much beyond per-message keys.
>
> Is it reasonable to extend this beyond a single message and think
> about per-transaction keys? The responder, for example, might reuse a
> symmetric key in the request to encrypt a portion of the response.
> For example, the responder might reuse a key that was used to encrypt
> the NameID in the request to encrypt an assertion in the response.

In theory I think this is possible, but it gets back to the question of
interoperability that Scott mentioned. To the best of my knowledge,
there isn't any spec for how to do this.

Is this close to what you're looking for (e.g.)?

http://www.oasis-open.org/committees/download.php/18058/sstc-saml-x509-authn-attrib-profile-cd-02.pdf

Or are you looking for something more low-level than that?

Tom



Archive powered by MHonArc 2.6.16.

Top of Page