<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 9/18/18 9:36 AM, Cantor, Scott

      wrote:</div>

    <blockquote type="cite"

      cite="mid:3FE893E1-0D9E-4EE4-9C1F-4ABAD81FC07E@osu.edu">

      <pre wrap=""> 

</pre>

      <blockquote type="cite">

        <pre wrap="">Not surprised -- I was groping for words. Let me try again: just

because you have what appears to be the right certificate defined in

your metadata, there's some complex policy machinery that can

effectively remove it from consideration: usage constraints, algorithm

constraints, etc.

</pre>

      </blockquote>

      <pre wrap="">

Algorithms don't come into play much, that's mostly if it's EC or RSA and you just don't see EC much if at all. It didn't sound like that was your issue here and in practice it just doesn't come up much. The one that does come up occasionally is name filtering but I've seen that more with my SP when picking decryption keys.</pre>

    </blockquote>

    <br>

    I don't think it was Marvin's issue.<br>

    <br>

    But for the record, in the OpenSAML Java ExplicitKeyTrustEngine and

    also the Decrypter, we do actually do various kinds of key algorithm

    and key length filtering with code like below.  Where we can (i.e.

    we have an algorithm URI), it makes sense to apriori exclude creds

    from resolution, e.g. it doesn't make sense to even try and validate

    an RSA signature with an EC key:<br>

    <br>

     <tt>       final String jcaAlgorithm =

      AlgorithmSupport.getKeyAlgorithm(signature.getSignatureAlgorithm());</tt><tt><br>

    </tt><tt>        if (!Strings.isNullOrEmpty(jcaAlgorithm)) {</tt><tt><br>

    </tt><tt>            criteriaSet.add(new

      KeyAlgorithmCriterion(jcaAlgorithm), true);</tt><tt><br>

    </tt><tt>        }</tt><tt><br>

    </tt><br>

  </body>

</html>