Metadata requireSignedMetadata=false Behavior

[Brent Putman]

On 6/8/15 7:24 AM, Nate Klingenstein wrote:
>> So the utility of the requireSignedMetadata/requireSignature attribs is the use case where the root is *not* expected to be signed, but 1 or more child elements *are* expected to be signed, and you still obviously need to validate signatures on those (otherwise you wouldn't bother configuring in the signature validation filter on that metadata in the first place).  As one example, think of a use case where the root is an EntitiesDescriptor which is merely a simple (non-signed) aggregation of signed EntityDescriptors obtained from elsewhere.
> That all makes sense, but it strikes me as something of an edge case. 

Definitely it is.


>  Is there a way to specify that you want a particular entity to be signed, for example, or could you only do this on the root?

No.  The root is easy because it's in an absolute position.  However,
being able to arbitrarily specify which children must be signed would
probably require an XPath-like syntax for trees of XMLObjects.  Believe
it or not, Chad once asked me to look into supporting that general
capability, for some other reason....  It's difficult.  I think there
was a library that purported to support expressions on arbitrary object
graphs, but it was going to be a lot of work to implement.  It would
sound pretty heinous for a deployer to configure in any case.

One thing that might be doable is to specify that any metadata that
passes the signature filter has to be "in the scope of" of a signature,
otherwise it gets removed.  So if the root isn't signed, then e.g. any
direct child EntityDescriptors must be signed.  And I think effectively
that really applies to Entity- and EntitiesDescriptors mostly.  I don't
think one could meaningfully support signed RoleDescriptors and
AffiliationDescriptors where the parent EntityDescriptor was neither
signed nor in the scope of a signed EntitiesDescriptor.


>
>> The signing key is for the whole metadata document.  The root may or may not be signed, but doesn't have anything to do with whether any other validation is going to happen.
>
> This is the most interesting thing that you wrote, to me.  I wonder whether this is going to create questions for future use cases where we're trying to support multiple signatures. 

As you've already raised later in the thread, there's definitely
questions/issues for actually doing this sort of thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150608/66eb5d73/attachment.html>