RSA-OAEP interop issues

Brent Putman putmanb at georgetown.edu
Wed Sep 24 20:36:45 EDT 2014


Probably mostly for Scott...

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.

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?

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?

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.
 
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.

Thanks,
Brent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20140924/aea40c99/attachment-0001.html 


More information about the dev mailing list