X.509-Extensions

Von MTG-CARA werden die in diesem Kapitel beschriebenen X.509-Extensions unterstützt. Weiterführende Informationen zu X.509-Extensions können z.B. dem [RFC X.509] entnommen werden.

Alle Extensions werden innerhalb des Elements <extensions> definiert. Jede einzelne Extension wird innerhalb des Elements <extension> definiert.

Damit ergibt sich folgender Aufbau:

<extensions>
    <extension>...</extension>
    <extension>...</extension>
    ...
</extensions>

Für das Element <extension> können folgende Attribute verwendet werden:

Attribute des XML-Elements „extension“
Attributname	Erläuterung
`critical`	Markiert eine Extension als critical. Gültige Werte sind `true` und `false`. Die Angabe ist optional. Als Standard wird `false` verwendet.

Beispiel:

<extension critical="true"></extension>

Für alle Extensions kann das optionale XML-Element <skip> verwendet werden.

Unterelemente

Allgemeine Unterelemente des XML-Elements „extension“
Element-Name	Erläuterung
`skip`	Gibt an, ob die Extension für das X.509 Zertifikat gebildet werden soll oder nicht. Der Wert muss `true` sein, um das die Extension nicht zu bilden. Wird das Element nicht angegeben oder es hat einen anderen Wert als `true`, wird die Extension gebildet. Wert des XML-Elements: valueType (siehe ValueType). Das Element ist optional.

Beispiel:

<extension>
    <skip><identName>id.skip</identName></skip>
    ...
</extension>

Alle möglichen X.509-Extensions werden in den folgenden Unterkapiteln beschrieben.

Key-Usage

Die X.509-Extension „Key-Usage“ (OID: 2.5.29.15) legt den Verwendungszweck des Schlüssels fest (siehe [RFC X.509]).

Im Template wird die „Key Usage“ über das XML-Element <keyUsage> beschrieben. Der Verwendungszweck wird durch Angabe des betreffenden Attributes, welches auf den Wert „true“ gesetzt wird, zugewiesen.

Für jeden Wert aus dem RFC kann ein Attribut gesetzt werden. Die exakten Namen der Attribute sind in [TECH_DOK] zu finden.

Beispiel

<extension>
    <keyUsage digitalSignature="true" nonRepudiation="true" />
</extension>

Authority-Key-Identifier

Die X.509-Extension „Authority-Key-Identifier“ (OID: 2.5.29.35) identifiziert den Schlüssel des Ausstellers (siehe [RFC X.509]).

Im Template wird die Extension über das XML-Element <authorityKeyIdentifier> beschrieben.

Unterelemente

Unterelemente des XML-Elements „authorityKeyIdentifier“
Element-Name	Erläuterung
`keyIdentifier`	Wenn dieses Element vorhanden ist, dann wird der keyIdentifier im Authority Key Identfier gesetzt. Das Element muss nur angegeben werden, evtl. vorhandener Inhalt wird ignoriert. Das Element ist optional.
`authorityCertIssuerAndSerialNumber`	Wenn dieses Element vorhanden ist, dann werden authorityCertIssuer und authorityCertSerialNumber im Authority Key Identifier gesetzt. Das Element muss nur angegeben werden, evtl. vorhandener Inhalt wird ignoriert. Das Element ist optional.

Beispiel:

<extension>
    <authorityKeyIdentifier><keyIdentifier/></authorityKeyIdentifier>
</extension>

Subject-Key-Identifier

Die X.509-Extension „Subject-Key-Identifier“ (OID: 2.5.29.14) identifiziert den Schlüssel des Zertifikatsnehmers (siehe [RFC X.509]).

Im Template wird die Extension über das XML-Element <subjectKeyIdentifier> beschrieben.

Diese Extension wird üblicherweise ohne Unterelemente verwendet. In diesem Fall bildet CARA den Key Identifier als SHA1-Hash über den BIT STRING SubjectPublicKeyInfo, wie in [RFC X.509] empfohlen.

Alternativ kann der Wert für diese X.509-Extension in einer CARA-Anwendung vorausberechnet werden. Hierzu muss die Anwendung den binären Wert in HEX-codierter Form als Name-Wert-Paar in den Ident-Daten des Antrags hinterlegen und im Zertifikats-Template muss das Unterelement <identName> verwendet werden.

Unterelemente

Unterelemente des XML-Elements „subjectKeyIdentifier“
Element-Name	Erläuterung
`identName`	Name eines Name-Wert-Paares aus Ident-Data, um die Extension mit einem applikationsseitig vorausberechneten Wert zu bilden (allgemeine Beschreibung dieser Unterelemente siehe ValueType). Die Verwendung des Unterelements ist optional.

Beispiele:

<extension>
    <subjectKeyIdentifier/>
</extension>

<extension>
    <subjectKeyIdentifier>
        <identName>id.customSKI</identName>
    </subjectKeyIdentifier>
</extension>

CRL-Distribution-Points

Die X.509-Extension „CRL-Distribution-Points“ (OID: 2.5.29.3) legt Verteilungspunkte für Sperrlisten fest (siehe [RFC X.509]).

Die Definition eines CRL-Distribution-Points kann auf zwei Arten gemacht werden, eine vereinfachte Form und eine vollständige Form.

Vereinfachte Definition

Die vereinfachte Form ermöglicht das Setzen eines CRL-DPs gemäß [RFC X.509] in der Form

    distributionPoint
        fullName
            uniformResourceIdentifier

Im Template wird die Extension über das XML-Element <crlDistributionPoint> beschrieben.

Unterelemente

Unterelemente des XML-Elements „crlDistributionPoint“
Element-Name	Erläuterung
`URL`	Festlegung eines CRL-DPs. Das Element kann einen oder mehrere Unterelemente vom Typ `<part>` enthalten. Der gesamte Distribution-Point wird aus diesen Teilen zusammengesetzt, wobei die Reihenfolge in der Definition eingehalten wird. Aufbau: `<URL> <part>...</part> <part>...</part> ... </URL>` Die möglichen Werte innerhalb von `<part>` sind in Unterelemente des XML-Elements „part“ beschrieben.

Unterelemente des XML-Elements „part“
Name des Unterelements	Erläuterung
`identName`	Die Verwendung wird in ValueType beschrieben. Die Angabe ist optional.
`default`	Die Verwendung wird in ValueType beschrieben. Die Angabe ist optional.
`issuer`	Mit diesem Unterelement kann der IssuerDN des auszustellenden Zertifikats in den CRL-DP übernommen werden. Die Angabe ist optional. Für das Element können Attribute gesetzt werden, siehe Attribute von „issuer“. In Version 1.19.2 wurde das Verhalten des CARA-Servers für dieses Unterelement angepasst. In den Vorversionen wurde der IssuerDN des CA-Zertifikats herangezogen.
`aki`	Mit diesem Unterelement kann der Authority Key Identifier (AKI) des auszustellenden Zertifikats (d.h. der Subject Key Identifier (SKI) des Aussteller-Zertifikats) in den CRL-DP übernommen werden. Der AKI wird in hexadezimaler Form in Kleinschreibung in die URL übernommen. Die Angabe ist optional.

Attribute von „issuer“
Attribute für „Issuer“	Erläuterung
`reverseOrder`	Hiermit kann die Reihenfolge der Werte im Subject-DN des Issuers umgekehrt werden. Mögliche Werte sind `true` und `false`. Bei `true` werden die Attribute im Subject-DN in umgekehrter Reihenfolge in den CRL-DP geschrieben, bei `false` in der existierenden Reihenfolge. Als Standard wird `false` verwendet. Die Angabe ist optional.
`encoding`	Hiermit wird das Encoding des Subject-DN definiert. Der DN-String wird zuerst in einen standardisierten Text umgewandelt, z.B. C=DE,O=Company,CN=CA 01 Durch Angabe der Kodierung werden Sonderzeichen `escaped`. Mögliche Werte sind in Werte für „encoding“ beschrieben.
`dnAttribute`	Mit diesem Parameter kann ein einzelnes DN-Attribut des Issuer-DN-Strings verwendet werden. Als Wert muss die OID des DN-Attributs angegeben werden, z.B. 2.5.4.3 für den CommonName.

