Wie funktionieren [0] und [3] in ASN1?

ASN.1 BER und DER verwenden ASN.1 TAGs, um bestimmte Komponenten in einem codierten Stream eindeutig zu identifizieren. Es gibt 4 Klassen von ASN.1-Tags: UNIVERSAL, APPICATION, PRIVATE und kontextspezifisch. Das [0] ist ein kontextspezifisches Tag, da es kein Tag-Klassen-Kewort davor gibt. UNIVERSAL ist für integrierte Typen in ASN.1 reserviert. Meistens sehen Sie kontextspezifische Tags, um mögliche Mehrdeutigkeiten in einer SEQUENCE zu eliminieren, die OPTIONALE Elemente enthält. Wenn Sie wissen, dass Sie nacheinander zwei nicht optionale Elemente erhalten, wissen Sie, welches das ist, selbst wenn ihre Tags identisch sind. Wenn der erste jedoch optional ist, müssen die beiden unterschiedliche Tags haben, oder Sie könnten nicht erkennen, welchen Sie erhalten hätten, wenn nur einer in der Codierung vorhanden wäre.

Am häufigsten wird heute in der ASN.1-Spezifikation "AUTOMATIC TAGS" verwendet, damit Sie sich keine Gedanken über diese Art von Disambiguierung in Nachrichten machen müssen, da Komponenten von SEQUENCE, SET und CHOICE automatisch kontextspezifische Tags erhalten, die mit [0 beginnen ], [1], [2] usw. für jede Komponente.

Weitere Informationen zu ASN.1-Tags finden Sie unter Ссылка wo zwei frei herunterladbare Bücher verfügbar sind.

Eine weitere hervorragende Ressource ist Ссылка , wo Sie Variationen der ASN.1-Spezifikationen mit verschiedenen Tags in einem Online-Compiler und einem Encoder ausprobieren können. Decoder. Dort können Sie die Auswirkungen von Tag-Änderungen auf Kodierungen sehen.

Es klingt als ob Sie eine Einführung in ASN.1 Tagging benötigen. Es gibt zwei Winkel, um davon zu kommen. X.690 definiert BER / CER / DER-Codierregeln. Als solches beantwortet es die Frage, wie Tags codiert sind. X.680 definiert ASN.1 selbst. Als solches definiert es die Syntax und die Regeln für die Markierung. Beide Spezifikationen finden Sie auf der ITU-T-Website. Ich gebe dir einen schnellen Überblick.

Tags werden in BER / DER / CER verwendet, um Typen zu identifizieren. Sie sind besonders nützlich, um die Komponenten einer SEQUENCE und die Alternativen einer CHOICE zu unterscheiden.

Ein Tag kombiniert eine Tag-Klasse und eine Tag-Nummer. Die Tag-Klassen sind UNIVERSAL, APPLICATION, PRIVATE und CONTEXT-SPECIFIC. Die UNIVERSAL-Klasse wird grundsätzlich für die eingebauten Typen verwendet. APPLICATION wird normalerweise für benutzerdefinierte Typen verwendet. CONTEXT-SPECIFIC wird typischerweise für die Komponenten innerhalb konstruierter Typen verwendet (SEQUENCE, CHOICE, SEQUENCE OF). Wenn Tags in einem ASN.1-Modul angegeben werden, werden sie syntaktisch in Klammern geschrieben: [tag_klasse tagnummer]; Für CONTEXT-SPECIFIC wird die tag_class weggelassen. Also, [ANWENDUNG 10] oder [0].

Obwohl jedem ASN.1-Typ syntaktisch ein Tag zugeordnet ist, gibt es auch den "TaggedType", der von einem ASN.1-Autor verwendet wird, um das Tag anzugeben, mit dem ein Typ codiert werden soll. Im Grunde stellt ein TaggedType ein Tag-Präfix vor einen Typ. Zum Beispiel:

Das Tag in einem TaggedType ist entweder explizit oder implizit. Wenn dies explizit ist, bedeutet dies, dass das ursprüngliche Tag explizit codiert werden soll. Wenn dies implizit ist, bedeutet das, dass ich froh bin, dass nur das von mir angegebene Tag codiert ist. Im expliziten Fall führt die BER-Codierung zu einem geschachtelten TLV (Tag-length-value): dem äußeren Tag ([0] im obigen Beispiel), der Länge und dann einem anderen TLV als Wert. Im Beispiel hätte diese innere TLV eine Kennung von [UNIVERSAL 12] für den UTF8String.

Ob das Tag explizit oder implizit ist, hängt davon ab, wie Sie das Tag und die Tagging-Umgebung schreiben. Zum Beispiel:

Wenn Sie weder IMPLICIT noch EXPLICIT angeben, gibt es einige Regeln, die festlegen, ob das Tag explizit oder implizit ist (siehe X.680 31). Diese Regeln berücksichtigen die für das ASN.1-Modul definierte Tagging-Umgebung. Das ASN.1-Modul kann die Markierungsumgebung als IMPLICIT-TAGS, EXPLICIT-TAGS oder AUTOMATISCHE TAGS spezifizieren. Grob gesagt , wenn Sie IMPLICIT oder EXPLICIT für ein Tag nicht angeben, ist das Tag explizit, wenn die Tagging-Umgebung EXPLICIT ist, und implizit, wenn die Tagging-Umgebung IMPLICIT oder AUTOMATIC ist. Eine automatische Tagging-Umgebung ist im Grunde die gleiche wie eine IMPLICIT-Tagging-Umgebung, mit der Ausnahme, dass eindeutige Tags automatisch für Mitglieder von SEQUENCE- und CHOICE-Typen zugewiesen werden.

Beachten Sie, dass im obigen Beispiel die drei Komponenten von MyType2 alle optional sind. In BER / CER / DER wird ein Decoder wissen, welche Komponente basierend auf dem codierten Tag vorhanden ist (was offensichtlich besser eindeutig ist).

[0] ist ein kontextspezifischer markierter Typ, das heißt, um herauszufinden, welche Bedeutung er den Feldern gibt (wenn das Flag "Constructed" gesetzt ist) oder Datenwert (wenn das Flag "Constructed" nicht gesetzt ist) Wraps; Sie müssen wissen, in welchem ​​Kontext es erscheint.

Außerdem müssen Sie wissen, welche Art von Objekt der Sender und der Empfänger im DER-Stream austauschen, d. das "ASN.1-Modul".

Nehmen wir an, sie tauschen eine Zertifikatsignierungsanforderung aus und [0] erscheint als 4. Feld innerhalb einer SEQUENCE innerhalb der Root-Sequenz:

Dann wird gemäß RFC2968, die den Inhalt der DER für Zertifikatsanmeldungsanfragen definiert, Anhang A, der das ASN.1-Modul definiert, die Bedeutung dieses bestimmten Feldes hinterhältig als "Attribute" und "Soll das Constructed-Flag gesetzt sein ":

Sie können auch anders herum gehen und sehen, dass "attributes" das vierte Feld in der ersten Sequenz innerhalb der Root-Sequenz sein muss und als [0] durch Betrachten der Root-Sequenzdefinition (Abschnitt 4: "top- level type CertificationRequest "), die CertificationRequestInfo-Position in dieser finden und herausfinden, wo sich das Element" attributes "innerhalb der CertificationRequestInfo befindet, und schließlich sehen, wie es getaggt wird.

ASN.1 ist so einfach, ich verstehe nicht, wie mehr Leute es nicht verstehen ... "Es ist nur ein TLV-Format .."; -)