Globale Typen

In diesem Kapitel werden XML-Elementtypen beschrieben, welche an anderer Stelle verwendet werden können. XML-Elementtypen stellen keine XML-Elementnamen dar, welche im XML-Dokument erscheinen. Stattdessen handelt es sich um Variablennamen für mehrfach verwendete XML-Element-Konstruktionen, welche zur Beschreibung eines XML-Elements eingesetzt werden können. Somit kann mit Hilfe von XML-Elementtypen in einfacher Art und Weise die Unterelemente eines XML-Elements angegeben werden. Weiterhin können über die XML-Elementtypen auch Attribute für das zu beschreibende XML-Element festgelegt werden.

dnDefinitionType

Mit diesem Typ kann ein Distinguished-Name nach X.500 definiert werden. Er kann aus festen und dynamischen Werten zusammengesetzt werden.

Der Typ wird in X.509-Zertifikate und PKCS#10-Requests zur Beschreibung des XML-Elements <dnDefinition> verwendet.

Ein einzelner Wert kann als XML-Element mit einem Wert <dnAttribute> oder mit mehreren Werten <dnMultiAttribute> angegeben werden.

Die XML-Elemente <dnAttribute> und <dnMultiAttribute> sind in den folgenden Unterkapiteln beschrieben.

Beispiel

<dnDefinition>
    <dnMultiAttribute>
        <dnAttribute><oid>2.5.4.3</oid>
            <identName>cn</identName>
        </dnAttribute>
        <dnAttribute>
            <oid>2.5.4.10</oid>
            <identName>o</identName>
        </dnAttribute>
    </dnMultiAttribute>
    <dnAttribute>
        <oid>2.5.4.6</oid>
        <identName>c</identName>
        <default>DE</default>
    </dnAttribute>
</dnDefinition>

dnAttribute

Dieses XML-Element definiert ein einzelnes DN-Attribut.

Attribute

Attribute von dnAttribute
Attributname Erläuterung

mandatory

Legt fest, ob dieses Attribut vorhanden sein muss.

Als Werte können true und false gesetzt werden.

Die Angabe ist optional, der Default ist false.

charset

Hiermit kann eine ASN1-Kodierung für ein DN-Attribut festgelegt werden.

Die unterstützten Werte sind in Gültige Werte für DN-Attribute-charset zu finden.

Die Angabe ist optional.
Gültige Werte für DN-Attribute-charset
Zeichensatz Erläuterung

PrintableString

Der Wert wird als PrintableString kodiert.

UTF-8

Der Wert wird als UTF-8-String kodiert.

IA5String

Der Wert wird als IA5String kodiert.

GeneralizedTime

Der Wert wird als GeneralizedTime kodiert.

VisibleString

Der Wert wird als VisibleString kodiert.

Unterelemente

Unterelemente des XML-Elements „dnDefinition“
Element-Name Erläuterung

oid

Der Object Identifier des DN-Attriutes.

Dieser Wert muss angegeben werden.

identName

Wird zur dynamischen Definition eines Werts für eine OID verwendet.

Siehe Beschreibung in „identName“ in valueType.

default

Wird zur Definition eines festen Werts für eine OID verwendet.

Siehe Beschreibung „default“ in valueType.

counter

Wird zur Definition eines System-internen Zählers verwendet.

Siehe Beschreibung „default“ in valueType

Beispiel

<dnAttribute>
    <oid>2.5.4.6</oid><default>DE</default >
</dnAttribute>

Mit dieser Definition wird ein DN-Feld für die OID 2.5.4.6 (Country) fest auf den Wert DE gesetzt.

dnMultiAttribute

Innerhalb des XML-Elements <dnMultiAttribute> können Mulit-Attribute definiert werden.

Schematischer Aufbau

<dnMultiAttribute>
    <dnAttribute>...<dnAttribute>
    <dnAttribute>...<dnAttribute>
    ...
</dnMultiAttribute>

Unterelemente

Unterelemente des XML-Elements „dnMultiAttribute“
Element-Name Erläuterung

dnAttribute

Legt ein einzelnes DN-Attribut fest.

siehe dnAttribute dnAttribute

Beispiel

<dnMultiAttribute>
    <dnAttribute>
        <oid>2.5.4.4</oid><identName>id.surName</identName>
    </dnAttribute>
    <dnAttribute>
        <oid>2.5.4.5</oid><identName>id.serNum</identName>
    </dnAttribute>
</dnMultiAttribute>

valueType

Mit diesem XML-Elementtyp können Werte dynamisch und statisch definiert werden.

Der XML-Elementtyp wird bei mehreren XML-Elementen verwendet.

Unterelemente des XML-Elements „valueType“
Element-Name Erläuterung

length

Mit diesem XML-Element wird die Länge des Werts definiert.

Falls der tatsächliche Wert kleiner ist, wird der Wert passend vergrößert, z.B. bei einem Integer-Wert, der als String angezeigt wird, mit führenden Nullen.

Dieser Wert wird nicht überall verwendet. Die Angabe ist immer optional.

identName

Hier kann der Wert dynamisch definiert werden. Dieser Wert dynamisch bei der Zertifikatserstellung übergeben.

