5.1. Specific Compatibility Notes on ASN.1 (Note di Compatibilità Specifiche su ASN.1)

Per scopi di compatibilità, gli implementatori dovrebbero prestare attenzione alle seguenti note specifiche riguardanti l'uso di ASN.1 in Kerberos. Queste note non descrivono deviazioni dall'uso standard di ASN.1. Lo scopo di queste note è invece descrivere alcune peculiarità storiche e non conformità di varie implementazioni, così come ambiguità storiche, che, sebbene siano ASN.1 valido, possono portare a confusione durante l'implementazione.

5.1.1. Regole di Codifica Distinta ASN.1

La codifica dei messaggi del protocollo Kerberos deve obbedire alle Distinguished Encoding Rules (DER) di ASN.1 come descritto in [X690]. Si sa che alcune implementazioni (ritenute principalmente quelle derivate da DCE 1.1 e precedenti) utilizzano le più generali Basic Encoding Rules (BER); in particolare, queste implementazioni inviano codifiche indefinite delle lunghezze. Le implementazioni POSSONO accettare tali codifiche nell'interesse della retrocompatibilità, sebbene gli implementatori siano avvertiti che decodificare BER completamente generale è pieno di pericoli.

5.1.2. Campi Interi Opzionali

Alcune implementazioni non distinguono internamente tra un valore intero opzionale omesso e un valore trasmesso di zero. I luoghi nel protocollo in cui questo è rilevante includono vari campi microseconds, nonce e numeri di sequenza. Le implementazioni DOVREBBERO trattare i valori interi opzionali omessi come se fossero stati trasmessi con un valore di zero, se l'applicazione si aspetta questo.

5.1.3. Tipi SEQUENCE OF Vuoti

Ci sono luoghi nel protocollo in cui un messaggio contiene un tipo SEQUENCE OF come membro opzionale. Ciò può risultare in una codifica che contiene una codifica SEQUENCE OF vuota. Il protocollo Kerberos non distingue semanticamente tra un tipo SEQUENCE OF opzionale assente e un tipo SEQUENCE OF opzionale presente ma vuoto. Le implementazioni NON DOVREBBERO inviare codifiche SEQUENCE OF vuote che sono contrassegnate OPTIONAL, ma DOVREBBERO accettarle come equivalenti a un tipo OPTIONAL omesso. Nella sintassi ASN.1 che descrive i messaggi Kerberos, le istanze di questi tipi SEQUENCE OF opzionali problematici sono indicate con un commento.

5.1.4. Numeri di Tag Non Riconosciuti

Le revisioni future di questo protocollo possono includere nuovi tipi di messaggio con numeri di tag della classe APPLICATION diversi. Tali revisioni dovrebbero proteggere le implementazioni più vecchie inviando solo i tipi di messaggio alle parti che si sa li comprendono; ad esempio, tramite un bit di flag impostato dal ricevitore in una richiesta precedente. Nell'interesse di una gestione degli errori robusta, le implementazioni DOVREBBERO comunque gestire elegantemente la ricezione di un messaggio con un tag non riconosciuto, e restituire un messaggio di errore, se appropriato.

In particolare, i KDC DOVREBBERO restituire KRB_AP_ERR_MSG_TYPE se viene inviato il tag errato su un trasporto TCP. I KDC NON DOVREBBERO rispondere ai messaggi ricevuti con un tag sconosciuto su trasporto UDP per evitare attacchi denial of service. Per le applicazioni non-KDC, l'implementazione Kerberos tipicamente indica un errore all'applicazione che prende i passi appropriati in base al protocollo applicativo.

5.1.5. Numeri di Tag Maggiori di 30

Un'implementazione ingenua di un decodificatore ASN.1 DER può avere problemi con i numeri di tag ASN.1 maggiori di 30, a causa del fatto che tali numeri di tag sono codificati utilizzando più di un byte. Le revisioni future di questo protocollo possono utilizzare numeri di tag maggiori di 30, e le implementazioni DOVREBBERO essere preparate a restituire elegantemente un errore, se appropriato, quando non riconoscono il tag.