Werte für „encoding“
encoding	Erläuterung
`http`	Alle Sonderzeichen gemäß HTTP werden kodiert, indem ein Zeichen ersetzt wird durch `&<ASCII-Code>`, z.B. wird `=` ersetzt durch `&3D`. Folgende Zeichen werden ersetzt: `blank = , # ; ? : & @ " \ %`
`ldap`	Alle Sonderzeichen gemäß LDAP werden kodiert, indem ein Zeichen ersetzt wird durch `&<ASCII-Code>`, z.B. wird `=` ersetzt durch `&3D`. Folgende Zeichen werden ersetzt: `blank # ; : @ " \ %`

Beispiel

<extension>
<crlDistributionPoint>
    <URL>
        <part><default>http://www.MTG.de/crl/</default></part>
        <part><issuer reverseOrder="true" encoding="http"/></part>
    </URL>
    <URL>
        <part><default>http://www.MTG.de/crl/</default></part>
        <part><aki/></part>
    </URL>
    <URL>
        <part><default>ldap://ldap.MTG.de/CN=CA%2001,O=mtG,C=DE?certificateRevocationList</default></part>
    </URL>
</crlDistributionPoint>
</extension>

Vollständige Definition

Im Template wird die Extension über das XML-Element <crlDistributionPoints> beschrieben. Innerhalb dieses Elements können mehrere Verteilungspunkte angegeben werden. Ein einzelner Verteilungspunkt wird über das XML-Element <crlDistributionPoint> beschrieben.

Mit diesem Element können alle Varianten definiert, die im [RFC X.509] beschrieben sind.

Eine genaue Beschreibung der Unterelemente und Attribute ist in [TECH_DOK] zu finden.

Beispiel:

<extension>
<crlDistributionPoints>
    <crlDistributionPoint>
        <distributionPoint>
        <fullName>
            <generalName>
                <URIType><default>http://...</default></URIType>
            </generalName>
            <generalName>
                <URIType><default>ldap://...</default></URIType>
            </generalName>
        </fullName>
        </distributionPoint>
        <reasons    keyCompromise="true"
                    superseded="true"
                    certificateHold="true" />
    </crlDistributionPoint>
</crlDistributionPoints>
</extension>

Extended-Key-Usage

Die X.509-Extension „Extended-Key-Usage“ (OID: 2.5.29.37) legt weitere Verwendungszwecke (siehe auch [RFC X.509]) für den Zertifikatsschlüssel festgelegt.

Im Template wird die Extension über das XML-Element <extendedKeyUsage> beschrieben.

Über Attribute des XML-Elements können vordefinierte Usages gesetzt werden. Eine Auflistung der Usages ist in [TECH_DOK] zu finden.

Unterelemente

Unterelemente des XML-Elements „extendedKeyUsage“
Element-Name	Erläuterung
`keyPurposeId`	Mit diesem Unterelement können ein oder mehrere OIDs als ExtendedKeyUsage gesetzt werden. Die OID wird mit Hilfe des globalen Datentyps valueType definiert (siehe ValueType). Die Verwendung ist optional.

Beispiel

<extension>
    <extendedKeyUsage clientAuth="true">
        <keyPurposeId><default>1.2.3.4</default></keyPurposeId>
    </extendedKeyUsage>
</extension>

Authority-Information-Access

Über die X.509-Extension „Authority-Information-Access“ (OID: 1.3.6.1.5.5.7.1.1) können Ort und Format weiterer Informationen, welche vom Zertifikatsaussteller zur Verfügung gestellt werden, angegeben werden (siehe auch [RFC X.509]).

Im Template wird die Extension über das XML-Element <authorityInfoAccess> beschrieben. Dieses Element besitzt genau ein Unterelement: <accessMethod>. Dieses Unterelement kann mehrfach verwendet werden. Die darin erlaubten Unterelemente sind in Unterelemente des XML-Elements „accessMethod“ beschrieben.

Unterelemente

Unterelemente des XML-Elements „accessMethod“
Name des Unterelements	Erläuterung
`OCSP`	Es wird eine AccessDescription für OCSP verwendet (OID 1.3.6.1.5.5.7.48.1). Der im XML-Element enthaltene Wert wird als URI kodiert.
`caIssuers`	Es wird eine AccessDescription für caIssuers verwendet (OID 1.3.6.1.5.5.7.48.2). Der im XML-Element enthaltene Wert wird als URI kodiert.

Beispiel

<extension>
    <authorityInfoAccess>
        <accessMethod>
            <OCSP>http://ocsp.MTG.de/ocspr</OCSP>
        </accessMethod>
    </authorityInfoAccess>
</extension>

Basic-Constraints

Die X.509-Extension „Basic-Constraints“ (OID: 2.5.29.19) legt fest, ob das Zertifikat ein CA-Zertifikat ist. Weiterhin kann im Falle eines CA-Zertifikats die maximale Pfadlänge angegeben werden (siehe auch [RFC X.509]).

Im Template wird die Extension über das XML-Element <basicConstraints> beschrieben.

Attribute

Attribute des XML-Elements „basicConstraints“
Attributname	Erläuterung
`ca`	Definiert ob es sich um ein CA-Zertifikat handelt. Mögliche Werte sind `true` und `false`. Die Angabe ist Pflicht.
`pathLen`	Gibt die maximale Pfadlänge an.

Beispiel

<extension>
    <basicConstraints ca="true" pathLen="2"/>
</extension>

Certificate-Policies

Die X.509-Extension „Certificate-Policies“ (OID: 2.5.29.32) legt Informationen zur Certificate Policy fest (siehe auch [RFC X.509]).

Im Template wird die Extension über das XML-Element <certificatePolicies> beschrieben.

Es wird die Struktur aus dem [RFC X.509] unterstützt. Eine genaue Definition der Elemente und Attribute ist in [TECH_DOK] zu finden.

Die Struktur für UserNotice wird zurzeit nicht unterstützt.

Beispiel

<extension>
<certificatePolicies>
    <policyInformation>
        <policyId><default>1.3.36.5.2.1</default></policyId>
        <qualifiers>
            <info>
            <CPS><default>http://www.MTG.de/download/cp.pdf</default></CPS>
            </info>
        </qualifiers>
    </policyInformation>
</certificatePolicies>
</extension>

Subject-Alternative-Name

Über die X.509-Extension „Subject-Alternative-Name“ (OID: 2.5.29.17) können alternative Namen für den Zertifikatsbesitzer angegeben werden (siehe auch [RFC X.509]).

Im Template wird die Extension über das XML-Element <subjectAltName> beschrieben.

Unterelemente

Unterelemente des XML-Elements „subjectAltName“
Name des Unterelements	Erläuterung
`caaCheckDnsNames`	Optional. Ist das CARA CAA-Modul installiert, so können hiermit DNS-CAA-Prüfungen für die `generalName`-Elemente des Typs dnsNameType gesteuert werden. Siehe hierzu auch `[Modulhandbuch_CAA]`. Ist dieses Element nicht vorhanden, so gelten die CAA-Prüfungen als aktiviert. Damit die Prüfungen tatsächlich durchgeführt werden, müssen sie zusätzlich auch in der Certification Authority aktiviert sein. Das Element benötigt das untergeordnete XML-Element `enabled`.
`publicSuffixList`	Optional. Ist das CARA Public Suffix List-Modul installiert, so können hiermit Public Suffix List-Prüfungen für die `generalName`-Elemente des Typs `dnsNameType` gesteuert werden. Dies betrifft ausschließlich Einträge mit Wildcard; siehe hierzu auch `[Modulhandbuch_PublicSuffixList]`. Ist dieses Element nicht vorhanden, so gelten die Public Suffix List-Prüfungen als aktiviert. Damit die Prüfungen tatsächlich durchgeführt werden, müssen sie zusätzlich auch in der Certification Authority aktiviert sein. Das Element benötigt das untergeordnete XML-Element `enabled`.
`generalName`	Hiermit können die gängigen Varianten von GeneralName definiert werden. Details dazu sind in `[TECH_DOK]` zu finden.

Unterelemente des Elements „caaCheckDnsNames“

Unterelemente des XML-Elements „caaCheckDnsNames“
Name des Unterelements	Erläuterung
`enabled`	Mandatory innerhalb von `caaCheckDnsNames`. Dieses Element muss den Text-Inhalt „`true`“ oder „`false`“ aufweisen. Der Datentyp ist `valueType` (siehe ValueType), sodass der Inhalt mittels `<default>` und/oder mittels `<identName>` gebildet werden kann. Jeder von „`true`“ verschiedene Wert (Groß-/Kleinschreibung egal) gilt als „`false`“.

Unterelemente des Elements „publicSuffixList“

