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

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

What I'm really asking is what order I should use. I don't really know much about hashing, and there doesn't seem to be a lot of advice about which ones to use once you get into SHA-2.

AES sizes are similarly muddled. I've seen some evidence that AES-128 is the best security/performance trade-off, but I don't really know.

My proposal at the moment is something like this. I am able to determine if an algorithm is supported, so they're only included when the code permits.

Encryption:
AES-128 GCM
AES-256 GCM
AES-192 GCM
AES-128 CBC
AES-256 CBC
AES-192 CBC
3DES

Key Transport:
RSA-OAEP (new version, pluggable MGF)
RSA-OAEP (original, MGFP1 w/ SHA1)
RSA-PKCS1.5

Digest:
SHA-256
SHA-224
SHA-512
SHA-384
SHA-1

Signing:

ECDSA w/ SHA-256
ECDSA w/ SHA-512
ECDSA w/ SHA-384
RSA w/ SHA-256
RSA w/ SHA-224
RSA w/ SHA-512
RSA w/ SHA-384
DSA w/ SHA-256
ECDSA w/ SHA-1
RSA w/ SHA-1
DSA w/ SHA-1


> 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