Im Admin-FE wird der hier angegebene Text als Beschriftung eines Eingabefelds angezeigt.

Ist dieses XML-Element im Template spezifiziert, so muss ein entsprechender Ident-Wert bei der Zertifikatserstellung übergeben werden, sofern kein Default-Wert (siehe XML-Element-Name default) angegeben wird.

default

Hiermit wird ein konstanter Wert angegeben. Der Wert wird exakt übernommen.

Bei der Generierung von dynamischen Formularen anhand von Template-Definitionen zum Erzeugen von Zertifikaten und Requests im Admin-FE werden die IdentName Felder mit diesem Wert vorbefüllt, wenn nicht schon andere Vorbefüllengsregeln gelten.

counter

Mit diesem XML-Element kann die Verwendung eines System-internen Zählers definiert werden. Der Zähler muss zuvor im Admin-FE angelegt werden und wird hier über den Counter-Namen referenziert.

Die Verwendung dieses XML-Elements wird nicht an allen Stellen unterstützt. Zurzeit ist dies nur bei den XML-Elementen ASCII und dnAttribute der Fall.

frontendPrefill

Hiermit kann beim Generieren eines Link-Zertifikats mit Hilfe des Admin-Operator Frontends das Formularfeld für die Sequence-Number mit der Sequence-Number des referenzierten CA-Zertifikat vorbefüllt werden.

