[JIRA] Commented: (CPPXT-78) Support configuration of name and policy restrictions for the signature metadata filter (signing certificate)

[Kaspar Brand (JIRA)]

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

Kaspar Brand commented on CPPXT-78:
-----------------------------------

Many thanks! I'm now running this combination on my test system:

XMLTooling-C 1.5.0, OpenSAML-C 2.4.3, Shibboleth 1.4.3

Looks good so far, and playing with some PolicyOID and TrustedName options gave the expected results ("path validation failure: no explicit policy", "XMLTooling.TrustEngine.PKIX : certificate name was not acceptable" etc.).

I can provide you with new versions of the "SWITCHaai Metadata Signer" and "SWITCHaai Metadata Signing CA" certs, if there's interest. These are not yet configured for signing our official metadata available at http://metadata.aai.switch.ch/metadata.switchaai.xml, but replacing them in the metadata's XML Signature can be used for manual tests. (The new certs have been issued for the same key pairs, and do include appropriate certificatePolicies extensions. We will switch to them at some later time.)

> Support configuration of name and policy restrictions for the signature metadata filter (signing certificate)
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: CPPXT-78
>                 URL: https://issues.shibboleth.net/jira/browse/CPPXT-78
>             Project: XMLTooling - C++
>          Issue Type: Improvement
>          Components: Security
>            Reporter: Kaspar Brand
>            Assignee: Scott Cantor
>            Priority: Minor
>             Fix For: 1.5
>
>         Attachments: CPPXT-78-testdata.zip, SSPCPP-369-v1.diff
>
>   Original Estimate: 2 days
>          Time Spent: 3 hours
>  Remaining Estimate: 0 minutes
>
> Reported by Kaspar Brand, moved from old Jira:
> The Signature MetadataFilter currently doesn't allow to configure specific restrictions on the signing certificate when using the PKIX trust engine (https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMetadataFilter#NativeSPMetadataFilter-SignatureMetadataFilter).
> The only way to correlate the signing cert to particular metadata is through the "the name of the entity over which a signature is being verified" - this doesn't offer much flexibility, however (it possibly requires you to have a signing cert for each entity you sign).
> The IdP supports the notion of a "trusted name" (https://wiki.shibboleth.net/confluence/display/SHIB2/IdPPKIXTrustedName) when configuring the trust engine for a signature validation filter (https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider#IdPMetadataProvider-SignatureValidationFilter).
> It would be useful to have support for TrustedName child elements in the trust engine config for the SP, to (where the value of that element would be checked using AbstractPKIXTrustEngine::checkEntityNames).
> Additionally, support for configuring policy restrictions (through one or more PolicyOID child elements, e.g.) would be a real plus. I.e., a trust engine configuration would then look like this:
>                 <TrustEngine type="StaticPKIX" certificate="/etc/shibboleth/FooCA.crt.pem"
>                              verifyDepth="2" checkRevocation="fullChain">
>                     <TrustedName>Foo Federation Metadata Signer</TrustedName>
>                     <PolicyOID>2.16.756.1.2.6.7.1.1</PolicyOID>
>                 </TrustEngine>
> (In OpenSSL, X509_VERIFY_PARAM_set1_policies() is used to configure policy checking. It was introduced with version 0.9.8. The X509_V_FLAG_EXPLICIT_POLICY, X509_V_FLAG_INHIBIT_ANY and X509_V_FLAG_INHIBIT_MAP verification flags should also be set accordingly [perhaps user-controllable?])
> Is this something which can perhaps be done in 2.5? I'd be willing to help with testing, of course.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira