Izpeljava arhitekture

Povzetek. Ta stran izpelje arhitekturo WKL TrustBridge iz zahtev. Poteka v štirih korakih: zahteve z izvorom, iz njih izpeljani varnostni cilji, iz teh izhajajoča načela zasnove in nazadnje posamezne arhitekturne odločitve s preučenimi alternativami in njihovimi posledicami. Kjer ima odločitev z vidika revizorja slabost, je to izrecno navedeno skupaj z izravnavo.

graph TD
  R[Predpisi<br/>in scenariji] --> A[Zahteve<br/>A-01 do A-24]
  A --> Z[Varnostni cilji<br/>Z-1 do Z-9]
  Z --> G[Načela zasnove<br/>G-1 do G-11]
  G --> E[Odločitve<br/>E-01 do E-21]
  E --> K[Komponente in poteki]
  E --> N[Dokazi]
  classDef s fill:#deecf9,stroke:#0078d4,color:#201f1e
  class R,A,Z,G,E,K,N s

Pojmi

Pojem	Pomen
Zahteva (A-nn)	Obveznost iz pravnega predpisa, tehničnega priporočila ali scenarija, z izvorom
Varnostni cilj (Z-n)	Lastnost TrustBridge, ki izpolni eno ali več zahtev
Načelo zasnove (G-n)	Pravilo, ki velja za vse odločitve in izhaja iz ciljev
Odločitev (E-nn)	Posamezna arhitekturna določitev s preučenimi alternativami in posledicami
Pokritost	Povezava vsakega varnostnega cilja z odločitvami, ki ga nosijo

Zahteve

Izvor: R = pravni predpis, T = tehnično priporočilo ali standard, S = scenarij ali varnostna potreba dobavne verige. Predpisi so pojasnjeni na strani Temelji in zahteve.

ID	Zahteva	Izvor
A-01	Sistem se sme pojaviti samo pod identiteto svojega partnerja; partner ne sme imeti možnosti ustvariti identitete drugega	S; NIS2 člen 21(2)(d)
A-02	Vsaka izdaja mora temeljiti na dokazljivi pooblastitvi	S; ETSI EN 319 411-1; NIS2 člen 21(2)(i)
A-03	Ključi CA morajo biti zaščiteni pred branjem in zlorabo, tudi pred skrbniki sistema	TR-02102; IT-Grundschutz CON.1; ETSI EN 319 411-1
A-04	Stanje preklica mora biti za preverjevalce zanesljivo in dosegljivo tudi ob motnjah	RFC 5280; zahteva naročnikov KRITIS; NIS2 člen 21(2)©
A-05	Preklic mora biti mogoč tudi ob izpadu osrednjih komponent	NIS2 člen 21(2)(b), ©
A-06	Kriptografski postopki morajo ustrezati stanju tehnike	BSIG § 30; TR-02102
A-07	TrustBridge mora omogočiti prehod na postkvantne postopke, ne da bi izključil klasične preverjevalce	načrt EU za PQC; TR-02102 (hibridno)
A-08	Dolgo veljavna sidra zaupanja morajo biti kvantno odporna pred iztekom rokov načrta PQ	načrt EU za PQC
A-09	Podatki različnih naročnikov morajo biti ločeni drug od drugega	GDPR člen 32; C5:2026; S
A-10	Dostop do upravljanja zahteva močno avtentikacijo	NIS2 člen 21(2)(j); ISO/IEC 27001 A.8.5
A-11	Varnostno pomembni dogodki se morajo beležiti tako, da se posegi razkrijejo	IT-Grundschutz OPS.1.1.5; ISO/IEC 27001 A.8.15; ETSI EN 319 401
A-12	Pomembne incidente, zlasti kompromitacijo ključev CA, je treba zaznati in obravnavati	BSIG § 32; NIS2 člen 21(2)(b)
A-13	Partnerski sistemi se morajo povezati prek standardnih protokolov	S; RFC 8555, RFC 7030
A-14	Običajni odjemalci HTTPS ne smejo potrebovati lastniške komponente	S
A-15	TrustBridge ne sme ustvarjati ali hraniti zasebnih ključev vlagateljev	S; najmanjši obseg podatkov
A-16	Osebne podatke v certifikatih in dnevnikih je treba omejiti na najmanjšo mero	GDPR člen 5
A-17	Programska oprema mora nastajati sledljivo; odvisnosti morajo imeti preverjen izvor	NIS2 člen 21(2)(e); CRA
A-18	Obnova po izpadu ne sme izgubiti izdaj ali jih izvesti dvakrat	S; IT-Grundschutz CON.3
A-19	Korenska CA hierarhije ne sme biti dosegljiva z nobenim spletnim napadom	ETSI EN 319 411-1; S
A-20	Upravljanje in avtomatizacija morata iti skozi ista pravila	S
A-21	Zaupanje med organizacijami mora biti dogovorjeno dvostransko, določeno za vsako smer, neprenosljivo prek tretjih, vsaka stran pa ga mora lahko sama preklicati	S; NIS2 člen 21(2)(d)
A-22	Povezave med partnerji morajo biti zaščitene pred snemanjem in poznejšim dešifriranjem, tudi če je eden od uporabljenih postopkov zlomljen	načrt EU za PQC; TR-02102-2; S
A-23	Veljavna identiteta ne sme utemeljevati pooblastila; vsako operacijo posebej pooblasti ciljna aplikacija	NIST SP 800-207; S
A-24	Upravljanje, ki ga izvaja tretji, ne sme vključevati pravic do odobritve ali razpolaganja z zasebnimi ključi; menjava upravljavca mora biti mogoča brez predaje zasebnih ključev	NIS2 člen 21(2)(d); C5:2026; S

