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

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

On hashes, I think your ordering (SHA-256 > SHA-224 > SHA-512 > SHA-384 > SHA-1) is fine.  It's probably worth documenting a rationale, though, which I reckon looks like this:

The point of the exercise is to move people away from SHA-1, because although it appears safe today it is clearly weakening.  Therefore, SHA-1 should be least preferred.  We think any of the SHA-2 functions are adequate for the medium term even if SHA-1 falls, so we prefer the cheapest of those (SHA-256).  We accept the reduced output variants (SHA-224, SHA-384) alongside their non-reduced variants because they still provide adequate security at the same computational cost, but prefer the full sized ones because they give us more margin at the same cost.

I thought about suggesting moving SHA-224 down between SHA-384 and SHA-1 (giving 256 > 512 > 384 > 224 > 1) on the basis that SHA-224 is the function with the next smallest margin after SHA-1 so we'd prefer to skip over it, but I don't think it really matters a lot as I can't see anyone preferring SHA-224 over SHA-256. In raw "more bits better" terms, 160 to 224 is +64 bits, 224 to 256 is +32 bits so you could hand wave that 224 is most of the way to 256.  Until some researcher proves otherwise, of course.

Related question: carrying that same ordering through to signing makes sense, but I note that there isn't an ECDSA w/ SHA-224 variant on your list.  Is that not defined for some reason, or is that just an accidental omission?

> 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