Skip to content

Latest commit

 

History

History
281 lines (178 loc) · 17.1 KB

0052.md

File metadata and controls

281 lines (178 loc) · 17.1 KB
Raw

BRC-52: Identity Certificates

Abstract

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. BRC-3 digital signatures ensure the authenticity of certified fields, while BRC-2 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.

Motivation

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.

Specification

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.

Data Structures

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

{
  “first_name”: “IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp”,
  “last_name”: “3o0jTew8WMW54svE8Btx9Aks1FlQCHOxGKLZpc7SR0ESSIomToAYFtCq6U7NUuf3ktwLgnv5XdCrCTo+mOTHl/H+oyjcxB7xfdwav+bBx6vG5y9voDI/Z2MQGxE/Pmeg”,
  “address_line_1”: “WGqZGJo7VHeQ5tx7uqeyA5q08tRVxJLUoprjAiJ8FmzOoe4gt0+6PGDgvrhkbzauSxGY9yRyOeP+irHclCIrzjwjbfkK19thoyUhr8u1283FobikPs2xKrhUvcYhDOV7”,
  “address_line_2”: “IjI5UXJnMbcSEqIVkH8B5a9cY8EtWO7RvJH9gAWuIq0Y3koINgfqNjmockAgXnGxLvdQXvWdlCIm+foedIdHhqs9Xi60wR7hLSs9emjo6nq1Mx01wYFRW1le//Sup80x”,
  “city”: “Ed4Nr8UL3h7AqX3PlExwLQ0Mi/QLBH9wCIpdeMb442HDbQlodF1eUuJQRXt+0ajzmXEqaGNSD59xEXmsFouLDLa6sOOzXr2psCKMXkU1+IFHGv8TgJx/vDTCxMvL7t2T”,
  “state”: “6oiC8AMFFrLRGhpbWUO1HkA05/QPmfaUg1be4cP2vbcadIv4quaBgfwmNWE6xItpQNAfEwrx1ub9b4cNIKnN+6JAsiDiqs42mbjsgTuZL90fSEL9yPTwRuvW1ccvJ43z”,
  “zipcode”: “Y+iqr8cSMEMMq8WqpIudzni1DIiQT5BsK29ld8lFCZddrrjep0qQyKoaP9+46ikIu9VOQIoOJayhiW7KifUSYt+D/WODyPei4Ru7tqfgR47Vo4u0EFI3KLBXyC3DgiN+”
}

CertificateFieldRevelationKeyring

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.

When a sender is communicating with a counterparty over a communications channel, the sender encrypts the field revelation keys by following the BRC-2 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 BRC-43 protocol and key IDs:

BRC-43 Attribute 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

{
  “first_name”: “G2GmxIWNPkO2SUP0XpQvQqX31yz58aLHk9e7JxO+q/MT3k9ZjTe3t8aN2Qwg2+AtBulXZpKhuvxOgxicfd8GqCjFkGtyUrbSdmCFjPUJm7z/P/LWkJHByeBzh3/yOWa7”,
  “last_name”: “YZAHgs+P8Tgci3+5uuAuHr0k3CXPEcB3trpqtEUygV+uwoTgDWk01XTT1eOW6n7qjcDt4g7tlzuWtkawDkvRbCcVe3oBsEI5X8+A10s8TAsyNQV5O1R8mkGoL8/Hec4K”
}

Certificate

The Certificate structure is an object with the following JSON fields:

Field Description
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

{
  “type”: ”8l5phhdm2Hi80s6QqFOLS0NwUzDzJhlUTWv2BezmstE=”,
  “subject”: ”0376d67c86b45be3c36c328c2aa5c5dd79c546d22859e39439bd5d934058345abc”,
  “validationKey”: ”G4pBfpBEZ7n5iEHrtG5MFOnIO0U1D758naHJilcK/RU=/7lzk4XTKI=+BNN63v8Na8/gW4Y=”,
  “serialNumber”: ”kUahacBHmYL2nkzemkatFg==”,
  “fields”: {
    “first_name”: “IlgngMNcUM0d4GyzkSGqXaIBw6/n8bB6BG0pprO6oGhxUcivP6wDfuMWjWrG64KQJYUMN3QjHoX40r3SvAyWQaAA9ldVuPLgZwi9q2TCECKHCyEuiATCM9PdB/Ba2rxp”,
    “last_name”: “3o0jTew8WMW54svE8Btx9Aks1FlQCHOxGKLZpc7SR0ESSIomToAYFtCq6U7NUuf3ktwLgnv5XdCrCTo+mOTHl/H+oyjcxB7xfdwav+bBx6vG5y9voDI/Z2MQGxE/Pmeg”,
    “address_line_1”: “WGqZGJo7VHeQ5tx7uqeyA5q08tRVxJLUoprjAiJ8FmzOoe4gt0+6PGDgvrhkbzauSxGY9yRyOeP+irHclCIrzjwjbfkK19thoyUhr8u1283FobikPs2xKrhUvcYhDOV7”,
    “address_line_2”: “IjI5UXJnMbcSEqIVkH8B5a9cY8EtWO7RvJH9gAWuIq0Y3koINgfqNjmockAgXnGxLvdQXvWdlCIm+foedIdHhqs9Xi60wR7hLSs9emjo6nq1Mx01wYFRW1le//Sup80x”,
    “city”: “Ed4Nr8UL3h7AqX3PlExwLQ0Mi/QLBH9wCIpdeMb442HDbQlodF1eUuJQRXt+0ajzmXEqaGNSD59xEXmsFouLDLa6sOOzXr2psCKMXkU1+IFHGv8TgJx/vDTCxMvL7t2T”,
    “state”: “6oiC8AMFFrLRGhpbWUO1HkA05/QPmfaUg1be4cP2vbcadIv4quaBgfwmNWE6xItpQNAfEwrx1ub9b4cNIKnN+6JAsiDiqs42mbjsgTuZL90fSEL9yPTwRuvW1ccvJ43z”,
    “zipcode”: “Y+iqr8cSMEMMq8WqpIudzni1DIiQT5BsK29ld8lFCZddrrjep0qQyKoaP9+46ikIu9VOQIoOJayhiW7KifUSYt+D/WODyPei4Ru7tqfgR47Vo4u0EFI3KLBXyC3DgiN+”
  },
  “certifier”: ”035ce8cc44dbcf4c991d666d381d67263aed9123f9b15cca215b54f1314152d23c”,
  “revocationOutpoint”: “48645047cd66f7b48b24efb080ec7e27f3f448c21109939b80afd11e40898c92.1”,
  “signature”: “3045022100c0686907d8914abfa7f356c560c7d17045dde5c10135b1cbf9bf6e4cc52e09820220366eec15372bc34db10f997e21755f603a2023c96578e9d71fca2570f23055d6”,
  “keyring”: {
    “first_name”: “G2GmxIWNPkO2SUP0XpQvQqX31yz58aLHk9e7JxO+q/MT3k9ZjTe3t8aN2Qwg2+AtBulXZpKhuvxOgxicfd8GqCjFkGtyUrbSdmCFjPUJm7z/P/LWkJHByeBzh3/yOWa7”,
    “last_name”: “YZAHgs+P8Tgci3+5uuAuHr0k3CXPEcB3trpqtEUygV+uwoTgDWk01XTT1eOW6n7qjcDt4g7tlzuWtkawDkvRbCcVe3oBsEI5X8+A10s8TAsyNQV5O1R8mkGoL8/Hec4K”
  }
}

Signing and Verification

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) Stable Stringify Algorithm to avoid ambiguous ordering.

When the certificate is signed, we specify that the certifier utilizes the BRC-3 signing process with their certifier private key and the following BRC-43 attributes:

BRC-43 Attribute 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.

For signature verification, we specify that the verifier checks the BRC-3 signature by using the certificate's validation key as the BRC-42 identity private key and the certifier's identity public key as the counterparty.

Revelation Key Generation

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.

BRC-43 Attribute 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

Secure Verifier Field Revelation Protocol

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:

  1. Retrieve the relevant symmetric field encryption keys
  2. Encrypt the keys for the verifier following the BRC-2 process for counterparty encryption.
  3. Construct the keyring with the field revelation keys and their associated field names according to the structure defined above.

For step 2, we stipulate the use of the following BRC-43 attributes when deriving the encryption keys:

BRC-43 Attribute 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.

UTXO-based Certificate Revocation

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.

Handling Key Compromises Responsibly

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.

Implementations

An example implementation of Identity Certificates can be seen in Authrite, and the MYAC tutorial can be followed for creating your own Authrite Certifier.