Unterelemente des XML-Elements „publicSuffixList“
Name des Unterelements	Erläuterung
`enabled`	Mandatory innerhalb von `publicSuffixList`. Dieses Element muss den Text-Inhalt „`true`“ oder „`false`“ aufweisen. Der Datentyp ist `valueType` (siehe ValueType), sodass der Inhalt mittels `<default>` und/oder mittels `<identName>` gebildet werden kann. Jeder von „`true`“ verschiedene Wert (Groß-/Kleinschreibung egal) gilt als „`false`“.

Beispiel Subject-Alternative-Name

<extension>
    <subjectAltName>
        <!-- Keine CAA-Prüfungen bei Verwendung dieses Templates -->
        <caaCheckDnsNames>
            <enabled>
                <default>false</default>
            </enabled>
        </caaCheckDnsNames>
        <!-- Keine Public Suffix List-Prüfungen bei Verwendung dieses Templates -->
        <publicSuffixList>
            <enabled>
                <default>false</default>
            </enabled>
        </publicSuffixList>
        <generalName>
            <rfc822NameType><identName>email</identName></rfc822NameType>
        </generalName>
        <generalName>
            <dnsNameType><identName>serverName</identName></dnsNameType>
        </generalName>
        <generalName>
            <ipAddressType><identName>ipAddress</identName></ipAddressType>
        </generalName>
    </subjectAltName>
</extension>

Restriction

Die X.509-Extension „Restriction“ (OID: 1.3.36.8.3.8) legt fest, dass der Schlüssel nur zur Signatur verwendet wird. Diese Extension wird in [TTT-PKI] definiert.

Im Template wird die Extension über das Element <restriction> spezifiziert. Von MTG-CARA wird nur die Kodierung des directory-Strings als UTF-8-String unterstützt. Details zur Definition sind in [TECH_DOK] zu finden.

Beispiel

<extension>
    <restriction>
        <utf8String><default>Demo</default></utf8String>
    </restriction>
</extension>

Additional-Information

Die X.509-Extension „Additional-Information“ (OID: 1.3.36.8.3.15) kennzeichnet den Zertifikatstyp. Diese Extension wird in [TTT-PKI] definiert.

Im Template wird die Extension über das XML-Element <additionalInformation> beschrieben. Von MTG-CARA wird nur die Kodierung des directory-Strings als UTF-8-String unterstützt. Details zur Definition sind in [TECH_DOK] zu finden.

Beispiel

<extension>
    <additionalInformation>
        <utf8String><default>1.3.6.1.4.1.24796.10.3</default></utf8String>
    </additionalInformation>
</extension>

Validity-Model

Die private X.509-Extension „Validity-Model“ (OID: 1.3.6.1.4.1.8301.3.5) kennzeichnet das Gültigkeitsmodell, das der Zertifikatsprüfung zugrunde gelegt werden muss. Die Extension ist von der Technischen Universität Darmstadt definiert worden.

Bei den Gültigkeitsmodellen kann grundsätzlich zwischen Kettenmodell und Schalenmodell unterschieden werden.

Im Template wird die Extension über das XML-Element <validityModel> beschrieben.

Attribute

Attribute des XML-Elements „validityModel“
Attributname	Erläuterung
`chain`	Als Gültigkeitsmodell wird das Kettenmodell verwendet (bei „`true`“). Gültige Werte sind `true` und `false`. Die Angabe ist optional.
`shell`	Als Gültigkeitsmodell wird das Schalenmodell verwendet (bei „`true`“). Gültige Werte sind `true` und `false`. Die Angabe ist optional.

Beispiel

<extension>
    <validityModel chain="true"/>
</extension>

Qualified-Certificate-Statements

Über die Extension „qcStatements“ (OID: 1.3.6.1.5.5.7.1.3) können „Qualified-Certificate-Statements“ angegeben werden. Die Extension ist in [RFC QCP] spezifiziert.

Im Template wird die Extension über das XML-Element <qcStatements> beschrieben. Innerhalb des Elements <qcStatements> können mehrere QCStatements über die in Unterelemente des XML-Elements „qcStatements“ enthaltenen Unterelemente festgelegt werden. Die Verwendung der Unterelemente ist optional. Mit Ausnahme des Unterelements <qcStatement> darf jedes Unterelement nur maximal einmal vorkommen. Die Verwendung der Unterelemente muss in der angegebenen Reihenfolge geschehen.

Grundsätzlich besteht ein QCStatement aus einer Statement ID (OID) und einer Statement-Info. Nur beim Unterelement <qcStatement> ist eine explizite Angabe der Statement ID notwendig. Es ist aus Gründen der Rückwärtskompatibilität enthalten, kann allerdings durch die andere Unterelemente ersetzt werden.

Unterelemente

Unterelemente des XML-Elements „qcStatements“
Element-Name	Erläuterung
`qcStatement`	Optional. StatementId muss explizit angegeben werden. Beschreibung in qcStatement.
`qcCompliance`	Optional. QcStatement mit StatementId „0.4.0.1862.1.1“. Beschreibung in qcCompliance.
`qcMonetaryLimit`	Optional. QcStatement mit StatementId „0.4.0.1862.1.2“. Beschreibung in qcMonetaryLimit.
`qcRetentionPeriod`	Optional. QcStatement mit StatementId „0.4.0.1862.1.3“. Beschreibung in qcRetentionPeriod.
`qcSSCD`	Optional. QcStatement mit StatementId „0.4.0.1862.1.4“. Beschreibung in qcSSCD.
`qcPDS`	Optional. QcStatement mit StatementId „0.4.0.1862.1.5“. Beschreibung in qcPDS.
`qcType`	Optional. QcStatement mit StatementId „0.4.0.1862.1.6“. Beschreibung in qcType.
`pds2QcType`	Optional. PSD2 QcStatement mit StatementId „0.4.0.19495.2“. Beschreibung in psd2QcType.

Die in Unterelemente des XML-Elements „qcStatements“ enthaltenen Unterelemente besitzen alle das in Gemeinsame Attribute der Unterelemente des XML-Elements „qcStatements“ beschriebene Attribut optional.

Gemeinsame Attribute der Unterelemente des XML-Elements „qcStatements“
Attributname	Erläuterung
`optional`	Definiert, ob das `QcStatement` benötigt wird oder nicht. Mögliche Werte sind `true` und `false`. Die Angabe ist optional, default ist `false`. `optional=false` → Das Zertifikat kann nicht ausgestellt werden, falls `QcStatement` nicht gebildet werden kann. Fehler. `optional=true` → Das `QcStatement` wird weggelassen, falls es nicht gebildet werden kann. Kein Fehler.

Abhängig vom Typ des QcStatements (d.h. davon, welches der in Unterelemente des XML-Elements „qcStatements“ enthaltenen Unterelemente verwendet wird), müssen verschiedene weitere Angaben gemacht werden. Grundsätzlich werden alle Werte über den Elementtyp „valueType“ (siehe ValueType) gesetzt. Die Werte können dynamisch mithilfe des <identName>-Elements definiert werden. Zusätzlich ist eine Angabe von konstanten Werten mithilfe des <default>-Elements möglich. Die Elemente <length> und <counter> werden an dieser Stelle nicht verwendet.

qcCompliance

Dieses XML-Element definiert ein QCStatement mit Statement ID „0.4.0.1862.1.1“. Das QCStatement besitzt keine Statement-Info. Es muss lediglich angegeben werden, ob das QCStatement gebildet werden soll oder nicht. Der Datentyp des XML-Elements ist „valueType“. Das QCStatement wird nur dann gebildet, wenn der Wert true beträgt. Am Vorhandensein dieses QCStatements ist zu erkennen, dass es sich bei dem Zertifikat um ein qualifiziertes Zertifikat gemäß der eIDAS-Verordnung (EU) Nr. 910/2014 handelt.

Beispiel

<qcCompliance>
    <default>true</default>
</qcCompliance>

qcMonetaryLimit

Dieses XML-Element definiert ein QCStatement mit Statement ID „0.4.0.1862.1.2“. Damit das QCStatement gebildet werden kann, müssen weitere Angaben gemacht werden. Mit diesem Element wird ein maximaler Wert festgelegt. Das Zertifikat kann nur für Transaktionen bis zu diesem Wert verwendet werden. Der Wert berechnet sich wie folgt: value = amount * 10^exponent.

Unterelemente

