[JIRA] Commented: (SSPCPP-366) generated metadata should include cryptographic algorithms

[Ian Young (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237#comment-14237 ] 

Ian Young commented on SSPCPP-366:
----------------------------------

Right, having convinced myself that you're not allowed to use multiple RSA operations in a signature (the signature has to be the same length as the RSA modulus, in other words) the potentially problematic case is an SP which supports and prioritises SHA-512 in its metadata, and an IdP which supports SHA-512 and determines that's what it should try and do even if its RSA signing key is (say) 512 bits.  The hash plus the required additional gubbins won't fit into the RSA operation, so the signature will fail at the IdP side (the SP won't see it) and it would look like that was caused by the SP's metadata.

I suppose the "right" approach is going to be that the IdP implementation will have to have enough smarts not to select a hash algorithm whose output is too large relative to the length of the RSA modulus.  In other words, this is something to be looked at in the IdP implementation that hasn't been written yet and not something we need to worry about on the SP side.

The less friendly approach would of course be to decide that people who are still using 512-bit RSA are in need of a wake-up call.  I don't know how common it still is; obviously some federations insist on longer keys but I can't speak for all of them.

> generated metadata should include cryptographic algorithms
> ----------------------------------------------------------
>
>                 Key: SSPCPP-366
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-366
>             Project: Shibboleth SP - C++
>          Issue Type: Improvement
>          Components: Other
>            Reporter: Ian Young
>            Assignee: Scott Cantor
>            Priority: Minor
>             Fix For: 2.5
>
>   Original Estimate: 1 day
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> The service provider should generate metadata describing the cryptographic algorithms supported, per the SAML v2.0 Metadata Profile for Algorithm Support Version 1.0.
> This should include alg:SigningMethod and alg:DigestMethod, as they are the ones we're most likely to need in the shorter term as MD5 and potentially SHA-1 go beyond their useful life.
> There's a note in the wiki that there are problems with OpenSAML-C 2.0 with respect to adding EncryptionMethod elements to KeyDescriptor elements. If this problem is isolated to IdP metadata, we should probably include EncryptionMethod elements as well. If the problem occurs even if EncryptionMethod is present in the metadata for another SP, there's an argument that the SP should not generate EncryptionMethod metadata until we really need it. I'd actually be interested in that clarification myself as at present UK federation checks preclude using EncryptionMethod on both SPs and IdPs, just to be on the safe side.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira