1. Prezentare generală

1.1 Arhitectura sistemului

EVO Wallet Verifier este o aplicație PHP server-side care implementează protocolul OpenID for Verifiable Presentations (OID4VP) 1.0 în modul cross-device cu response_mode=direct_post.jwt. Comunicația cu portofelul EVO are loc exclusiv prin HTTP/HTTPS, fără canal Bluetooth sau NFC.

Sistemul interacționează cu următoarele entități externe:

1.2 Endpoint-uri HTTP

Toate rutele sunt relative la BASE_URL din configurație (ex: https://server.example.com/evo).

2. Generarea codului QR

Fiecare ghișeu afișează un cod QR static - nu se schimbă la fiecare tranzacție. QR-ul codifică un URI de engagement conform OID4VP 1.0, care instruiește portofelul EVO să contacteze server-ul verificatorului pentru a obține cererea de prezentare.

2.1 Formatul URI de engagement

eudi-openid4vp://?client_id=x509_hash:<base64url_SHA256_DER>
                 &request_uri=https://server.example.com/evo/wallet/teller/ghiseu-1/request
                 &request_uri_method=post

Schema URI (eudi-openid4vp://) este configurabilă prin variabila WALLET_URI_SCHEME. QR-ul se generează cu biblioteca chillerlan/php-qrcode, ECC level M, scale 10.

2.2 Calculul client_id (x509_hash)

Formatul x509_hash identifică verificatorul prin hash-ul certificatului său X.509, conform OID4VP 1.0 § 5.3.3:

// 1. Citeste certificatul PEM al verificatorului
$pem = file_get_contents('certs/verifier.pem');

// 2. Normalizeaza prin re-export OpenSSL
openssl_x509_export(openssl_x509_read($pem), $normalized);

// 3. Extrage bytes DER (strip PEM headers, base64 decode)
$der = base64_decode(preg_replace('/-----.+-----|\s/', '', $normalized));

// 4. SHA-256 peste DER bytes
$hash = hash('sha256', $der, true);  // 32 bytes raw

// 5. Base64url encode (fara padding)
$b64 = rtrim(strtr(base64_encode($hash), '+/', '-_'), '=');

// Rezultat: "x509_hash:abCdEf12..."
$clientId = 'x509_hash:' . $b64;

3. Authorization Request (JAR)

După scanarea QR-ului, portofelul EVO inițiază protocolul OID4VP prin trimiterea unei cereri POST către request_uri. Server-ul răspunde cu un JWT Authorization Request semnat (JWS), conform RFC 9101 (JWT-Secured Authorization Request).

3.1 Inițierea cererii de către wallet

Request body (application/x-www-form-urlencoded):

Server-side processing:

1. Validează că tellerId există în configurația teller-elor
2. Creează tranzacție nouă: $id = bin2hex(random_bytes(16)) - 32 caractere hex
3. Generează nonce tranzacție: $nonce = bin2hex(random_bytes(16))
4. Generează cheie efemeră ECDH-ES (P-256) + UUID kid
5. Construiește payload JWT (secțiunea 3.2)
6. Semnează cu ES256 folosind cheia privată a verificatorului
7. Salvează tranzacția cu status request_sent

Response body: JWS compact serialization (header.payload.signature)

3.2 Structura payload-ului JWT

{
  "response_uri":    "{BASE_URL}/wallet/response/{transactionId}",
  "aud":             "https://wallet.staging.egov.md",
  "wallet_nonce":    "{wallet_nonce din POST}",
  "response_type":   "vp_token",
  "state":           "{transactionId}",
  "nonce":           "{transaction_nonce, 32 hex}",
  "iat":             1708430400,
  "client_id":       "x509_hash:...",
  "response_mode":   "direct_post.jwt",
  "dcql_query":      { /* vezi sectiunea 3.5 */ },
  "client_metadata": {
    "jwks": {
      "keys": [{
        "kty": "EC",  "crv": "P-256",
        "x": "...",    "y": "...",
        "kid": "{uuid4}",
        "use": "enc",  "alg": "ECDH-ES"
      }]
    },
    "vp_formats_supported": {
      "mso_mdoc": {
        "issuerauth_alg_values": [-7, -35, -36],
        "deviceauth_alg_values": [-7, -35, -36]
      }
    },
    "encrypted_response_enc_values_supported": ["A256GCM"]
  }
}

3.3 Generarea cheii efemere ECDH-ES

// Genereaza pereche EC P-256
$key = openssl_pkey_new([
    'curve_name'      => 'prime256v1',
    'private_key_type' => OPENSSL_KEYTYPE_EC,
]);

// Extrage coordonate x, y, d (base64url encoded)
$details = openssl_pkey_get_details($key);
$public  = ['kty'=>'EC', 'crv'=>'P-256', 'x'=>$x, 'y'=>$y];
$private = ['kty'=>'EC', 'crv'=>'P-256', 'x'=>$x, 'y'=>$y, 'd'=>$d];

// kid = UUID v4 (16 random bytes, variant/version bits set per RFC 4122)
$kid = generateUuid4();

Cheia privată (d) este salvată în sesiunea tranzacției și folosită la decriptarea JWE. După decriptare, cheia nu mai este necesară. Fiecare tranzacție folosește o cheie unică.

3.4 Semnarea JWS (ES256)

JWS protected header:

{
  "alg": "ES256",
  "typ": "oauth-authz-req+jwt",
  "x5c": [
    "MIIBxTCCAW...certificat_leaf_base64...",
    "MIICATCCAa...certificat_CA_base64..."
  ]
}

Semnarea se face cu cheia privată EC din certs/verifier.key prin biblioteca web-token/jwt-signature. Wallet-ul verifică semnătura folosind certificatul din x5c și validează că hash-ul său corespunde cu client_id.

3.5 Interogarea DCQL

Cererea de prezentare folosește formatul DCQL (Digital Credentials Query Language):

{
  "credentials": [{
    "id":     "pid_query",
    "format": "mso_mdoc",
    "meta":   { "doctype_value": "md.gov.wallet.pid.1" }
  }]
}

Interogarea solicită o credențială de tip md.gov.wallet.pid.1 (PID moldovenesc) în format mso_mdoc (ISO 18013-5). Wallet-ul returnează toate elementele disponibile din namespace-ul md.gov.wallet.

Elementele așteptate (20 câmpuri):

4. Wallet Response

După ce utilizatorul confirmă prezentarea pe dispozitiv, wallet-ul criptează răspunsul folosind cheia efemeră din cerere și îl trimite ca JWE compact la response_uri.

4.1 Recepția răspunsului criptat

Request body (application/x-www-form-urlencoded):

Dacă wallet-ul raportează eroare, trimite error + error_description în loc de response. Server-ul setează tranzacția pe status=failed.

4.2 Decriptarea JWE

JWE compact serialization: header.encrypted_key.iv.ciphertext.tag

Validarea headerului JWE:

Decriptarea folosește biblioteca web-token/jwt-encryption cu algoritm de cheie ECDHES, criptare conținut A256GCM, și compresie Deflate. Cheia destinatar este cheia privată efemeră din sesiunea tranzacției.

Payload decriptat (JSON):

{
  "vp_token": "<base64url DeviceResponse CBOR>",
  "state":    "{transactionId}"
}

vp_token poate fi un string (singur DeviceResponse) sau un obiect {"pid_query": "<base64url>"} (indexat pe query ID din DCQL).

4.3 Parsarea DeviceResponse (CBOR)

vp_token este base64url-decoded în bytes CBOR, apoi parsat cu spomky-labs/cbor-php v2. Structura conform ISO 18013-5:

DeviceResponse = {
  "version":   "1.0",                          // obligatoriu
  "status":    0,                               // 0 = OK
  "documents": [Document, ...],
  "documentErrors": [...]                      // optional, trebuie absent
}

Document = {
  "docType": "md.gov.wallet.pid.1",
  "issuerSigned": {
    "nameSpaces": {
      "md.gov.wallet": [                     // array de IssuerSignedItemBytes
        #6.24(bstr .cbor IssuerSignedItem),
        ...
      ]
    },
    "issuerAuth": COSE_Sign1                 // [protected, unprotected, payload, sig]
  },
  "deviceSigned": {
    "nameSpaces": #6.24(bstr .cbor {}),     // de obicei gol
    "deviceAuth": {
      "deviceSignature": COSE_Sign1            // [protected, {}, null, signature]
    }
  }
}

IssuerSignedItem = {
  "digestID":           int,                // index in MSO valueDigests
  "random":             bstr,               // random salt (16+ bytes)
  "elementIdentifier":  tstr,               // ex: "family_name"
  "elementValue":       any                 // valoarea efectiva
}

5. Verificări criptografice

După parsarea DeviceResponse, server-ul execută 7 verificări criptografice independente. Fiecare verificare produce un rezultat pass / fail / warning care este inclus în evidence.

5.A Semnătura emitentului (Issuer Signature)

issuerAuth este un COSE_Sign1 (RFC 9052) care semnează Mobile Security Object (MSO). Structura:

COSE_Sign1 = [
  protected:   bstr,       // CBOR-encoded header {1: alg, 33: x5chain}
  unprotected: {},          // de obicei gol
  payload:     bstr,       // MSO encoded CBOR (Tag 24 wrapped)
  signature:   bstr        // ECDSA r||s concatenation
]

Extracția certificatului emitentului

Protected header, label 33 (x5chain): conține certificatul X.509 DER al emitentului. Poate fi un singur bstr (leaf) sau un array [leaf, intermediate, ...].

Construcția Sig_structure

Sig_structure = [
  "Signature1",      // CBOR text string (major type 3, 0x6a prefix)
  protectedBytes,    // CBOR byte string (raw protected header bytes)
  b"",               // external_aad = empty byte string (0x40)
  msoPayload         // CBOR byte string (MSO bytes)
]

Verificarea semnăturii ECDSA

Semnătura COSE este în format IEEE P1363 (r||s concatenat). Se convertește în DER (ASN.1 SEQUENCE { INTEGER r, INTEGER s }) pentru OpenSSL:

// r si s se extrag din semnatura (32/48/66 bytes fiecare)
$r = substr($signature, 0, $keySize);
$s = substr($signature, $keySize, $keySize);

// Conversie la DER: strip leading zeros, prepend 0x00 daca high bit set
// DER: 0x30 <len> 0x02 <len_r> <r> 0x02 <len_s> <s>

openssl_verify($sigStructureBytes, $derSignature, $issuerPublicKey, $algo);

5.B Validarea MSO (Mobile Security Object)

Payload-ul COSE_Sign1 conține MSO-ul, structură CBOR definită în ISO 18013-5 §9.1.2:

MSO = {
  "version":        "1.0",
  "digestAlgorithm": "SHA-256",
  "valueDigests":   {
    "md.gov.wallet": {
      0: bstr,    // SHA-256 hash al IssuerSignedItem cu digestID=0
      1: bstr,    // SHA-256 hash al IssuerSignedItem cu digestID=1
      ...
    }
  },
  "deviceKeyInfo":  {
    "deviceKey": COSE_Key,    // cheia publica a dispozitivului
    "keyAuthorizations": { ... },
    "statusList": {           // optional (ISO 18013-7)
      "uri": "https://...",
      "idx": 42
    }
  },
  "validityInfo":   {
    "signed":    tdate,     // momentul semnarii
    "validFrom": tdate,     // inceputul validitatii
    "validUntil": tdate     // sfarsitul validitatii
  },
  "status":         {          // optional (EUDI ARF)
    "status_list": { "uri": "...", "idx": 42 }
  }
}

Verificări:

1. version = "1.0"
2. docType corespunde cu cel așteptat (md.gov.wallet.pid.1)
3. validFrom ≤ now ≤ validUntil
4. digestAlgorithm este suportat (SHA-256 / SHA-384 / SHA-512)

5.C Validarea lanțului de certificate

Certificatul emitentului (din x5chain, label 33) este validat conform ISO 18013-5 §9.5:

Certificatele root de încredere sunt preinstalate în directorul certs/trusted-issuers/. Fiecare fișier PEM poate conține unul sau mai multe certificate (bundle).

5.D Integritatea elementelor (Digest Verification)

Fiecare IssuerSignedItem are un digestID corespunzător în MSO.valueDigests. Verificarea:

// Pentru fiecare IssuerSignedItem din nameSpaces["md.gov.wallet"]:

// 1. Obtine bytes-ii CBOR originali ai item-ului (Tag 24 wrapped)
$itemBytes = getOriginalCborBytes(item);

// 2. Calculeaza hash
$computed = hash('sha256', $itemBytes, true);

// 3. Compara cu valoarea din MSO
$expected = $mso['valueDigests']['md.gov.wallet'][item['digestID']];

assert($computed === $expected);  // byte-exact match

Această verificare demonstrează că fiecare element de date (nume, dată naștere, etc.) corespunde exact cu ceea ce a semnat emitentul. Modificarea oricărui octet invalidează hash-ul.

5.E Semnătura dispozitivului (Device Signature)

Semnătura dispozitivului dovedește că prezentarea a fost generată de telefonul pe care sunt stocate credențialele, nu de un atacator care a interceptat datele. Este un COSE_Sign1 detached - payload-ul este null, datele semnate se reconstruiesc din context.

Construcția SessionTranscript (OID4VP 1.0)

// Pas 1: OpenID4VPHandoverInfo
HandoverInfo = [
  clientId,        // tstr: "x509_hash:..."
  nonce,           // tstr: nonce-ul tranzactiei
  jwkThumbprint,   // bstr (32 bytes SHA-256) sau null
  responseUri      // tstr: "{BASE_URL}/wallet/response/{id}"
]

// Pas 2: Hash peste CBOR-encoded HandoverInfo
infoHash = SHA-256(CBOR(HandoverInfo))   // 32 bytes raw

// Pas 3: OpenID4VPHandover
Handover = [
  "OpenID4VPHandover",   // CBOR text string
  infoHash               // CBOR byte string (32 bytes)
]

// Pas 4: SessionTranscript
SessionTranscript = [null, null, Handover]

// Pas 5: DeviceAuthentication
DeviceAuthentication = [
  "DeviceAuthentication",   // CBOR text string
  SessionTranscript,
  docType,                  // tstr: "md.gov.wallet.pid.1"
  DeviceNameSpacesBytes     // Tag 24 wrapped
]

// Pas 6: Wrap in Tag 24
DeviceAuthenticationBytes = #6.24(bstr .cbor DeviceAuthentication)
// = 0xD8 0x18 <bstr-encoded CBOR(DeviceAuthentication)>

Calculul JWK Thumbprint (RFC 7638)

// Membrii EC in ordine lexicografica (RFC 7638 §3.2)
$input = json_encode([
  "crv" => $jwk['crv'],   // "P-256"
  "kty" => $jwk['kty'],   // "EC"
  "x"   => $jwk['x'],     // base64url X coordinate
  "y"   => $jwk['y']      // base64url Y coordinate
]);
$thumbprint = hash('sha256', $input, true);  // 32 bytes raw

Sig_structure pentru Device Signature

Sig_structure = [
  "Signature1",                // CBOR text string (0x6a prefix)
  protectedHeader,              // CBOR byte string
  b"",                          // external_aad (0x40)
  DeviceAuthenticationBytes    // CBOR byte string (Tag 24 encoded)
]

Conversia COSE_Key în cheie publică OpenSSL

// COSE_Key labels:
//   1 = kty (2 = EC2)
//  -1 = crv (1 = P-256, 2 = P-384, 3 = P-521)
//  -2 = x coordinate (bstr)
//  -3 = y coordinate (bstr)

// Uncompressed EC point:
$point = "\x04" . $x . $y;

// SubjectPublicKeyInfo DER:
// SEQUENCE {
//   SEQUENCE { OID ecPublicKey (1.2.840.10045.2.1), OID curve }
//   BIT STRING { 0x00 || point }
// }
//
// OID P-256: 06 08 2A 86 48 CE 3D 03 01 07
// OID P-384: 06 05 2B 81 04 00 22
// OID P-521: 06 05 2B 81 04 00 23

Verificarea se face cu openssl_verify() pe Sig_structure encoded CBOR.

5.F Starea de revocare - Status List (RFC 9596)

MSO-ul conține o referință la status list: un URI și un index (poziția în bitstring). Referința se caută în două locații posibile:

Auto-detecția formatului

Status list-ul descărcat poate fi în format JWT (text, puncte separatoare) sau CWT (binar, COSE_Sign1 tag 0xD2 sau array CBOR cu 4 elemente 0x84).

Parsare JWT

1. Split pe ., decode base64url header și payload
2. Verificare semnătură: certificat din x5c header, sau brute-force pe certificatele trusted
3. Extragere status_list din payload: {"bits": N, "lst": "<base64url zlib>"}
4. Extragere exp claim pentru cache TTL

Parsare CWT (COSE_Sign1)

1. Decode CBOR: Tag(18) [protected, unprotected, payload, signature]
2. Protected header: label 1 = algorithm, label 33 = x5chain
3. Verificare semnătură COSE_Sign1 (aceeași Sig_structure ca la issuer)
4. Payload = CBOR map: claim key 65533 = status_list
5. Status list: {"bits": int, "lst": bstr} - lst = raw zlib bytes

Decompresie și extracție status

// Decompresie bitstring (3 strategii fallback)
$raw = base64url_decode($lst);
$bits = gzuncompress($raw)     // zlib
     ?: gzinflate($raw)        // raw DEFLATE
     ?: gzdecode($raw);        // gzip

// Extragere valoare la pozitia idx
$byteIndex = ($idx * $bitsPerEntry) / 8;
$bitPos    = ($idx * $bitsPerEntry) % 8;
$mask      = (1 << $bitsPerEntry) - 1;
$status    = (ord($bits[$byteIndex]) >> $bitPos) & $mask;

5.G Revocarea certificatelor (OCSP / CRL)

Pe lângă verificarea revocării credențialelor (Status List), se verifică și starea certificatelor X.509 din lanțul emitentului.

OCSP (Online Certificate Status Protocol) - preferat

1. Se extrage OCSP URL din extensia authorityInfoAccess a certificatului leaf
2. Se generează cerere OCSP: openssl ocsp -issuer <ca> -cert <leaf> -reqout <file> -no_nonce
3. Se trimite prin HTTP POST: curl -X POST -H "Content-Type: application/ocsp-request" --data-binary @<req> <url>
4. Se parsează răspunsul: openssl ocsp -respin <resp>
5. Rezultat: ": good" = valid, ": revoked" = revocat

Certificatul issuer pentru OCSP: din x5chain[1], sau matching din certs/trusted-issuers/ după DN.

CRL (Certificate Revocation List) - fallback

1. Se extrage CRL URL din extensia crlDistributionPoints
2. Se descărcă CRL-ul (cu cache): curl -o <file> <url>
3. Se detectează formatul: PEM sau DER
4. Se parsează: openssl crl -inform <PEM|DER> -text -noout
5. Se caută numărul serial al certificatului leaf în lista de seriale revocate

Toate cererile HTTP folosesc curl cu suport opțional de proxy (HTTP_PROXY, HTTP_PROXY_AUTH din .env). Rezultatele sunt cache-uite cu TTL configurabil (REVOCATION_CACHE_TTL, implicit 3600s).

6. Generarea evidence-ului

După toate verificările criptografice, sistemul generează un evidence - un fișier JSON auto-verificabil care constituie proba de audit. Evidence-ul este protejat prin trei straturi: hash de integritate, marcă temporală TSA, și semnătură digitală JWS.

6.1 Structura JSON

{
  "evidence_version":     "2.0",
  "regulation":           "Regulament intern ...",
  "transaction_id":       "a1b2c3d4e5f6...",
  "verification_timestamp": "2026-02-20T14:30:00+02:00",
  "verifier": {
    "name":     "Numele Institutiei",
    "system":   "EVO Wallet Verifier v2.0",
    "base_url": "https://..."
  },
  "presenter": {
    "ip_address":   "...",
    "user_agent":   "...",
    "protocol":     "OpenID4VP 1.0 (cross-device)",
    "response_mode": "direct_post.jwt"
  },
  "encryption": {
    "algorithm":         "ECDH-ES",
    "encryption":         "A256GCM",
    "ephemeral_key_kid": "{uuid4}"
  },
  "oid4vp_session": {
    "client_id":      "x509_hash:...",
    "response_uri":   "...",
    "nonce":          "...",
    "jwk_thumbprint": "..."
  },
  "documents": [{
    "docType":     "md.gov.wallet.pid.1",
    "query_id":    "pid_query",
    "elements":    { "family_name": "...", ... },
    "elements_by_namespace": { "md.gov.wallet": { ... } },
    "cryptographic_verification": {
      /* rezultatele fiecarei verificari A-G */
    },
    "cryptographic_evidence": {
      /* certificate DER base64, MSO raw, etc. */
    }
  }],
  "vp_token_sha256": "...",
  "cryptographic_evidence": {
    "vp_token_raw": { "pid_query": ["<base64url CBOR>"] },
    "verification_instructions": { /* 42 pasi */ }
  },

  // Straturile de protectie (adaugate in ordine)
  "tsa_token":      "<base64 DER TimeStampResp>",
  "integrity_hash": "sha256:a1b2c3d4...",
  "jws_header":     "<base64url JWS header>",
  "jws_signature":  "<base64url JWS signature>"
}

6.2 Hash-ul de integritate (SHA-256)

// 1. Construieste JSON-ul evidence FARA campurile de protectie
$json = json_encode($evidence, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);

// 2. Calculeaza SHA-256
$hash = hash('sha256', $json);  // hex string

// 3. Apoi adauga tsa_token (daca disponibil)
// 4. Adauga integrity_hash
$evidence['integrity_hash'] = 'sha256:' . $hash;

6.3 Marca temporală (RFC 3161)

Dacă TSA_URL este configurat, se solicită o marcă temporală de la un Time Stamping Authority:

// 1. Genereaza cerere TSA
openssl ts -query -digest $sha256Hex -sha256 -cert -no_nonce -out $reqFile

// 2. Trimite cererea
curl -s -S --max-time 15 \
     -H "Content-Type: application/timestamp-query" \
     --data-binary @$reqFile \
     -o $respFile $tsaUrl

// 3. Verifica raspunsul
openssl ts -reply -in $respFile -text
// Trebuie sa contina "Granted"

// 4. Salveaza DER bytes ca base64 in evidence
$evidence['tsa_token'] = base64_encode(file_get_contents($respFile));

Marca temporală demonstrează că hash-ul exista la un moment precis în timp, independent de ceasul instituției. La re-verificare, se validează lanțul TSA până la certificatele din certs/trusted-tsa/.

6.4 Semnătura JWS a verificatorului

// JWS protected header
{
  "alg": "ES256",
  "typ": "evidence+jwt",
  "x5c": ["<verifier cert base64>", ...]
}

// Payload = JSON complet CU tsa_token si integrity_hash
// FARA jws_header si jws_signature

// Se semneaza cu cheia privata a verificatorului (ES256)
$jws = sign($header, $payload);  // header.payload.signature

// Se embeds header si signature inapoi in JSON
$evidence['jws_header']    = explode('.', $jws)[0];
$evidence['jws_signature'] = explode('.', $jws)[2];

Output fișiere:

7. Re-verificarea evidence-ului

Endpoint-ul POST /verify acceptă un evidence JSON sau JWS și re-execută integral 10 verificări independente (A–J):

8. Ciclul de viață al tranzacției

Fiecare prezentare creează o tranzacție în data/sessions/{id}.json. ID-ul este bin2hex(random_bytes(16)) = 32 caractere hex alfanumerice.

Sesiunile sunt fișiere JSON individuale (LOCK_EX la scriere). ID-ul este validat contra regex /^[a-f0-9]{32}$/ pentru prevenirea path traversal.

9. Standarde și referințe

10. Instalare și configurare

Această secțiune acoperă deploy-ul efectiv al pachetului de distribuție: structura fișierelor, cerințele de sistem, dependențele, și pașii de instalare.

10.1 Structura pachetului de distribuție

Pachetul se livrează ca arhivă evo-wallet-verifier.tar.gz (~85 KB). După dezarhivare, structura este:

10.2 Cerințe de sistem

Nu sunt necesare servicii suplimentare (Redis, Memcached, bază de date, message queue).

10.3 Dependențe PHP

Instalate automat prin composer install:

10.4 Instalare pas cu pas

# 1. Dezarhivare
tar xzf evo-wallet-verifier.tar.gz
cd evo-wallet-verifier

# 2. Instalare dependente PHP
composer install

# 3. Configurare
cp .env.example .env
nano .env   # completeaza cu datele institutiei (vezi 10.5)

# 4. Generare cheie privata + CSR (Certificate Signing Request)
openssl ecparam -name prime256v1 -genkey -noout -out certs/verifier.key
openssl req -new -key certs/verifier.key -out certs/verifier.csr \
    -subj "/CN=EVO Verifier/O=Numele Institutiei/C=MD"

# 5. Expediere CSR catre AGE
#    Transmiteti fisierul certs/verifier.csr catre AGE.
#    AGE va returna:
#      - certificatul semnat (verifier.pem)
#      - lantul CA (root + intermediate)

# 6. Plasare certificate primite de la AGE
#    certs/verifier.pem     — certificatul verificatorului (primit de la AGE)
#    certs/trusted-issuers/ — root/intermediate CA AGE (primite de la AGE)
#    certs/trusted-tsa/     — root CA pentru TSA (optional)

# 7. Configurare Apache
#    DocumentRoot → public/
#    Asigura AllowOverride All pe directorul public/

# 8. Setare permisiuni
chmod 750 data/sessions data/evidence
chmod 640 .env certs/verifier.key

# 9. Verificare — acceseaza BASE_URL in browser

10.5 Configurare .env

Toate variabilele disponibile:

10.6 Personalizare white-label

Pachetul este neutru - nu conține identitatea niciunei instituții. Personalizarea se face exclusiv prin .env, fără modificarea codului sursă:

Actualizări viitoare: se înlocuiește pachetul (src/, public/, templates/), se păstrează .env, certs/, și data/. Codul sursă este identic pentru toate instituțiile.

Anexă: Fluxul complet al protocolului

Rezumatul tuturor request-urilor HTTP între componentele sistemului: