Clarification on encryption

[Brent Putman]

On 3/31/14 11:01 AM, Cantor, Scott wrote:
> Brent,
>
> I think the reference to the EncryptionParameters class in
> SecurityParametersContext was to the wrong class (per my check-in, please
> double check). 

Yes, it was wrong.  Just a Eclipse auto-complete misimport.


> Assuming that's the case, seems like we should rename
> support.EncryptionParameters to avoid confusion.

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.

> And is the intent that I manufacture the "lower level"
> EncryptionParameters and KeyEncryptionParameters objects from the higher
> level one(s)?

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.

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).

I'm working on all the encryption stuff right now, so I'll do all this
on Wednesday.


>
> 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. 

Yes, that was precisely the issue that I already noted in a previous thread.


> To make that work, I really need a candidate list of
> algorithms to use for each relying party that I can intersect.

Yes.


>  Unless we
> want to try and make the parameter resolver deal with all of the relying
> parties at once. Either way is very ugly.

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

>
> 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.

Yeah, that's basically what I thought as well.  It's a specialized case,
so I think we need specialized code to support it.

>
> If we want to make that part of the resolver, then EncryptionParameters
> itself needs to understand multicast.

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140401/81bb7755/attachment-0001.html