Unterelemente des XML-Elements „qcMonetaryLimit“
Element-Name	Erläuterung
`currency`	Währung, für die der definierte Maximalwert gilt. Der Datentyp ist „valueType“ (siehe ValueType). Als Wert wird ein ISO 4217 Währungscode erwartet, d.h. drei Großbuchstaben, z.B. „EUR“ oder „USD“.
`amount`	Betrag. Der Datentyp ist „valueType“ (siehe ValueType). Als Wert wird eine Zahl erwartet. Wenn das Element `exponent` nicht angegeben wird und die Währung Euro ist, handelt sich es hier um eine Angabe in Cent.
`exponent`	Exponent. Der Datentyp ist „valueType“ (siehe ValueType). Als Wert wird eine Zahl erwartet. Dieses Element ist optional. Wenn es nicht angegeben wird, wird der Wert „-2“ verwendet.

Beispiel

<qcMonetaryLimit>
    <currency><default>EUR</default></currency>
    <amount><default>10000</default></amount>
</qcMonetaryLimit>

qcRetentionPeriod

Dieses XML-Element definiert ein QCStatement mit Statement ID „0.4.0.1862.1.3“. Damit das QCStatement gebildet werden kann, muss lediglich eine Anzahl an Jahren angegeben werden. Sie gibt an, wie lange zusätzliche Informationen zum Zertifikat bzw. dessen Inhaber nach Ablauf der Gültigkeit des Zertifikats von der CA aufbewahrt werden. Der Datentyp des XML-Elements ist „valueType“. Als Wert wird eine Zahl erwartet.

Beispiel

<qcRetentionPeriod>
    <default>5</default>
</qcRetentionPeriod>

qcSSCD

Dieses XML-Element definiert ein QCStatement mit Statement ID „0.4.0.1862.1.4“. Das QCStatement besitzt keine Statement-Info. Es muss lediglich angegeben werden, ob das QCStatement gebildet werden soll oder nicht. Der Datentyp des XML-Elements ist „valueType“. Das QCStatement wird nur dann gebildet, wenn der Wert true beträgt. Am Vorhandensein dieses QCStatements ist zu erkennen, dass der private Schlüssel, der zu dem im Zertifikat enthaltenen öffentlichen Schlüssel gehört, in einem Secure Signature Creation Device (SSCD) aufbewahrt wird.

Beispiel

<qcSSCD>
    <default>true</default>
</qcSSCD>

qcPDS

Dieses XML-Element definiert ein QCStatement mit Statement ID „0.4.0.1862.1.5“. Damit das QCStatement gebildet werden kann, müssen weitere Angaben gemacht werden. Innerhalb des Elements <qcPDS> können mehrere PKI Disclosure Statements (PDS) Locations über das Unterelement <pdsLocation> angegeben werden.

Unterelemente

Unterelemente des XML-Elements „pdsLocation“
Element-Name	Erläuterung
`url`	URL unter der das PDS der entsprechenden Sprache gefunden werden kann. Der Datentyp ist „valueType“ (siehe ValueType).
`language`	Sprache, in der das PDS geschrieben ist. Der Datentyp ist „valueType“ (siehe ValueType). Als Wert wird ein ISO 639-1 Sprachcode erwartet, d.h. zwei Kleinbuchstaben, z. B. „de“ oder „en“.

Beispiel

<qcPDS>
    <pdsLocation>
        <url><default>https://example.com/de/test.pdf</default></url>
        <language><default>de</default></language>
    </pdsLocation>
    <pdsLocation>
        <url><default>https://example.com/en/test.pdf</default></url>
        <language><default>en</default></language>
    </pdsLocation>
</qcPDS>

qcType

Dieses XML-Element definiert ein QCStatement mit Statement ID „0.4.0.1862.1.6“. Damit das QCStatement gebildet werden kann, müssen weitere Angaben gemacht werden. Mit diesem Element wird angegeben, zu welchem Zweck das Zertifikat verwendet werden darf. Es darf entweder für elektronische Signaturen (esign) ODER für elektronische Siegel (eseal) ODER zur Authentifizierung von Webseiten (web) verwendet werden. Ferner ist die Angabe weiterer Verwendungszwecke in Form von OIDs möglich.

Unterelemente

Unterelemente des XML-Elements „qcType“
Element-Name	Erläuterung
`type`	Optional. Der Datentyp ist „valueType“ (siehe ValueType). Es wird `esign`, `eseal` oder `web` erwartet.
`oid`	Optional. Der Datentyp ist „valueType“ (siehe ValueType). Als Wert wird eine OID erwartet.

Beispiel

<qcType>
    <type><default>eseal</default></type>
</qcType>

psd2QcType

Dieses XML-Element definiert ein Payment Services Directive 2 (PSD2) QCStatement mit Statement ID „0.4.0.19495.2“. Damit das QCStatement gebildet werden kann, müssen weitere Angaben gemacht werden. Innerhalb des Elements <psd2QcType> können einem Payment Service Provider (PSP) mit dem Unterelement <rolesOfPSP> ein oder mehrere Rollen zugewiesen werden. Ein PSP ist bei der einer National Competent Authority (NCA) registriert, deren Name und ID ebenfalls Teil des QCStatements sind.

Unterelemente

Unterelemente des XML-Elements „psd2QcType“
Element-Name	Erläuterung
`rolesOfPSP`	Rollen des Payment Service Providers. Innerhalb des Unterelements muss jede Rolle über das Unterelement `<role>` angegeben werden. Der Datentyp ist „valueType“ (siehe ValueType). Als jeweiliger Wert wird eine der folgenden vier Rollen erwartet: `PSP_AS` ( account servicing ) `PSP_PI` (payment initiation) `PSP_AI` (account information) `PSP_IC` (issuing of card-based payment instruments)
`nCAName`	Name der NCA. Der Datentyp ist „valueType“ (siehe ValueType).
`nCAId`	ID der NCA. Der Datentyp ist „valueType“ (siehe ValueType).

Beispiel

<psd2QcType>
    <rolesOfPSP>
        <role><default>PSP_AS</default></role>
    </rolesOfPSP>
    <nCAName>Name</nCAName>
    <nCAId>ID</nCAId>
</psd2QcType>

qcStatement

Innerhalb des Elements <qcStatements> können mehrere qcStatements über das XML-Element <qcStatement> festgelegt werden.

Die Verwendung des Elements <statementInfo> ist optional. Es hängt von der konkreten OID ab, ob <statementInfo> benötigt wird oder nicht. Das Verhalten bei fehlendem oder leerem statementInfo kann über die Attribute „optional“ und „mandatory“ festgelegt werden (s.u.).

Ebenfalls von der OID abhängig ist die ASN.1-Struktur von <statementInfo>. Die diversen Varianten werden nicht von Cara erzeugt, sondern müssen in der VCA gebildet werden und sind als base64-String in den Ident-Daten des Requests zu hinterlegen.

Der Wert des XML-Elements „statementInfo“ wird über den Elementtyp „valueType“ (siehe ValueType) gesetzt. Deshalb kann anstelle von (oder zusätzlich zu) <identName> auch <default> verwendet werden. Die Elemente <length> und <counter> werden von qcStatementInfo nicht verwendet.

Attribute

Attribute des XML-Elements „statementInfo“
Attributname	Erläuterung
`mandatory`	Definiert, ob das `QcStatement` bei leerem `statementInfo` gebildet werden kann. Mögliche Werte sind `true` und `false`. Die Angabe ist optional, default ist `false`. `mandatory=true` → Das `QcStatement` kann bei leerem `statementInfo` nicht gebildet werden. `mandatory=false` → Das `QcStatement` wird ggf. ohne `statementInfo` gebildet und beschränkt sich auf die OID.

Details sind in [TECH_DOK] zu finden.

Beispiel 1

<extension>
    <qcStatements>
        <qcStatement>
            <statementId><oid>0.4.0.1862.1.1</oid></statementId>
        </qcStatement>
        <qcStatement>
            <statementId><oid>0.4.0.1862.1.2</oid></statementId>
                <statementInfo>
                    <identName>id_qc_monetary_limit</identName>
                </statementInfo>
        </qcStatement>
    </qcStatements>
</extension>

In diesem Beispiel ist für das erste QcStatement die OID ohne statementInfo ausreichend.

Im zweiten qcStatement wird statementInfo benötigt und hat den Typ QcEuLimitValue. Somit ist die folgende ASN.1-Struktur von der VCA zu bilden und base64-kodiert als id_qc_monetary_limit in den ident-Daten zu hinterlegen:

QcEuLimitValue ::= MonetaryValue
MonetaryValue::= SEQUENCE {
    currency Iso4217CurrencyCode,
    amount INTEGER,
    exponent INTEGER
    }
