[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=14228#comment-14228 ] 

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

If I understand that Ubuntu forum post, all he's saying is that any of the has functions will fit into an RSA operation if the RSA modulus is 1024 bits long.  Which is true, but my question was whether one might run into problems if the RSA modulus was, say, 512 bits.  We know that there are people out there using 512-bit credentials, and you can't pad a 512-bit hash result and then perform an RSA operation on that message straight off, as I understand it this would require doing RSA on multiple message blocks.  I may be confused, of course.

> 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