Configuring additional signing/encryption certificate/key pairs for IDP 3.4.6

[Mak, David]

Heh, yes, sadly, while I tried explaining that to them, it fell on deaf ears. They acknowledged they could accept our SHA1 MD RSA2048 cert, and I thought we were done. THEN, they asked our legal department to sign a document stating that we accept / absolve them of any responsibility should there be a data privacy violation... soooo, in the interest of not tilting at windmills more than I already do, I decided to acquiesce.

Thanks Scott for pointing out my error! Indeed, I didn't have all the parts connected. It's working well now, and if this should come up again in the future, we can handle it without trying to lecture them on cryptographic basics.

David Mak
Identity Services Specialist
Information Technology Services
Northeastern University
360 Huntington Ave. Boston MA 02115-5000
Mail Stop: 322-C21
O:617-373-7836 M:617-840-7543
d.mak at northeastern.edu<mailto:%20d.mak at neu.edu>
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Peter Schober <peter.schober at univie.ac.at>
Sent: Friday, May 29, 2020 5:58 AM
To: users at shibboleth.net <users at shibboleth.net>
Subject: Re: Configuring additional signing/encryption certificate/key pairs for IDP 3.4.6

* Mak, David <d.mak at northeastern.edu> [2020-05-28 23:33]:
> We have a vendor who is complaining about a SHA1 signed RSA2048 self
> signed cert (not due to expire until 2032) and how they need to
> configure an exception to accept our signed responses (that they
> require) so we looked into creating a new SHA256 MD/signed RSA2048
> cert and added it as per:

Not that this will matter much but that means they have a bug, no?
(Just so that we're clear about this at least here.)

The signature on a self-signed certificate by its nature is
meaningless (because its self-asserted so provides no more information
nor trust than what's being signed), so is the signature algorithm
used in that signature.

The only useful thing in such a certificate is the public key itself
and it's trustworthy only because of trustworthy exchange of the SAML
2.0 metadata its embedded into.

https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.oasis-open.org%2Fsecurity%2FSAML2MetadataIOP&data=02%7C01%7Cd.mak%40northeastern.edu%7C35fed3d5e3584606809308d803b6e969%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637263431425728553&sdata=WYyECmf9gQWZjZjQxdYHYU5SMlBx9D0YlL4NI77OHE4%3D&reserved=0

If so you should be telling the vendor that so that maybe they could
fix this and spare other customers to perform the dance you're now
having to go through to work around their bug.

Best,
-peter
--
For Consortium Member technical support, see https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.shibboleth.net%2Fconfluence%2Fx%2FcoFAAg&data=02%7C01%7Cd.mak%40northeastern.edu%7C35fed3d5e3584606809308d803b6e969%7Ca8eec281aaa34daeac9b9a398b9215e7%7C0%7C0%7C637263431425728553&sdata=uMOrlAr9bIiGN2vnsjrFIx0nRK%2FAWaoXoWOzeRcg%2BYM%3D&reserved=0
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/20200603/4156e283/attachment.htm>