Identity Certificates
Last updated
Was this helpful?
Last updated
Was this helpful?
Brayden Langley (brayden@projectbabbage.com)
Ty Everett (ty@projectbabbage.com)
Identity on the internet has come to rely almost exclusively on trusted third parties acting as gatekeepers for user authentication. Digital signatures provide part of the solution, but there is still a need to link the public key with the true identity of the signer, while still tolerating key compromises. We define an open-ended, ubiquitous and privacy-centric version of digital identity certificates that facilitate selective revelation and UTXO-based revocation. digital signatures ensure the authenticity of certified fields, while encryption facilitates an approval-based access control scheme. In this standard, we define the data structures, key derivation protocols, signing and verification procedures for identity certificates. We also discuss how responsible certificate issuers can handle key compromises.
The motivation behind this standard is to address the limitations of digital signatures for verifying the true identity of internet users, a verification process which currently relies heavily on passwords and trusted third parties.
The goal is to create an open-ended, privacy-centric, and ubiquitous solution for digital identity certificates that facilitates selective revelation and UTXO-based revocation. This standard aims to provide a decentralized and reliable method for identity verification without compromising user privacy, and could be useful in various scenarios, including e-commerce, financial transactions, and secure communication.
By providing a secure method for linking a user's public key to their true identity, the standard would enable secure and private online transactions and collaborations, while also protecting against fraudulent activities and identity theft. By recognizing that key compromises do occur and supporting certificate revocation, we allow users to recover from breaches without tying their entire digital identity to a single key.
We start by specifying the data structures needed to represent various components of identity certificates, then proceed to key derivation schemes, signing and verification procedures, the secure verifier field revelation protocol, and finally UTXO-based revocation and responsible key compromise handling procedures.
PublicKey
The PublicKey structure is a compressed, DER-encoded secp256k1 public key (only the X coordinate), formatted as a 33-byte hexadecimal string.
Example:
02e087b19a205ae13f512341d1cfc0c712d66cacad24a809fce7edb3529e78b5da
Nonce
The Nonce structure is a 256-bit number, converted to a base64 string.
Example:
L9t1aQLkWkmMw1Poi1ofIjHV6GO+BNN63v8Na8/gW4Y=
Signature
The Signature structure is a DER-encoded ECDSA signature converted into a hexadecimal string.
Example
3045022100c0686907d8914abfa7f356c560c7d17045dde5c10135b1cbf9bf6e4cc52e09820220366eec15372bc34db10f997e21755f603a2023c96578e9d71fca2570f23055d6
RevocationOutpoint
The Outpoint structure is a Bitcoin SV TXID (a hexadecimal string) and output index (a decimal integer), separated by a decimal point (“.”). When a certificate outpoint has been spent, the certificate has been revoked.
Example
48645047cd66f7b48b24efb080ec7e27f3f448c21109939b80afd11e40898c92.1
CertificateTypeID
The CertificateTypeID structure is a 256-bit number that represents the distinct type or class of certificate issued by the certifier, converted to a base64 string. All certificate types with the same unique Type ID can be expected to have the same fields, and fields can be expected to have the same meanings.
Example
8l5phhdm2Hi80s6QqFOLS0NwUzDzJhlUTWv2BezmstE=
CertificateValidationKey
The CertificateValidationKey structure is a 256-bit key converted to a base64 string. The key is used by verifiers to check the signature on the certificate.
Example
G4pBfpBEZ7n5iEHrtG5MFOnIO0U1D758naHJilcK/RU=/7lzk4XTKI=+BNN63v8Na8/gW4Y=
CertificateSerialNumber
The CertificateSerialNumber structure is a 128-bit number that represents the unique identifier of the certificate, converted to a base64 string. No two certificates should have the same serial number, especially certificates from the same certifier or of the same type.
Example
kUahacBHmYL2nkzemkatFg==
CertificateFieldValue
The CertificateFieldValue structure is a piece of certified information that is encrypted with one of the CertificateFieldRevelationKeys. The 256-bit initialization vector used is prepended to the beginning of the data, and the AES-256-GCM algorithm is used. The structure is represented as a base64 string.
Example
IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp
CertificateFieldRevelationKey
The CertificateFieldRevelationKey structure is a 256-bit AES-GCM encryption key used to decrypt and reveal one of the CertificateFieldValues. It is represented as a base64 string.
Example
ZG3C7x11lIeqd5Fi9BDzeTXMEAIlh+uDOB53d03EV5s=
CertificateFields
The CertificateFields structure is an object whose keys are certificate field names, and whose values are CertificateFieldValue structures.
Example
The CertificateFieldRevelationKeyring structure is an object whose keys are certificate field names and whose values are encrypted versions of the corresponding CertificateFieldRevelationKeys that decrypt them.
Value
Security Level
2
Protocol ID
authrite certificate field encryption xxxxx
Key ID
yyyyy zzzzz
Counterparty
The sender uses the recipient's identity key, the recipient uses the sender's identity key.
Where:
xxxxx is the certificate type ID
yyyyy is the certificate Serial Number
zzzzz is the field name which the CertificateFieldRevelationKey decrypts
NOTE: The bearer of a certificate is not obligated to reveal the keys to all certificate fields at all times to all parties. Therefore, a Certificate structure that contains an incomplete CertificateFieldRevelationKeyring (lacking keys for certain fields) can still be considered valid. It is up to the verifier how much information they need to examine.
Example
The Certificate structure is an object with the following JSON fields:
type
A CertificateTypeID structure indicating the type of certificate.
subject
A PublicKey structure denoting the key belonging to the party being certified.
validationKey
A CertificateValidationKey structure representing the validation key of the certificate.
serialNumber
A CertificateSerialNumber structure representing the unique serial number of the certificate.
fields
A CertificateFields structure containing all of the encrypted fields that were certified by the certifier.
certifier
A PublicKey structure denoting the well-known public key of the entity issuing the certificate.
revocationOutpoint
A RevocationOutpoint structure pointing to a Bitcoin SV UTXO. If the UTXO has been spent by the certifier, the certificate should be considered revoked. If all zeroes, this functionality is disabled for the certificate. Disabling UTXO-based revocation should be in accordance with the rules defining this certificate type.
signature
A Signature structure denoting the signature made by the certifying entity over the certified fields of the subject.
keyring
A CertificateRevelationKeyring structure containing keys for some or all of the fields of the certificate. If no fields are being revealed, this is optional.
Example
Value
Security Level
2
Protocol ID
authrite certificate signature xxxxx
Key ID
yyyyy
Counterparty
The public key of the validation key included in the certificate.
Where:
xxxxx is the certificate type ID
yyyyy is the certificate Serial Number
NOTE: The validation key is part of the certificate, so anyone with this key can check the certificate signature.
The subject (the person being certified) may use this key derivation scheme to derive the field revelation keys used to encrypt the various fields of their certificate, based on their own identity private key.
Value
Security Level
2
Protocol ID
authrite certificate field xxxxx
Key ID
yyyyy zzzzz
Counterparty
self
Where:
xxxxx is the certificate type ID
yyyyy is the certificate Serial Number
zzzzz is the field name from the certificate
In order to preserve data integrity, we need a way to keep certificate fields encrypted such that only particular fields can be revealed as needed. We stipulate the use of a keyring structure for selective field revelation to verifiers. As the keyring is not included in the certificate's signature (only the encrypted field values themselves), verifiers can still check the authenticity of the certificate without access to all keyring keys.
When a prover reveals the fields to a verifier, they will follow these steps:
Retrieve the relevant symmetric field encryption keys
Construct the keyring with the field revelation keys and their associated field names according to the structure defined above.
Value
Security Level
2
Protocol ID
authrite certificate field encryption
Key ID
xxxxx yyyyy
Counterparty
self
Where:
xxxxx is the certificate Serial Number
yyyyy is the field name from the certificate
It is strictly forbidden for a verifier to store or reveal the field revelation keys or the field values themselves to anyone else without the consent of the certificate holder. Doing so would be a violation of the terms of agreement and would result in the revocation of the certificate for that verifier.
One of the problems with identity certificates of the past is that certificate authorities would have to maintain a list of any certificates that were revoked due to key compromises, violation of the terms of agreements, or other reasons. Then anyone that wanted to check if a certificate was still valid would have to check against this list, assuming it wasn't compromised, to make sure it hadn't been revoked.
A simple solution to this problem is to make use of an associated Bitcoin transaction and output created at the time the certificate is issued. As described above, this revocation outpoint structure points to a UTXO that, if ever spent, indicates that the certificate is revoked.
This allows verifiers to easily check if a certificate has been revoked, without having to rely on a trusted centralized revocation list.
If the private key corresponding to a certificate issuer's public key ever becomes compromised, it is important that the issuer generate a new key pair, revoke existing certificates, and issue new certificates to the relevant certificate holders.
If one of the certificate holders has a key compromised, there needs to be a standard way to request a new certificate.
Certifiers should establish a process for coordinating with certificate holders to manage the reissuance of certificates.
Future BRCs can define protocols by which this process can occur.
When a sender is communicating with a counterparty over a communications channel, the sender encrypts the field revelation keys by following the Encryption process (each CertificateFieldRevelationKey is encrypted with AES-256-GCM, and the 256-bit initialization vector is prepended to the ciphertext).
For each field revelation key that is included, the sender and recipient of the information use the following protocol and key IDs:
Attribute
The signature for a certificate is over all the fields, the subject, the certifier, the type, the serial number, the revocation outpoint, and the validation key. Each field is organized deterministically, in alphabetical order, in a JSON object. We stipulate the use of the (default) to avoid ambiguous ordering.
When the certificate is signed, we specify that the certifier utilizes the signing process with their certifier private key and the following attributes:
Attribute
For signature verification, we specify that the verifier checks the signature by using the certificate's validation key as the identity private key and the certifier's identity public key as the counterparty.
Attribute
Encrypt the keys for the verifier following the process for counterparty encryption.
For step 2, we stipulate the use of the following attributes when deriving the encryption keys:
Attribute
An example implementation of Identity Certificates can be seen in Authrite, and the tutorial can be followed for creating your own Authrite Certifier.
