<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 9/23/22 6:19 PM, Nate Klingenstein
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+eXai67wdXOkzc4x_qHYDDQ4DG5d30kmoPvPdmXZ0oHWwRg=Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</body>
</html>