Varnostni cilji

Cilj	Opredelitev	Zahteve
Z-1 Pristnost	Veljaven certifikat nastane samo iz pooblaščenega naročila v imenskem prostoru upravičenega partnerja	A-01, A-02, A-15, A-24
Z-2 Zaščita ključev	Noben ključ CA ni dosegljiv zunaj HSM; vsaka uporaba je sledljiva	A-03, A-12, A-19
Z-3 Razpoložljivost stanja	Veljaven, aktualen seznam preklicanih certifikatov je dosegljiv določen čas tudi ob izpadu podatkovne baze, upravljanja ali delavca CA	A-04, A-05
Z-4 Dokazljivost	Vsako izdajo in vsak preklic je mogoče dokazati tretjim, tudi proti skrbniku podatkovne baze	A-02, A-11
Z-5 Ločitev najemnikov	Noben naročnik ne vidi podatkov ali identitet drugega in nanje ne vpliva	A-09, A-16
Z-6 Pripravljenost na prihodnost	Prehod na postkvantne postopke je načrtovan in mogoč brez preloma za klasične preverjevalce	A-06, A-07, A-08, A-14
Z-7 Operativna varnost	Izpadi ne povzročijo ne dvojne izdaje ne izgube; ponovni zagon je preizkušen	A-18, A-05
Z-8 Meja razmerja	Organizacija pri drugi doseže samo to, kar je ta dovolila v svoji smeri razmerja, in samo do preklica; ciljna aplikacija pooblasti vsako operacijo	A-21, A-23
Z-9 Zaščita povezav	Promet med partnerji ostane zaupen, dokler ni zlomljena dodatna skrivnost agentov ključev ali hibridni dogovor o ključu	A-22, A-06

Načela zasnove

