<style>
/* Changing the layout to use less space for mobiles */
@media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) {
#email-body { min-width: 30em !important; }
#email-page { padding: 8px !important; }
#email-banner { padding: 8px 8px 0 8px !important; }
#email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; }
#email-fields { padding: 0 8px 8px 8px !important; }
#email-gutter { width: 0 !important; }
}
</style>
<div id="email-body">
<table id="email-wrap" align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#f0f0f0;color:#000000;width:100%;">
<tr valign="top">
<td id="email-page" style="padding:16px !important;">
<table align="center" border="0" cellpadding="0" cellspacing="0" style="background-color:#ffffff;border:1px solid #bbbbbb;color:#000000;width:100%;">
<tr valign="top">
<td bgcolor="#ffffff" style="background-color:#ffffff;color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;line-height:1;"><img src="https://shibboleth.net/images/shib_240x83.png" alt="" style="vertical-align:top;" /></td>
</tr><tr valign="top">
<td id="email-banner" style="padding:32px 32px 0 32px;">
<table align="left" border="0" cellpadding="0" cellspacing="0" width="100%" style="width:100%;">
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;padding:0;">
<img id="email-avatar" src="https://issues.shibboleth.net/jira/secure/useravatar?ownerId=ian%40iay.org.uk&avatarId=10125" alt="" height="48" width="48" border="0" align="left" style="padding:0;margin: 0 16px 16px 0;" />
<div id="email-action" style="padding: 0 0 8px 0;font-size:12px;line-height:18px;">
<a class="user-hover" rel="ian@iay.org.uk" id="email_ian@iay.org.uk" href="https://issues.shibboleth.net/jira/secure/ViewProfile.jspa?name=ian%40iay.org.uk" style="color:#326ca6;">Ian Young</a>
commented on <img src="https://issues.shibboleth.net/jira/images/icons/issuetypes/bug.png" height="16" width="16" border="0" align="absmiddle" alt="Bug"> <a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/IDP-574'>IDP-574</a>
</div>
<div id="email-summary" style="font-size:16px;line-height:20px;padding:2px 0 16px 0;">
<a style='color:#326ca6;text-decoration:none;' href='https://issues.shibboleth.net/jira/browse/IDP-574'><strong>V2 to V3 upgraded IdP does not use algorithm agility metadata</strong></a>
</div>
</td>
</tr>
</table>
</td>
</tr>
<tr valign="top">
<td id="email-fields" style="padding:0 32px 32px 32px;">
<table border="0" cellpadding="0" cellspacing="0" style="padding:0;text-align:left;width:100%;" width="100%">
<tr valign="top">
<td id="email-gutter" style="width:64px;white-space:nowrap;"></td>
<td>
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr valign="top">
<td colspan="2" style="color:#000000;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:12px;padding:0 0 16px 0;width:100%;">
<div class="comment-block" style="background-color:#edf5ff;border:1px solid #dddddd;color:#000000;padding:12px;"><p>It's possible that I was jumping to conclusions on the signature side, as the use of DigestMethod I was looking at turns out not to be in a signature context at all. So let's put that to one side for now and look at the encryption side. I am in the middle of some tax paperwork at the moment, so I won't be able to get engaged enough to do any tracing for a couple of days, but I did look at the relevant metadata, which looks like this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java"><EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#aes128-cbc"</span>/>
</span><EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#aes192-cbc"</span>/>
</span><EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#aes256-cbc"</span>/>
</span><EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#tripledes-cbc"</span>/>
</span><EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2009/xmlenc11#rsa-oaep"</span>/>
</span><EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"</span>/></span>
</pre>
</div></div>
<p>What I had missed on looking at this the first time round is that (as Brent reminds me) the algsupport spec says that these are "listed in order of preference by the entity". I note that the spec does not say whether this is in <b>increasing</b> order of preference or <b>decreasing</b> order, but it's clear from what Brent is saying that the IdP is interpreting this as being "first thing preferred over later things".</p>
<p>I'd like Scott to comment on what he thinks the spec intends, particularly in light of the example, in which for DigestMethod and SigningMethod the earlier (and I assume therefore preferred) algorithms are stronger than the later ones, but the reverse is true for EncryptionMethod in which <b>weaker</b> algorithms appear earlier.</p>
<p>With that interpretation, the IdP is I suppose arguably correct in choosing the weaker algorithm over the stronger ones also listed (although the spec doesn't say that the reader of this metadata can't have its own opinions, in the same way as the negotiation in TLS can be resolved in different ways).</p>
<p>The next thing to note is that this same "stronger first for DigestMethod and SigningMethod, weaker first for EncryptionMethod" pattern is carried through from the example in the spec to the auto-generated metadata that the Shibboleth SP provides, which is how it made it into the metadata I am using. The metadata we registered for our own entities with the UK federation has the stronger EncryptionMethod elements first in the list, however, so someone (I think probably Chad originally) made these up by hand.</p>
<p>I don't think the SP should be listing weaker encryption algorithms ahead of stronger ones in general, as that means that weaker cryptography will always be used unless:</p>
<ul>
<li>The deployer understands crypto and the various specs enough to know that this needs to be changed, or,</li>
<li>Someone at his federation does, and has a long educational discussion with him, or,</li>
<li>Federations just reorder these lists to put them in a more sensible order, or,</li>
<li>The IdP (the only relying party we know for this metadata at present) overrides that order with its own preferences, or,</li>
<li>The IdP blacklisted use of the weaker algorithm at some time in the future.</li>
</ul>
<p>I think the first two options are pretty laughable, and even the third is only viable in a very few contexts. Admittedly the UKf is one of those, and I may need to go down that route, but I don't think the project should rely on that one happening more generally.</p>
<p>So I guess (a) this looks like an SP bug to me but (b) maybe we need to think again about having the IdP not slavishly follow the SPs stated ordering, given that essentially all use of this metadata in federations today will have it pretty much backwards.</p>
<p>As a side note, the UKf at present collects EncryptionMethod metadata from members but only publishes it in our test aggregate, due to concerns about an old Shibboleth 2.0 release which fell over if it was included. We are planning to start publishing it soon because the V3 IdP can make use of it, but obviously there is little or no point in doing that if the result is going to be that everyone is locked into AES-128-CBC anyway.</p>
<p>I looked through eduGAIN metadata to try and get a feeling for support for this metadata element other than from the UKf. Bottom line seems to be that there is a bare handfull of people who have made manual lists, and those are ordered strong/weak. Everyone else has this metadata only as a result of the shibboleth SP, so it's listed in the order the SP comes up with, for example:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java"><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2009/xmlenc11#aes128-gcm"</span>/>
</span><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2009/xmlenc11#aes192-gcm"</span>/>
</span><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2009/xmlenc11#aes256-gcm"</span>/>
</span><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#aes128-cbc"</span>/>
</span><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#aes192-cbc"</span>/>
</span><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#aes256-cbc"</span>/>
</span><md:EncryptionMethod Algorithm=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/04/xmlenc#tripledes-cbc"</span>/></span>
</pre>
</div></div>
<p>So that at least has 3DES at the end, but although we have AES+GCM preferred over AES+CBC, we still have 128-bit preferred over anything stronger. If we actually believe the IdP is obliged to honour that ordering, there's no real point in including the stronger forms unless 128-bit AES were actually broken and we blacklisted it at the IdP.</p></div>
<div style="color:#505050;padding:4px 0 0 0;"> </div>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td>
</tr>
</table>
</td><!-- End #email-page -->
</tr>
<tr valign="top">
<td style="color:#505050;font-family:Arial,FreeSans,Helvetica,sans-serif;font-size:10px;line-height:14px;padding: 0 16px 16px 16px;text-align:center;">
This message is automatically generated by JIRA.<br />
If you think it was sent incorrectly, please contact your JIRA administrators<br />
For more information on JIRA, see: <a style='color:#326ca6;' href='http://www.atlassian.com/software/jira'>http://www.atlassian.com/software/jira</a>
</td>
</tr>
</table><!-- End #email-wrap -->
</div><!-- End #email-body -->