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

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

I think we should include all the information we can: people can always filter, but I don't think we can expect people to generate anything that's missing (deployers will almost never have the specialist knowledge required to make the judgements, and registrars won't know enough about the details of the deployment to be able to guess what has been left out).

This whole algorithm agility thing is obviously a long game, and the sooner we start to include relevant information the more likely we are to have it when we need it.  As time passes hopefully the 2.0 SP is less relevant, and of course we're now worried more about encryption algorithms than we were when I wrote this up originally.  So I reckon we should include EncryptionMethod.

That does probably mean that we need to publicise this a bit more, particularly for federations so that they can do their own risk assessments, so if you wanted to start a mailing list thread on this question that would be fine.

On the UK side, I'd expect to continue with the current regime of accepting EncryptionMethod, retaining it in our registry but filtering it out before publication.  It's probably time for us to give notice to our deployers that this won't be the case forever, as I'd like to move to not filtering this out once there is software that can actually make use of it.  If that's likely to be IdP V3, we should probably start the clock ticking soon.

Of course, some federation registries won't accept this kind of metadata in the first place so they will presumably not be affected.

My inclination is for the SP to issue metadata for all encryption methods and hash sizes that it supports.  That might just be the capabilities of the underlying libraries, but obviously if the SP has some kind of hard-coded policy (or available configuration) that rejects certain possibilities as insecure, then you'd need to filter those out.

I'd be nervous about saying things like "just SHA-256" as it might be taken to indicate a lack of support for any other algorithms, despite their being MTI in other specs.  The algsupport spec is kind of ambiguous about this now that I come to read it, as it says both that "it is a natural assumption that a peer stating support for particular algorithms requires their use" but also that a metadata consumer should be doing a strict intersection.  I'd say include everything rather than make the metadata consumer's job more complicated.

As to ordering, as the algsupport spec says "take first algorithm in the intersection" I guess we need to come up with an ordering we think will give the least surprising result (use the strongest).  We can't rely on, say, any ordering in the underlying library, to give that result.  Of course, deployers and federations may in principle both filter and reorder that list, but I think we should operate on the basis that most won't.

> 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