Question: how to search the trust store to find the HIN certificate when validating the SAML assertion signature

[arhuberg]

We verify the signature of the SAML assertion we received during authentication using the applicable HIN certificate. We find the certificate in our local application trust store (Java Key Store) by the 'alias name' used when it was stored.

Each year we manually download the latest HIN test and production certificates and install them into our trust store.

The use of the alias name is not optimal as it must be manually configured into our system each time we apply the new certificates (a new alias name is used each time a certificate is added - so during the yearly maintenance cycle, the HIN certificates are added, but have a different alias name).

My question is... how to search the trust store to find the HIN certificate? I was thinking of using the 'Subject CN'. We would configure the certificate Subject-CN instead of the alias name and use that to locate the HIN certificate (ignoring those expired or not yet active). I did not think there was anything that could be 'reliably' used from the SAML assertion to identify the certificate used for signing (like the 'KeyInfo/X509Data/X509Certificate' since this was not mandatory, nor should be trusted anyway).

We just want to avoid any downtime (or manually configuration to get the system working again) when HIN performs its certificate maintenance.

What are other doing for solve this issue?

[qligier]

Why would you want to check the assertion signature? Just use it, the EPR will tell you if it is not valid :)

[arhuberg]

I thought Annex 8 required it.

"The -Assertion SHALL be cryptographically signed by the RP and the IdP SHALL validate the signature. The or SHALL be cryptographically signed by the IdP and the RP SHALL validate the signature of each such assertion"

I thought we were the "RP" relying party - but that could be the EPR - I just did not read it that way.

[qligier]

In Annex 8, your role is more probably the subscriber/claimant (as per page 7):

Subscriber/Claimant: A user after successful identification and registration

Relying Party (Service Provider): Data storage and infrastructure operated by the community that is connected to the EIM and provides the access control for identified users (authorization control in accordance with the regulation). Additionally a secure channel exists between the (reference-) community infrastructure and the EIM.

[oliveregger]

• Service Provider (or relying party) in SAML domain means X-Service User in IHE domain
• This means that the relying party would be the the client application (Browser, Rich Client) and the claimant: The user

Therefore the rules of Annex 8 would apply for the client application: The signature SHALL either be validated with the public key of a pre-registered X.509 certificate, or the certificate embedded in the assertion.

[qligier]

But the client application is not operated by the community, nor does it provide the access control for identified users.

The IdP and the Relying Party communicate through a protected backchannel (IPsec or TLS) to exchange the <ArtifactResolve>-Token and the corresponding <Artifact-Response>-Token

Okay, client applications are RPs in that paragraph.

What's the point for a client application to verify the IDP signature here, before the XUA transaction? It does not bring any safety, but requires all implementers to keep up-to-date with IDPs.

It seems like Annex 8 is badly written and conflates roles.

[oliveregger]

I ask @msmock to provide feedback and maybe it needs to be taken up to AG TSI.

[arhuberg]

I forwarded our discussion to Aaron Akeret from HIN. Here made this suggestion: "But as you see in the discussions, there is always a lot of room for interpretation of annex 8. Your solution will be validated by KPMG, right? In my experience, checking such changes with KPMG before implementing it is the best way to go. Otherwise you'll have unpleasant discussions with them during the certification. "

Thoughts? Do we have a KPMG contact?

Full Email Exchange...

From: Aaron Akeret [aaron.akeret@hin.ch](mailto:aaron.akeret@hin.ch) Sent: Monday, January 30, 2023 2:57 AM To: Anthony.Rhuberg@Cerner.com Subject: [External] : Re: HIN certificate maintenance

Hello Tony

My question is... how to search the trust store to find the HIN certificate? I was thinking of using the 'Subject CN'. We would configure the certificate Subject-CN instead of the alias name and use that to locate the HIN certificate (ignoring those expired or not yet active). I did not think there was anything that could be 'reliably' used from the SAML assertion to identify the certificate used for signing (like the 'KeyInfo/X509Data/X509Certificate' since this was not mandatory, nor should be trusted anyway). Good question: There are various ways to handle this. I'm aware of solutions, where just all certificates in a truststore are checked. So no pinning by using the alias, but accept all certificates. I think that's the best way, as you also can handle certificate changes (where the new and the old certificates are active in parallel for a short period of time).

Is it appropriate and good practice to verify the signature? Another developer commented and asked “did I really need to verify the signature if I use the assertion only to pass as a header parameter in a REST call on to the EPR which will verify it anyway”? It is good practice in SAML generally, yes. But the developer is right: in the special case here where you pass the assertion to the XUA-Service, which will check the assertions signature as well, is the signature check on your side is technically redundant (my opinion). However, you've already mentioned the most important argument yourself in your github discussion https://github.com/ahdis/ch-emed-pmp/issues/39: "The -Assertion SHALL be cryptographically signed by the RP and the IdP SHALL validate the signature. The or SHALL be cryptographically signed by the IdP and the RP SHALL validate the signature of each such assertion"

But as you see in the discussions, there is always a lot of room for interpretation of annex 8. Your solution will be validated by KPMG, right? In my experience, checking such changes with KPMG before implementing it is the best way to go. Otherwise you'll have unpleasant discussions with them during the certification.

Regards aaron ........................ HEALTH INFO NET AG · HIN Seidenstrasse 4 · 8304 Wallisellen Telefon +41 52 235 02 70 Direktwahl +41 43 211 48 56 [www.hin.ch](https://urldefense.com/v3/__http:> /www.hin.ch__;!!ACWV5N9M2RV99hQ!KYgzB0dnWEmXhK4FCcLbJW6GkFNxTN4NCLCuFapYNlMdoB70EHPVMTZhZL_fqr1CKAlrb5h3UpdUUj5Ug-UTWsqNMoo$)

HIN · einfach, sicher kommunizieren

[msmock]

I ask @msmock to provide feedback and maybe it needs to be taken up to AG TSI.

To make a long story short: If you rely on any information send by the IdP (name, GLN, or other) you must validate the signature. You must also validate the signature if you are acting as a EPR portal provided by a community. But if you are a medical information system in a hospital or practice, don't use information from the token and just pass it to the communities X-Assertion Provider to retrieve a XUA token, you do not need to verify the signature (although it is good practice and recommended anyway).

I am sorry, but I cannot help with questions on what the best ways are to allocate the X.509 certificates or what others implemented.

[arhuberg]

Michaela, did HCI validate the assertion signature?

We need to decide to keep or remove the our signature validation. If we keep it, it just a little extra yearly maintenance for our client to download and install the HIN public certificates into our system.

Maybe I will make this validation conditional (allow the client to enable/disable it).

[qligier]

HUG has not implemented such a verification, and CARA has not requested it when asserting the implementation.

@msmock Why would it be a good practice? Except for forcing implementers to add support for the validation and synchronize the IdP certificates, what are the expected benefits?

[oliveregger]

cherner chuv will also make it optional the validation, we can close this issue

[arhuberg]

After further review, we decided not to implement the signature validation of the IdP assertion (nor make it optional). We were unable to understand the exact benefit without incurring the maintenance required for the certificates (considering HUG/CARA not implementing; the fact there is mutual authentication between Soarian Clinicals and HIN; and finally we pass the assertion to CARA/EPR to be verified anyway); although optional to the client, internally we would need to test with the feature enabled. We can add the feature in the future if it becomes required.