Signé non trusted est l'un des résultats C2PA les plus mal compris. Cela ne signifie pas que le fichier est faux. Cela signifie généralement que la cryptographie a réussi mais que la politique de confiance ne l'a pas. Les équipes sécurité et éditoriales voient ce statut quotidiennement lors des pilotes — déclenchant souvent des escalades inutiles tant que la conception de confiance n'est pas documentée.
Cet article parcourt validation de signature versus évaluation de confiance, le rôle des chaînes X.509, et les étapes pratiques pour résoudre ou accepter correctement les résultats untrusted en production.
Signature valide versus signataire trusted
La validation de signature confirme que les octets du manifeste correspondent à la signature intégrée et que le certificat de signature était valide au moment de la signature. L’évaluation de confiance pose une question supplémentaire : cette chaîne de certificats se termine-t-elle sur une source reconnue par votre organisation ?
Voyez la validation comme « ce manifeste a-t-il été altéré depuis la signature ? » et la confiance comme « acceptons-nous ce signataire pour publication ? ». Un certificat de dev auto-signé peut passer le premier test et échouer au second — par conception.
ProvSeal sépare ces couches pour que les reviewers puissent distinguer les signatures cassées des écarts de politique.