Načelo	Vsebina	Utemeljitev
G-1 Majhna zaupanja vredna osnova	V zaupanja vredno osnovo spadajo samo komponente, brez katerih nepooblaščena izdaja ni mogoča	Vsako komponento v zaupanja vredni osnovi je treba varovati in preverjati z največjim trudom; manj ko jih je, bolj verodostojna je osnova
G-2 Podatkovna baza je vhod, ne avtoriteta	Kar storitev prebere iz podatkovne baze, je nepreverjen vhod	Podatkovne baze upravlja, varnostno kopira, obnavlja in seli veliko ljudi; njihova vsebina ni dovolj zaupanja vredna za odločitve o izdaji
G-3 Pooblastitev je kriptografska	Odobritev je podpis, ki ga podpisnik preveri	Oznako v tabeli lahko nastavi vsak, ki sme pisati
G-4 Podpisovanje brez vhoda	Podpisna storitev nima dohodne povezave in si delo pridobi sama	Napadalec je ne doseže neposredno, temveč samo prek naročil, ki jih sama preveri
G-5 Stanje pred funkcijo	Podatki o stanju so zasnovani robustneje kot izdaja	Manjkajoča izdaja zamuja, manjkajoč preklic škoduje
G-6 Identiteta iz verige	Varnostno pomembna identiteta izhaja iz certifikatne verige in omejitev imen, nikoli iz opisnih polj	Preverjevalci opisna polja vrednotijo neenotno; preverjanje poti po RFC 5280 je standardizirano
G-7 Navzven standardi	Zunanji vmesniki nespremenjeno sledijo standardom; lastni vmesniki samo, kjer standarda ni	Interoperabilnost, preverljivost, brez odvisnosti od lastnih odjemalcev
G-8 Brez tihega umika	Vsak umik na šibkejši postopek je zavestna, zabeležena odločitev	Tihi umik na klasične postopke postkvantno zaščito razvrednoti, ne da bi kdo opazil
G-9 Zaupanje je dvostransko	Vsaka organizacija sama odloči, komu zaupa in za kaj; priznanje učinkuje samo v razmerju, v katerem je bilo dano	Zaupanje, ki se nadaljuje po verigah, uide nadzoru tistih, ki ga nosijo
G-10 Identiteta ni pooblastilo	TrustBridge zagotovi preverjeno identiteto; pravice dodeli ciljna aplikacija	Certifikat pove, kdo govori, ne pa, kaj je dovoljeno
G-11 Skrivnosti ostanejo na končni točki	Sejne skrivnosti nastanejo in se končajo na obeh udeleženih strežnikih; nobena osrednja storitev jih ne pozna	Storitev z vsemi skrivnostmi bi bila najvrednejša tarča napada

Odločitve

Vsaka odločitev navaja preučene alternative in posledice. „Ocena“ beleži, kje ima odločitev z vidika revizorja slabosti.

E-01 Podpisovanje v lastnem delavcu CA brez dohodne povezave

Odločitev. Podpisuje samo delavec CA. Nikoli ne teče v istem procesu ali pod istim računom operacijskega sistema kot storitev z vhodom HTTP in nima dohodne omrežne povezave. Bere naročila, jih preveri glede na lokalni pravilnik in podpiše v HSM.

Alternativa	Zakaj ne
Podpisovanje v spletni storitvi, ki sprejme zahtevek	Vsaka ranljivost spletne storitve postane zmožnost izdaje
Podpisna storitev z dohodnim vmesnikom (npr. REST)	Napadljiva površina neposredno ob zaupanja vredni osnovi; avtentikacija klicatelja bi sama postala varnostno kritična
Vključitev gotove programske opreme CA	Njen pravilnik ni pravilnik TrustBridge; jamstva bi bila odvisna od tuje konfiguracije

Posledice. Izdaja je asinhrona: zahtevek ustvari naročilo, certifikat nastane pozneje. Vmesniki nikoli ne smejo čakati na podpis. Izpolnjuje: Z-1, Z-2 (G-1, G-4).

E-02 Podatkovna baza zunaj zaupanja vredne osnove; lokalni pravilnik in register

Odločitev. Kaj se sme izdati, določa lokalni pravilnik delavca CA (datoteka na njegovem gostitelju): dovoljene CA za vsak razred profila, odobritelji z javnimi ključi, veljavnosti, dovoljene razširitve. Kaj je bilo izdano in preklicano, je v njegovem lokalnem registru, v katerega se samo dodaja. Podatkovna baza vsebuje naročila in projekcije.

Alternativa	Zakaj ne
Podatkovna baza kot avtoriteta s podpisanimi zapisi	Problem samo premakne: kdo podpiše zapise in kdo preveri?
Pravila v podatkovni bazi, delavec jim zaupa	Skrbnik podatkovne baze bi se lahko sam postavil za odobritelja

Posledice. Spremembe pravilnika so operativni postopek na gostitelju delavca CA, ne klik v upravljanju. Register je treba varnostno kopirati in ga po obnovi uskladiti s podatkovno bazo. Ocena: Register postane edini vir resnice o izdaji in preklicu; njegova izguba bi bila huda. Zato sta predvidena varnostno kopiranje z RPO blizu nič in zunanje sidro glave verige (gl. E-14). Izpolnjuje: Z-1, Z-4 (G-2).

E-03 Odobritev kot podpis osebe

Odločitev. Ročno naročilo se odobri tako, da oseba, vpisana v pravilnik, zgoščeno vrednost naročila podpiše s svojim osebnim ključem. Privzeto je to oseba, ki ni vlagatelj; varnostno pomembni razredi profilov zahtevajo dve različni osebi. Samodejni razredi profilov namesto tega zahtevajo potrditev (atestacijo) storitve za vpis z njenim storitvenim ključem.

