RSA-OAEP vs. RSA-OAEP-MGF1P

[Ian Young]

> On 3 Feb 2015, at 15:32, Cantor, Scott <cantor.2 at osu.edu> wrote:
> 
>> It's not so clear to me what the former indicates, though. Just using that
>> algorithm alone for key transport isn't valid, as you need to indicate which
>> mask generation function and digest algorithm you want to use. Indeed, the
>> v3 IdP does just that and selects MGF1 with SHA-1 so everything is nicely
>> compatible.
> 
> The meaning is valid, it just means that the defaults are in effect.

OK, it turns out the reason I didn't know that is that there is a bad link from the algorithm cross-reference document to XMLENC 1.0. In XMLENC 1.1, that's properly specified.

> The SP isn't advertising 4-5 of each by enumerating all the digests.

I guess I'd respond by saying that if it advertises those two algorithms -- with no mask function parameters -- then if I understand what you're saying it's just saying the same thing twice.

* If we don't want the SP to advertise the ability to use other digest functions (I assume it has that ability, and note that I'm not saying that it's necessary at this point, AFAIK MGF1+SHA-1 is fine unless if you just don't like the musty smell of SHA-1 anywhere in your system) then there's no need to advertise the unparameterised generic form as well as the MGF1P form as they are semantically identical.

* If we *do* want the SP to advertise the ability to use other digest functions, we'd need to advertise each one and take the size hit. People or federations can always edit them down again.

The other alternative would be to reason that it isn't necessary to advertise every one: MGF1 and SHA-256 would seem like the obvious upgrade, so maybe replacing the current RSA-OAEP descriptor with RSA-OAEP+MGF1+SHA-256 would be a reasonable compromise, particularly for people who wish to shun SHA-1 on principle.

>> Shouldn't the SP be explicitly indicating which MGFs and digest algorithms it
>> supports for use with RSA-OAEP though?
> 
> 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.

I'd be interested to know whether the IdP handles it too. I'd like to know there's a migration path available in principle even if at present we have no reason to think it's going to be needed any time soon.

    -- Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5250 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20150203/bf0f8ac0/attachment.bin