nl::Weave::Profiles::Security::CASE::WeaveCASEAuthDelegate

Appelée au début de la validation du certificat.

Les implémentations doivent initialiser l'objet WeaveCertificateSet fourni avec des ressources suffisantes pour gérer la prochaine validation du certificat. Pour le moment, les implémentations peuvent charger des certificats racine ou CA de confiance dans l'ensemble de certificats, ou attendre l'appel de OnPeerCertsLoaded().

La fonction de chargement attribue à chaque certificat chargé dans l'ensemble de certificats un type de certificat par défaut. Les implémentations doivent ajuster ces types si nécessaire pour garantir le bon traitement du certificat lors de la validation et l'attribution correcte de WeaveAuthMode pour les interactions CASE.

Le contexte de validation fourni sera initialisé avec un ensemble de critères de validation par défaut que l'implémentation pourra modifier si nécessaire. L'implémentation doit définir le champ EffectiveTime ou définir les indicateurs de validation appropriés pour supprimer la validation de la durée de vie du certificat.

Si vous souhaitez obtenir des résultats de validation détaillés, l'implémentation peut initialiser les champs CertValidationResults et CertValidationLen.

Des implémentations sont nécessaires pour conserver les ressources allouées pendant BeginValidation() jusqu'à l'appel de la méthode EndValidation() correspondante. Les implémentations sont assurées que EndValidation() sera appelé exactement une fois pour chaque appel réussi à BeginValidation().

Encodez les informations de certificat CASE pour le nœud local.

Les implémentations peuvent utiliser cet appel pour remplacer l'encodage par défaut de la structure CertificateInformation CASE pour le nœud local. Lorsqu'elle est appelée, l'implémentation doit écrire une structure CertificateInformation contenant au minimum le certificat d'entité du nœud local. L'implémentation peut éventuellement inclure un ensemble de certificats et/ou d'ancres de confiance associés.

Encodez une charge utile spécifique à l'application à inclure dans le message CASE envoyé au pair.

L'implémentation de cette méthode est facultative. L'implémentation par défaut renvoie une charge utile de longueur nulle.

Appelée à la fin de la validation du certificat.

Les intégrations peuvent utiliser cet appel pour effectuer un nettoyage une fois la certification terminée. Les implémentations sont assurées que EndValidation() sera appelé exactement une fois pour chaque appel réussi à BeginValidation().

Générez une signature à l'aide de la clé privée du nœud local.

Lorsqu'elles sont appelées, les implémentations doivent calculer une signature à partir de la valeur de hachage donnée à l'aide de la clé privée du nœud. La signature générée doit ensuite être écrite sous la forme d'une structure CASE ECDSASignature dans l'écriture TLV fournie à l'aide de la balise spécifiée.

Si la clé privée du nœud est conservée dans un tampon local, la fonction utilitaire GenerateAndEncodeWeaveECDSASignature() peut s'avérer utile pour implémenter cette méthode.

Appelée avec le résultat de la validation du certificat.

Les implémentations peuvent utiliser cet appel pour inspecter, et éventuellement modifier, le résultat de la validation du certificat de l'homologue. Si la validation aboutit, validRes sera défini sur WEAVE_NO_ERROR. Dans ce cas, le contexte de validation contiendra les détails du résultat. Plus spécifiquement, le champ "TrustAnchor" sera défini sur le certificat de l'ancre de confiance.

Si l'implémentation a initialisé les champs CertValidationResults et CertValidationLen dans la structure ValidationContext pendant l'appel de BeginValidation(), ces champs contiennent les résultats de validation détaillés de chaque certificat de l'ensemble de certificats.

Les implémentations peuvent contourner ce problème en définissant validRes sur une valeur d'erreur, ce qui entraînerait l'échec de la validation.

Si la validation échoue, validRes indique la raison de l'échec. Les implémentations peuvent remplacer le résultat par une valeur d'erreur différente, mais NE DOIVENT PAS définir le résultat sur WEAVE_NO_ERROR.

Appelée après le chargement des certificats du pair

Les implémentations peuvent utiliser cet appel pour finaliser les certificats d'entrée et les critères de validation qui seront utilisés pour effectuer la validation du certificat de l'homologue. Lors de l'appel, les certificats fournis par le pair ont été chargés dans l'ensemble de certificats (y compris son propre certificat, le cas échéant). De plus, les arguments subjectDN et subjectKeyId ont été initialisés sur les valeurs qui serviront à résoudre le certificat de l'homologue à partir de l'ensemble de certificats. Si le pair a fourni son propre certificat (plutôt qu'une référence de certificat), le champ "EntityCert" de l'argument validCtx contiendra un pointeur vers ce certificat.

Pendant cette phase, les implémentations peuvent modifier le contenu de l'ensemble de certificats, y compris en ajoutant de nouveaux certificats. Ils peuvent également modifier les arguments subjectDN, subjectKeyId ou validCtx si nécessaire. Plus important encore, les implémentations doivent ajuster les champs de type de certificat avec le certificat défini avant le renvoi pour garantir un traitement correct des certificats lors de la validation et des contrôles de contrôle d'accès ultérieurs.

REMARQUE: Si le pair fournit une référence de certificat pour lui-même, plutôt qu'un certificat complet, le champ "EntityCert" du contexte de validation contiendra une valeur NULL. Si une implémentation souhaite prendre en charge les références de certificat, elle doit ajouter un certificat correspondant au nom distinctif de l'objet et à l'ID de clé de l'homologue au certificat défini avant d'être renvoyé.

L'implémentation de cette méthode est facultative. L'implémentation par défaut n'a aucun effet.