-- value = amount * 10^exponent
Iso4217CurrencyCode ::= CHOICE {
    alphabetic PrintableString (SIZE 3), -- Recommended
    numeric INTEGER (1..999)
    }
-- Alphabetic or numeric currency code as defined in ISO 4217
-- It is recommended that the Alphabetic form is used

Beispiel 2

<extension>
    <qcStatements>
        <qcStatement optional="true">
            <statementId><oid>0.4.0.1862.1.2</oid></statementId>
                <statementInfo mandatory="true">
                    <identName>id_qc_monetary_limit</identName>
                </statementInfo>
        </qcStatement>
    </qcStatements>
<extension>

Bleibt hier id_qc_monetary_limit leer, wird das Zertifikat ohne qcStatement gebildet, kein Fehler.

Beispiel 3

<extension>
    <qcStatements>
        <qcStatement optional="false">
            <statementId><oid>0.4.0.1862.1.2</oid></statementId>
                <statementInfo mandatory="true">
                    <identName>id_qc_monetary_limit</identName>
                </statementInfo>
        </qcStatement>
    </qcStatements>
</extension>

Bleibt hier id_qc_monetary_limit leer, kann das Zertifikat nicht gebildet werden, Fehler.

Beispiel 4

<extension>
    <qcStatements>
        <qcStatement optional="false">
            <statementId><oid>0.4.0.1862.1.2</oid></statementId>
                <statementInfo mandatory="false">
                    <identName>id_qc_monetary_limit</identName>
                </statementInfo>
        </qcStatement>
    </qcStatements>
</extension>

Bleibt hier id_qc_monetary_limit leer, wird das qcStatement ohne statementInfo gebildet werden („nur die OID“), kein Fehler.

Beispiel 5

<extension>
    <qcStatements>
        <qcStatement optional="true">
            <statementId><oid>0.4.0.1862.1.2</oid></statementId>
                <statementInfo mandatory="false">
                    <identName>id_qc_monetary_limit</identName>
                </statementInfo>
        </qcStatement>
    </qcStatements>
</extension>

Bleibt hier id_qc_monetary_limit leer, wird das qcStatement ohne statementInfo gebildet werden („nur die OID“), kein Fehler.

Admission

Über die X.509-Extension „Admission“ (OID: 1.3.36.8.3.3) können Zertifikatsberechtigungen bzw. Zulassungen festgelegt werden. Diese Extension ist in [TTT-PKI] spezifiziert.

Im Template wird die Extension über das XML-Element <admission> beschrieben. Details sind in [TECH_DOK] zu finden.

Ein Element des ASN.1-Strukturtyps professionInfo wird nur dann gebildet, wenn mindestens eines der untergeordneten Elemente von <info> nicht leer ist. Inhalte können durch <default> oder durch <identName> gegeben sein.

Beispiel

<extension>
    <admission>
    <contentsOfAdmissions>
        <admission>
            <professionInfos>
                <info>
                    <professionItems>
                        <item>
                        <utf8String>
                        <identName>id.professionItem</identName>
                        </utf8String>
                        </item>
                    </professionItems>
                    <professionOIDs>
                        <oid><identName>id.professionOid</identName></oid>
                    </professionOIDs>
                </info>
            </professionInfos>
        </admission>
    </contentsOfAdmissions>
    </admission>
</extension>

Certificate-Template-Name

Über die X.509-Extension „Certificate-Template-Name“ (OID: 1.3.6.1.4.1.311.20.2) wird das Microsoft Zertifikats-Template spezifiziert. Die Extension enthält den BMP-Wert „DomainController“

Im Template wird die Extension über das XML-Element <certificateTemplateName> beschrieben. Der Wert des XML-Elements wird über den Elementtyp „valueType“ (siehe ValueType) gesetzt.

Beispiel

<extension>
    <certificateTemplateName>
        <default>DomainController</default>
    </certificateTemplateName>
</extension>

Private-Key-Usage-Period

Über die X.509-Extension „Private-Key-Usage-Period“ (OID: 2.5.29.16) kann eine gesonderte Nutzungsperiode für den privaten Schlüssel ins Zertifikat aufgenommen werden (siehe auch [RFC X.509]). Diese Extension wird in manchen Kontexten verwendet, um ein vorzeitiges Ende der Private-Key-Nutzung festzulegen, selbst wenn das Zertifikat an sich noch gültig ist. Während der restlichen Gültigkeitsperiode kann das Zertifikat noch eingeschränkt verwendet werden, bspw. zur Verifikation von Signaturen, weil hierbei der private Schlüssel nicht zum Einsatz kommt.

Ist die X.509-Extension „Private-Key-Usage-Period“ im Template gesetzt, so wird diese ins ausgestellte Zertifikat übernommen.

CARA berücksichtigt diese Extension auch in CA- und EE-Signer-Zertifikaten, die bereits ausgestellt sind. Bei jeder Nutzung eines Private Keys zur Erstellung einer Signatur wird geprüft, ob im verwendeten Signaturzertifikat die „Private-Key-Usage-Period“ vorhanden ist. Ist dies der Fall, darf der Schlüssel des Signaturzertifikats nur innerhalb der „Private-Key-Usage-Period“ zum Signieren verwendet werden. Dies gilt auch dann, wenn das Signaturzertifikat selbst noch gültig ist.

Neben der Signatur von Zertifikaten sind auch andere Signaturoperationen nicht mehr möglich, wenn das Ende der „Private-Key-Usage-Period“ überschritten ist. Mögliche Ausnahmen sind das Signieren von Sperrlisten und das Signieren von Daten via CARA WS-API. Für diese Signaturoperationen kann – abhängig von der jeweiligen Policy – in der CA-Konfiguration (im Admin-FE) festgelegt werden, ob sie auch außerhalb der „Private-Key-Usage-Period“ ausgeführt werden dürfen. Weitere Signaturoperationen wie z.B. das Signieren von OCSP-Responses oder das Signieren von SCEP-Nachrichten sind dagegen nur innerhalb der „Private-Key-Usage-Period“ zulässig.

Bei der Verwendung der „Private-Key-Usage-Period“ sind folgende Punkte zu beachten:

Soll ein Zertifikat ausgestellt werden, dessen validNotBefore-Datum in der Zukunft liegt, so muss nicht nur das Datum der Signaturerstellung, sondern auch das validNotBefore-Datum des auszustellenden Zertifikats innerhalb der „Private-Key-Usage-Period“ der CA liegen. Andernfalls wird das Zertifikat nicht ausgestellt.
Das validNotAfter-Datum des auszustellenden Zertifikats darf hingegen nach dem Ende der „Private-Key-Usage-Period“ der CA liegen. Im Schalenmodell darf es jedoch nicht später sein als das validNotAfter-Datum der CA.
Die „Private-Key-Usage-Period“ eines CA-Zertifikats wird auch bei der Bildung des BestBefore-Datums, welches im Admin-Frontend bei der Statusanzeige der Template-Signer angezeigt wird, berücksichtigt.

Im Template wird die Extension über das XML-Element <privateKeyUsagePeriod> beschrieben.

Unterelemente

Unterelemente des XML-Elements „privateKeyUsagePeriod“
Element-Name	Erläuterung
`period`	Gültigkeitszeitraum des Schlüssels. Der Wert wird als ValidityType (siehe ValidityType) angegeben. Die Unterstützung des XML-Attributs `useOnlyDates` wurde in Version 2.6.1 umgesetzt. Dieses Element muss genau einmal angegeben werden. notBefore wird automatisch auf den aktuellen Zeitpunkt der Zertifikatserstellung gesetzt. notAfter wird mit Hilfe der Angabe von `period` berechnet. Über die Angabe von `max` kann die maximale Private Key Usage Period begrenzt werden. Dabei ist es auch möglich, ein festes Enddatum anzugeben.

Beispiel

<extension>
<privateKeyUsagePeriod>
    <period>
        <max><year>0</year><month>2</month><day>0</day></max>
        <default><year>0</year><month>2</month><day>0</day></default>
    </period>
</privateKeyUsagePeriod>
</extension>

OCSP-NoCheck

Die Extension „OCSP-NoCheck“ (OID: 1.3.6.1.5.5.7.48.1.5) ist eine Erweiterung, welche für OCSP-Resonder-Zertifikate verwendet werden kann (siehe auch [TTT-PKI]). Ist diese Extension gesetzt, so garantiert die signierende CA die Gültigkeit des OCSP-Responder-Zertifikats während der gesamten Laufzeit. Seitens des OCSP-Clients ist in diesem Falle keine Statusabfrage bzgl. des OCSP-Responder-Zertifikats notwendig.

