IdentityServer4 Signing Key, Validation Key and .Net Core Data Protection

Question

The Identity Server 4 documentation (here http://docs.identityserver.io/en/latest/topics/crypto.html?highlight=data%20protection ) discusses signing keys and validation keys. I know that the signing key is configured using

AddSigningCredential(<X509Certificate2>)

and there are two APIs for validation keys

AddValidationKey(<X509Certificate2>)
AddValidationKeys(<Microsoft.IdentityModel.Tokens.AsymmetricSecurityKey[]>) 

The document talks about signing key rollover and adding multiple validation keys to the discovery document. Questions:

• When do you use AddValidationKey with X509Certificate2? Do you need to do this even though you are using AddSigningCredential?
• What does "you request/create new key material" refer to? Is this a new certificate? Or is this a Microsoft data protection key?
• What is an AsymmetricSecurityKey? Is there a method to create from an X509Certificate2?
• We are using cookie authentication - are the ValidationKeys the same as the keys stored PersistKeysToAzureBlobStorage in Net Core 2.0? (https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/configuration/overview?view=aspnetcore-2.1&tabs=aspnetcore2x)

Answer 1

IdentityServer uses asymmetric encryption. Asymmetric encryption means you have a public key and a private key. The public key is shared (obviously) and is used only to encrypt. The private key is, well, private. It should be strictly protected and never shared, and it's used to decrypt. The signing key is your public key, while the validation key is your private key, so yes, you need both. An X509Certicate can be used because certificates employ both public and private keys, but ultimately, IdentityServer is just using the cert to get at the keys.

The AddValidationKeys (plural) method is used explicitly for key rollover. Your cert, for example, will likely expire after one year (the default in most cases). At the end of that period, you would replace it with the new cert. However, clients may still have access tokens and such encrypted via the public key from the previous cert, and IdentityServer would need the private key from the previous cert to decrypt that. Using this method, you can add the previous keys only for the purpose of validating material IdentityServer can't validate with the current keys.

Data Protection is really totally separate. It too uses public and private keys to do what it does, so technically, you could use the same keys for IdentityServer as well. However, it's better to keep your keys restricted to unique purposes. That way, if you do get compromised, you aren't completely compromised, and can somewhat limit the scope of the potential leak.