CWE ID 327: AbstractNamedCurve.java:94

Nate Klingenstein ndk at sudonym.me
Sat Sep 24 00:24:37 UTC 2022


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:

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.

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...

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.

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.

On Fri, Sep 23, 2022 at 5:07 PM Brent Putman via users <users at shibboleth.net>
wrote:

>
> On 9/23/22 6:19 PM, Nate Klingenstein wrote:
>
>
> 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.
>
>
> Sure, I was answering based on the implied assumption that one wants to do
> EC crypto in the first place.
>
> 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.)
>
> 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.
>
> 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. :-)
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220923/be382941/attachment.htm>


More information about the users mailing list