Metadata requireSignedMetadata=false Behavior

[Brent Putman]

On 6/6/15 6:14 AM, Nate Klingenstein wrote:
> I’m having a hard time interpreting the default configuration in metadata-providers.xml in IdPv3.  I don't understand:

First off, I wanted to clarify what the boolean flag actually means. 
Part of the confusion may be that the filter custom schema attrib is
'requireSignedMetadata', but on the actual Java filter class it's
'requireSignature'. Perhaps a slight change in meaning there... 


The JavaDoc tells the story:


    /**
     * Get whether incoming metadata's root element is required to be
signed.
     *
     * <p>Defaults to <code>true</code>.</p>
     *
     * @return whether incoming metadata is required to be signed
     */
    public boolean getRequireSignature() {
        return requireSignature;
    }


So what the flag actually does is require (or not) the *root* element
of the input metadata document to be signed.  Period.  Perhaps the
property would have been better named as 'requireSignedRoot' or something.

Second, remember that in metadata, any/all of EntityDescriptor(s),
EntitiesDescriptor(s), RoleDescriptor(s) and AffiliationDescriptor(s)
may be signed.  The signature validation filter will validate them
all.  If a signature is present, it must pass the SignatureTrustEngine,
period.  If the root element fails trust eval, the whole filter throws
an exception.  However, if a non-root element fails, it is simply
effectively removed from the metadata document.

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.


> A) What happens if there's a public key but signed metadata is not required

Any signatures present are still validated and must pass, period.  A
root failure throws.  A non-root failure results in removal of that
element only.


> B) What the value is in specifying a signing key that is optional, since accepting unsigned metadata despite having a validation key seems to defeat the purpose of signing

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.


> C) Why you wouldn't make requireSignedMetadata=true implicit behavior if there's a key, and requireSignedMetadata=false implicit behavior if there is no key, which would seem to obviate the need for requireSignedMetadata as a flag.

B/c things other than the root may be signed.  The 2 cases are really
orthogonal to one another.  Also remember that besides the new key/cert
syntactic sugar in the schema, you can still wire a
SignatureTrustEngine as in the past. So there's multiple ways to
specify how the trust material for signature validation is specified.


Let me know if that doesn't at least clarify the technical aspects of
what's going on.  I haven't looked at all the docs/comments, esp in the
IdP and schema, so I don't know if any of that disagrees with the
technical reality.  Perhaps we should deprecate the
'requireSignedMetadata' and/or 'requireSignature' properties in favor
of something more descriptive like 'requireSignedRoot'.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150607/9b31dbae/attachment-0001.html>