Im Template wird die Extension über das XML-Element <ocspNoCheck> beschrieben.

Das Element <ocspNoCheck> muss nur vorhanden sein, ein evtl. vorhandener Wert wird ignoriert.

Beispiel:

<extension><ocspNocheck/></extension>

ICAO-NameChange

Die Extension „ICAO-NameChange (OID: 1.23.136.1.1.6.1) ist eine Erweiterung, welche für CSCA-Zertifikate verwendet werden kann (siehe auch [TR-LDS-PKI]). Ist diese Extension gesetzt, so wird das CSCA-Zertifikat als „Namenswechsel-Zertifikat“ markiert.

Wenn ein CSCA Schlüsselwechsel eintritt, MUSS ein Zertifikat herausgegeben werden, das den neuen Schlüssel mit dem alten Schlüssel verlinkt, um für die vertrauenden Parteien einen sicheren Übergang zu gewährleisten. Dies wird durch die Herausgabe eines self-issued Zertifikats erreicht, wobei die Issuer- und Subject-Felder identisch sind, aber der zur Signaturprüfung verwendete Schlüssel das alte Schlüsselpaar und der zertifizierte Public Key das neue Schlüsselpaar repräsentiert.

Es wird empfohlen, dass CSCAs ihren DN nicht unnötig ändern. Wenn allerdings ein Namenswechsel notwendig ist, so kann dies den vertrauenden Parteien durch die Herausgabe eines Zertifikats mitgeteilt werden, bei dem der Issuer der alte DN und das Subject der neue DN ist. Dieses Zertifikat kann auch einen Schlüsselwechsel mitteilen, in gleicher Weise wie das self-issued Zertifikat, bei dem der Schlüssel zur Signaturprüfung das alte Schlüsselpaar und der zertifizierte Public Key das neue Schlüsselpaar repräsentiert. Zertifikate, die sowohl einen CSCA Namenswechsel als auch einen Schlüsselwechsel für diese CSCA mitteilen, sollen auch die ICAO-NameChange-Extension beinhalten, um das Zertifikat als solches zu identifizieren.

Im Template wird die Extension über das XML-Element <ocspNoCheck> beschrieben.

Das Element <ICAONameChange> muss nur vorhanden sein, ein evtl. vorhandener Wert wird ignoriert.

Beispiel:

<extension><ICAONameChange/></extension>

ICAODocumentType

Über die X.509-Extension „ICAO-DocumentType“ (OID: 1.23.136.1.1.6.1) werden die erlaubten Dokumenttypen des Document-Signers aufgelistet (siehe auch [TR-LDS-PKI]).

Im Template wird die Extension über das XML-Element <ICAODocumentType> beschrieben.

Unterelemente

Unterelemente des XML-Elements „ICAODocumentType“
Element-Name	Erläuterung
`version`	Version der Dokumententypen Wert: v0 Der Wert muss angegeben werden.
`documentType`	Erlaubter Dokumententyp des Document-Signers Das Element kann mehrmals vorkommen.

Beispiel

<extension>
<ICAODocumentType>
    <version>v0</version>>
    <documentType>P</documentType>
    <documentType>ID</documentType>
</ICAODocumentType>
</extension>

Generic-Extension

Über die „Generic-Extension“ können beliebige X.509-Extensions definiert werden. Gemäß RFC5280 ist die ASN.1-Struktur einer X.509-Extension folgendermaßen aufgebaut:

Extension ::= SEQUENCE {
    extnID OBJECT IDENTIFIER,
    critical BOOLEAN DEFAULT FALSE,
    extnValue OCTET STRING
            -- contains the DER encoding of an ASN.1 value
            -- corresponding to the extension type identified
            -- by extnID
    }

Die CARA Generic-Extension erlaubt die direkte explizite Angabe von extnID („oid“) und extnValue („value“) im Zertifikats-Template (das critical-Flag ist im übergeordneten XML-Element „extension“ anzugeben, siehe am Anfang von X.509 Extensions). Der Extension-Value muss DER-kodiert in Hex-Binary-Schreibweise angegeben werden.

Als Value sind sowohl konstante Werte als auch vom CARA-Frontend hinterlegte Ident-Daten möglich (siehe ValueType). Der Hex-Binary-String wird von CARA lediglich HEX-dekodiert und dann unverändert ins Zertifikat übernommen. Für die Bildung des Values ist entweder der Autor des Zertifikats-Templates oder das jeweilige CARA-Frontend verantwortlich.

Im Template wird die Extension über das XML-Element <genericExtension> beschrieben.

Unterelemente

Unterelemente des XML-Elements „genericExtension“
Element-Name	Erläuterung
`oid`	Der Object Identifier der Extension.
`value`	Angabe eines Werts, zum Object Identifier passend. Wert: ValueType (sieheValueType). Der Wert muss als Hex-String angegeben werden.

Beispiel

<extension critical="true">
    <genericExtension>
        <oid>1.3.6.1.4.1.311.21.10</oid>
        <value><default>300D300B06092B0601040182371513</default></value>
    </genericExtension>
</extension>

Das Beispiel bildet eine als „kritisch“ markierte X.509-Extension „APPLICATION_CERT_POLICIES“ mit der folgenden ASN.1-Struktur als Value ab:

C 0x30 [Universal 16] (Sequence) length: 13
    C 0x30 [Universal 16] (Sequence) length: 11
        P 0x06 [Universal 6] (OID) length: 9 value: 1.3.6.1.4.1.311.21.19

Issuer-Alt-Name

Die X.509-Extension „Issuer-Alt-Name“ (OID: 2.5.29.32) enthält zusätzliche Angaben zum Issuer eines Zertifikats (siehe auch [RFC X.509]).

Im Template wird die Extension über das XML-Element <issuerAltName> beschrieben.

Das XML-Element besitzt genau ein Unterelement: <generalName>. Mit diesem können die gängigen Varianten von GeneralName definiert werden. Details dazu sind in [TECH_DOK] zu finden.

Beispiel

<extension>
<issuerAltName>
    <generalName>
        <rfc822NameType><identName>issuerEmail</identName></rfc822NameType>
    </generalName>
    <generalName>
        <dnsNameType><identName>issuerDns</identName></dnsNameType>
    </generalName>
</issuerAltName>
</extension>

ctList

Über das XML-Element <ctList> wird die Anwendung von Certificate Transparency nach [RFC-CT] in MTG CARA gesteuert. Voraussetzung ist das CARA CtLog-Modul. Die Nutzung des Elements im Zertifikats-Template verursacht eine zweistufige Ausstellung des Zertifikats:

Resultat von „Stufe 1“ (Genehmigung des Requests mit Ausstellung des Zertifikats) ist ein sog. Präzertifikat. Zur Kennzeichnung enthält es automatisch eine sog. Poison-Extension, die im Template nicht angegeben werden muss.
Bei der nachfolgenden Aktivierung des Zertifikats („Stufe 2“) wird das Präzertifikat mittels MTG CARA DMZ Proxy-Server zu CT Logservern gesendet. DMZ-Proxy-Server und CT-Logserver müssen zu diesem Zeitpunkt erreichbar sein. Sobald hinreichend viele Responses der Logserver (sog. Signed Certificate Timestamps; SCTs) vorliegen, wird das endgültige Zertifikat ausgestellt. Hierzu wird der ToBeSigned-Block des Präzertifikats modifiziert. Die Poison-Extension wird entfernt und stattdessen eine ctList Extension (OID: 1.3.6.1.4.1.11129.2.4.2) an gleicher Stelle eingefügt. Ansonsten bleibt der ToBeSigned-Block unverändert. Der modifizierte ToBeSigned-Block wird anschließend mit demselben Signer signiert wie zuvor das Präzertifikat. Damit sind Ausstellung und Aktivierung des endgültigen Zertifikats abgeschlossen.

Falls aus einem Aktivierungsversuch (Stufe 2) nicht genügend SCTs hervorgehen, verbleibt das Präzertifikat in der Cara-Datenbank und die Aktivierung könnte über die CARA WS API erneut versucht werden; bereits vorhandene SCTs bleiben hierbei erhalten und es werden nur fehlende nachgefordert. Wenn keine weiteren Versuche mehr stattfinden und das endgültige Zertifikat nicht ausgestellt wird, muss das Präzertifikat manuell oder per Systemjob gesperrt werden; siehe hierzu [Modulhandbuch_CtLog].

