
<html>

  <head>


    <meta http-equiv="content-type" content="text/html; charset=utf-8">

  </head>

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

    Probably mostly for Scott...<br>

    <br>

    I was reviewing the code in the OpenSAML Java Encrypter and

    Decrypter around what we do on the RSA OAEP key transport case and

    expressing the various optional EncryptionMethod parameters.<br>

    <br>

    In v2, on encryption we always add an explicit ds:DigestMethod with

    SHA-1 if it wasn't already added by Santuario.  IIRC, at the time we

    found that some other libraries (I think including Santuario C++)

    didn't like it if you left that out.  For v3, it seems reasonable to

    leave that in.  It's technically never wrong to explicitly express

    it, even if it's the implicit default. Do you disagree?<br>

    <br>

    Now with the new Encryption 1.1 variant, I was looking at what to do

    with xenc11:MGF re: always expressing it explicitly (or not) if it's

    the SHA-1 default.  Do you have any opinions?<br>

    <br>

    In particular, I was wondering what the current state of Santuario

    C++ and the SP is wrt the 1.1 variant.  I'm assuming it

    fundamentally supports this key transport at some level. Does it

    support MGF's other than the default MGF-1 w/ SHA-1?  If not, will

    it barf if it encounters an explicit xenc11:MGF element?  If so,

    does it conversely require that the xenc11:MGF be explicitly

    expressed?  And since Java Santuario and OpenSAML now support

    explicitly-configured OAEPparams, would also be nice to now what C++

    Santaurio and OpenSAML support there, or not.<br>

      <br>

    Is anyone aware of any other interop issues we need to consider

    here, such as what SimpleSAMLphp's SP supports?  I'll try looking on

    their site, but thought I would ask here also.<br>

    <br>

    Thanks,<br>

    Brent<br>

    <br>

  </body>

</html>