Alternativa	Zakaj ne
Odobritev kot sprememba stanja v podatkovni bazi	odobril bi lahko vsak s pravico pisanja
Odobritev po prijavi v upravljanje	upravljanje bi postalo del zaupanja vredne osnove

Ocena. Pravilo „vlagatelj ni odobritelj“ pri eni sami odobritvi sloni na podatku, ki ga delavec CA ne more preveriti: kdor nadzoruje upravljanje ali podatkovno bazo in je hkrati odobritelj, lahko vloži zahtevek pod tujim imenom in ga sam odobri. Ločitev nalog je kriptografsko trdna šele z dvema podpisoma odobriteljev. Pri samodejnih razredih spada storitev za vpis s svojim storitvenim ključem v zaupanja vredno osnovo – zato so ti razredi omejeni na kratke veljavnosti in imenski prostor partnerja. Izpolnjuje: Z-1, Z-4 (G-3).

E-04 Nespremenljivo naročilo za izdajo

Odločitev. Naročilo je v celoti razrešen posnetek vseh varnostno pomembnih vsebin prihodnjega certifikata, enkrat ustvarjen kot UTF-8 JSON, nato pa bajt za bajtom shranjen, prenesen in podpisan. Njegov identifikator je SHA-256 teh bajtov. Serijsko številko ustvari delavec CA (vsaj 64 bitov naključja).

Alternativa	Zakaj ne
Naročilo se sklicuje na profil, delavec CA izpelje	med odobritvijo in izdajo bi se profil lahko spremenil; odobreno ne bi bilo to, kar se izda
Ponovna serializacija na vsaki postaji	različni serializatorji dajo različne bajte in s tem različne zgoščene vrednosti

Posledice. Kar oseba odobri, je bit za bitom to, kar se izda. Upravljalna aplikacija mora naročilo prikazati iz natanko podpisanih bajtov. Izpolnjuje: Z-1.

E-05 Partner = izdajateljska CA z omejitvijo imen

Odločitev. Vsak partner ima vsaj eno lastno izdajateljsko CA, katere certifikat z nameConstraints (kritično) določa njegov imenski prostor DNS. Sistem je v njem natanko en dNSName. Subject, CN, O in lastni OID niso nikoli varnostno pomembni; druge vrste SAN je mogoče izdati samo, če jih certifikat CA prav tako omejuje.

Alternativa	Zakaj ne
Partner v polju `O` ali v lastni razširitvi	Preverjevalci to vrednotijo neenotno; ni standardiziranega mehanizma uveljavljanja
Ena skupna CA za vse partnerje	Vsaka napačna izdaja zadene vse; v verigi ni ločitve

Posledice. Zadnja obrambna črta je pri preverjevalcu: uveljaviti mora nameConstraints. Iz tega izhaja pogodba preverjevalca. Ocena: Ne uveljavlja vsaka knjižnica TLS omejitev imen v celoti; pogodba preverjevalca mora biti del partnerskih pogodb in preverljiva s testnimi certifikati. Izpolnjuje: Z-1, Z-5 (G-6).

E-06 Vnaprej ustvarjeni seznami preklicanih certifikatov namesto OCSP

Odločitev. Stanje se objavlja prek seznamov preklicanih certifikatov (CRL), ki jih delavec CA ustvari vnaprej: veljavnost 72 ur, nov seznam vsakih 6 ur in takoj po vsakem preklicu; številka CRL strogo narašča iz registra. Delta seznami in OCSP se ne ponujajo.

Alternativa	Zakaj ne
OCSP s podpisom na poti zahteve	Podpisni ključ na najbolj izpostavljenem mestu; v nasprotju z G-4
OCSP z vnaprej ustvarjenimi odgovori	dodaten delegiran ključ za vsako CA brez koristi v primerjavi s seznamom, ki ga adapter TLS tako ali tako prenaša v ritmu
Kratke veljavnosti brez preklica	za sisteme z veljavnostjo več mesecev ne zadošča

Posledice. Med preklicem in tem, ko preverjevalec zanj izve, mine do šest ur (ritem prenosa). Rezerva 66 ur (veljavnost minus ritem) je čas, ki ga ima operativa za obnovo izpadlega delavca CA. Izpolnjuje: Z-3 (G-4, G-5).

E-07 Dve poti objave; distribucija preverja podpise

