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

[Scott Cantor (JIRA)]

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

Scott Cantor commented on SSPCPP-366:
-------------------------------------

Layman's guide is probably overstating it, but Schneier's blog is always a good source and the questions and comments there and his responses were the main information I found.

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

On hashing, I found:

http://crypto-gram.blogspot.com/ (notes NIST introducing new truncated 512 variants and why)

http://ubuntuforums.org/showthread.php?p=4903822 (notes that with DSA, you have limits on hash size based on key size, but with RSA you don't)

That's for GPG, but I assume it's relevant to any use of RSA, and indicates that the digest size isn't a factor. I guess it might be if the key was small enough, but a 512-bit hash is the largest here, and any of the limitations wouldn't matter to the *verifier*, since the key there is up to the signer. Obviously you can't produce a signature if the sizes don't work, but that will never come into play for the relying party.

Do you have an opinion about the minor issue of role vs. entity? I'm inclined to use the entity-level Extensions block.

> 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: 3 hours
>  Remaining Estimate: 5 hours
>
> 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