Über das XML-Element <ctList> wird gesteuert, bei welchen Logservern das Präzertifikat zu registrieren ist und welche Akzeptanzkriterien CARA zur Bewertung der empfangenen SCTs anwenden soll. Gegenstand der Akzeptanzkriterien ist stets eine Mindestanzahl bzw. eine bestimmte Auswahl von CT-Logservern, bei denen das Präzertifikat erfolgreich registriert worden sein muss, so dass dabei jeweils ein valides SCT entsteht.

Falls die empfangenen SCTs den Akzeptanzkriterien nicht genügen, bricht CARA die Aktivierung des Zertifikats mit einer Fehlermeldung ab.

Weitere Informationen zu Certificate Transparency finden Sie im [Modulhandbuch_CtLog].

Attribute

Das XML-Element <ctList> besitzt keine Attribute.

Unterelemente

Unterelemente des XML-Elements ctList
Element-Name	Erläuterung
`logGroups`	Umschließt die Definition der Logserver. Es muss ein oder mehrere Unterelemente `<logGroup>` angegeben werden (siehe Das XML-Element `<logGroup>`). Besitzt keine Attribute und keine sonstigen Inhalte.
`minimumLogDefinitions`	Umschließt die Definition der Akzeptanzkriterien. Es muss ein oder mehrere Unterelemente `<minimumLogs>` angegeben werden (siehe Das XML-Element `<minimumLogs>`). Besitzt keine Attribute und keine sonstigen Inhalte.

Das XML-Element `<logGroup>`

Innerhalb des XML-Elements <logGroups> können ein oder mehrere <logGroup>-Elemente angegeben werden. Jedes <logGroup>-Element definiert eine Gruppe von Logservern. Die Gruppierungsmöglichkeit wurde eingerichtet, um eine gruppenspezifische Mindestanzahl von SCTs als Akzeptanzkriterium definieren zu können.

Attribute

Attribute von logGroup
Attributname	Erläuterung
`name`	Legt den Namen der Logserver-Gruppe fest. Der Name ist Pflichtfeld und wird in den Akzeptanzkriterien zur Referenzierung der Logserver-Gruppe benötigt.

Unterelemente

Unterelemente von logGroup
Element-Name	Erläuterung
`log`	Definition eines Logservers durch dessen URL, siehe Das XML-Element `<log>`

Das XML-Element `<log>`

Das Element <log> gibt die vollständige URL oder ein URL-Muster eines CT-Logservers an. Dabei muss entweder http:// oder https:// als Protokoll angegeben werden, so wie es in der Gesamtliste bekannter CT-Logs all_logs_list.json verzeichnet ist. CARA prüft für alle im Template enthaltenen CT-Log-URLs, ob sie in der Gesamtliste zu finden sind. Dies geschieht unabhängig davon, ob Temporal Sharding aktiviert ist. Das CT-Log muss in der Gesamtliste entweder den log_type „test“ besitzen oder es muss den Status „usable“ aufweisen; der zugehörige Zeitstempel des Statuswechsels muss in der Vergangenheit liegen. Das Ablaufdatum des auszustellenden Zertifikats muss innerhalb des temporal_interval des CT-Logs liegen.

Wenn nicht genügend gültige CT-Log-URLs vorliegen, um die Akzeptanzkriterien erfüllen zu können, wird die Zertifikatsausstellung abgebrochen, bevor versucht wird, die CT-Logserver zu kontaktieren. Es ist daher essenziell, dass die Log-URLs im Zertifikats-Template exakt so angegeben werden, wie sie in der Liste aufgeführt sind. Dies betrifft nicht nur das Protokoll, sondern auch die Groß-/Kleinschreibung und eventuelle Endungen. Beispielsweise muss ein in all_logs_list.json verzeichneter Schrägstrich am Ende der URL auch im Zertifikats-Template enthalten sein. Möglich ist jedoch die Verwendung von bis zu zwei Platzhaltern in Verbindung mit dem XML-Attribut temporalSharding="true", siehe hierzu Attribute des Elements log.

Für den Inhalt des Elements gelten die Angaben des Datentyps valueType (siehe ValueType), d.h. es kann über das Unterelement <default> ein Standardwert angegeben werden.

Über das Unterelement <identName> ist es möglich, einen im CARA Zertifikatsrequest hinterlegten Wert als Log-URL zu verwenden. Zu beachten ist allerdings, dass hierbei die Kontrolle über die Log-URL an die Client-Applikation abgegeben wird. In diesem Fall besteht ein inhärentes Risiko, dass die Client-Applikation den Platzhalter nicht oder mit einem ungültigen Wert belegt. Ferner kann die Gültigkeit aller Log-URLs dann nur im Kontext eines bestimmten Zertifikats-Requests vollständig beantwortet werden.

Attribute

Attribute des Elements log
Attributname	Erläuterung
`essential`	Das Attribut ist optional, erlaubte Werte sind `true` oder `false`. Ist der Wert `true`, so gilt das SCT dieses Logservers als unverzichtbar für die Zertifikatsausstellung, d.h. ohne dieses SCT bricht CARA die Ausstellung des Zertifikats ab. Der Defaultwert ist `false`.
`temporalSharding`	Das Attribut ist optional; erlaubte Werte sind `true` oder `false`. Der Standardwert ist `false`. Ist der Wert `false`, so wird die Log-URL aus dem Template als vollständig angesehen. Sie darf in diesem Fall keine Wildcard-Zeichen enthalten. Die Log-URL wird mit den Datums- und Zustandsinformationen in `all_logs_list.json` abgeglichen und nur aufgerufen, wenn sie in dieser Liste enthalten ist. Ist der Wert true, so gilt Folgendes: Die Log-URL muss ein oder zwei Wildcard-Zeichen () enthalten und wird als Muster interpretiert. Ist kein Wildcard vorhanden, verhält sich CARA so, als wäre es am Ende der URL vorhanden. Zur Wahrung der Abwärtskompatibilität darf anstelle des Wildcards auch der vormals eingeführte Platzhalter `{expirationYear}` weiterhin verwendet werden. Hiervon ist allerdings nur einer je URL erlaubt, und er darf nicht mit Wildcard-Zeichen () kombiniert werden. CARA versucht, automatisch eine URL aus der Gesamtliste `all_logs_list.json` zu wählen, die dem Muster entspricht. Falls mehrere URLs zu dem Muster passen, wird immer nur die erste passende URL verwendet, weitere Treffer werden nicht in Betracht gezogen. Unter den so gefilterten CT-Logs wird dasjenige ausgewählt, dessen Status und Datumsangaben passend sind. CT-Logs mit `log_type=test` haben keinen Status und sind zulässig^[1]; sonstige CT-Logs müssen den Status `usable` haben, und der zugehörige Zeitstempel muss in der Vergangenheit liegen. Das Ablaufdatum des auszustellenden Zertifikats muss innerhalb des `temporal_interval` des CT-Logs liegen. 1. Es obliegt dem Betreiber, in Test- und Wirkumgebungen die jeweils richtigen Log-URLs festzulegen. CARA hat kein eigenes „Bewusstsein“ über den Betrieb in einer Test- oder Wirkumgebung.

Unterelemente

Die möglichen Unterelemente sind beim Datentyp valueType (siehe ValueType) definiert.

Beispiel

<!-- Ein Wildcard als Platzhalter -->
<log temporalSharding="true">
<default>https://ct.googleapis.com/logs/us1/argon*/</default>
</log>

<!-- Traditioneller Platzhalter {expirationYear} -->
<log temporalSharding="true">
<default>https://ct.googleapis.com/logs/us1/argon{expirationYear}/</default>
</log>

<!-- Zwei Wildcards als Platzhalter -->
<log temporalSharding="true">
<default>https://ct*.trustasia.com/log*/</default>
</log>

<!-- Einfache statische URL ohne Temporal Sharding, d.h. ohne Platzhalter -->
<log temporalSharding="false">
<default>https://ct.googleapis.com/testtube/</default>
</log>

Das XML-Element `<minimumLogs>`

Das XML-Element <minimumLogs> definiert ein einzelnes Akzeptanzkriterium, welches mit Hilfe des XML-Attributs years, months und/oder des XML-Attributs days in Abhängigkeit von der Zertifikatslaufzeit angegeben werden kann. Wenn mehrere XML-Attribute angegeben werden, wirken sie additiv, d.h. die Angaben werden aufsummiert. Werden mehrere Akzeptanzkriterien definiert, so müssen sich die Summen aus ihren years-, months- und days-Angaben unterscheiden. CARA wählt anhand der Zertifikatslaufzeit aus, welches minimumLogs-Element zur Bewertung der empfangenen SCTs verwendet werden soll - dies ist stets genau eines.