Odločitev. Seznami preklicanih certifikatov dosežejo distribucijo prek podatkovne baze in po drugi poti mimo nje. Distribucija nima ključa, preveri vsak podpis in streže najvišjo veljavno številko CRL. Preklic je mogoč tudi na konzoli gostitelja delavca CA.

Alternativa: samo pot prek podatkovne baze – zavrnjeno, ker bi izpad podatkovne baze najpozneje po 72 urah povzročil neuspeh vsakega preverjanja in nihče ne bi mogel preklicati. Izpolnjuje: Z-3 (G-5).

E-08 Hibridnost kot alternativni podpis v istem certifikatu

Odločitev. Hibridni certifikat nosi klasični ključ subjekta in ključ ML-DSA (subjectAltPublicKeyInfo, 2.5.29.72); CA podpiše z ML-DSA v altSignatureValue (2.5.29.74) in nato klasično prek celotnega podpisanega dela. Razširitve niso kritične.

Alternativa	Ocena
Vzporedni verigi (en klasični certifikat in en certifikat PQ za vsak sistem)	dvojno upravljanje, preverjevalci morajo povezati dve verigi
Sestavljeni podpisi po osnutku IETF	neločljiva vezava obeh podpisov; klasični preverjevalci pa algoritma ne poznajo in zavrnejo
Samo ML-DSA	izključi klasične preverjevalce; v nasprotju s hibridnim priporočilom BSI

Ocena. Alternativni podpis je ločljiv: kdor bo v prihodnje znal ponarediti klasični podpis, lahko ustvari certifikat brez razširitev PQ. Zaščita zato obstaja samo, če preverjevalec alternativni podpis zahteva in manjkajoč člen šteje za neveljaven (točka 9 pogodbe preverjevalca, brez tihega umika po G-8). Izpolnjuje: Z-6.

E-09 Ključi CA samo v HSM, tudi ML-DSA

Odločitev. Ključi CA nastanejo v HSM in tam ostanejo, neizvozljivi, tako klasični kot ML-DSA. Programskega ključa za CA ni, niti prehodno. Modul brez neizvozljivega ML-DSA ni dovoljen. Delavec CA ob zagonu preveri prstni odtis in neizvozljivost; en ključ pripada natanko eni CA.

Alternativa: ML-DSA začasno v programski opremi – zavrnjeno, ker ključ, ki je bil enkrat izvozljiv, naknadno ne postane zaupanja vreden. Izpolnjuje: Z-2.

E-10 Korenska CA brez povezave s ceremonijo

Odločitev. Korenska CA je trajno brez povezave. Izdajateljske CA podpisuje samo na ceremoniji s poimenovanimi vlogami. Kar podpiše, nikoli ne prihaja iz spletnega sistema: ključ in imenski prostor se potrdita po drugem kanalu; prek meje gredo samo izčrpno našteti artefakti. Izpolnjuje: Z-2 (A-19).

E-11 Kriptografska osnova

Odločitev. V certifikatni agenciji postkvantni postopki prihajajo iz skupnega gradnika .NET na osnovi OpenSSL (od 3.5); klasični postopki (RSA, ECDSA, AES, zgoščevalne funkcije, ASN.1, tipi X.509) ostanejo pri kriptografiji ogrodja .NET. Komponente na končnih točkah so samostojni programi v strojni kodi s knjižnico TLS, ki podpira RFC 9973.

Alternativa	Ocena
Tipi PQ iz .NET 10	bi stare aplikacije prisilili v ponovno pisanje; skupni gradnik ponuja enake podpise kot kriptografija ogrodja in obstoječe aplikacije postopoma usposobi za PQ
Vse prek OpenSSL, tudi klasično	brez varnostne koristi: v sistemu Linux .NET klasično tako ali tako računa prek OpenSSL, v sistemu Windows prek CNG
Ista osnova tudi za komponente na končnih točkah	kriptografija certifikatne agencije ne ponuja zunanjih PSK po RFC 9973; izvajalno okolje na vsakem partnerskem strežniku bi pomenilo dodatno delo z namestitvijo in vzdrževanjem

Izpolnjuje: Z-6, A-06.

E-12 Upravljanje kot aplikacija Access brez povezave s podatkovno bazo

Odločitev. Zaposleni v organizaciji in pri njenem operativnem partnerju upravljajo sistem z aplikacijo Access, ki prek HTTPS kliče izključno upravljalni API: seznami kot množice OData v4 prek gonilnika ODBC, ki uporablja samo HTTP, ukazi prek razreda VBA. Povezava odjemalca s podatkovno bazo je izključena.

