5.1. Notes de compatibilité spécifiques sur ASN.1

À des fins de compatibilité, les implémenteurs doivent prêter attention aux notes spécifiques suivantes concernant l'utilisation d'ASN.1 dans Kerberos. Ces notes ne décrivent pas de déviations par rapport à l'utilisation standard d'ASN.1. L'objectif de ces notes est plutôt de décrire certaines particularités historiques et non-conformités de diverses implémentations, ainsi que des ambiguïtés historiques, qui, bien qu'elles soient de l'ASN.1 valide, peuvent conduire à de la confusion lors de l'implémentation.

5.1.1. Règles d'encodage distinctif ASN.1

L'encodage des messages du protocole Kerberos doit obéir aux règles d'encodage distinctif (DER) d'ASN.1 telles que décrites dans [X690]. Certaines implémentations (que l'on croit principalement être celles dérivées de DCE 1.1 et antérieures) sont connues pour utiliser les règles d'encodage de base (BER) plus générales; en particulier, ces implémentations envoient des encodages de longueurs indéfinies. Les implémentations PEUVENT accepter de tels encodages dans l'intérêt de la compatibilité ascendante, bien que les implémenteurs soient avertis que le décodage de BER entièrement général est semé d'embûches.

5.1.2. Champs entiers optionnels

Certaines implémentations ne distinguent pas en interne entre une valeur entière optionnelle omise et une valeur transmise de zéro. Les endroits dans le protocole où cela est pertinent incluent divers champs de microsecondes, nonces et numéros de séquence. Les implémentations DEVRAIENT traiter les valeurs entières optionnelles omises comme ayant été transmises avec une valeur de zéro, si l'application s'attend à cela.

5.1.3. Types SEQUENCE OF vides

Il y a des endroits dans le protocole où un message contient un type SEQUENCE OF en tant que membre optionnel. Cela peut résulter en un encodage qui contient un encodage SEQUENCE OF vide. Le protocole Kerberos ne fait pas de distinction sémantique entre un type SEQUENCE OF optionnel absent et un type SEQUENCE OF optionnel présent mais vide. Les implémentations NE DEVRAIENT PAS envoyer d'encodages SEQUENCE OF vides qui sont marqués OPTIONAL, mais DEVRAIENT les accepter comme étant équivalents à un type OPTIONAL omis. Dans la syntaxe ASN.1 décrivant les messages Kerberos, les instances de ces types SEQUENCE OF optionnels problématiques sont indiquées par un commentaire.

5.1.4. Numéros de balise non reconnus

Les révisions futures de ce protocole peuvent inclure de nouveaux types de messages avec différents numéros de balise de classe APPLICATION. De telles révisions devraient protéger les implémentations plus anciennes en n'envoyant les types de messages qu'aux parties connues pour les comprendre; par exemple, au moyen d'un bit de drapeau défini par le récepteur dans une requête précédente. Dans l'intérêt d'une gestion d'erreur robuste, les implémentations DEVRAIENT gérer gracieusement la réception d'un message avec une balise non reconnue de toute façon, et retourner un message d'erreur, si approprié.

En particulier, les KDC DEVRAIENT retourner KRB_AP_ERR_MSG_TYPE si la balise incorrecte est envoyée sur un transport TCP. Les KDC NE DEVRAIENT PAS répondre aux messages reçus avec une balise inconnue sur le transport UDP afin d'éviter les attaques par déni de service. Pour les applications non-KDC, l'implémentation Kerberos indique généralement une erreur à l'application qui prend les mesures appropriées en fonction du protocole d'application.

5.1.5. Numéros de balise supérieurs à 30

Une implémentation naïve d'un décodeur ASN.1 DER peut rencontrer des problèmes avec les numéros de balise ASN.1 supérieurs à 30, en raison du fait que de tels numéros de balise sont encodés en utilisant plus d'un octet. Les révisions futures de ce protocole peuvent utiliser des numéros de balise supérieurs à 30, et les implémentations DEVRAIENT être préparées à retourner gracieusement une erreur, si approprié, lorsqu'elles ne reconnaissent pas la balise.