Alla voce DANE , la catena della fiducia digitale va (approssimativamente):
- [ Visibilità pubblica della cerimonia per la generazione del]
- Chiave zona radice ICANN , che
- qualcosa che riguarda le autorità e i registrar di TLD, che culmina nella convalida
- DS Record che elenca i domini autorizzati
- KSK , [che potrebbe certificare altro,
- KSK intermedi , che certificano / i sono autorizzati
- ZSK s, che vengono utilizzati per produrre
- RRSIG s su
- Record TLSA contenenti l'impronta digitale di
- Chiave TLS che il server (certifica • chiavi temporanee con; che quindi utilizza per crittografare le comunicazioni.
Ora, normalmente, (pre-DANE), se il server DNS principale viene dirottato, questo non è (ancora) un "game over" non qualificato, per quanto riguarda SSL: poiché c'è ancora il problema (assumendo HSTS) di ottenere un certificato corrispondente al dominio (e dato OCSP, CAA, ecc., questo è per fortuna almeno leggermente non banale.)
Tuttavia, per un browser o un altro client che implementa effettivamente DANE per l'autenticazione positiva (ovvero, in assenza di una sequenza di certificati x509 con ancoraggio dell'autorità attendibile), ciò non significa che qualsiasi accesso a pubblicare nuovi record DNS distrugge istantaneamente non solo l'accesso, ma l'autenticità di tutti i server interessati?
Quindi quello che sto chiedendo è se esiste un modo per definire gli ZSK che NON hanno l'autorità per generare RRSIG per i record TLSA .
Vorrei conservare tutto ciò che è in grado di certificare direttamente i nuovi certificati TLS (chiavi di firma TLSA, chiavi private delle CA intermedie, ecc.) sotto conservazione frigorifera e effettuare tutte le emissioni / rinnovi in un modo offline / airgapped; mentre molto probabilmente dovrò commissionare aggiornamenti più frequenti su A / AAAA / SRV / TXT / altri record.
O sono bloccato a dover proteggere una semplice infrastruttura di aggiornamento DDNS come se tutto il dominio HTTPS dei miei domini direttamente e immediatamente dipendesse da questo?