<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <div class="moz-cite-prefix">On 2/3/15 10:32 AM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote

cite="mid:9846A6064BD102419D06814DD0D78DE10A9E52@CIO-TNC-D2MBX02.osuad.osu.edu"

      type="cite">

      <blockquote type="cite">

        <pre wrap="">Shouldn't the SP be explicitly indicating which MGFs and digest algorithms it

supports for use with RSA-OAEP though?

</pre>

      </blockquote>

      <pre wrap="">

Technically, but you can see how bloated that's going to get pretty quickly. Brent would have to comment as to whether the IdP would handle it.

</pre>

    </blockquote>

    <br>

    Yes, as you already saw we do fully support expressed OAEP

    parameters in metadata, etc.  However, in reviewing this and the

    issues raised, I think there is a bug in the code right now. 

    Relatively easy to fix.<br>

    <br>

    Right now when considering a candidate Credential (KeyDescriptor)

    and samlmd:EncryptionMethod pair, only the cred and

    EncryptionMethod@Algorithm are considered.  If those are acceptable,

    then that pair gets picked.  Then later the RSAOAEPParamers is

    resolved from the EncryptionMethod.  If the DigestMethod and/or MGF

    is unusable (runtime support and/or policy), it falls back to

    configuration for those.<br>

    <br>

    I think that's wrong.  I think the eval of the Credential and

    EncryptionMethod should also take into account the various OAEP algo

    params.  If a DigestMethod and/or MGF are present, then they need to

    be acceptable or else you have to reject the whole

    EncryptionMethod.  That makes the candidate eval fall through to the

    next listed EncryptionMethod.  <br>

    <br>

    That would be necessary if you want to list them in metaddata like:<br>

    <br>

    #rsa-oaep with SHA-512<br>

    #rsa-oaep with SHA-256<br>

    <br>

    Right now, if say SHA-512 was unsupported, you'd wind up getting the

    config default of SHA-1 rather than the next expressed preference of

    SHA-256.<br>

    <br>

    I'll open an issue on that, should be able to get that addressed

    this week.  Do we have a tentative timeline for 3.1 yet?<br>

    <br>

    <br>

    <br>

  </body>

</html>