Alternativa	Zakaj ne
Access z neposredno povezavo s podatkovno bazo	Pooblastila in preverjanje bi bila v odjemalcu; obhod revizije
Spletni vmesnik kot upravljanje	dve upravljanji podvojita delo s preverjanjem. Partnerji s partnersko CA uporabljajo partnerski portal, ki isti API uporablja z obsegom vidnosti za vsakega partnerja

Izpolnjuje: Z-5, A-10, A-20.

E-13 Skupni strokovni API in protokolni adapterji

Odločitev. Partnerski sistemi uporabljajo standardne protokole (ACME, EST), katerih adapterji protokol izvedejo v celoti, strokovne odločitve pa prepustijo skupnemu jedru. Upravljanje in avtomatizacija uporabljata isti strokovni API (OData v4 z akcijami) in iste pravice.

Izpolnjuje: A-13, A-20 (G-7).

E-14 Tri ravni beleženja z zunanjim sidrom

Odločitev. Operativni dnevnik (brez dokazne vrednosti), varnostni revizijski dnevnik v podatkovni bazi (veriženo za vsakega najemnika, sproti kopirano navzven) in register delavca CA in korenske CA, ki razkrije vsak poseg. Glave verig gredo periodično v shrambo, v katero se samo dodaja, zunaj podatkovne baze in gostitelja delavca CA.

Alternativa: podpisane glave verig z lastnim ključem – zavrnjeno, ker zunanja shramba, v katero se samo dodaja, doseže isto brez dodatnega ključa. Izpolnjuje: Z-4.

E-15 Ločitev najemnikov v dveh linijah

Odločitev. Strokovni tuji ključi nosijo najemnika; poleg tega pri branju filtrira varnost na ravni vrstic (Row-Level Security). Osebe dobijo poimenovane obsege vidnosti (vsi najemniki, skupina, en najemnik), da je mogoče preslikati tako podporo z zabeleženim vpogledom kot notranji model pooblastil dobavne verige. Izpolnjuje: Z-5.

E-16 Meja izdelka

Odločitev. WKL TrustBridge obsega certifikatno agencijo vsake organizacije, dvostranska razmerja zaupanja, agente ključev z lokalnim posrednikom ključev, adapter TLS in povezavo s ciljnimi aplikacijami, kot je Database Gateway. Ne spadajo vanj pooblastila v ciljnih aplikacijah, identitete delovnih obremenitev po SPIFFE in storitve prijave za osebe.

Utemeljitev. Certifikatna agencija sama zagotovi identitete, ne pa sodelovanja: med organizacijami je potrebno razmerje, uveljavljanje na povezavi in zaščita prometa. Varnostna pravila certifikatne agencije pri tem ostanejo nespremenjena: ne ustvarja ključev za druge in ne pozna nobene sejne skrivnosti (G-11). Identitete SPIFFE so imena URI, ki jih model identitet (natanko eno ime DNS za vsak sistem) ne predvideva. Izpolnjuje: Z-8, Z-9.

E-17 Dvostranska federacija prek podpisanih svežnjev zaupanja

Odločitev. Organizacije sidra zaupanja nasprotne strani priznajo za vsako razmerje posebej. Odobreno razmerje doseže adapterje TLS in agente ključev kot sveženj zaupanja, ki ga podpiše delavec CA organizacije, z naraščajočo številko in omejeno veljavnostjo.

Alternativa	Zakaj ne
Skupna korenska CA vseh udeležencev	upravljavec korenske CA nadzoruje vse; izstop je odvisen od njega
Navzkrižni certifikati med korenskimi CA	zaupanje se nadaljuje po verigah; A zaupa C, takoj ko B izda navzkrižni certifikat za C
Mostna CA	kot navzkrižni certifikati, poleg tega osrednje mesto
Seznam zaupanja vrednih sider v podatkovni bazi	kdor obvladuje podatkovno bazo, vtihotapi sidra

Posledice. Vsaka organizacija sama vzdržuje svoja razmerja; novi partnerji potrebujejo dogovor z vsako organizacijo, s katero sodelujejo. Izpolnjuje: Z-8 (G-2, G-9).

E-18 Dodatna skrivnost kot zunanji PSK po RFC 9973

