<div dir="ltr">Very well put.  I guess what I should have written in my initial response and how I'd summarize things from an operational perspective is:<div><br></div><div>In federated identity, your ability to achieve a given level of security is highly constrained by the level of security that your partners are able to achieve.  This is particularly true in cryptography, where Shibboleth supports things that most implementations don't, but even simply listing valid attribute scopes in metadata is still a Shibboleth-specific extension.</div><div><br></div><div>It'd be great to have sufficiently strong keys for both EC and RSA (until, as you mentioned, RSA is eventually broken) in your metadata, but there are a ton of IdP's out there that are unable to even handle multiple credentials in metadata for rollover.  If I have to see another configuration screen where you copy and paste the SP's certificate manually...</div><div><br></div><div>When you can constrain the IdP's that you work with to sufficiently sophisticated implementations, you're in great shape.  If you can't, you're kind-of at their mercy.</div><div><br></div><div>I think the Shibboleth Consortium should place more emphasis on the software's ability to go above and beyond the limitations of most implementations so that more deployers see the substantial value added.  The Dev team does great work that is often underappreciated.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 23, 2022 at 5:07 PM Brent Putman via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p><br>
    </p>
    <div>On 9/23/22 6:19 PM, Nate Klingenstein
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>Yes, absolutely.  But if I were the SP in question, I
            would fear that supplying just a strong EC key in metadata
            would be more likely to lead to interoperability failures or
            unencrypted assertions with most IdP's, which lack the code
            to deal with EC keys at all.  The ideal may be the enemy of
            the good in this instance.</div>
        </div>
      </div>
    </blockquote>
    <br>
    <p>Sure, I was answering based on the implied assumption that one
      wants to do EC crypto in the first place.</p>
    <p>If one is concerned about interop and suspects that some peers
      just don't even support EC at all, then you'd probably want to
      include both an RSA and EC key in your metadata.  Then the
      encrypting party can choose which one they prefer. (Assuming *you*
      support EC - the Shib SP does not currently support ECDH and
      probably won't until we move to the Java-based shibd
      re-implementation.)<br>
    </p>
    <p>For signing you'd include both in metadata as well, for peers to
      validate with. But on the local config side, you'd have to decide
      whether to sign with RSA by default and add specific RP config to
      use EC, or vice versa, depending on how prevalent you think EC
      support is within your common peer entities.</p>
    <p>Or, of course, not do EC at all, and stick with RSA only for now,
      which I imagine is what the vast majority of people are probably
      actually doing...at least until RSA falls. :-)<br>
    </p>
  </div>

-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>