<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Sorry for just getting to this, I've been heads down the last 2 days
on GU work, and also my Shib Eclipse workspace in the office is
hosed at the moment...<br>
<br>
<br>
<div class="moz-cite-prefix">On 3/9/14 6:35 PM, Cantor, Scott wrote:<br>
</div>
<blockquote cite="mid:CF426327.4B32D%25cantor.2@osu.edu" type="cite">
<pre wrap="">Mainly to Brent...
I'm wondering if we need to split up the EncryptionParameters into Data
and Key types to represent the difference between whether and how to
encrypt the data and who to encrypt it for?</pre>
</blockquote>
<br>
I'd note at the outset re: the EncryptionParameters that it isn't
assumed that all the properties on a given instance are populated.
In particular, the 3 slots related to data encryption will often be
null, since the Encrypter can and usually does just auto-generate an
ephemeral data encryption Credential internally. The
dataEncryptionAlgorithmURI might and probably will be populated
based on a resolved preference from configuration and/or metadata
(although it doesn't have to be, the Encrypter inputs effectively
have an internal default of AES-128). The dataKeyInfoGenerator isn't
used in at least most SAML cases - the EncryptedData gets a KeyInfo
with the EncryptedKey, if you're using INLINE key placement, and
that doesn't come from a generator since it's an internal detail of
the Encrypter.<br>
<br>
So in a way there's not much reason to split them in practice....
But if you really wanted to have 2 different instances, you could
theoretically just have 2 instances of EncryptionParameters: one
with just the data slots populated and one with just the
keyTransport slots populated. But really, thinking of them as being
separate (whether different classes or not) I think isn't
conceptually correct, since the type of key encryption that is
chosen depends (or *can* depend), in part, on the type of key you
are encrypting. And so it seems to me they have to be resolved
together, hence just a single EncryptionParameters class.<br>
<br>
Speaking of multiple RP's and key multicasting, there is an issue
there in general (not just with our code) of what data encryption
algorithm to use. More on multiple RP's and key multicast later.<br>
<br>
<blockquote cite="mid:CF426327.4B32D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I can't pull a single parameter set from a RelyingPartyContext as a signal
whether to encrypt because that doesn't tell me which objects need to be
encrypted. But if we split these, I could create separate subcontexts for
the different types of objects that might need encryption and hang those
off the profile context, but put the KeyEncryptionParameters below the
RelyingPartyContext.
</pre>
</blockquote>
<br>
I guess I don't see those 2 things as necessarily related. In
practice, based on the resolved config and metadata prefs of the RP,
all 3 SAML types would have the same data encryption algorithm URI
anyway. I don't know of any way to signal differences there.<br>
<br>
The only reason to split them to multiple instances that I can see
would be if we wanted to have the resolver actually auto-generate
the ephemeral data encryption Credential itself, rather than let the
Encrypter do it (the assumption being that you don't want to reuse
the same data encryption key for multiple encryption ops). <br>
<br>
Aside from the fact that we don't need to (since the Encrypter does
it), that doesn't really fit at the moment with my (evolving) notion
of how the -Resolvers work and what they do. They are really about
resolving and winnowing down preference lists coming from 1 or more
-Configuration instances (which have order-of-precedence) +
metadata.<br>
<br>
But if we did want to do that, I'd argue for keeping things simple
and just having a single EncryptionParameters class. The multiple
instances that would be resolved for the 3 cases (with different
dataEncryptionCredentials), would just happen to have the same data
for the keyTransport* slots (in particular the
keyTransportEncryptionCredential, since for a given RP you're
typically going to always resolve the same one anyway, at least with
SAML and keys coming from metadata). <br>
<br>
<blockquote cite="mid:CF426327.4B32D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Otherwise we'd have to combine the idea of presence/absence as a signal
with something more fine grained to tell what to do.</pre>
</blockquote>
<br>
Re: signalling whether to encrypt for the 3 distinct SAML 2 types
(Assertion, Attribute, NameID): In the first email in the thread you
were proposing not having distinct security context param "slots"
for these to do the signaling (i.e. stick with one generic
SecurityParametersContext). So given that, what I assumed is that
something like the following would happen:<br>
<br>
1) In an early action as you proposed (for error handling purposes),
you had something like this in pseudo code:<br>
<tt><br>
</tt><tt>if (effectivelyEncryptAssertion() ||
effectivelyEncryptNameID() || effectivelyEncryptAttribute()) {</tt><tt><br>
</tt><tt> EncryptionParameters params =
resolveEncryptionParams(.... )</tt><tt><br>
</tt><tt> storeEncryptionParams(params, relyingPartyContext)</tt><tt><br>
</tt><tt>}</tt><br>
<br>
Meaning basically pre-resolve the params if you know you're going to
encrypt. (Same for signing btw).<br>
<br>
2) in the later actions that do the encryption e.g. Assertions:<br>
<br>
<tt>if (effectivelyEncryptAssertion()) {</tt><tt><br>
</tt><tt> EncryptionParameters params =
getEncryptionParams(relyingPartyContext)</tt><tt><br>
encryptAssertion(assertion, params)<br>
</tt><tt>}</tt><br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:CF426327.4B32D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
I don't know what you have in mind yet as Criteria for the resolvers, but
I'm assuming that we'd need a way to signal the "type of encryption"
(Assertion, NameID, Attribute) for it to resolve the parameters if the
intention is to bury whether to encrypt it all into that resolution
process.
</pre>
</blockquote>
<br>
<br>
No, I hadn't thought of anything like that. I wasn't intending for
the -Resolvers to eval stuff that is really IdP-specific notions of
configuration, for profiles, etc. What I have meant by "IdP
security configuration" evaled in the resolvers was really multiple
instances of -Configuration (e.g. EncryptionConfiguration), some of
which are coming from layers in the IdP. They are arrayed in some
order-of-precedence with others from say OpenSAML (e.g. global
library defaults). But hadn't considered taking into account for
example the encryptAssertion and signResponse kind of flags.
Instead my thought was that the IdP evals those flags, and then if
it's going to do that particular cryptographic op, it calls the
appropriate resolver with the appropriate inputs to resolve the
-Parameters.<br>
<br>
I'll do more writeup when this is more solid, but right now I see
2-3 obvious runtime inputs to the -Resolvers as Criterion instances:<br>
<br>
1) one that takes a list (or probably a varargs) of the appropriate
-Configurations<br>
2) for the SAML-aware specializations, one that takes a
RoleDescriptor to support the algorithm support extension (for
signing at least, encryption doesn't need b/c the info will be
attached already to the credential by the
MetadataCredentialResolver)<br>
3) for niche cases, one that takes a KeyInfo "profile" name, used
with NamedKeyInfoGeneratorManager. Always optional, and in practice
would be infrequently used.<br>
<br>
Contrary to what I previously thought, at the moment I don't think
that we'd even have -Resolver subclasses that live in the IdP
project. They're all in OpenSAML. Things like the IdP-specific
-Configuration instances would just be passed at runtime as
Criterion inputs. Maybe that changes if we identify stuff I've
missed, but that's my current thinking.<br>
<br>
I have some pretty well-formed ideas about the -Configuration and
-Resolver components now, and how they work, and I'm working on
implementing things in draft. Hopefully I'll have something more
concrete checked in by the end of the week so we can straw man in
more detail.<br>
<br>
<br>
<blockquote cite="mid:CF426327.4B32D%25cantor.2@osu.edu" type="cite">
<pre wrap="">
Alternatively, we can split "whether to sign/encrypt" from "how to
sign/encrypt" and just add predicates to the signing/encryption actions
that determine that and fail in those actions if they have to do them but
can't find parameters.
</pre>
</blockquote>
<br>
<br>
Yes, that's essentially what I assumed you were talking about when
you suggested not using anything other than the current single
SecurityParametersContext, with an instance living somewhere under
the RelyingPartyContext.<br>
<br>
<br>
*************************<br>
<br>
This may deserve eventually a separate thread, but I have thought of
some issues related to multiple RP's and key multicast for
encryption. <br>
<br>
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...<br>
<br>
1A) If you have to do this data encryption algorithm URI selection
for multiple RP's, that's probably some other kind of resolver or
selector component.<br>
<br>
2) What should happen if there are multiple RPs and encryption is
required for one of more of the SAML types, but can not resolve an
encryption key for all of the RPs? Is that an error, or do you just
not encrypt to some them?<br>
<br>
<br>
<br>
</body>
</html>