Odločitev. Agenta ključev se prek ML-KEM, overjeno s certifikati agentov ML-DSA, dogovorita za skrivnost za vsako razmerje in vsak par strežnikov. Adapter TLS jo z razširitvijo tls_cert_with_extern_psk (RFC 9973) vnese v rokovanje TLS 1.3 kot zunanji PSK, v načinu psk_dhe_ke s hibridno skupino in vzajemno avtentikacijo s certifikati.

Alternativa	Zakaj ne
Samo hibridna skupina v TLS	en sam protokol, ena sama izvedba, brez povezave z razmerjem; ostane del rešitve, a ne sam
Lasten šifriran tunel ob TLS	druga transportna pot z lastno konfiguracijo in lastnimi omrežnimi pravili; obstoječe aplikacije TLS ne pridobijo ničesar
IPsec s postkvantnimi vnaprej deljenimi ključi (RFC 9867)	zaščita na omrežni ravni brez povezave z identiteto storitve; zahteva spremembe omrežja pri obeh organizacijah
Lastna sprememba protokola TLS	ni interoperabilna in je ni mogoče preveriti glede na standard

Ocena. RFC 9973 PSK-ja izrecno ne šteje za avtentikacijo. Avtentikacija ostane pri hibridnih certifikatih (E-08); dodatna skrivnost okrepi zaupnost in poveže povezavo z razmerjem. Izpolnjuje: Z-9 (G-8, G-11).

E-19 Lokalni posrednik ključev

Odločitev. Skrivnost pride od agenta ključev prek posrednika ključev na istem strežniku do adapterja TLS. Strežnika nikoli ne zapusti in se ne zapiše na nosilec podatkov.

Alternativa: osrednja storitev ključev, ki skrivnosti razdeljuje končnim točkam – zavrnjeno, ker bi poznala vse povezave in bi zaupanja vredno osnovo razširila s spletno tarčo največje vrednosti. Izpolnjuje: Z-9 (G-1, G-11).

E-20 Obnova z menjavo povezave

Odločitev. TLS 1.3 novo zunanjo skrivnost sprejme samo ob vzpostavitvi povezave. Adapter TLS zato povezave po najdaljši življenjski dobi razmerja nadomesti z novimi z aktualno skrivnostjo, preden se stara konča. Nadaljevanje seje je za povezave razmerij izklopljeno.

Alternativa	Zakaj ne
`KeyUpdate` v obstoječi povezavi	izpelje samo iz dosedanje prometne skrivnosti, ne prinese svežega materiala
Obnova deležev ključa znotraj povezave po osnutku IETF Extended Key Update	ni standard; zunanjega PSK ne sprejme
Neomejeno dolge povezave	ena skrivnost bi tedaj ščitila poljubno veliko prometa poljubno dolgo

Izpolnjuje: Z-9.

E-21 Upravljanje brez posesti ključev

Odločitev. V modelu Managed namestitev organizacije upravlja operativni partner. Odobritelji in skrbniki so izključno osebe iz organizacije; ključi CA so v HSM ali particiji, ki je dodeljena samo tej organizaciji. Menjava upravljavca poteka prek nove generacije CA, ne z izvozom ključev.

Alternativa: operativni partner kot odobritelj po naročilu – zavrnjeno, ker bi tedaj lahko izdajal v imenskem prostoru organizacije, ne da bi ta sodelovala. Izpolnjuje: Z-1, Z-2.

Pokritost

Cilj	Odločitve
Z-1 Pristnost	E-01, E-02, E-03, E-04, E-05, E-21
Z-2 Zaščita ključev	E-01, E-09, E-10, E-21
Z-3 Razpoložljivost stanja	E-06, E-07
Z-4 Dokazljivost	E-02, E-03, E-14
Z-5 Ločitev najemnikov	E-05, E-12, E-15
Z-6 Pripravljenost na prihodnost	E-08, E-09, E-11
Z-7 Operativna varnost	E-02, E-07
Z-8 Meja razmerja	E-16, E-17
Z-9 Zaščita povezav	E-16, E-18, E-19, E-20

Česa ta stran ne dokazuje

Učinkovitosti. Ali odločitev doseže svoj cilj, dokaže postopek preverjanja pripadajoče zaveze na strani Varnostne zaveze.
Popolnosti zahtev. Zahteve izhajajo iz predpisov in scenarijev na strani Temelji in zahteve, ne iz vsake možne obveznosti naročnika.