Straw-man for security parameter placement

[Cantor, Scott]

On 3/12/14, 9:38 PM, "Brent Putman" <putmanb at georgetown.edu> wrote:
>
>Ok.  I'm not sure exactly what I said or where, but in general:  If there
>is a natural place in the PRC tree to put the EncryptionParameters for
>each of the 3 cases so as to use the presence/absence to signal (either
>hanging a SecurityParametersContext underneath
> something, or adding named slot(s) for the params), than that's fine.
>If not, then having the IdP config params evaled twice (early on for
>resolution, later for the encryption op) is also fine.  I'm actually
>neutral on that, I don't have strong feelings either way.

What was confusing me was that I thought you had intended the resolver
process itself to act as a signal (returning something or nothing), so
that it would be the thing evaluating the conditions. That was throwing me
off, but I'm fine now.

>For encryption, I'd say it's just whatever makes the most sense.  You are
>much more familiar with the PRC hierarchy than I am.

I think now that I see the different cases, I'm inclined to separate the
parameter types up after all, and I'm wondering if maybe the *Parameter
beans should just be context types so that they can be directly attached
into the tree instead of having to wrap them. Does that seem crazy? You
had said they're "just beans" and that's consistent with most of the
context types.

>Short of failing, an option of last resort that seems easy and defensible
>is perhaps just falling back to an algorithm that is required to be
>supported by the XML Encryption spec.  AES-128-CBC and AES-256-CBC are,
>for example.  Although the CBC mode is of course
> problematic.

The likely reason for a blacklist or different choices is precisely
because of that issue. I guess it's ok to pick something that's not
blacklisted as a fall back if the metadata offers no intersection, but you
wouldn't want to pick something the local config had blacklisted.

>I just realized that there is also theoretically a parallel issue with
>signing.  For the protocol message signature I think it's pretty clear
>that you only consider the SAML requester's metadata prefs and IdP
>configuration.  But for the assertion, it's less
> clear since the assertion itself will be consumed by multiple RP's.  I
>suppose we could just say that the SAML requester's prefs and config
>wins.  And maybe a similar strategy makes sense for the encryption data
>encryption algorithm URI also.

I think I originally noticed the issue there, in fact, when I was thinking
about the multi RP case in the context tree. I don't really know a good
answer, but at least failing is understandable and predictable.

-- Scott