Es sollte daher für Eintrage für die SequenceNumber verwendet werden (z.B mit identName SequenceNumber

Die genaue Syntax lautet:

<frontendPrefill>$caCert.sequenceNumber</frontendPrefill>

Diese Funktionalität steht nur zur Verfügung, wenn im Admin-Operator-Frontend der Konfigurationsparameter
template.show.prefill.values gesetzt ist und den Wert ‚true‘ besitzt.

label

Mit diesem XML-Element kann ein Label (Beschriftung) für das jeweilige Eingabe-Feld festgelegt werden. Dieses Label wird dann z. B. im Admin-Operator Frontend angezeigt, wenn ein Formular dynamisch aus dem Zertifikats-Template generiert wird und dem Benutzer als Hilfestellung dienen.

Mit diesem XML-Element werden Werte in Zertifikaten gesetzt. Dies kann entweder konstant mit dem XML-Element <default> geschehen oder dynamisch mit dem XML-Element identName. Eines der beiden muss immer angegeben werden. Sind beide definiert, wird zuerst überprüft, ob ein Wert für die dynamische Definition existiert. ist dies nicht der Fall, wird der Default-Wert verwendet.

counterType

Mit diesem XML-Element kann die Verwendung eines System-internen Zählers definiert werden. Der Zähler muss zuvor im Admin-FE angelegt werden und wird hier über den Counter-Namen referenziert.

Der XML-Elementtyp wird zur Beschreibung des XML-Elements counter verwendet (siehe valueType).

Attribute

Attributname Erläuterung

length

Wenn sowohl das Attribute length also auch das Attribut fillingCharacter vorhanden sind, wird der Wert auf die angegebene Länge erweitert, indem der fillingCharacter entsprechend oft am Anfang eingefügt wird.

Ist nur ein Attribut vorhanden, wird dieses nicht berücksichtigt.

Die Angabe ist optional.

fillingCharacter

signatureType

Über den XML-Elementtyp <signatureType> werden Informationen zur Signatur festgelegt.

Der XML-Elementtyp wird zur Beschreibung mehrerer XML-Elemente verwendet (siehe X.509-Zertifikate, Aufbau, Attribut-Zertifikate, Plain-Sign Struktur, PKCS#10-Requests).

Attribute

Attribute des XML-Elements „signature“
Attributname Erläuterung

algorithmIdentifierParameters

Hiermit wird der Inhalt von parameters innerhalb der Struktur AlgorithmIdentifier definiert.

Die möglichen Werte und Bedeutungen sind in Werte für algorithmIdentifierParameters beschrieben.

Mit dieser Einstellung kann eine nicht-Standard-konforme Kodierung von AlgorithmIdentifier erzeugt werden.

Die Angabe ist optional.

Der Element wird bei RSASSA-PSS ignoriert.

algorithmIdentifierParameters-rsa

Hiermit wird der Inhalt von parameters innerhalb der Struktur AlgorithmIdentifier definiert.

Die möglichen Werte und Bedeutungen sind in Werte für algorithmIdentifierParameters beschrieben.

Mit dieser Einstellung kann eine nicht-Standard-konforme Kodierung von AlgorithmIdentifier erzeugt werden.

Die Angabe ist optional.

Wird das Attribut angegeben, wenn ein RSA Algorithmus ohne PSS definiert wurde, wird der Wert dieses Elements gegenüber dem Wert des Elements <algorithmIdentifierParameters> bevorzugt. Das Element wird bei RSASSA-PSS, DSA und ECDSA ignoriert.

algorithmIdentifierParameters-ecdsa

Hiermit wird der Inhalt von parameters innerhalb der Struktur AlgorithmIdentifier definiert.

Die möglichen Werte und Bedeutungen sind in Werte für algorithmIdentifierParameters beschrieben.

Mit dieser Einstellung kann eine nicht-Standard-konforme Kodierung von AlgorithmIdentifier erzeugt werden.

Die Angabe ist optional.

Wird das Attribut angegeben, wenn ein ECDSA Algorithmus definiert wurde, wird der Wert dieses Elements gegenüber dem Wert des Elements <algorithmIdentifierParameters> bevorzugt. Das Element wird bei RSASSA-PSS, DSA und RSA ignoriert.
Werte für algorithmIdentifierParameters
Zeichensatz Erläuterung

omit

Dieser Wert wird für RSA verwendet.

Als Standard wird parameters auf den Wert ASN1Null gesetzt. Wenn der Wert omit definiert wird, ist parameters nicht vorhanden.

null

Dieser Wert wird für ECDSA und DSA verwendet.

Als Standard ist parameters nicht vorhanden. Wenn der Wert omit definiert wird, wird parameters auf den Wert ASN1Null gesetzt.

Unterelemente

Unterelemente des XML-Elements „signature“
Element-Name Erläuterung

algorithm

Die OID des Signaturalgorithmus.

Das XML-Element besitzt drei gültige Unterelemente:

default (erforderlich):

Hiermit wird ein konstanter Wert angegeben. Der Wert wird exakt übernommen.

identName (optional):

Hier kann der Wert dynamisch definiert werden. Dieser Wert wird dynamisch bei der Zertifikatserstellung übergeben.

Ist dieses XML-Element im Template definiert und es wird kein entsprechender Ident-Wert bei der Zertifikatserstellung übergeben, wird der Default-Wert (siehe XML-Element-Name default) verwendet.

pssParameters (optional):

Hier werden zusätzliche Angaben gemacht um RSASSA-PSS als Signaturalgorithmus zu unterstützen. Die Unterelemente sind in Unterelemente des Elements „pssParameters“ erläutert. Soll RSASSA-PSS verwendet werden, sind im Element <algorithm> nur folgende Werte erlaubt:

SHA1withRSAandMGF1 (nicht für CARA GenericHSM-Modul)
SHA256withRSAandMGF1
SHA384withRSAandMGF1
SHA512withRSAandMGF1

Soll RSASSA-PSS als Signaturalgorithmus verwendet werden, muss das Unterelement <pssParameters> vorhanden sein.

Beispiel:

<algorithm>
    <default>1.2.840.113549.1.1.5</default>
    <identName>id.hashAlgorithm</identName>
</algorithm>

Beispiel:

<signature>
    <algorithm>
        <default>1.2.840.113549.1.1.5</default>
    </algorithm>
</signature>

In obigem Beispiel wird als Signaturalgorithmus SHA512 mit RSA festgelegt.

Unterelemente des Elements „pssParameters“

Unterelemente des XML-Elements „pssParameters“
Element-Name Erläuterung

saltLength

Octet-Länge des Salt (RSASSA.PSS Parameter Feld).

Das CARA GenericHSM-Modul unterstützt hier ausschließlich folgende Werte:
für SHA256withRSAandMGF1: 32
für SHA384withRSAandMGF1: 48
für SHA512withRSAandMGF1: 64

trailerField

Trailer Field Nummer für Kompatibilität mit Draft IEEE P1363a (RSASSA.PSS Parameter Feld).

Das CARA GenericHSM-Modul unterstützt hier ausschließlich den Wert 1.

buildNullParamsForHashAlgorithm

Optional; zulässige Werte sind true und false. Wird das XML-Element nicht verwendet, so gilt implizit false. Hiermit wird gesteuert, ob bei RSASSA-PSS-Signaturen die AlgorithmIDs der Hash-Algorithmen jeweils mit expliziter Angabe von {NULL} als parameters gebildet werden sollen. Standardmäßig wird diese Struktur nicht gebildet.[1]

Beispiel:

<signature>
    <algorithm>
        <default>SHA256withRSAandMGF1</default>
        <pssParameters>
            <saltLength>32</saltLength>
            <trailerField>1</trailerField>
            <buildNullParamsForHashAlgorithm>true</buildNullParamsForHashAlgorithm>
        </pssParameters>
    </algorithm>
</signature>

Gültige Kombinationen von saltLength und trailerField sowie weitere Informationen zu RSASSA-PSS sind im RFC-3447 zu finden.

ValidityType

Der XML-Elementtyp dient der Festlegung einer Gültigkeit und des Gültigkeitsmodells.

Der XML-Elementtyp wird zur Beschreibung mehrerer XML-Elemente verwendet (siehe X.509-Zertifikate, CV-Zertifikate, Attribut-Zertifikate, PrivateKeyUsagePeriod, ICAONameChange).

Attribute

Attribute des XML-Elements „validity“
Attributname Erläuterung

cutToMax

Dieses Attribut wird verwendet, wenn die Laufzeit von einer Anwendung angegeben wird.

Wenn hier der Wert true angegeben wird, dann wird die Laufzeit eines Zertifikats automatisch auf die maximale Laufzeit gekürzt, die im Template definiert ist.

Wird das Attribut auf false gesetzt, wird die Ausstellung eines Zertifikats mit einem Fehler beendet, sollte die Laufzeit länger sein als erlaubt.

Gültige Werte sind true und false. Die Angabe ist optional. Als Standard wird false verwendet.

useOnlyDates

Bei useOnlyDates=false (Default) ist garantiert, dass das Zertifikat mindestens so lange gültig ist, dass die als DefaultValidity angegebene Zeitspanne vollständig in die Gültigkeitsperiode hineinpasst. Als validNotAfter wird das Ende des Tages verwendet, der sich aus validNotBefore + Default-Validity ergibt.

Bei useOnlyDates=true wird das validNotAfter-Datum hingegen so berechnet, als wäre das Zertifikat ab 0:00:00.000 Uhr gültig. Als validNotAfter wird das Ende des Tages verwendet, der sich aus Tagesanfang(validNotBefore) + Default-Validity ergibt. Hierdurch ist garantiert, dass die tatsächliche Gültigkeitsdauer des Zertifikats die in DefaultValidity angegebene Zeitspanne nicht übersteigt.

Unterelemente

Unterelemente des XML-Elements „validity“
Element-Name Erläuterung

max

Maximale Gültigkeit; wird in Kombination mit dem Attribut cutToMax verwendet.

Aufbau:

<max>
    <year>…</year><month>…</month><day>…</day>
</max>

Werte: Jeweils Anzahl der Jahre, Monate und Tage (siehe Beispiele). Es müssen alle 3 Unterelemente angegeben werden.

Oder:

Aufbau:

<max>
    <date>YYYY-MM-DD</date>
</max>

Wert: Das maximale Datum, an dem das Zertifikat noch bis 23:59:59.000 Uhr UTC gültig sein darf.

Oder:

Aufbau:

<max>
    <year>…</year><month>…</month><day>…</day>
    <date>…</date>
</max>

Werte: Jeweils wie oben beschrieben, jedoch gilt das Minimum aus den beiden Angaben.

default

Standardwert für die Gültigkeit.

Aufbau:

<default><year>…</year><month>…</month><day>…</day></default>

Werte: Jeweils Anzahl der Jahre, Monate und Tage (siehe Beispiele). Es müssen alle 3 Unterelemente angegeben werden.

verifyModel

Legt fest, ob als Gültigkeitsmodell das Ketten- oder das Schalenmodell verwendet wird. Wenn kein Gültigkeitsmodell angegeben ist, werden die Gültigkeitsdauern von EE- und CA-Zertifikat nicht miteinander verglichen. Es wird dann lediglich geprüft, dass das CA-Zertifikat nicht gesperrt und nicht abgelaufen ist, wenn das EE-Zertifikat ausgestellt wird, weil dies sowohl beim Kettenmodell als auch beim Schalenmodell so sein muss.

Das XML-Element besitzt zwei gültige Unterelemente, die jeweils ohne Inhalt angegeben werden:

chain – zur Definition des Kettenmodells

shell – zur Definition des Schalenmodells

Es kann nur eines der beiden Unterelemente angegeben werden.

Beispiel:

<verifyModel><chain/><verifyModel>

Dieses XML-Element besitzt das Attribut cutToParentValidity

Das Attribut cutToParentValidity wird für das Gültigkeitsmodell shell verwendet. Wenn hier der Wert true angegeben wird, dann wird die Laufzeit eines Zertifikats automatisch auf die Laufzeit des Issuers gekürzt.

Wird das Attribut auf false gesetzt, wird die Ausstellung eines Zertifikats mit einem Fehler beendet, sollte die Laufzeit länger sein als die des Issuers.

Gültige Werte sind true und false. Die Angabe ist optional. Als Standard wird false verwendet.

Beispiel 1

<validity>
    <max><year>20</year><month>0</month><day>0</day></max>
    <default><year>20</year><month>0</month><day>0</day></default>
    <verifyModel><shell cutToParentValidity="true"/></verifyModel>
</validity>

Beispiel 2

<validity cutToMax="true">
    <max><year>2</year><month>0</month><day>0</day></max>
    <default><year>1</year><month>0</month><day>0</day></default>
</validity>"

Beispiel 3

Ein Zertifikat darf höchstens bis zum 31.12.2019 gültig sein, andernfalls wird ein Fehler gemeldet, die Standardgültigkeit beträgt ein Jahr:

<validity>
    <max> <date>2019-12-31</date></max>
    <default><year>1</year><month>0</month><day>0</day></default>
</validity>

Beispiel 4

Ein Zertifikat darf höchstens 1 Jahr und niemals länger als bis zum 31.12.2019 gültig sein, andernfalls wird die Gültigkeit entsprechend angepasst, die Standardgültigkeit beträgt ein Jahr:

<validity cutToMax="true">
    <max>
        <year>1</year><month>0</month><day>0</day>
        <date>2019-12-31</date></max>
    <default><year>1</year><month>0</month><day>0</day></default>
</validity>

keyAttributes (encoding)

Der XML-Elementtyp dient zur Angabe von Kodierungsregeln eines Schlüssels.

Der XML-Elementtyp wird zur Beschreibung mehrerer XML-Elemente verwendet (siehe X.509-Zertifikate und Attribut-Zertifikate).

Unterelemente

Unterelemente des XML-Elements „keyAttributes“
Element-Name Erläuterung

RSA

Informationen zum Algorithmus RSA werden über Attribute festgelegt. Die möglichen Attribute sind in Attribute des XML-Elements „RSA“ beschrieben.

EC

Informationen zum Algorithmus Elliptic Curves werden über Attribute festgelegt. Die möglichen Attribute sind in Attribute des XML-Elements „EC“ beschrieben.
Attribute des XML-Elements „RSA“
Attribute von „RSA“ Erläuterung

modulusLength

Angabe der Länge, mit der der Modulus kodiert werden soll. Ist der Modulus kürzer, wird er mit führenden Nullen aufgefüllt.

Dieser Wert wird nur bei der Ausstellung von CV-Zertifikaten verwendet.

Die Angabe ist optional. Die Länge wird in Bytes angegeben.

exponentLength

Angabe der Länge, mit der der Exponent kodiert werden soll. Ist der Modulus kürzer, wird er mit führenden Nullen aufgefüllt.

Dieser Wert wird nur bei der Ausstellung von CV-Zertifikaten verwendet.

Die Angabe ist optional. Die Länge wird in Bytes angegeben.
Attribute des XML-Elements „EC“
Attribute von „EC“ Erläuterung

parameterEncoding

legt die Kodierung der SubjectPublicKey-Struktur fest.

Die Angabe ist optional.

Gültige Werte sind in Werte des Attributs „parameterEncoding“ aufgeführt.

useCofactor

Dieses Attribut kann verwendet werden, wenn als Encoding „ecParameters“ verwendet wird. Es legt fest, ob in den Domain-Parametern der Cofactor enthalten ist oder nicht.

Gültige Werte sind true und false.

Die Angabe ist optional.

Als Standard wird der Co-Faktor nur gesetzt, wenn er ungleich 1 ist.

useCompression

Dieses Attribut definiert, ob der Schlüssel compressed oder uncompressed kodiert werden soll.

Gültige Werte sind true und false.

Die Angabe ist optional.

Als Standard wird false verwendet.
Werte des Attributs „parameterEncoding“
Encoding Erläuterung

ecParameters

Die SubjectPublicKey-Struktur enthält die Domain-Parameter der Kurve.

namedCurve

Die SubjectPublicKey-Struktur enthält die OID der Kurve.

implicitlyCA

wird zurzeit nicht unterstützt

Beispiel 1

<keyAttributes>
    <encoding>
        <RSA exponentLength="4" modulusLength="1024"/>
    </encoding>
</keyAttributes>

Beispiel 2

<keyAttributes>
    <encoding>
        <EC parameterEncoding="ecParameters" useCofactor="true"/>
    </encoding>
</keyAttributes>

keyAttributes (quality)

Der XML-Elementtyp dient zur Aktivierung von Cara-internen Schlüsselprüfungen und (optional) zur Angabe bestimmter Qualitäts-Parameter, die ein Schlüssel erfüllen muss.

Der XML-Elementtyp wird in mehreren Kontexten verwendet (X.509- und CV-Templates; siehe X.509-Zertifikate und CV-Zertifikate).

Unterelemente des Elements „quality“

Unterelemente des XML-Elements „keyAttributes“
Element-Name Erläuterung

RSA

Informationen zum Algorithmus RSA. Die möglichen Unterelemente sind in Unterelemente des XML-Elements „RSA“ beschrieben.

Unterelemente des Elements „RSA“

Unterelemente des XML-Elements „RSA“
Element-Name Erläuterung

modulus

Informationen zum Modulus des RSA-Schlüssels werden über Attribute festgelegt. Die möglichen Attribute sind in Attribute des XML-Elements „RSA“ beschrieben.

exponent

Informationen zum Exponenten des RSA-Schlüssels werden über Attribute festgelegt. Die möglichen Attribute sind in Attribute des XML-Elements „RSA“ beschrieben.

Attribute des Elements „modulus“

Attribute des XML-Elements „RSA“
Attribute von „modulus“ und „exponent“ Erläuterung

minLength

Der verwendete Schlüssel muss diese Mindestlänge haben. Ist dies nicht der Fall, wird die Ausstellung des Zertifikats mit einem Fehler abgebrochen.

Die Angabe ist optional. Die Länge wird in Bits angegeben.

maxLength

Der verwendete Schlüssel darf diese Maximallänge haben. Ist dies nicht der Fall, wird die Ausstellung des Zertifikats mit einem Fehler abgebrochen.

Die Angabe ist optional. Die Länge wird in Bits angegeben.

Beispiel

<keyAttributes>
    <quality>
        <RSA>
            <modulus minLength="2048" maxLength="4096"/>
            <exponent minLength="16"/>
        </RSA>
    </quality>
</keyAttributes>

Wirkung bei der Ausstellung von X.509-Zertifikaten

Auswirkungen auf Schlüsselprüfungen mittels Lint-Server

Bei der Ausstellung von X.509-Zertifikaten werden Schlüsselprüfungen mittels Lint-Server durchgeführt gemäß CA-Konfiguration, unabhängig von den Inhalten des Zert.-Templates, d.h. auf diese Prüfungen hat das quality-Element keine Auswirkungen. Siehe hierzu auch in [Modulhandbuch_CertLint] im Kapitel „Ablauf der Schlüsselprüfung“.

Auswirkungen auf Cara-interne Schlüsselprüfungen

Ist im X.509-Template das quality-Element vorhanden, so werden die Cara-internen Schlüsselprüfungen durchgeführt. Je nach Festlegung in der CA-Konfiguration gelten hierbei entweder die „erweiterten“ Cara-internen Schlüsselprüfungen (siehe Erweiterte Cara-interne Schlüsselprüfungen) oder die Cara-internen Basis-Schlüsselprüfungen (siehe Cara-interne Basis-Schlüsselprüfungen). Bei fehlendem quality-Element findet keine Cara-interne Prüfung der Schlüsselqualität statt.

Wirkung bei der Ausstellung von CV-Zertifikaten

Auswirkungen auf Schlüsselprüfungen mittels Lint-Server

Bei der Ausstellung von CV-Zertifikaten werden Schlüsselprüfungen mittels Lint-Server derzeit nicht unterstützt. Das quality-Element ist hier somit nicht relevant.

Auswirkungen auf Cara-interne Schlüsselprüfungen

Hier gilt analog zu X.509: Ist im CV-Template das quality-Element vorhanden, so werden die Cara-internen Schlüsselprüfungen durchgeführt. Je nach Festlegung in der CA-Konfiguration gelten hierbei die „erweiterten“ Cara-internen Schlüsselprüfungen (siehe Erweiterte Cara-interne Schlüsselprüfungen) oder die Cara-internen Basis-Schlüsselprüfungen (siehe Cara-interne Basis-Schlüsselprüfungen). Bei fehlendem quality-Element findet keine Cara-interne Prüfung der Schlüsselqualität statt.

Wirkung bei der API-Funktion checkPublicKey()

Dies betrifft den REST-Endpoint /api/crypto/check-public-key, der unabhängig von Zertifikatsausstellungen zur Schlüsselprüfung verwendet werden kann. Bei dieser API-Funktion kann optional der Aufrufparameter templateSignerId übermittelt werden, wovon das Verhalten der Funktion in hohem Maße abhängig ist.

Aufruf von checkPublicKey() mit templateSignerId

Durch Übermittlung der templateSignerId wird eine bestimmte Template-Signer-Konfiguration referenziert. Zur Prüfung der Schlüsselqualität sind in diesem Fall die Einstellungen maßgeblich, die in Template und Signer-CA festgelegt sind.

In diesem Unterkapitel wird davon ausgegangen, dass eine gültige templateSignerId übermittelt wurde. Für den Aufruf ohne templateSignerId ist das Verhalten in Aufruf von checkPublicKey() ohne templateSignerId beschrieben.

Auswirkungen auf Schlüsselprüfungen mittels Lint-Server

Schlüsselprüfungen mittels Lint-Server, die in der Signer-CA konfiguriert sind, werden unabhängig vom Zertifikats-Template durchgeführt, so dass das quality-Element hier keine Auswirkungen hat.

Auswirkungen auf Cara-interne Schlüsselprüfungen

Wenn die Schlüsselprüfungen via Lint-Server bereits Fehler oder Warnungen ergeben haben, wird auf Cara-interne Schlüsselprüfungen verzichtet. Ansonsten werden die Cara-internen Schlüsselprüfungen beim Aufruf der API-Funktion checkPublicKey() unabhängig davon aufgerufen, ob im referenzierten Template das quality-Element vorhanden ist oder nicht. Das quality-Element hat hier somit keine Auswirkungen.

Die CA-Einstellung „CARA-interne erweiterte Schlüsselprüfungen durchführen“ kann durch den API-Aufrufparameter forceCheckBaselineRequirements übersteuert werden. Es gelten die erweiterten Cara-internen Schlüsselprüfungen (siehe Erweiterte Cara-interne Schlüsselprüfungen), wenn diese in der CA aktiviert sind oder über den API-Parameter angefordert werden, ansonsten gelten die Cara-internen Basis-Schlüsselprüfungen (siehe Cara-interne Basis-Schlüsselprüfungen).

Aufruf von checkPublicKey() ohne templateSignerId

Wird die API-Funktion mit templateSignerId=null aufgerufen, so können keine Signer-CA- oder Template-spezifischen Einstellungen (wie bspw. Lint-Settings) berücksichtigt werden und es kommen daher grundsätzlich nur Cara-interne Schlüsselprüfungen zur Anwendung. Längenprüfungen für RSA-Modulus und Exponent, wie sie in einem Zert.-Template anzugeben wären, finden in diesem Fall nicht statt. Über den API-Aufrufparameter forceCheckBaselineRequirements=true können die „erweiterten“ Cara-internen Schlüsselprüfungen aktiviert werden (siehe Erweiterte Cara-interne Schlüsselprüfungen), ansonsten gelten die CARA-internen Basis-Schlüsselprüfungen (siehe Cara-interne Basis-Schlüsselprüfungen).

Cara-interne Basis-Schlüsselprüfungen

  • RSA: Längenprüfung von Modulus und Exponent gemäß Angaben im Zert.-Template

  • RSA: ROCA Vulnerability Test

  • ECC: Prüfung, ob Public Point auf der Kurve liegt

Erweiterte Cara-interne Schlüsselprüfungen

Erweiterte Cara-interne Schlüsselprüfungen für RSA

  • Cara-interne Basis-Schlüsselprüfungen

  • Modulus muss min. 2048 Bit Länge aufweisen

  • Modulus-Länge muss durch 8 teilbar sein

  • Modulus muss ungerade sein

  • Public Exponent muss ungerade sein

  • Public Exponent muss mindestens 216+1 betragen

  • Public Exponent darf nicht größer sein als 2256-1

  • Modulus darf durch keine Primzahl < 752 teilbar sein.

  • FIPS 186-4 C.3.2 Enhanced Miller-Rabin Probabilistic Primality Test (80 Iterationen);

  • Modulus muss „composite“ sein und darf keine Potenz einer Primzahl sein.

Erweiterte Cara-interne Schlüsselprüfungen für ECC

  • Cara-interne Basis-Schlüsselprüfungen

  • Es müssen EC-Domainparameter im Schlüssel vorhanden sein

  • Die EC-Domainparameter müssen eine Kurve definieren

  • Die Koordinaten des Public Points müssen normiert sein gemäß ANSI X9.62.

  • Der Public Point darf nicht der unendlich ferne Punkt der Kurve sein.

  • Der Public Point muss ein Vielfaches des Generatorpunkts der Kurve sein.

Weitere Schlüsselqualitätsprüfungen wie bspw. „Debian Weak Keys“, „Prohibited Keys“ oder „ECC Key Compression“ sind nicht als Cara-interne Prüfung, sondern nur über den Lint-Server verfügbar. Siehe hierzu in [MTG-CARA-CertLintServer-Installationshandbuch].

Audit-Event-Typen

Mit dem quality-Element und der Cara-internen Schlüsselprüfung gehen zwei weitere Audit-Event-Typen einher, die jeweils Statusinformationen zur Cara-internen Schlüsselüberprüfung beinhalten (siehe auch [Technische_ Dokumentation]):

  • REQUEST_PUBLIC_KEY_INTERNAL_CHECKS_FAILED (124)

  • REQUEST_PUBLIC_KEY_INTERNAL_CHECKS_PASSED (125)

Die entsprechenden Event-Typen werden ausgelöst, je nachdem, ob die Schlüsselprüfung negativ oder positiv ausgefallen ist. Dies gilt sowohl für die „Cara-internen Basis-Schlüsselprüfungen“ als auch für die „Erweiterten Cara-internen Schlüsselprüfungen“ gleichermaßen.

Die Event-Typen werden ausschließlich im Zusammenhang einer Cara-internen Schlüsselprüfung ausgelöst. Hierzu muss das quality-Element in dem Zertifikats-Template definiert sein.

Die in den Events enthaltenen Protokollinformationen können in den Frontends in den entsprechenden Ereignistabellen (Historie) der Requests bzw. Zertifikate eingesehen werden.

Im Falle einer positiven Schlüsselüberprüfung wird ein Zertifikat generiert. Die Events können dann in den entsprechenden Frontends sowohl über das Zertifikat als auch über den Request eingesehen werden. Fällt die Schlüsselprüfung negativ aus, wird kein Zertifikat generiert. In diesem Fall kann das Event nur über den Request eingesehen werden.

Im Folgenden sind zwei Beispiele von Eventinformationen aufgelistet.

Beispiel für erfolgreiche „Cara-interne Basis-Schlüsselprüfung“:

requestData.id: 3995459, extendedQualityCheck: false, passed: true, quality: [rsa:[exp:[minLen:16,maxLen:null]mod:[minLen:2048,maxLen:4096]]

Beispiel für fehlgeschlagene „Erweiterte Cara-interne Schlüsselprüfung“:

requestData.id: 3996054, extendedQualityCheck: true, passed: false, Failed extended check: RSA Quality check: Modulus size must be divisible by 8, quality: [rsa:[exp:[minLen:16,maxLen:null]mod:[minLen:2048,maxLen:4096]]

cvValueType

Dieser XML-Elementtyp wird zur Definition von Werten in CV-Zertifikaten verwendet. Ein Wert kann dabei auf mehrere Arten definiert werden. Die einzelnen Möglichkeiten sind in der folgenden Tabelle beschrieben.

Unterelemente

Unterelemente des XML-Elements „cvValueType“
Element-Name Erläuterung

BCD

Der Wert wird als Binary Coded Decimal (BCD) kodiert, d.h. seine Hex-Darstellung entspricht dem Integer-Wert.

Es dürfen nur ganzzahlige Werte angegeben werden.

Optional kann eine Länge angegeben werden. Sollte der kodierte Wert nicht die definierte Länge haben, werden führende Nullen hinzugefügt oder entfernt.

Beispiel:

<BCD>
    <length>2</length>
    <identName>o</identName>
    <default>10</default>
</BCD>

Der Wert kann dynamisch oder statisch über den Elementtyp „valueType“ (siehe in valueType) festgelegt werden. Das XML-Element counter wird hier nicht unterstützt.

ASCII

Der Wert wird in Form eines ASCII-Strings definiert und mit dem entsprechenden ASCII-Wert übernommen.

Wenn das Feld length vorhanden und der Parameter fillingCharacter definiert sind, wird der Wert auf die angegebene Länge erweitert, indem der fillingCharacter entsprechend oft am Anfang eingefügt wird.

Beispiel:

<ASCII fillingCharacter="0">
    <length>5</length>
    <identName>Sequence Number</identName>
</ASCII>

Der Wert kann dynamisch oder statisch über den Elementtyp „valueType“ (siehe in valueType) festgelegt werden.

Hex

Der Wert wird in Form eines Hexadezimalen Strings definiert und entsprechend übernommen.

Beispiel:

<Hex>
    <default>10</default>
</Hex>

Der Wert kann dynamisch oder statisch über den Elementtyp „valueType“ (siehe in valueType) festgelegt werden. Das XML-Element counter wird hier nicht unterstützt.

Nibble

Der Wert wird in Form eines Nibbles definiert und entsprechend übernommen. Ein Nibble entspricht 4 Bits. Die Definition erfolgt mit den beiden Unterelemente firstPart und secondPart. Ein Part kann hexadezimal oder BCD-kodiert angegeben werden. Die Kodierung entspricht den oben beschriebenen XML-Elementen BCD und Hex.

Der Wert eines Parts darf nicht größer als 127 oder 0x79 sein.

Beispiel:

<Nibble>
    <firstPart>
        <Hex><default>05</default></Hex>
    </firstPart>
    <secondPart>
        <BCD><default>01</default></BCD>
    </secondPart>
</Nibble>

validFrom

Mit diesem XML-Element kann der Gültigkeitsbeginn des Schlüssels verwendet werden. Datum und Uhrzeit werden in einen String umgewandelt und dann BCD-kodiert in das Zertifikat geschrieben.

Das Format der Zeitangabe muss mit Hilfe des Attributs pattern spezifiziert werden. Die Definition des Pattern entspricht der von der Java-Klasse java.text.SimpleDateFormat verwendeten.

Beispiel:

<validFrom pattern="yy" />

validTo

Mit diesem XML-Element kann der Gültigkeitsbeginn des Schlüssels verwendet werden. Datum und Uhrzeit werden in einen String umgewandelt und dann BCD-kodiert in das Zertifikat geschrieben.

Das Format der Zeitangabe muss mit Hilfe des Attributs pattern spezifiziert werden. Die Definition des Pattern entspricht der von der Java-Klasse java.text.SimpleDateFormat verwendeten.

Beispiel:

<validTo pattern="yyMM"/>

BitField

Der Wert wird in Form eines Bit-Strings definiert. Im String sind nur die Zeichen 0 und 1 erlaubt. Alternativ kann ein einzelnes Bit in Form eines boolean (true oder false) definiert werden. Aus der Definition wird der Integer-Wert erzeugt und verwendet. Die Länge entspricht dem angegebenen Wert, aufgerundet auf ganze Bytes.

Beispiel:

<BitField>
    <bits><default>0000</default></bits>
    <bits><identName>id.readAccessBits</identName></bits>
    <bit>false</bit>
</BitField>

Der Wert von bits wird als valueType definiert (siehe valueType). Das XML-Element length wird nicht unterstützt.

cvDataObjectType

Dieser XML-Elementtyp wird zur Definition von ein oder mehreren DataObject in der CV-Extension genericExtension (Siehe GenericExtension) verwendet.

Attribute

Attribute des XML-Elements „cvDataObjectType“

Attributname

Erläuterung

mandatory

Gibt an, ob für das jeweiligen DataObject über die im Unterelement content gemachten Angaben ein Wert generiert werden muss oder nicht.

Gültige Werte sind true und false. Die Angabe ist optional. Als Standard wird true verwendet.

Wird true angegeben, so wird bei einem leeren Wert eine Exception geworfen und das Zertifikat kann nicht generiert werden.

Wird false angegeben so wird das jeweilige DataObject nicht in die Extension übernommen.

Kann für die Extension kein DataObject erzeugt werden, wird ebenfalls eine Exception geworfen und das Zertifikat kann nicht generiert werden.

Unterelemente

Unterelemente des XML-Elements „cvDataObjectType“
Element-Name Erläuterung

tag

Gibt die Tag-Nummer des DataObjects an.

Es dürfen nur ganzzahlige Werte angegeben werden.

Der Wert wird in Form eines Hexadezimalen Strings definiert und entsprechend übernommen.
Der Element muss immer angegeben werden.

Beispiel:

<tag>80</tag>

content

Der Wert wird in Form eines Hexadezimalen Strings definiert und entsprechend übernommen.

Die Definition erfolgt mit dem Unterelement Hex, der immer mit angegeben werden muss.

Beispiel:

<content>
    <Hex>
        <default>10</default>
    </Hex>
</content>

Der Wert kann dynamisch oder statisch über den Elementtyp „valueType“ (siehe in valueType) festgelegt werden. Das XML-Element counter wird hier nicht unterstützt.