Straw-man for security parameter placement

[Cantor, Scott]

On 3/12/14, 5:33 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>2) in the later actions that do the encryption e.g. Assertions:
>
>if (effectivelyEncryptAssertion()) {
>  EncryptionParameters params = getEncryptionParams(relyingPartyContext)
>  encryptAssertion(assertion, params)
>}

The crux of my message was this, I misunderstood your intent. I thought
you said you wanted the presence of the parameters to signal whether to
encrypt, so that meant that a single parameters instance wouldn't be
enough.

I think what you meant to say was you wanted the option to encrypt to
determine whether to resolve the parameters, which isn't quite the same
thing. Same with signing, except that in that case, it's at least
coincidentally possible to actually use that as a signal later because
there are only two locations where we'd put parameters for signing, and
those match the two common cases for signing, the assertions and the
response.

>But hadn't considered taking into account for example the
>encryptAssertion and signResponse kind of flags.   Instead my thought was
>that the IdP evals those flags, and then if it's going to do that
>particular cryptographic op, it calls the appropriate resolver with the
>appropriate inputs to resolve the -Parameters.

That's what I didn't understand. I agree that if the actions are
responsible for that checking, then obviously they can check in two
actions, to resolve the parameters and again to decide to use them.

>This may deserve eventually a separate thread, but I have thought of some
>issues related to multiple RP's and key multicast for encryption.
>
>1) It could turn out that based on -Configurations + metadata +
>whitelist/blacklist, you wind up with different resolved values for the
>data encryption algorithm URI.  In general I guess you then attempt to
>extract the lowest (or highest) common denominator.
> But it's also possible (based on say whitelist/blacklist values) that
>you could theoretically wind up with mutually exclusive choices.  So then
>I'm not sure what you do...

I thought of that recently, and I think given the obscureness of the use
case itself, we don't need to do more than behave predictably (which right
now might mean failing or needing a new class we haven't implemented yet).

>2) What should happen if there are multiple RPs and encryption is
>required for one of more of the SAML types, but can not resolve an
>encryption key for all of the RPs?  Is that an error, or do you just not
>encrypt to some them?

To answer that I think we need more than a theoretical use case, but I
would guess whatever policies we could have for one RP would apply to
many. We already have the open question of supporting "encrypt if you
can", and that applies to both 1 RP and many. Perhaps less usefully.

-- Scott