RDX Specification

JSON Web Encryption (JWE)

The implementation of JWE with RDX facilitates the secure transmission of API requests from VCAS to the issuer/partner, protecting sensitive and non-sensitive data provided through the challenge process.

Suggest Edits

JSON Web Encryption

JSON Web Encryption (JWE) is an open message encryption format which can be used as a method of securely passing the RDX message during transaction processing.

VCAS encrypts the RDX payload message and formats it according to the JWE specification. The encrypted RDX payload message is then sent to the issuer’s server where the issuer processes the JWE and decrypts the message for further processing. Note that the client RDX response will not be encrypted. The specifics regarding JWE implementation are covered in RFC-7516.

Supported JWE Formats

Currently VCAS only supports certain JWE algorithms for both key management and content encryption.
The key management algorithm is used for key exchange between Cardinal and the issuer and for wrapping the content encryption key during message encryption for JWE.

Key Management AlgorithmJWE Algorithm (alg) Value
RSAES OAEP using SHA-256 and MGF1RSA-OAEP-256

The content encryption algorithm is used for ephemeral key generation and content encryption of the RDX payload/message.

Content Encryption AlgorithmJWE Algorithm (enc) Value
AES GCM using 256-bit keyA256GCM

Issuer Key Exchange

The issuer will generate a key-pair based on the key management algorithm chosen above, using openssl, key tool or a similar tool. The public key/certificate will be encoded with several pieces of information as shown below. The key/certificate will then be exported as a certificate and sent to Cardinal’s key management team to be imported into the VCAS system. Cardinal follows NIST recommendations for key-wrapping of two years.

Shown below is an example of the certificate that the issuer sends to VCAS:

-----BEGIN CERTIFICATE-----
MIIJojCCB4qgAwIBAgITFQACoT1f6hJJ+g1QuwAAAAKhPTANBgkqhkiG9w0BAQsF
ADBoMRMwEQYKCZImiZPyLGQBGRYDY29tMRMwEQYKCZImiZPyLGQBGRYDY
GAYKCZImiZPyLGQBGRYKZ2xvYmFsdGVzdDEgMB4GA1UEAxMXQU5aIEdsb2Jh
c3QgQ0EgMDEgdjMwHhcNMjIxMDE5MDMzMDIxWhcNMjMxMDE5MDMzMDIxW
mvpuGfZHkPbUC/91IQLe/Kerp/IBgz6TuOriTuKn8xJwpypwH0iqK6cBlm9WWgW
vizZa0LnAoCz2xYeUc9ebH+0Fl2+4ZEc3pWEJxc8UdEA6ZmtxhInY56gANpxyRp9
ByDr2JzzcweEEBmq6ShFjZyb5njUYixjYPDspL2QRh5D/6D1Ybmbk0nBGhdYAjxe
sis+rCjA3yotZSjsm39QZMxYulHayIHK7f4hQrZcqwEf3OioDwqqCfo89+NIunD0lpk
pKmCCxCqEZZVrr55XXP6JqXk/XCIo/YcwrteLaryqUSWPxaSrFWceLw6mSA9kRC
/xdmYkkehzc7R2rFIXlI1pQwpwIDAQABo4ID5jCCA+IwRAYJKoZIhvcNAQkPBDcwl
NTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoG
SIb3DQMHMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUHAwEwCgYIKwYBBQ
cDySVyZ3hZLIX3SAt2asO+meYp0McT5tSEC95Oksgm6/sdwErFbiiRnt2ytlgO8Nko
T9HwMWWJOqn6/dJfwrdBfiawwPdznkEP10olExj9ggX814fnVN6nwm2d2YzieMXp
-----END CERTIFICATE-----

Key Exchange Process

Implementation: During onboarding, issuers are required to generate and exchange a new key-pair using their own internal conventions. Unique key-pairs must be generated for both Staging (UAT) and Production environments.

The key-pair generated must only be used for the JWE integration and for no other purposes.

  1. Issuer generates key-pair in their system using their conventions (not defined by Cardinal)
  2. One key-pair for each environment – STAG (UAT) & PROD
  3. Key rotation frequency
    a. NIST – Two-year recommendation
  4. Issuer generates a certificate
    a. Key generation
    • RSA encryption - RSA 2048, 3072 or 4096
    • 4096 is the preferred format
    b. These parameters on the certificate need to be completed with the appropriate information:
    • “key usage”, “o”, “ou”
    • o = organization
    • ou = organization unit
    • contact email in certificate for easy tracking when expiring
    • specify a two-year expiration date
    c. Certificate must be X.509 type using one of the following extensions:
    • .pem
    • .cer
    • .crt
    • .p7b
  5. Issuer or CA does not need to sign this certificate
  6. Issuer provides email and contact information for their key team / renewal
  7. Issuer exports and sends only the public key to Cardinal
  8. Issuer sends email with public certificate/key to:
    [email protected]
  9. Issuer sends follow-up email with the SHA256 checksum value of the certificate for validation of authenticity.

During the implementation process, issuers should work with their implementation team for certificate creation. Following creation of the certificate, the issuer should export and send only the public key to CardinalCommerce. The public key should be emailed to: [email protected]

Rotation: Cardinal follows NIST recommendations on key rotation frequency requiring key-wrapping rotation every two years. For key rotation, Issuers are required to perform key generation process and send the new public certificate to VCAS. The VCAS certification team will send the issuer a renewal notification 60 days prior to key expiration. If VCAS does not receive a response, VCAS will engage the GCS support team to provide an alternate issuer contact.

JWE Certificate Expiration and Renewal

Clients using JWE are responsible for notifying the VCAS team at least 60 days before the certification expiration date. The key generation for renewed certificates should be handled by the client. Contact information is shown below.

These are the expected values VCAS requires for certificate creation:

  • Common Name

  • Key ID (kid)
  • Alias Name
  • Serial Number

Email Template

To: [email protected]; [email protected]
Subject: JWE Certificate
Body:
Reason/Entity: RDX-JWE
Certificate Owning Entity: Issuer’s Name (include ID – PKE – etc.)
Environment: Specify Target Environment: STAG or PROD

Updated 6 months ago