AndersAbel
commented
2 years ago If I understand this right, the issue is with how other libraries handles the KeyInfo and thus not a feature request for the Sustainsys.Saml2 libraries. Closing.
Closed aberro3s closed 2 years ago
AndersAbel
commented
2 years ago If I understand this right, the issue is with how other libraries handles the KeyInfo and thus not a feature request for the Sustainsys.Saml2 libraries. Closing.
I am running a SAML configuration using 2.7 latest release, using OKTA as one of my main Idp.
This is a question about XML crypto key management assertions with fips compliance valid algorithms.
The assertion is signed with a private key held by the identity provider as well. I am implementing an override on the GetDecryptionKey .net class referencing to https://referencesource.microsoft.com/#System.Configuration/System/Configuration/FipsAwareEncryptedXml.cs , that override is manging a valid FIPS-certified AES provider for fips complience.
The trouble is, document doesn't carry any identification of the keypair used to encrypt them, it only has the RetrievalMethod and URI reference attributes referencing the encription key. The overriden GetDecryptionKey class has no way to tell it "use a particular key pair to decrypt this document". If the encriptedKey node is not in the KeyInfo from the Encripted Data node the code wont be able to resolve the private key.
There is no problem with documents encrypted with sustainsys library using the overriden GetDecryptionKey class, those end up with the X509 certificate embedded in plain text in them along with the cipher text for the session key in the KeyInfo node. The decryption method uses that certificate to identify the private key so it can decrypt the session key and then the message.
The problem is with documents encrypted on other platforms. They don't carry the X509 certificate within the KeyInfo XML node which is a child element from the EncriptedData node which is at the end where the overriden method is looking for. Looks like it is expecting to have the encriptedkey node to be always as a child in the KeyInfo node from the EncriptedData node
A solution to this is insert the encriptionNode within the EncriptedData->KeyInfo node using the correct certificate but this does not look natural or may have any saml protocol violation on it.
What are the best practices for key management for cross-platform document exchange using fips compliance algorithms and signatures, is there a way to force the encripted key to be inserted in KeyInfo in the library? It is ok to add them manually and insert the nodes where we are expecting to look for them by decryption methods? Can we extract the encriptedKey in KeyInfo node using RetrievalMethod and URI reference attributes?