Frage

Ich habe eine Spezifikation für eine ASN.1 -Syntax, die ich durch Hinzufügen einiger Felder ändern möchte. Wenn ich eine codierte Zeichenfolge mit BER mit den neuen Feldern erstelle und dann versuche, diese Zeichenfolge mit einem Decoder zu entschlüsseln, der nicht über diese zusätzlichen Felder weiß, was sollte das Ergebnis sein? Wird die Dekodierung fehlschlagen, weil es Felder gibt, die der Decoder nicht erkennt? Wird der Decoder nur die Felder dekodieren, die er erkennen und diejenigen ignorieren kann, die er nicht nicht ignorieren kann? Ist dies völlig ein Problem mit Decoder-Implementierung, so dass eines der beiden Ergebnisse möglich ist, abhängig davon, wie der Decoder implementiert wird?

Im Moment verwende ich einen Open Source ASN.1 -Compiler/Decoder und es scheint vollständig zu fehlschlagen, aber ich bin mir nicht sicher, ob dies an der Implementierung liegt oder weil die ASN.1 -Regeln diese Art von Ergebnis vorweisen?

Keine korrekte Lösung

Andere Tipps

Es hängt mit Sicherheit nicht von der Implementierung ab. Das heißt, wenn verschiedene Implementierungen es anders behandeln, macht einer von ihnen es falsch. Wenn Sie mit einem Decoder, der nicht unbekannte Felder erwartet, zu dekodieren, unbekannte Felder, sollte das Dekodieren fehlschlagen. Es wird nicht unbekannte Felder überspringen.

Es gibt jedoch eine Möglichkeit, zusätzliche Felder bereitzustellen, noch bevor sie bekannt sind. Es soll den Erweiterungsmarker ("...") verwendet. Nehmen wir an, wir entwickeln verschiedene Versionen einer ASN.1 -Spezifikation. Nennen wir sie v1, v2, v3 usw. v1 ist die ursprüngliche Spezifikation, aber wir verstehen zu dem Zeitpunkt, als wir V1 entwerfen, dass wir sie wahrscheinlich irgendwann ändern müssen. Um dies zuzulassen, anstatt so etwas wie

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1
}

Wir würden Z für so erweiterbar erklären

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1,
                 ...
}

Der Erweiterungsmarker besagt, dass es nach C möglicherweise mehr Felder geben, die noch unbekannt sind. Der Decoder sollte Nachrichten behandeln, die solche Felder enthalten, solange sie C als gültig folgen. Der Decoder wäre nicht in der Lage, sie zu dekodieren, da er nicht weiß, was sie sein sollten, aber es weiß, dass sie zulässig sind.

Nehmen wir an, wir aktualisieren V1 auf V2, indem wir zwei neue Felder wie diese einfügen

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN          ]] -- V2
}

In diesem Fall kann die V1 -Version mit der V2 -Version zusammenarbeiten. Der V1 -Encoder würde nicht D oder E enthalten, während der V2 -Encoder sie enthalten würde. Aus Sicht des Decoders würde der V1 -Decoder d und e entschlüsseln (aber nicht dekodieren), während der V2 -Decoder D und E dekodieren würde, wenn sie gefunden werden. Ein V1 -Decoder würde also sowohl V1- als auch V2 -Codierungen akzeptieren und d und e ignorieren, wann immer sie gefunden werden; Ein V2 -Decoder würde auch sowohl V1- als auch V2 -Codierungen akzeptieren und feststellen, dass eine V1 -Codierung nicht D oder E enthalten würde, aber es bleibt gültig.

Wir können dies beispielsweise durch zusätzliche Versionen fortsetzen,

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN         ]], -- V2
             [[  f PrintableString,    -- V3
                 g ExtensionMessage]]  -- V3
}

wo v1, v2 und v3 alle interoperieren können.

Beachten Sie jedoch, dass die Reihenfolge erhalten bleiben muss, da wir mit einer Sequenz zu tun haben. Sie könnten E ohne D oder g ohne D, E und f haben.

Die Schlussfolgerung lautet daher, dass Sie, wenn Ihre Typdefinition Erweiterungsmarker enthält, neue Felder hinzufügen können. Wenn dies jedoch nicht der Fall ist, können Sie dies möglicherweise nicht tun.

Dies alles hängt von der Spezifikation und der Implementierung ab. Kurz gesagt - es gibt keine Möglichkeit zu sagen. Und es liegt an der Implementierung. In einigen Spezifikationen für ein bestimmtes Protokoll/Format, das ASN.1 verwendet, heißt es ausdrücklich, dass unbekannte Elemente ignoriert werden sollen. In diesem Fall sollte die Dekodierung nicht fehlschlagen.

Häufiger sind Decoder jedoch jede Eingabe ab, die nicht der ASN.1 -Syntax entspricht, die sie decodieren soll.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top