9. Formats d'encodage des Claims
9. Formats d'encodage des Claims
La figure 8 illustre une relation à laquelle on souhaite ajouter l'attestation à distance :
.-------------. .------------. Évaluer la
| +-------------->| | requête par
| Attester | Accéder à | Relying | rapport à la
| | une ressource| Party | politique de
'-------------' '------------' sécurité
Figure 8 : Accès typique aux ressources
Dans ce diagramme, le protocole entre l'Attester et une Relying Party peut être n'importe quel protocole nouveau ou existant (par exemple, HTTP(S), CoAP(S), Resource-Oriented Lightweight Information Exchange (ROLIE) [RFC8322], 802.1x, OPC UA [OPCUA], etc.) selon le cas d'usage.
En général, ces protocoles disposent déjà de mécanismes pour transmettre des informations de sécurité à des fins d'authentification et d'autorisation. Les formats courants incluent les JSON Web Tokens (JWTs) [RFC7519], les CWTs [RFC8392] et les certificats X.509.
L'ajout de l'attestation à distance aux protocoles déjà déployés nécessite d'ajouter des messages conceptuels RATS aux flux de données existants. Cela doit être fait d'une manière qui ne dégrade pas les propriétés de sécurité des systèmes impliqués et devrait utiliser les mécanismes d'extension fournis par le protocole sous-jacent. Par exemple, si une négociation TLS doit être étendue avec des capacités d'attestation à distance, l'Evidence d'attestation peut être intégrée dans une extension de certificat X.509 ad hoc (par exemple, [TCG-DICE]) ou dans un nouveau type de certificat TLS (par exemple, [TLS-CWT]).
En particulier pour les nœuds contraints, il existe un désir de minimiser la quantité de code d'analyse nécessaire dans une Relying Party afin de minimiser à la fois l'empreinte et la surface d'attaque. Bien qu'il soit possible d'intégrer un CWT dans un JWT, ou un JWT dans une extension X.509, etc., il existe un désir d'encoder les informations dans un format déjà pris en charge par la Relying Party.
Cela motive le fait d'avoir un « modèle d'information » commun qui décrit l'ensemble des informations liées à l'attestation à distance de manière agnostique en termes d'encodage et permet plusieurs formats d'encodage (CWT, JWT, X.509, etc.) qui encodent les mêmes informations dans le format Claims requis par la Relying Party.
La figure 9 illustre que l'Evidence et les Attestation Results peuvent être exprimés via plusieurs formats d'encodage potentiels afin qu'ils puissent être transmis par divers protocoles existants. Elle motive également pourquoi le Verifier peut également être responsable d'accepter l'Evidence qui encode des Claims dans un format tout en émettant des Attestation Results qui encodent des Claims dans un format différent.
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 |
'--------------' `-------------------'
Figure 9 : Plusieurs Attesters et Relying Parties avec différents
formats