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

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

On signing, I am fine with the general approach to ordering but I'm not sure you haven't missed a couple of possibilities out.  I had a look at FIPS 186-3 and it seems to me that both DSA and ECDSA permit the use of SHA-224 and indeed all of the other SHS algorithms.

For example, the table on page 15 defines some (L, N) pairs whose security strength you can then look up in 800-57.  The last paragraph on page 15 of 186-3 seems to imply you can use *any* of the SHS algorithms whose strength (again, in 800-57) is at least that strength.

That *seems* to imply that for "plain" DSA you could use any of the algorithms, even SHA-512, although SHA-1, SHA-224 and SHA-256 are the obvious choices (with there being no practical advantage to using SHA-224 as the signature size would not change).  I'm not sure to what extent we need to take the other possible choices into account.  The selection you have (SHA-1, SHA-256) does seem to be a sensible set for DSA, though, and if that's all the underlying libraries support then fair enough.

I think the same applies to ECDSA, where the last paragraph of 186-3 p.27 just says that the strength of the hash function must "meet or exceed" that associated with the bit length ranges.  Working it through, it *appears* to me that ECDSA could in principle be used with any of the SHS algorithms, including SHA-1 at the low end (80-bit strength) all the way up to SHA-512 but certainly including SHA-224 (which isn't in your list).  If included, ECDSA with SHA-224 could (by the same argument as before) either go just after ECDSA with SHA-256 or down in the depths just above ECDSA with 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