<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/6/15 6:14 AM, Nate Klingenstein
wrote:<br>
</div>
<blockquote
cite="mid:3E4534A8-39DF-422F-9A8F-BBADCEDE6A45@internet2.edu"
type="cite">
<pre wrap="">I’m having a hard time interpreting the default configuration in metadata-providers.xml in IdPv3. I don't understand:
</pre>
</blockquote>
<br>
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... <br>
<br>
<br>
The JavaDoc tells the story:<br>
<br>
<br>
<tt> /**</tt><tt><br>
</tt><tt> * Get whether incoming metadata's root element is
required to be signed.</tt><tt><br>
</tt><tt> * </tt><tt><br>
</tt><tt> * <p>Defaults to
<code>true</code>.</p></tt><tt><br>
</tt><tt> * </tt><tt><br>
</tt><tt> * @return whether incoming metadata is required to be
signed</tt><tt><br>
</tt><tt> */</tt><tt><br>
</tt><tt> public boolean getRequireSignature() {</tt><tt><br>
</tt><tt> return requireSignature;</tt><tt><br>
</tt><tt> }</tt><br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:3E4534A8-39DF-422F-9A8F-BBADCEDE6A45@internet2.edu"
type="cite">
<pre wrap="">
A) What happens if there's a public key but signed metadata is not required
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:3E4534A8-39DF-422F-9A8F-BBADCEDE6A45@internet2.edu"
type="cite">
<pre wrap="">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
</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:3E4534A8-39DF-422F-9A8F-BBADCEDE6A45@internet2.edu"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
<br>
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'.<br>
<br>
<br>
</body>
</html>