<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 2/4/14 1:31 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:CF169B3F.48F34%25cantor.2@osu.edu" type="cite">
<pre wrap="">On 2/4/14, 1:21 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="">
Also need to settle on and work out how the whitelist/blacklist
algorithm URI's from DecryptionParameters and
SignatureValidationParameters actually get applied, but I think that's
probably just updating the Decrypter and SignatureValidator code to
support those inputs, in some fashion. Since I just reminded myself of
it, I'll work on that this week.
</pre>
</blockquote>
<pre wrap="">
Yes, I'm presuming we want blacklisting to be an input to the construction
of the parameters, not imposed after.</pre>
</blockquote>
<br>
Yes, for the "generation" cases of signing and encryption all the
inputs (including white/blacklisting) ultimately produce the actual
effective values to use, which are reflected and held by the
corresponding -Parameters instances (which don't carry
white/blacklists). It's basically for example:
SignatureSigningConfiguration(s) + (other inputs TBD) --feed-to->
SignatureSigningParametersResolver --generates->
SignatureSigningParameters.<br>
<br>
For the "consumption" cases of signature validation and decryption,
the -Parameters do carry the white/blacklists since that's computed
for what should be in effect for a particular invocation at runtime
(e.g. based on relying party, etc).<br>
<br>
<br>
<blockquote cite="mid:CF169B3F.48F34%25cantor.2@osu.edu" type="cite">
<pre wrap=""> On the validation side, it does
probably have to be part of the validation process, possibly as just a
supplementary validator added to others, or maybe it's just a policy
rule/message handler.</pre>
</blockquote>
<br>
I had up to now actually been (fuzzily) conceiving of
white/blacklisting as being built into the actual SignatureValidator
(and Decrypter) as a fundamental part of what they do. (Or for
signature, maybe the SignatureTrustEngine). Although in looking at
it just now, supplying params via the SignatureValidator and
TrustEngine interfaces may not be the way to go...maybe an external
validator does make more sense for that. <br>
<br>
Related: I saw what you did today with the Decrypter and new
constructor taking DecryptionConfiguration. That definitely wasn't
what I had been thinking - but I'm not sure it's wrong, it depends.
I had not been planning that the security -Configuration classes
would be inputs into anything other than the corresponding -Resolver
which produces the associated -Parameters (i.e. like my above
example for signing). All other runtime components would consume
only the -Parameters instances.<br>
<br>
But: so in v2, the Decrypter (which of course we never have
actually used in the IdP) was actually more or less intended to be
used (generally) like a singleton, in that you could configure just
one instance with the appropriate resolvers and use that for your
decryption needs across many invocations of decryption. In *that*
model, using a DecryptionConfiguration for construction might sort
of make sense to supply the various -Resolvers, but... Thinking
about how to apply white/black lists (if done in the Decrypter
itself, not external), that would most definitely *not* be done via
DecryptionConfiguration, since that info can vary from decryption
invocation to invocation. So it therefore has to be based on
DecryptionParameters.<br>
<br>
So.. the two options I see are:<br>
1) we add DecryptionParameters args to all the decrypt* methods to
supply the per-invocation info, or<br>
2) explicitly reconceive Decrypter as an instance-per-use class that
is constructed with DecryptionParameters.<br>
<br>
Still thinking on it, but slightly leaning at the moment to #2,
since it's more parallel with the way the Encrypter works as a
instance-per-use component (at least the SAML subclass does). <br>
<br>
Also, just noting that this is actually conceptually sort of related
to the same issue I mentioned in my MessageContext notes re: the use
(or not) of the SignatureValidationParams SignatureTrustEngine:
whether to support use of a runtime dynamically-derived trust engine
per invocation (via SignatureValidationParams), or to use one that
is statically wired into the signature validating MessageHandlers
(currently they do the latter).<br>
<br>
</body>
</html>