<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
OK, but I don't agree with the rationale behind this:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
"Specifically, metadata obtained via an insecure transport should be both signed, and should expire, so that consumers are forced to refresh it often enough to limit the damage from compromised information."</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The cat's out of the bag - it doesn't take very long to get access all the information. By the time you find out you should assume it's all been accessed and compromised. I don't see how a key rollover offers any protection whatsoever.</div>
<div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div>
<div></div>
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<div style="font-family:Tahoma; font-size:13px">---
<div><span id="ms-rterangepaste-start"></span><span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Roberto Ullfig - rullfig@uic.edu</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Systems Administrator</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Enterprise Applications & Services | Technology Solutions</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">University of Illinois - Chicago</span>
<div><span id="ms-rterangepaste-end"></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> users <users-bounces@shibboleth.net> on behalf of Peter Schober <peter.schober@univie.ac.at><br>
<b>Sent:</b> Wednesday, July 21, 2021 7:49 AM<br>
<b>To:</b> users@shibboleth.net <users@shibboleth.net><br>
<b>Subject:</b> Re: Service Provider not checking for certificate expiration</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">* Ullfig, Roberto Alfredo <rullfig@uic.edu> [2021-07-20 20:56]:<br>
> We're running a service provider at version 3.2.3 and I noticed that<br>
> if the assertions are signed with an expired certificate that the<br>
> service provider will accept that - that doesn't seem<br>
> right. Shouldn't the SP reject those assertions?<br>
<br>
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.oasis-open.org%2Fsecurity%2FSAML2MetadataIOP&data=04%7C01%7Crullfig%40uic.edu%7Ce826c909e8aa4a7f0eef08d94c45f0c5%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637624685838417056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1bkky7tDJSUKgGUhRSIJ0d3lEZO2jRsNjQ47i4JSH6o%3D&reserved=0">https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.oasis-open.org%2Fsecurity%2FSAML2MetadataIOP&data=04%7C01%7Crullfig%40uic.edu%7Ce826c909e8aa4a7f0eef08d94c45f0c5%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637624685838417056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1bkky7tDJSUKgGUhRSIJ0d3lEZO2jRsNjQ47i4JSH6o%3D&reserved=0</a><br>
<br>
Section 2.6.1 specifically but if you're asking that you'll want to<br>
read at least the Introduction in full.<br>
<br>
-peter<br>
-- <br>
For Consortium Member technical support, see <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=04%7C01%7Crullfig%40uic.edu%7Ce826c909e8aa4a7f0eef08d94c45f0c5%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637624685838417056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WBqIpUJ0y8sUXT%2F2B3AvL6eWDPZ8cQdJ%2BmgJ3UQwTcg%3D&reserved=0">
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fshibboleth.atlassian.net%2Fwiki%2Fx%2FZYEpPw&data=04%7C01%7Crullfig%40uic.edu%7Ce826c909e8aa4a7f0eef08d94c45f0c5%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C637624685838417056%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=WBqIpUJ0y8sUXT%2F2B3AvL6eWDPZ8cQdJ%2BmgJ3UQwTcg%3D&reserved=0</a><br>
To unsubscribe from this list send an email to users-unsubscribe@shibboleth.net<br>
</div>
</span></font></div>
</body>
</html>