ASN1-Strukturbeschaffungssyntax

589
Opa114

Ich möchte die Procuration-Erweiterung zu meinem Zertifikat hinzufügen. Dazu verwende ich das Tool XCA, das zur Erstellung der Zertifikate OpenSSL conf verwendet.

Dies ist die ASN1-Struktur:

ProcurationSyntax ::= SEQUENCE { country [1] EXPLICIT PrintableString OPTIONAL typeOfSubstitution[2] EXPLICIT DirectoryString OPTIONAL signingFor [3] EXPLICIT SigningFor }  SigningFor ::= CHOICE { thirdPerson GeneralName certRef IssuerSerial }  IssuerSerial ::= SEQUENCE { issuer GeneralNames serial CertificateSerialNumber issuerUID UniqueIdentifier OPTIONAL } 

Nun möchte ich diese Erweiterung als beliebige Erweiterung über openssl conf hinzufügen ( https://www.openssl.org/docs/man1.1.0/apps/x509v3_config.html#ARBITRARY-EXTENSIONS ).

Mein Code sieht so aus, aber ich bleibe beim Rest - ThirdPersons Zeug:

1.3.36.8.3.2=ASN1:SEQUENCE:proc_sect  [proc_sect] country=EXPLICIT:1,IA5STRING:EN typeOfSubtitution=EXPLICIT:2,IA5STRING:My Type of Substitution thirdPerson OR certRef=EXPLICIT:3,TODO 

Es wäre also sehr hilfreich, wenn jemand einen funktionierenden Beispielcode für die fehlende Restdatei bereitstellen könnte, also ThirdPerson und certRef.

2

1 Antwort auf die Frage

3
grawity

Minimales Beispiel für das Ganze

1.3.36.8.3.2 = ASN1:SEQUENCE:procuration  [procuration] country = EXP:1, PRINTABLE:EN typeOfSubstitution = EXP:2, UTF8:My Type of Substitution thirdPerson = EXP:3, EXP:0, EXP:1, IA5:fred@example.com 

Um einen Testfall zu erhalten, habe ich die folgende ASN.1- Wertnotation mit asn1-playground erstellt :

procuration ProcurationSyntax ::= { country "EN", typeOfSubstitution utf8String : "My Type of Substitution", signingFor thirdPerson rfc822Name : "fred@example.com" } 

Ich habe dieses Schema verwendet .

[proc]

Achten Sie auf die verschiedenen Arten von Zeichenfolgen.

countryist als PrintableString definiert (dies ist nur eine Teilmenge von IA5String):

country = EXPLICIT:1, PRINTABLE:EN 

typeOfSubstitutionist als DirectoryString definiert. Dies ist eine WAHL zwischen TeletexString, PrintableString, UniversalString, UTF8String oder BMPString - einige davon sind Teilmengen von IA5String, andere sind Supersets, der eigentliche IA5String ist jedoch nicht zulässig. Gehen wir also zu UTF-8 Unicode:

; ┌── tag for ProcurationSyntax sequence ; ¦ typeOfSubstitution = EXPLICIT:2, UTF8:My Type of Substitution 

(Die Online-Version von asn1step besagt, dass es keinen eigenen Tag für DirectoryString gibt; ich denke, das liegt daran, dass alle möglichen Optionen bereits eindeutige 'universelle' Tags haben.)

Da signingFores sich um eine WAHL zwischen thirdPersonvs handelt certRef, können Sie die eine oder die andere Option verwenden. Es liegt an Ihnen, den geeigneten Typ auszuwählen.

thirdPersonist definiert als [0] GeneralName, was eine WAHL zwischen verschiedenen weiteren Typen ist - genau dieselbe Auswahl wie in der Erweiterung subjectAltName. Beispielsweise können Sie eine E-Mail-Adresse angeben (in Form von rfc822Name [1] IA5String):

; ┌── tag for ProcurationSyntax sequence ; │ ┌── tag for SigningFor choice ; │ │ ┌── tag for GeneralName choice ; ¦ ¦ ¦ thirdPerson = EXP:3, EXP:0, EXP:1, IA5:fred@example.com 

Oder ein dNSName (definiert als [2] IA5String):

thirdPerson = EXP:3, EXP:0, EXP:2, IA5:example.com 

(Oder ein anderer Name, der ein MPEG-Video eines Kätzchens enthält.)

Wenn Sie stattdessen eine auswählen möchten certRef, ist dies eine ganze verschachtelte SEQUENCE.

; ┌── tag for ProcurationSyntax sequence ; │ ┌── tag for SigningFor choice ; ¦ ¦ certRef = EXP:3, IMP:1, SEQUENCE:proc_certref 

[proc_certref]

Innerhalb des [proc_certref]Abschnitts müssen Sie mindestens issuerund definieren serial.

issuerist GeneralNames, eine Folge von GeneralName-Werten.

issuer = IMP:0, SEQUENCE:proc_certref_issuer ; └── tag for IssuerSerial sequence 

serialis CertificateSerialNumber ist einfach eine ganze Zahl.

serial = IMP:1, INTEGER:0x123456 

Hinweis: Ich bin sehr unsicher, ob diese implizite Tags enthalten sollen oder nicht.

[proc_certref_issuer]

Großartig. Ein weiterer Abschnitt und ein GeneralNames dazu . Zum Glück gibt es nur einen davon. Leider gibt es mehr als null davon.

Der einfachste gültige Wert wäre ein einzelner GeneralName, der nur ein rfc822Name oder ein dNSName (beide IA5String) ist:

issuer.0 = IMP:1, IA5:fred@example.com ; └── tag for GeneralName choice 

… Eigentlich haben wir schon einmal einen verzeichnisnamen gemacht, oder? Da dies issuer.0ein GeneralName ist, verwendet er dasselbe Format wie admissionAuthorityin Ihrer vorherigen Erweiterung (mit dem gleichen Tagging und allem), so dass ich nicht versuche, es hier erneut zu implementieren.

Vielen Dank für diese sehr ausführliche Erklärung, die mir sehr hilft und einige Punkte klarstellt. Ich werde mich in den nächsten Tagen genauer ansehen. Opa114 vor 6 Jahren 0
Ich habe einen Blick darauf geworfen. Ist das zweite EXPLICIT nicht zu viel? "drittePerson = EXP: 3, EXP: 0, EXP: 1, IA5: fred @ example.com"? Opa114 vor 6 Jahren 0
Ja, die Tags _might_ sind tatsächlich falsch. Ich denke, es hängt davon ab, welcher Standard-Tagging-Modus für das gesamte Schema verwendet wurde (Ihr Beitrag enthält nicht die Kopfzeile `DEFINITIONS [<...> TAGS] :: =`, daher ist diese etwas mehrdeutig). grawity vor 6 Jahren 0
danke für den Tipp. Ich werde nach diesen DEFINITIONEN und diesem Bericht suchen. Opa114 vor 6 Jahren 0
danke für den Tipp. Ich habe mir die CommonPKI-Spezifikation angesehen und diese Informationen gefunden: CHOICE-Objekte werden immer EXPLICITly markiert, unabhängig vom Standard-Tagging-Modus. Also dein zweiter EXPLICIT? ist richtig oder? Es enthält jedoch keine Informationen, wenn die Tags 0 und 1 oder 1 und 2 sind. Opa114 vor 6 Jahren 0
Ich glaube, Tags beginnen immer bei 0, wenn nicht anders angegeben. grawity vor 6 Jahren 0
und was ist mit dem "CHOICE" -Typ. Wenn kein Tag angegeben ist, lautet der Standard-Tagging-Modus `EXPLICIT`. Aber es muss ein Tag sein, sonst kann ich nicht erkennen, welche Wahl es ist, oder? Opa114 vor 6 Jahren 0
Ich bin mir nicht sicher. Ich würde sagen, SigningFor steht kurz davor, mehrdeutig zu sein. Wenn ich also das Schema entwerfe, würde ich immer die expliziten Tags hinzufügen ... (Andererseits haben alle möglichen Auswahlmöglichkeiten in DirectoryString bereits verschiedene UNIVERSAL-Tags, also zusätzliche.) Tagging ist _apparently_ nicht erforderlich.) Dies liegt außerhalb meines ASN.1-Wissens. grawity vor 6 Jahren 0
Wie ich es sehe, ist der Standardmodus Explicit. Die `IMPLICIT'-Tags auf serial, issuer und issuerUID sind jedoch nicht richtig, da in der Basisstrukturdefinition keine Tags angegeben werden. Daher wird standardmäßig 'EXPLICIT` verwendet, oder ich bin falsch. Opa114 vor 6 Jahren 0