From c78ac5bad444f9727106813d4b230342276af3f0 Mon Sep 17 00:00:00 2001 From: shreyav Date: Tue, 20 Feb 2024 12:07:11 -0800 Subject: [PATCH] lint --- umad-02-keys-and-authentication.md | 39 ++++++++++++++++-------------- 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/umad-02-keys-and-authentication.md b/umad-02-keys-and-authentication.md index fc5df6c..32dfd97 100644 --- a/umad-02-keys-and-authentication.md +++ b/umad-02-keys-and-authentication.md @@ -25,15 +25,16 @@ section. ## Public Key Exchange -TThe UMA protocol relies on X.509 certificates for public key exchange among VASPs. In order to obtain an X.509 certificate, the -VASP is required to submit a request to a trusted certificate authority (CA), which issues the certificate. The issuing CA must keep -track of certificates that are revoked, and provide this information to other parties via Certificate Revocation Lists (CRLs) -or an Online Certificate Status Protocol (OCSP) server. The URLs for accessing a CA's CRL/OCSP can be found inside the certificate, -and VASPs should ensure the validity of all of the certificates they receive to ensure compliance and security. +TThe UMA protocol relies on X.509 certificates for public key exchange among VASPs. In order to obtain an X.509 +certificate, the VASP is required to submit a request to a trusted certificate authority (CA), which issues the +certificate. The issuing CA must keep track of certificates that are revoked, and provide this information to other +parties via Certificate Revocation Lists (CRLs) or an Online Certificate Status Protocol (OCSP) server. The URLs for +accessing a CA's CRL/OCSP can be found inside the certificate, and VASPs should ensure the validity of all of the +certificates they receive to ensure compliance and security. -It is not recommended for VASPs to use self-signed certificates when communicating with other VASPs outside their organization. -They should only be used in test environments. To generate a self-signed X.509 certificate based on the key generated above, -run: +It is not recommended for VASPs to use self-signed certificates when communicating with other VASPs outside their +organization. They should only be used in test environments. To generate a self-signed X.509 certificate based on the +key generated above, run: ```bash # Generate a certificate based on the key we generated: @@ -57,21 +58,23 @@ VASPs expose their certificates to other VASPs by responding to `GET` requests a } ``` -VASPs can revoke their certificates if their keys are compromised or if they want to rotate their keys for security reasons. For this -reason, VASPs should periodically check certificates for revocation. In the event that the counter party's certificate is revoked, the VASP -can request a new set of certificates at the same endpoint and validate them. Optionally, the counter party can specify an expiration -timestamp at which the VASP is required to revalidate or refresh their certificates, outside of periodic validation. +VASPs can revoke their certificates if their keys are compromised or if they want to rotate their keys for security +reasons. For this reason, VASPs should periodically check certificates for revocation. In the event that the counter +party's certificate is revoked, the VASP can request a new set of certificates at the same endpoint and validate them. +Optionally, the counter party can specify an expiration timestamp at which the VASP is required to revalidate or +refresh their certificates, outside of periodic validation. ## Authentication Some messages in the UMA protcol must be signed by the VASP who created the message using ECDSA and the secp256k1 keys as described above. Signatures are created using a VASP's private signing key. The signature is then verified by the -receiving VASP using the sending VASP's signing public key from the `signingCertificate`. The signature is included in the message -itself, along with the sending VASP's domain if needed. The receiving VASP can then verify the signature using the public key and - ensure that the message was not tampered with. +receiving VASP using the sending VASP's signing public key from the `signingCertificate`. The signature is included in +the message itself, along with the sending VASP's domain if needed. The receiving VASP can then verify the signature +using the public key and ensure that the message was not tampered with. ## Encryption -VASPs encrypt sensitive information like payment and Travel Rule information using the receiving VASP's encryption public key from -the `encryptionCertificate` via [ECIES](https://cryptobook.nakov.com/asymmetric-key-ciphers/ecies-public-key-encryption). The receiving -VASP can then decrypt the data using their private encryption key only when required for compliance reasons. +VASPs encrypt sensitive information like payment and Travel Rule information using the receiving VASP's encryption +public key from the `encryptionCertificate` via +[ECIES](https://cryptobook.nakov.com/asymmetric-key-ciphers/ecies-public-key-encryption). The receiving VASP can then +decrypt the data using their private encryption key only when required for compliance reasons.