Dois-je accepter un certificat de répondeur OCSP signé par l'ancre de confiance?

Question

Quelqu'un pourrait-il m'aider sur les points suivants?
La RFC2560 définit quand un certificat de répondeur OCSP (signifiant la réponse) peut être accepté:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

Ma question est:
Si le certificat du répondeur OCSP est signé par le Trust Anchor du chemin de validation, est-il également considéré comme accepté?
J'ai l'impression que cela devrait l'être, mais cela n'est pas indiqué explicitement ci-dessus dans la RFC et je n'ai pas trouvé de référence explicite à ce sujet.

D'après ma lecture de la RFC, même si elle est signée par le TA, elle n'est toujours pas valide pour la réponse OCSP.
Toute aide est appréciée
Remarque: je travaille en java là-dessus, au cas où cela importerait

MISE À JOUR:
Dans la section 2.2 de la RFC:

Tous les messages de réponse définitifs DOIT être signé numériquement. La clé
utilisé pour signer la réponse DOIT appartenir à l'un des éléments suivants:

- l'autorité de certification qui a émis le certificat en question
- un Répondeur de confiance dont la clé publique est approuvée par le demandeur
- un Répondant Désigné par l'AC (Répondant Autorisé) qui détient un certificat spécialement marqué émis directement par l'AC, indiquant que le répondeur peut émettre des réponses OCSP pour cette CA

Le point 2 me semble ambigu.
Cela pourrait signifier:
a) Tout PK de confiance, alors Trust Anchor est acceptable
ou
b) Avoir la signification du point (1) dans la première citation, ce qui signifie préconfigurer un certificat (any) à faire confiance comme étant le répondeur OCSP comme par exemple cela se fait en java ici:

   Security.setProperty("ocsp.responderCertSubjectName",ocspCert.getSubjectDN().getName));
   List<X509Certificate> list = new ArrayList<X509Certificate>();
   list.add(ocspCert);
   CollectionCertStoreParameters p = new CollectionCertStoreParameters(list);  
   CertStore store = CertStore.getInstance("Collection", p);
   PKIXParameters params = new PKIXParameters(Collections.singleton(anchor));
   params.addCertStore(store);      

Answer 1

Dans la RFC 2560, cela signifie:

1. Matches a local configuration of OCSP signing authority for the
certificate in question; or

→ Vous pouvez faire ce que vous voulez tant que vous êtes constamment conscient de ce que vous faites. Il s'agit de la clause «fourre-tout», ce qui signifie que vous vous conformerez probablement à la RFC 2560 quoi que vous fassiez. Mais si vous êtes le producteur de réponses OCSP, vous voudrez éviter d'utiliser cette licence-to-be-standard car vous préféreriez que les utilisateurs de vos réponses les acceptent même si elles n'ont pas la même "configuration locale" que vous.

2. Is the certificate of the CA that issued the certificate in
question; or

→ Le point délicat est que l'ancre de confiance est une autorité de certification. Il n'est pas formellement représenté par un certificat (bien que dans de nombreux systèmes les ancres de confiance soient codées en tant que certificats auto-signés); mais il délivre des certificats et, en tant que tel, est une autorité de certification. Vous êtes dans ce cas si la réponse OCSP a été signée avec la clé TA.

3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
extension and is issued by the CA that issued the certificate in
question."

→ De même que ci-dessus, un répondeur OCSP signant une réponse pour le certificat X, où X semble avoir été émis par le TA, peut utiliser un certificat de répondeur R qui a également été émis par le même TA - par ceci, je signifie que X et R ont été émis par l'autorité de certification dont vous utilisez le nom et la clé comme Trust Anchor.

Ces trois cas décrivent les étapes de vérification qui doivent être effectuées par quiconque reçoit une réponse OCSP, et souhaite l'utiliser dans le cadre d'une validation de chemin de certificat. La section 2.2 de la RFC concerne les tâches du répondeur OCSP:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a specially
   marked certificate issued directly by the CA, indicating that the responder
   may issue OCSP responses for that CA

Ces trois cas correspondent à ceux du récepteur, que nous avons détaillés ci-dessus, dans l'ordre "2, 1, 3". Là encore, le "CA qui a émis le certificat" peut être l'entité dont le nom et la clé publique seront utilisés comme ancre de confiance par le receveur.