Class ClientAssertionSignature
- Namespace
- MailFathom.Common.ClientAssertions
- Assembly
- MailFathom.Common.dll
Which algorithm a client signs an assertion with, given the key it holds.
public static class ClientAssertionSignature- Inheritance
-
ClientAssertionSignature
- Inherited Members
Remarks
The client chooses nothing here. An RSA key signs with RS256 and an elliptic-curve key signs with the
algorithm defined over its own curve, so the algorithm follows from the key pair the operator generated rather than
from a setting either side could get wrong. Every value this produces is inside the asymmetric allow-list the
endpoint already applies to a signed credential, which is what makes minting and verifying one decision instead of
two.
A curve is recognized by its object identifier and never by the size of its field. RFC 7518 section 3.4 defines
ES256, ES384, and ES512 over the three NIST curves and over nothing else, while
secp256k1 and the Brainpool curves are the same sizes — so admitting a key by its length would trust a curve
the allow-list was written to exclude and then label its signatures with an algorithm name that does not describe
them.
Only the algorithms a client needs to produce are here. The endpoint verifies a wider set, because what it accepts is a policy about signatures rather than a description of this command.
Fields
- RsaAlgorithmName
The algorithm an RSA key signs with.
Methods
- AlgorithmFor(AsymmetricAlgorithm)
Names the algorithm one key signs with.
- IsOverAPermittedCurve(ECDsa)
Reports whether a permitted algorithm is defined over the curve a key was generated on.
- Sign(AsymmetricAlgorithm, ReadOnlySpan<byte>)
Signs the assertion's signing input with the key that mints it.