<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 3/12/14 6:23 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF465425.9DCC%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 3/12/14, 5:33 PM, "Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
2) in the later actions that do the encryption e.g. Assertions:
if (effectivelyEncryptAssertion()) {
EncryptionParameters params = getEncryptionParams(relyingPartyContext)
encryptAssertion(assertion, params)
}
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
<br>
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.<br>
<br>
I was mainly just pointing out that, for a given RP, the
EncryptionParams for the 3 cases would all contain the same data, if
not literally be the same instance (assuming we don't want it to
contain an auto-generated ephemeral data encryption key).<br>
<br>
<br>
<blockquote cite="mid:CF465425.9DCC%25cantor.2@osu.edu" type="cite">
<pre wrap="">
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.</pre>
</blockquote>
<br>
Yes. Signing is easier as you say, because there's already 2
natural distinct spots to put the params (MessageContext for
protocol message, somewhere underneath the ProfileRequestContext for
assertion).<br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote cite="mid:CF465425.9DCC%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
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...
</pre>
</blockquote>
<pre wrap="">
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).</pre>
</blockquote>
<br>
<br>
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.<br>
<br>
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. <br>
<br>
</body>
</html>