<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 3/31/14 11:01 AM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">Brent,
I think the reference to the EncryptionParameters class in
SecurityParametersContext was to the wrong class (per my check-in, please
double check). </pre>
</blockquote>
<br>
Yes, it was wrong. Just a Eclipse auto-complete misimport.<br>
<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">Assuming that's the case, seems like we should rename
support.EncryptionParameters to avoid confusion.
</pre>
</blockquote>
<br>
Yeah, that was already on my list. I was planning on renaming it to
something like DataEncryptionParameters, which would also more
clearly distinguish it from its sibling KeyEncryptionParameters.<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">
And is the intent that I manufacture the "lower level"
EncryptionParameters and KeyEncryptionParameters objects from the higher
level one(s)?</pre>
</blockquote>
<br>
Yes, more or less. I was either going to have some support methods
that do that, and/or just add copy-constructor-ish constructor
variants to those 2 that take the newer params instance.<br>
<br>
I did think about just making the Encrypter take the new params
instance, or at least as a variant, but that doesn't seem to work
very, precisely because of the multicast case that the Encrypter
already supports and the need to really distingish a (single) data
encryption params input from the (possibly many) key encryption
params input(s).<br>
<br>
I'm working on all the encryption stuff right now, so I'll do all
this on Wednesday.<br>
<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Related to this for multicast, I think we have to consider that case as
causing Encryption to be a bit different in how we go about resolving
algorithms. </pre>
</blockquote>
<br>
Yes, that was precisely the issue that I already noted in a previous
thread.<br>
<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">To make that work, I really need a candidate list of
algorithms to use for each relying party that I can intersect.</pre>
</blockquote>
<br>
Yes.<br>
<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap=""> Unless we
want to try and make the parameter resolver deal with all of the relying
parties at once. Either way is very ugly.</pre>
</blockquote>
<br>
No, I personally don't think the normal params resolver handle
should do that. I was thinking that specifically for the multicast
case, there would likely be some other component, perhaps another
Resolver, that took a set of inputs corresponding to each relying
party and produced the single data encryption params info.
Something like that. I'll give it some more thought later this week<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">
My preference I guess was to hang a new EncryptionContext off of each
RelyingPartyContext, and push the complexity around multicast into an
encrypting Action that would figure out what all to do.</pre>
</blockquote>
<br>
Yeah, that's basically what I thought as well. It's a specialized
case, so I think we need specialized code to support it.<br>
<br>
<blockquote cite="mid:CF5EFB84.4C530%25cantor.2@osu.edu" type="cite">
<pre wrap="">
If we want to make that part of the resolver, then EncryptionParameters
itself needs to understand multicast.</pre>
</blockquote>
<br>
I personally don't think that would be the best route. To me that
would complicate the basic design just for this one special need.<br>
<br>
</body>
</html>