Attribute

Attribute von minimumLogs
Attributname	Erläuterung
`logs`	Gibt die Gesamt-Anzahl von SCTs an, die nach der Registrierung des Präzertifikats mindestens vorliegen müssen. Anzugeben ist eine Ganzzahl. Es handelt sich um eine Pflichtangabe.
`years / months / days`	Maximale Zertifikatslaufzeit in Jahren, Monaten bzw. Tagen (Ganzzahl). Diese Attribute verwendet CARA zur Auswahl des maßgeblichen `minimumLogs`-Elements in Abhängigkeit von der Laufzeit des auszustellenden Zertifikats. Die Angabe ist optional. Für jeden Wert für die Summe aus `years`, `months` und `days` darf nur ein Element `<minimumLogs>` angegeben werden. Es darf höchstens ein Element `<minimumLogs>` ohne `years`, `months` und `days`-Angabe verwendet werden. Zur Bewertung der SCTs für ein auszustellendes Zertifikat kommen nur diejenigen `minimumLogs`-Elemente infrage, deren Summe aus `years`-, `months`- und `days`-Angabe größer oder gleich der Zertifikatslaufzeit ist, zusätzlich das `minimumLogs`-Element ohne `years`-, `months`- und `days`-Angabe (falls vorhanden). Unter den infragekommenden `minimumLogs`-Elementen wählt CARA dasjenige mit der kleinsten Summe aus `years`-, `months`- und `days`-Angabe aus. Sind sämtliche Summen aus `years`-, `months`- und `days`-Angaben kleiner als die Laufzeit des Zertifikats, so verwendet CARA das `minimumLogs`-Element ohne `years`-, `months`- und `days`-Angabe. Ein Grenzfall für `years="1"` wäre bspw. der Gültigkeitszeitraum vom 01.01.2010 00:00:00 bis zum 31.12.2010 23:59:59. Für diesen Zeitraum wäre gerade noch das `minimumLogs`-Element mit `years="1"` maßgeblich. Wäre das Gültigkeitsende der 01.01.2011 00:00:00, so würde das `minimumLogs`-Element mit der nächstgrößeren `years`-Angabe herangezogen werden.

Unterelemente

Unterelemente des XML-Elements minimumLogs
Element-Name	Erläuterung
`essentialGroup`	Definiert eine für die Zertifikatsausstellung unverzichtbare Gruppe von Logservern. Wenn aus dieser Gruppe nicht genügend SCTs vorliegen, bricht CARA die Zertifikatsausstellung ab. Siehe Das XML-Element `<essentialGroup>`

Das XML-Element `<essentialGroup>`

Das inhaltslose XML-Element <essentialGroup> erlaubt die Definition einer Mindestanzahl erforderlicher SCTs für eine bestimmte Logserver-Gruppe. Es darf mehrmals innerhalb jedes <minimumLogs>-Elements verwendet werden, höchstens jedoch entsprechend der Anzahl definierter Logserver-Gruppen. Liegen von der angegebenen Logserver-Gruppe nicht genügend SCTs vor, so bricht CARA die Ausstellung des Zertifikats ab.

Attribute

Attribute von essentialGroup
Attributname	Erläuterung
`name`	Name der Logserver-Gruppe, auf die sich das `essentialGroup`-Element bezieht. Pflichtangabe. Muss dem `name`-Attribut eines logGroup-Elements entsprechen. Die `essentialGroup`-Unterelemente eines `minimumLogs`-Elements müssen sich in ihrem `name`-Attribut voneinander unterscheiden.
`logs`	Gibt die Gesamt-Anzahl von SCTs an, die nach der Registrierung des Präzertifikats von der durch `name` angegebenen Gruppe mindestens vorliegen müssen. Ganzzahl. Die Angabe ist optional, der Default-Wert ist 1.

Unterelemente

Das XML-Element <essentialGroup> besitzt keine Unterelemente.

Beispiel

<ctList>
    <logGroups>
        <logGroup name="google">
            <log essential="true">
                <identName>id.logServerUrl</identName>
            </log>
            <log><default>https://ct.googleapis.com/aviator</default></log>
            <log><default>http://ct.googleapis.com/rocketeer</default></log>
        </logGroup>
        <logGroup name="others">
            <log><default>https://ct1.digicert-ct.com/log</default></log>
            <log><default>https://ct.izenpe.com</default></log>
            <log><default>https://log.certly.io</default></log>
        </logGroup>
    </logGroups>
    <minimumLogDefinitions>
        <minimumLogs years="1" logs="2"/>
        <minimumLogs years="2" logs="3">
            <essentialGroup name="others"/>
        </minimumLogs>
        <minimumLogs logs="4">
            <essentialGroup name="google" logs="2"/>
            <essentialGroup name="others" logs="2"/>
        </minimumLogs>
    </minimumLogDefinitions>
</ctList>

In diesem Beispiel sind die beiden Gruppen „google“ und „others“ mit jeweils drei Logservern definiert. Die URL des ersten Logservers ist als Platzhalter angegeben. Das CARA-Frontend muss zwingend vor der Zertifikatsgenehmigung einen Wert dafür hinterlegen, weil kein Default-Wert angegeben ist. Dieser Logserver ist zudem als „unverzichtbar“ markiert. Fehlt das von ihm erstellte SCT, so kann das Zertifikat nicht ausgestellt werden, egal welche SCTs von anderen Logservern vorliegen. Die URLs der übrigen Logserver sind statisch angegeben und können vom CARA-Frontend nicht beeinflusst werden. Es sind drei Akzeptanzkriterien angegeben, mit folgender Bedeutung:

Beträgt die Zertifikatslaufzeit höchstens ein Jahr, so müssen insgesamt mindestens zwei SCTs vorliegen.

Beträgt die Zertifikatslaufzeit mehr als ein, aber höchstens zwei Jahre, so müssen insgesamt mindestens drei SCTs vorliegen, davon mindestens eines aus der Gruppe „others“.

Beträgt die Zertifikatslaufzeit mehr als zwei Jahre, so müssen insgesamt mindestens vier SCTs vorliegen, davon mindestens zwei aus der Gruppe „google“ und mindestens zwei aus der Gruppe „others“.

Procuration

Die X.509-Extension „Procuration“ (OID: 1.3.36.8.3.2) wird verwendet, wenn der Zertifikatsinhaber für eine andere Person Unterschriften leisten darf. Diese Extension ist in [TTT-PKI] spezifiziert.

Im Template wird die Extension über das XML-Element <procuration> beschrieben. Details sind in [TECH_DOK] zu finden.

Inhalte können durch <default> oder durch <identName> gegeben sein.

Beispiel

<extension>
    <procuration>
    <country>
        <identName>id.procurationCountry</identName><default>DE</default>
    </country>
    <signingFor>
        <thirdPerson>
            <dnAttribute>
                <oid>2.5.4.6</oid>
                    <identName>id.thirdPersonCountry</identName>
            </dnAttribute>
            <dnAttribute>
                <oid>2.5.4.c</oid>
                    <identName>id.thirdPersonCN</identName>
            </dnAttribute>
        </thirdPerson>
    </signingFor>
    </procuration>
</extension>

X.509-Extensions

Key-Usage

Authority-Key-Identifier

Subject-Key-Identifier

CRL-Distribution-Points

Vereinfachte Definition

Vollständige Definition

Extended-Key-Usage

Authority-Information-Access

Basic-Constraints

Certificate-Policies

Subject-Alternative-Name

Restriction

Additional-Information

Validity-Model

Qualified-Certificate-Statements

qcCompliance

qcMonetaryLimit

qcRetentionPeriod

qcSSCD

qcPDS

qcType

psd2QcType

qcStatement

Admission

Certificate-Template-Name

Private-Key-Usage-Period

OCSP-NoCheck

ICAO-NameChange

ICAODocumentType

Generic-Extension

Issuer-Alt-Name

ctList

Das XML-Element <logGroup>

Das XML-Element <log>

Das XML-Element <minimumLogs>

Das XML-Element <essentialGroup>

Procuration

Das XML-Element `<logGroup>`

Das XML-Element `<log>`

Das XML-Element `<minimumLogs>`

Das XML-Element `<essentialGroup>`