Les deux peuvent créer une signature C2PA cryptographiquement valide. Seule une chaîne de certificats reconnue par le contexte de confiance actif peut soutenir la confiance publique.
Une signature valide prouve qu’une opération de signature peut être contrôlée. Elle ne rend pas automatiquement le signataire publiquement reconnu.
Le choix du certificat doit correspondre à l’étape du cycle de vie et aux attentes de confiance des personnes qui vérifieront le média.
Un credential de développement utilisé pour l’apprentissage, les démos, les prototypes et la validation interne contrôlée.
Un credential de production dont la chaîne peut être reconnue par la politique de confiance du vérificateur concerné.
Le même format de manifeste peut conduire à un résultat de confiance différent, car le credential et son chemin de certificats sont évalués séparément.
| Question | Certificat de test | Certificat de production trusted |
|---|---|---|
| Objectif | Développement, démos, formation et tests internes. | Signature de production pour un contexte de confiance cible reconnu. |
| Émission | Souvent généré localement ou émis pour un usage hors production. | Émis et géré selon les exigences de production applicables. |
| Validité de la signature | Peut produire une signature de manifeste cryptographiquement valide. | Peut produire une signature de manifeste cryptographiquement valide. |
| Reconnaissance de la chaîne | Normalement absente des sources de confiance publique. | Dépend d’un chemin valide vers une source de confiance reconnue par le vérificateur. |
| Statut habituel | Souvent Signed but untrusted lorsque tous les autres contrôles réussissent. | Peut soutenir Trusted lorsque tous les contrôles de preuve et de confiance réussissent. |
| Meilleur usage | Prouver que le workflow fonctionne sans revendiquer de confiance publique. | Exploiter un service de signature de production avec les contrôles requis. |
Choisissez selon ce que le résultat de vérification doit signifier en dehors de votre propre environnement.
Utilisez un certificat de test pour valider la création, la signature, la vérification et le reporting sans présenter le résultat comme publiquement trusted.
Utiliser la signature de testUtilisez du matériel de signature de production dont la chaîne de certificats et les contrôles opérationnels répondent aux exigences de l’écosystème de confiance cible.
Préparer la confiance de productionTraitez la confiance de production comme une transition opérationnelle, pas comme le simple remplacement d’un fichier de certificat.
Créer des manifestes et confirmer le comportement du vérificateur avec du matériel de test.
Identifier les vérificateurs et la politique de confiance qui doivent reconnaître la chaîne.
Appliquer des contrôles d’accès, la rotation, la journalisation et des procédures d’incident.
Tester les sorties signées dans le parcours réel de diffusion et de vérification.
Un vérificateur peut confirmer qu’un manifeste signé avec un certificat de test est cryptographiquement valide tout en indiquant que sa chaîne n’est pas reconnue. Cette séparation est normale et doit être visible pour les utilisateurs.
Utilisez ces réponses pour planifier les démos, pilotes et déploiements en production.
Pas nécessairement. Sa signature peut être valide tandis que sa chaîne reste non reconnue, ce qui conduit à Signed but untrusted.
Oui, avec une politique de confiance privée explicite. Précisez sa portée et ne la décrivez pas comme une confiance publique de l’écosystème.
Non. ProvSeal peut prendre en charge les workflows de signature et de vérification, mais l’émission des certificats et leur reconnaissance publique dépendent de l’écosystème de confiance applicable.
