<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 5/17/14 12:47 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF9D4E7C.CEED%25cantor.2@osu.edu" type="cite">
<pre wrap="">
</pre>
<pre wrap="">
So, correct me, but the purpose of listing multiple algorithms is
basically to "survive" a blaclist imposed at some level? So if the first
one in the list is blacklisted, the order matters because it will pick the
second.</pre>
</blockquote>
<br>
Yes, exactly.<br>
<br>
Think of the algorithm lists as expressions of:<br>
<br>
1) capability (just by virtue of presence in the list)<br>
2) preference (ordered, so first one wins)<br>
<br>
In contrast, the whitelist/blacklist is an expression of policy. An
algorithm must pass the whitelist/blacklist eval, or it doesn't get
used, period (applies to algos in metadata as well).<br>
<br>
So in the effectively configured algorithm list (i.e. all the
configs logically combined in order), you need to enumerate all the
ones you are capable and (potentially) willing to use. As I earlier
mentioned, listing multiples is practically speaking really only
necessary for the special case of the lowest level default config,
just to get them all in there. That's to then allow a more natural
use of the higher order-of-precedence configs, wherein: <br>
<br>
1) you just might list the single algorithm that you want to state
as a preference at that level (goes to the head of the list in front
of the others)<br>
or <br>
2) you just blacklist/whitelist some algorithms at that level, e.g.
setting an IdP or RP-specific policy<br>
<br>
<br>
<br>
<blockquote cite="mid:CF9D4E7C.CEED%25cantor.2@osu.edu" type="cite">
<pre wrap="">
It's a little confusing I think because if you look at, say, RSA PKCS 1.5
key transport, which we'll be blacklisting, having it listed in the global
defaults seems kind of odd.
</pre>
</blockquote>
<br>
Ah, I just missed that particular one. I didn't know we literally
wanted to blacklist that. If that is the case, then we would do
like I already did there for the MD5 signing and digest variants:
put it in the blacklist and do NOT put it in the algorithm list. <br>
<br>
<br>
<br>
<blockquote cite="mid:CF9D4E7C.CEED%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I guess I understand the point, not having to add it back there if
somebody wants to override the blacklist for a particularly regressive SP?</pre>
</blockquote>
<br>
<br>
No, my intention would be the opposite: if someone really wants to
use a weak or broken algorithm (and that we blacklist by default)
for a regressive SP, they absolutely should have to jump through
hoops. Specifically:<br>
1) they would have to include that algo in the appropriate algorithm
list, obviously. It's not otherwise listed by us by default.<br>
2) blacklists merge now by default (as of last night), so they'd
have to also set the blacklist merge flag on the RP-specific config
to false. Otherwise the blacklist from the global config would
preclude it.<br>
<br>
<br>
Speaking of blacklists: I suppose that for the IdP, the blacklists
could be explicitly duplicated in the IdP global config, with
merging set to false. Then it becomes more explicit to people what
is blacklisted, and theoretically makes it possible for them to
easily change (although we obviously wouldn't recommend it, at least
for the IdP-wide config).<br>
<br>
<br>
<blockquote cite="mid:CF9D4E7C.CEED%25cantor.2@osu.edu" type="cite">
<pre wrap="">
It's going to be pretty crucial to document the steps you want to take to
do certain things here.</pre>
</blockquote>
<br>
<br>
I agree, although I've tried to design this so that doing things for
the common cases is easy and natural and requires minimal
data/typing.<br>
<br>
It's true that in some cases, depending on what you want to do,
there may be more than one way to achieve a particular desired
effect, so that certainly deserves documenting. For example, in the
absence of metadata info (so algorithms coming solely from config),
adding an algo (assumed to already be in the config somewhere) to
the RP's whitelist would have the same effect as adding it
explicitly to RP's algorithm list: it's the one that would get used,
albeit for different reasons (policy vs preference). However, in
the presence of relevant metadata info, the behavior would
potentially be different: metadata algos are considered before
looking at config algos and will be used as long as they pass the
whitelist/blacklist policy.<br>
<br>
<br>
</body>
</html>