9. Formati di codifica dei Claims
9. Formati di codifica dei Claims
La Figura 8 illustra una relazione a cui si desidera aggiungere l'attestazione remota:
.-------------. .------------. Valutare la
| +-------------->| | richiesta
| Attester | Accedere a | Relying | rispetto alla
| | una risorsa | Party | politica di
'-------------' '------------' sicurezza
Figura 8: Tipico accesso alle risorse
In questo diagramma, il protocollo tra l'Attester e una Relying Party può essere qualsiasi protocollo nuovo o esistente (ad esempio, HTTP(S), CoAP(S), Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322], 802.1x, OPC UA [OPCUA], ecc.) a seconda del caso d'uso.
In genere, tali protocolli dispongono già di meccanismi per trasmettere informazioni di sicurezza per scopi di autenticazione e autorizzazione. I formati comuni includono JSON Web Tokens (JWTs) [RFC7519], CWTs [RFC8392] e certificati X.509.
L'aggiunta dell'attestazione remota a protocolli già distribuiti richiede l'aggiunta di messaggi concettuali RATS ai flussi di dati esistenti. Questo deve essere fatto in modo da non degradare le proprietà di sicurezza dei sistemi coinvolti e dovrebbe utilizzare i meccanismi di estensione forniti dal protocollo sottostante. Ad esempio, se un handshake TLS deve essere esteso con capacità di attestazione remota, l'Evidence di attestazione può essere incorporata in un'estensione di certificato X.509 ad hoc (ad esempio, [TCG-DICE]) o in un nuovo tipo di certificato TLS (ad esempio, [TLS-CWT]).
Soprattutto per i nodi vincolati, c'è il desiderio di ridurre al minimo la quantità di codice di parsing necessario in una Relying Party al fine di minimizzare sia l'ingombro che la superficie di attacco. Sebbene sia possibile incorporare un CWT all'interno di un JWT, o un JWT all'interno di un'estensione X.509, ecc., c'è il desiderio di codificare le informazioni in un formato già supportato dalla Relying Party.
Questo motiva l'esistenza di un "modello di informazione" comune che descrive l'insieme delle informazioni relative all'attestazione remota in modo indipendente dalla codifica e consente più formati di codifica (CWT, JWT, X.509, ecc.) che codificano le stesse informazioni nel formato Claims richiesto dalla Relying Party.
La Figura 9 illustra che l'Evidence e gli Attestation Results possono essere espressi tramite più formati di codifica potenziali in modo che possano essere trasmessi da vari protocolli esistenti. Motiva anche il motivo per cui il Verifier potrebbe anche essere responsabile dell'accettazione di Evidence che codifica Claims in un formato mentre emette Attestation Results che codificano Claims in un formato diverso.
Evidence Attestation Results
.--------------. CWT CWT .-------------------.
| Attester-A +-----------. .---------->| Relying Party V |
'--------------' | | `-------------------'
v |
.--------------. JWT .---------+--. JWT .-------------------.
| Attester-B +-------->| +-------->| Relying Party W |
'--------------' | | `-------------------'
| |
.--------------. X.509 | | X.509 .-------------------.
| Attester-C +-------->| Verifier +-------->| Relying Party X |
'--------------' | | `-------------------'
| |
.--------------. TPM | | TPM .-------------------.
| Attester-D +-------->| +-------->| Relying Party Y |
'--------------' '---------+--' `-------------------'
^ |
.--------------. other | | other .-------------------.
| Attester-E +-----------' '---------->| Relying Party Z |
'--------------' `-------------------'
Figura 9: Più Attesters e Relying Parties con formati diversi