Please note: this is a non authoritative version for informational purposes only. It may differ from the official version located here. This website will not be updated after 19th May, 2023.

1. INTRODUCTION / Einleitung

Management-Statement

Trust Services, in particular digital electronic signatures and digital certificates, are seen as key technologies for the production of reliable global business processes. The secure management of confidential certification data, the long-term sustainability of certification procedures and the verifiability of Trust Services are of central importance to the business activity of the Certification Authority (CA).

Information security is understood to be, alongside the security of IT infrastructure, the secure usage of all information relevant to Trust Services outside of IT.
The fundamental principles of information security are confidentiality, integrity and availability.
In this sense, the provision of appropriate technology and resources is of central importance. The performance of Trust Services is considered the principle task of the operator. All objectives of or changes to Trust Services, including changes to policies regarding Trust Services, take place upon the instruction of the management, taking strict information security standards into account.

The foundation of these strict information security standards is that Trust Services are performed exclusively on the basis of defined business models.

In the implementation of new business processes or the adaptation of existing business processes, their effects on the existing information security concept is first reviewed, and the implementation is conceived so that the existing security concept ( GLOBALTRUST Certificate Security Policy, OID: 1.2.40.0.36.1.2.2.11) is adhered to. This document is not publicly available. The security concept describes the Information Security Management System (ISMS) for all Trust Services for which the operator assumes responsibility (either as the CA or the contractor of the CA).

The operation and adaptation of existing business processes as well as the implementation of new business processes is performed using the PDCA2 model, in which PDCA cycles are arranged in appropriate time periods. Independent of the pre-defined standard PDCA cycle, unforeseen events can necessitate additional or shortened PDCA cycles (in particular during adaptations of essential technical, personnel, commercial or legal parameters). Sub-processes, as well as sub-PDCA processes, are organised insofar as they are materially applicable.

Furthermore, information security is ensured organisationally using a clear role concept (ð GLOBALTRUST Certificate Security Policy), in which a certification committee is assigned a central role in the planning of Trust Services. All functions relevant to Trust Services are represented in the certification committee. Changes in the certificate policies are approved by the certification committee.

In the certification committee, sufficient financial funding for information security measures is established, in consideration of legal guidelines and commercial resources.

For the purpose of motivating all employees and achieving an optimal role model function, the management and the members of the certification committee commit themselves to regularly taking part in training events and observing security regulations faithfully. All employees are obliged to maintain confidentiality.
To maintain information security, all employees holding responsibilities conduct tests of the information security processes, in which internal and external audits have an important role. Recognised vulnerabilities lead invariably to consequences. Vulnerabilities and consequences are documented. The management commits itself to regular evaluation of the suitability, up-to-dateness and appropriateness of the security objectives and guidelines.

The flow of information, the required reports at management level and the required documentation are stipulated within the framework of the accountability concept (ð GLOBALTRUST Certificate Security Policy). The internal documentation of Trust Services takes place through an internal Content Management System. The documents are accessible to all responsible personnel. Those parts of the documentation that are necessary for the recovery of the IT system in the event of emergency are kept ready in printed form. Through a complex and on-going enhanced authority and keyword process documents can be assigned flexibly designated themes and tasks or designated usage groups (for example, technical documents, user documents, contract and certification documents, instructions, reports and so on).

The CA conducts the necessary audits to ensure the conformity of its Trust Services with the documents listed under ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen (p178). The audit reports are published or otherwise made available as necessary.

The VDA will regularly execute safety analyses of its public and internal network. The analyses will be executed due to the requirements of supervisory authorities, or due to agreements with third parties, the CA/Browser Forum or similar institutions, due to system or network changes, once in the quarter at the minimum. As far as such checks will be executed due to requirements by the supervisory authorities or a third party, the check can take place in one week.

1.1 Overview / Übersicht

The operator offers all Trust Services as defined by this document

The GLOBALTRUST Certificate Policy (GCP) governs all requirements of the operator’s Trust Services. If regulations are provided for individual products in the applicable practice statement (in particular the GLOBALTRUST Certificate Practice Statement), these are to be understood as supplementary within the framework of this policy.

The GLOBALTRUST Certificate Policy described in this document is referred to henceforth as the “Policy”. This Policy is to be understood as the foundation within which the Trust Services are performed. Additional restrictions in the applicability of the policy can be agreed, in particular, cases of certification and signature procedures. However, this in no way affects legal foundations (in particular [eIDAS-VO], [SVG], [SVV], …) or technical foundations (in particular [CWA-14167-1], [ETSI TS 101 456], including successors: [ETSI EN 319 401], [ETSI EN 319 411-1], [ETSI EN 319 411-2], [ETSI TS 102 042], including successors [ETSI EN 319 411-3], …). The terms and conditions of the CA or additional agreements with partner companies cannot render the Policy fully or partially invalid.

All processes necessary for Trust Services are documented by the operator internally.
The GLOBALTRUST Certificate Policy, the GLOBALTRUST Certificate Practice Statement and the GLOBALTRUST Certificate Security Policy together constitute the foundation of the operation concept as submitted to the regulator for licensing. The implementation of the technical procedures of the operation concept is ensured by the internal documentation system.
Changes to or new developments of business processes take place according to written documentation and always contain the following information: description of the planned changes or new developments, date of initialisation, participating employees, expected duration, interim results, and information on the date of completion, on-going adjustment of the date of completion, including information on work to be completed and the personnel responsible for acceptance and documentation of the completed business process.
Changes or new developments are to be initiated by the personnel responsible according to ð GLOBALTRUST Certificate Security Policy. In the event of doubt, permission must come directly from the management.

1.2 Document name and identification / Dokumenttitel und -identifikation

Document title: “GLOBALTRUST Certificate Policy“ (GCP)
This policy is valid for GLOBALTRUST and has the OID: 1.2.40.0.36.1.1.8.1.
This document becomes valid on the day that it is published on the website of the operator. Where not otherwise indicated, the validity of the earlier version of the document ends as the new version becomes valid.

This document was compiled in conformity with RFC3647.
External documents are cited in square brackets [] and can be found in ð Appendix A: I Bibliography (p109) listed with bibliographic information. They are cited with the date 27th April 2023, but the respectively valid versions or the applicable subsequent standards apply.

Unless otherwise indicated, the validity of web links refers to the day upon which editing of the document was completed.
This policy contains all rules for the issuance and usage of certificates for simple, advanced and qualified electronic signatures and seals, qualified timestamps and certificates for website authentication.

Changes on the basis of legal changes become effective from the time at which the legal provisions enter into force. Other changes become effective through announcement on the website of GLOBALTRUST.
Where legal changes or changes to those documents and standards for which Trust Services require conformity necessitate a change of the GLOBALTRUST Certificate Policy,
the GLOBALTRUST Certificate Practice Statements
or the GLOBALTRUST Certificate Security Policy, adaptation ensues in a timely fashion sufficient to ensure that the changed requirements can be fulfilled.

History of changes

Drafts 1.0 to 1.4 were internal versions and never entered into force.

Version 1.5 Original Version 10th August 2006

Version 1.6 Changes I 12th April 2007
– Explanation of the trademark GLOBALTRUST
– OID given for the English translation of the Policy
– Conformity with [ETSI TS 102 042] established
– Newly added key management subscriber
– Various editorial corrections of spelling and phrasing errors

Version 1.7 Changes II 1st April 2014
– New structure of the document according to [RFC3647]
– Description of detailed certification procedures in ð GLOBALTRUST Certificate Practice Statement
– Addition of the issuance of qualified certificates for advanced and qualified signatures
– Operation of time stamp service defined
– Operation of mobile Trust Services defined
– Change of Trust Service Provider
– Additions and corrections in the bibliography
– Regulation of the labelling of simple certifications from 1.7.2014 (ð GLOBALTRUST Certificate Practice Statement).
– Editorial correction of spelling and phrasing errors

Version 1.8 Changes III 1st June 2014
– Proposed version RTR
– Editorial correction of spelling and phrasing errors

Version 1.8a Changes IV 1st October 2014
– Adjustment based on insights from 10 September 2014 from RTR
– Editorial correction of spelling and phrasing errors

Version 1.8b Changes V 1st February 2015
– Adjustments based on meeting on 15 January 2015 at the RTR
– Specification of used key and hash algorithms
– Editorial correction of spelling and phrasing errors

Version 1.8c Changes VI 1st June 2015
– Integration of English translation
– Editorial correction of spelling and phrasing errors

Version 1.8d Changes VI 1st June 2016
– internal Version, not activated

Version 2.0 Changes VII 1st June 2017
– Description of allowed and suitable Common Names (CN)
– Procedure in case of dispute
– Disclaimer of warranties for the browser suppliers
– Clarification of the responsibility for company certificates
– Change to the european regulation on signatures [eIDAS-VO], the austrian law “Signatur- und Vertrauensdienstgesetz” [SVG] and the austrian regulation “Signatur- und Vertrauensdiensteverordnung” [SVV]
– Use of the term “Vertrauensdiensteanbieter (VDA)” instead of “Vertrauensdiensteanbieter”
– Editorial correction of spelling and phrasing errors

Version 2.0b Changes VIII 13th August 2018
– Reduction validity period new server certificates according CA Browserforum [CABROWSER-BASE]
– Consideration of CAA-Records according CA Browserforum [CABROWSER-BASE]
– More detailed definitions of identification procedure during certificate delivery
– Editorial correction of spelling and phrasing errors

Version 2.0c Changes 15th January 2019
– Additional clarifications accorting issuing- und check-processes
– Editorial correction of spelling and phrasing errors, update of citations

Version 2.0d Changes 19th April 2019
– internal Version, not activated

Version 2.0e Changes 25th June 2019
– Definition of videobased online identification
– Description of qualified server certificates
– Description of EV certificates
– Clarifications concerning key pair generation
– Editorial correction of spelling and phrasing errors

Version 2.0f Changes 13th December 2019
– Update Business address
– Precision of email validation procedure
– Description of disseminating status information in case of CA-key
compromise
– Beschreibung Certificate Transparency
– Editorial correction of spelling and phrasing errors

Version 2.0g Changes 3rd April 2020
– Permitted Subject Names of CA-certificates restricted
– Clarifications on the use of EKU constraints
– Server certificate validity period limited to 397 days
– organizationIdentifier (OID: 2.5.4.97) and cabfOrganizationIdentifier
(OID: 2.23.140.3.1) introduced
– Editorial correction of spelling and phrasing errors

Version 2.0h Changes 15th January 2021
– Minor alignments according to browser requirements
– Additional technical clarifications
– Editorial correction of spelling and phrasing errors

Version 2.0i Changes 29th April 2021
– Additional information concerning other hardware based certificates
– Special requirements related to key compromise
– Clarifications on revocation list profiles
– Clarification of the terms signature and seal
– Editorial correction of spelling and phrasing errors

Version 3.0 Changes 28th April 2022
– qualified signatures and seals as Server-based signature services
– introduction of term S/MIME certificate
– Editorial correction of spelling and phrasing errors

Version 3.1 Changes 27th April 2023
– Terminological specifications electronic seals (alignment with eIDAS, sole control vs control, …)
– Replacement of obsolete terms (trust services instead of certification, …)
– Editorial correction of spelling and phrasing errors

 

1.3 PKI participants / Beteiligte

1.3.1 Certification authorities / Vertrauensdienstanbieter

Issuer and Certification Authority (CA)

The issuer of this Policy and Certification Authority (CA) is e-commerce monitoring GmbH, a company listed on the commercial register according to Austrian law, with its place of business in Vienna (commercial court Vienna FN 224536 a). e-commerce monitoring performs all Trust Services attributed to GLOBALTRUST (Certification Services Provider responsible). The CA runs the website https://www.globaltrust.eu. The CA fulfills all requirements of a trustworthy organisation, in particular making available sufficient financial and personnel resources to fulfil all obligations in the framework of the Trust Services.

1.3.2 Registration authorities / Registrierungsstelle

Registration authority

The business offices of the CA and certification partners authorised by the CA. The registration authority acts in the framework of the standards of the CA. Provided that independent registration authorities are established, they must have completed all audits that are relevant for their area of activity, according to GLOBALTRUST Certificate Practice Statements, the GLOBALTRUST Certificate Security Policy and this GLOBALTRUST Certificate Policy.

Certification partner

Persons who are authorised to receive and review certification applications (including verification of identity) in the commission of the CA.

Authorised person

A natural person who is authorised to review certification applications and conduct full or partial Trust Services. This can be employees of the CA (authorised employees), of the registration authority, a contractor, a contractually authorised certification partner or employees of the provider of commerical identification services. The scope of activity is demonstrably adhered to in the framework of instructions, descriptions of activities, contractual agreements and other appropriate documentation, documented and can be made available to authorised interested third parties, should they exist. Authorised employees of the CA are specifically trained and are particularly trustworthy.

1.3.3 Subscribers / Signator

Applicant

A person who submits an application for the issuance of a certificate on the basis of a valid certificate policy and applicable additional agreements, either for themselves personally or for a private, public or international organisation.

Subscriber

A person who either directly possesses a signature-creation device or has a signature creation device managed on his behalf by the CA or a third party and who acts either in their own name or in the capacity of the position occupied by them or in the name of a legal or natural person. As far as not explicitly stated otherwise, the term the term subscriber also refers to the creator of a seal.

Creator of a seal

A legal person who either directly possesses a signature-creation device or has a seal creation device managed on his behalf by the CA or a third party and who acts either in their own name or in the capacity of the position occupied by them or in the name of a legal or natural person. The terms Subscriber and Creator of a seal may be used synonymously.

Certificate Requester

Natural person who is either the applicant, or a duly authorised representative of the applicant, and makes an application for the issue of an EV certificate on the applicant’s behalf, and whose name, title and authorisation have been validated by the operator.

Certificate Approver

Natural person who is either the applicant, or a duly authorised representative who is expressly authorised to represent the applicant to act as a Certificate Requester and to approve applications for the issuance of an EV certificate made by other Certificate Requesters, and whose name, title and authorisation have been validated by the operator.

Contract Signer

Natural person who is either the applicant or an authorised representative who is expressly authorised to sign the policy and any other provisions (general terms and conditions, individual agreements) for the use of the EV-certificate on behalf of the applicant, and whose name, title and authorisation have been validated by the operator.

1.3.4 Relying parties / Nutzer

Relying party

A natural person who uses the services or products of the operator or uses services or products produced with the services and products of the operator. This usage can take place with or without a contract with the operator. In particular, every relying party who uses a public key validated with a certificate from the operator or receives electronically signed information.

Participants

All persons and entities subject to this GLOBALTRUST Certificate Policy and the applicable GLOBALTRUST Certificate Practice Statement. This is, in particular, the CA, registration and validation authorities, contractors and certification partners with regard to application review, issuance, archiving and revocation of certificates for the purposes of this GLOBALTRUST Certificate Policy. Also, the subscriber in the context of the usage of the certificate (in particular for electronic signatures) and all relying parties.

1.3.5 Other participants / Weitere Beteiligte

Operator

This describes the role of the CA as service provider. If the CA is contracted by other Trust Service providers, it is obliged to treat technical and organisational procedures identically to the described GLOBALTRUST Certificate Policy. Where the independent performance of Trust Services (CA) as well as the performance of services as a contractor is referred to, this is referred to comprehensively as “operator” in this document

Service Provider

Further entities or natural Persons who have been fully or partially entrusted with the technical or commercial implementation of Trust Services by the CA. The issuer of this document acts as a conractor if it performs Trust Services under the instruction of another certificate authority (“contractor of a CA”).

Reseller

Entities that have specific agreements with the CA regarding distribution. A list of resellers is available on the website of the CA.

Regulator

A regulator responsible for the Trust Services s of the CA by law.

Confirmation authority

A confirmation authority as established by the Austrian Signature Law [SVG] (“Bestätigungsstelle”), or confirmation authority for qualified signature-creation devices as established by legal provisions in other States issued on the basis of the EU signature regulation [eIDAS-VO].

Competent independent auditor

An auditor that is competent to audit certification authorities according to at least one of the following or a stricter criterion:
– [[ETSI EN 319 401], [ETSI EN 319 411-1], [ETSI EN 319 411-2]
– [eIDAS-VO]
– [SVG] + [SVV]
– [CABROWSER-BASE]
– [CABROWSER-EV]
– [MOZILLA-CAPOL]
– [WEBTRUST-CA]
– [WEBTRUST-EV]

The auditor employs employees with the competence to examine PK infrastructure, IT security technology and IT security, as audited and accredited by a third partyThe auditor is accredited to audit to ETSI standards, according to ETSI EN 319 403, and to conduct ISO 27001 audits (or similar), according to ISO 27006. The auditor acts on the basis of a legal warrant, according to public guidelines, or follows the guidelines of a professional association. If the auditor does not act in the framework of a legal warrant, it has liability insurance available to it with an indemnity limit of at least 1 000 000 USD.

In the event of an audit, the auditor announces the criteria under which the audit will be conducted and under which criteria it acts and is accredited.

Concerned party

All persons whose personal data is stored and/or processed by the operator.

1.4 Certificate usage / Verwendungszweck der Zertifikate

1.4.1 Appropriate certificate uses / Verwendungszweck

Legitimate uses are derived from the certificate’s contents, the GLOBALTRUST Certificate Policy and the applicable GLOBALTRUST Certificate Practice Statement.
Legitimate formats of data to be signed can be listed in the document ð Appendix / Anhang A: 3 supported signature creation unitS / Unterstützte Signaturerstellungsprodukte (p221), in the respectively applicable certificate policy or on the website of the CA. If restrictions regarding specific formats exist, they are included in the document. Reference to publications of regulators with regard to acceptable and/or recommended data formats is also permissible.
With regard to signature-creation devices, there are no obligatory technical guidelines for advanced signatures. The subscriber is free to use the signature-creation device at his discretion, but must ensure sole personal control of the signatures assigned to him as is legally compulsory.
Binding transactions with a value over 100 000 EUR require a qualified certificate for electronic signatures.
If it is not possible to verify the certificate of an electronic signature, it is the sole responsibility of the relying party whether or not they recognise the validity of the signature. The CA holds no responsibility in this regard.
It is permissible to announce limitations on the use or validity of the certificate on the website or in otherwise published conditions (in particular notice of the maximum transaction value for which the signature can be validly issued). The responsibility of the CA is also limited in line with the given limitations and maximum amounts.
Additional limitations can also arise from the type of certificate issued and its usage.
The subscriber is required to use the Key Pair only in accordance with this Policy and to use only the key generation algorithms and parameters described in this Policy.

1.4.2 Prohibited certificate uses / Untersagte Nutzung der Zertifikate

Where it is technically feasible and appropriate, usage restrictions are included in the certificates in a form compliant with the standard. Restrictions on permissible domain names and IP addresses are given on enduser-sub-certificates intended for the issuance of server certificates. If it is not technically possible to implement an intended limitation, an agreement regarding permissible domain names and IP addresses is made.

1.5 Policy administration /Policy Verwaltung

1.5.1 Organization administering the document /Zuständigkeit für das Dokument

This document is the sole responsibility of the operator.

1.5.2 Contact person / Kontaktperson

Queries regarding this document can be directed to the operator. Current contact details are listed on the operator’s website. (ð Contact details: http://www.globaltrust.eu/impressum.html).
Requests for revocation should be sent as soon as possible via https://www.globaltrust.eu/revocation.html. Alternatively, revocations can also be requested by email to revocation@globaltrust.eu or by phone. In any case, sufficient revocation authorization must be demonstrated, for example through online authentication.
In the case of certificate-related problems, such as suspected misuse, everyone involved can contact the operator via abuse@globaltrust.eu or by phone. A Certificate Problem Report must contain at least:
– An indication that allow a unique identification oft he certificate
– An understandable statement of the circumstances
– The contact details of the sender
Both requests for revocation and Certificate Problem Reports are taken seriously and are given priority.

1.5.3 Person determining CPS suitability for the policy / Person die die Eignung der CPS bestätigt

GLOBALTRUST Certificate Practice Statements are assigned and accepted by the certification committee in accordance with the accountability concept (ð GLOBALTRUST Certificate Security Policy.

1.5.4 CPS approval procedures / Verfahren zur Freigabe der CPS

GLOBALTRUST Certificate Practice Statements are verified and issued by regular members of the certification committee. Acceptability is confirmed by a representative of the management and at least one further member of the certification committee.

1.6 Definitions and acronyms / Definitionen und Kurzbezeichnungen

Business process
A logical unit of measures and procedures towards a defined objective. The ð Trust Services are a subgroup of all the business processes of the operator.

Trust services
All services performed by the operator, in particular the following principle services:
– Administration of applicants for certificates (including identification of applicants)
– Issuing of certificates (including suspension and revocation of certificates)
– Distribution of certificates
– Administration of applications for suspension and revocation
– Distribution of information on suspension and revocation

Further trust services services include, in particular
– Provisioning and distribution of signature-creation devices
– Time stamp services
– Other signature services, such as signature services via mobile devices, other server-based signature services, in particular document archive services that are run by the operator.

Trust Services are performed according to EU signature regulation [eIDAS-VO], [SVG] and [CWA-14167-1], and include simple, advanced and qualified electronic signatures, qualified or simple certificates and qualified or simple time stamp services.
Individual services are organised as ð business processes.

Electronic signature
Data in electronic form according to EU signature regulation [eIDAS-VO], which is attached or logically linked to electronic data and authenticates it.
The term “signature” also includes electronic seals, unless explicitly stated otherwise.

Certificate data
All data, in particular identification data, which is necessary for issuance, audit or revocation of certificates.

Simple electronic signature
An electronic signature that conforms to the requirements of neither the advanced electronic signature nor the qualified electronic signature.

Advanced electronic signature
An electronic signature that fulfils the following criteria:
a) it is assigned exclusively to the subscriber;
b) it enables the identification of the subscriber;
c) it is created by means that the subscriber can keep under their sole control;
d) it is linked to the data to which it refers in such a way that later changes to the data can be recognised.

Governmental signature (“Amtssignatur”)
Advanced electronic signature according to the E-Government Law [E-GOVG], in particular taking [ASZ] and similar documentation with a governmental character into account.

Qualified electronic signature
An electronic signature that fulfils the following criteria:
– all criteria of an advanced electronic signature,
– that is based upon a qualified certificate and
– has been created by a qualified signature-creation device (QSCD).

Server-based signature services
Services of the operator in administration, archiving, creation, verification or delivery of signed documents. The documents can be signed by the relying party, the operator, authorised third parties or a combination of the above-named groups. Qualified or non-qualified certificates can be used as proof of authenticity. The server-based signature service may also be offered as a part of the operator’s services, for example in the context of pseudonymisation and anonymisation services.

Remote signature
An electronic signature, whose signature creation data is managed by the CA or a third party on behalf of the subscriber.
Remote signatures may be simple, advanced, qualified or governmental (“Amtssignatur”) signature.
Unless otherwise stated, the term “remote signature” also covers remote seas.Qualified remote signatures are based on a qualified certificate and are created by a qualified remote signature creation device (QRSCD)

Mobile signature service
Mobile signature services are initiated using mobile phones or other suitable mobile technical devices. Mobile signature services are offered as server services or as “direct electronic signature” (signature on end device) in a mobile technical device.

Certificate
An electronic attestation that assigns signature verification data to a subscriber and confirms the identity of that signatory, the legal entity he represents, or a system controlled by him or his legal entity.
The name of the issuing certificate for which this policy is valid is set out in detail in the GLOBALTRUST Certificate Practice Statement.

Server certificate
A certificate for website authentication and SSL/TLS that has been issued in accordance with [CABROWSER-BASE] or [CABROWSER-EV].
The name of the issuing certificate for which this policy is valid is set out in detail in the GLOBALTRUST Certificate Practice Statement.

S/MIME certificate
A certificate containing the emailProtection extendedKeyUsage extension and at least one verified rfc822-email address in the subjectAlternativeName extension.

Simple certificate
A certificate that does not fulfil the criteria of a qualified certificate. Simple certificates contain at least the following entries:
The subject is encoded according to UTF-8 if it contains umlauts or special characters. PrintableString can be used if it does not contain umlauts or special characters.
The subject can contain the following inputs: countryName (mandatory), localityName (mandatory), stateOrProvinceName (optional), organizationName (if the certificate is being issued for an organisation), organizationalUnitName (optional), commonName or pseudonym or givenName (it is mandatory to fill in one), title (optional), serialNumber (optional). Each field can only be used for those inputs which are defined according to the applicable standards and norms.
Further information in the certificate:
– X509v3 Key Usage: critical e.g. Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
– X509v3 Extended Key Usage: mandatory at least one entry e.g. emailProtection. AnyExtendedKeyUsage is not used.
– X509v3 Subject Alternative Name, e.g. z.B. email:my@other.address,URI:http://my.url.here/
– CA Issuers – URI:http://service.globaltrust.eu/static/globaltrust-NN-**-der.cer3
– X509v3 CRL Distribution Points: Full Name: URI:http://service.globaltrust.eu/static/globaltrust-NN-**.crl
– OCA – URI:http://OCA-NN-**4.globaltrust.eu
– X509v3 Certificate Policies: Policy: 1.2.40.0.36.1.1.8.1
– CPS: http://www.globaltrust.eu/certificate-policy.htm
– Policy: 1.2.40.0.36.4.1.10 (Certificates that had been issued between 1.7.2014 and 1st April 2019 and whose keys have not been generated in a signature creation device that do not comply with at least FIPS-140 2 L2 or CC Protection Profile CWA 14169)
– Administration attribute “Verwaltungseigenschaft” (OID 1.2.40.0.10.1.1.1): Administration identifier (optional)
– Operator attribute “Dienstleistereigenschaft” (OID 1.2.40.0.10.1.1.2): NULL (optional)
– Official attribute “Organwaltereigenschaft” (OID 1.2.40.0.10.3.4): Administration identifier (optional)
– Attribute of signature for electronic authority (OID 1.2.40.0.10.1.7.2): NULL (optional)
– Signature algorithm used for end-user certifcates: SHA2 (sha256WithRSAEncryption or higher)

Qualified certificate for electronic signatures
A certificate for the creation of electronic signatures that it is issued with the latest technology and fulfils, in particular, the requirements in [eIDAS-VO] Appendix I and is provided by a Trust Service Provider (CA) that fulfils the requirements in [eIDAS-VO].
The content follows [ETSI EN 319 412]. The validity period of the qualified certificate for electronic signatures is limited to 5 years by law and can be shortened by the CA for legal or other important reasons at any time.

Qualified certificate for electronic seals
A certificate for the creation of electronic seals that it is issued with the latest technology and fulfils, in particular, the requirements in [eIDAS-VO] Appendix III and is provided by a Trust Service Provider (CA) that fulfils the requirements in [eIDAS-VO].
The content follows [ETSI EN 319 412]. The validity period of the qualified certificate for electronic seals is limited to 5 years by law and can be shortened by the CA for legal or other important reasons at any time.

Qualified server certificate
A certificate for website authentication that it is issued with the latest technology and fulfils, in particular, the requirements in [eIDAS-VO] Appendix IV as well as [CABROWSER-EV] and is provided by a Trust Service Provider (CA) that fulfils the requirements in [eIDAS-VO].
The content follows [ETSI EN 319 412] as well as [CABROWSER-EV] The validity period of the qualified server certificate is limited to 825 days by law and can be shortened by the CA for legal or other important reasons at any time. Qualified server certificates issued on or after 1st September 2020 will have a validity period no greater than 397 days.

Qualified certificate
The certificate can be issued either as a qualified certificate for electronic signatures or as a qualified server certificate and contains a reference to the certificate policy under which the certificate has been issued and which clearly identifies it as a qualified certificate.
The subject is encoded according to UTF-8 if it contains umlauts or special characters. PrintableString can be used if it does not contain umlauts or special characters.
The subject can contain the following inputs: countryName (mandatory), localityName (mandatory), stateOrProvinceName (optional), organizationName (if the certificate is being issued for an organisation), organizationalUnitName (optional), commonName or pseudonym or givenName (it is mandatory to fill in one), title (optional), serialNumber (mandatory), businessCategory (mandatory in case of qualified server certificates), jurisdictionLocalityName and/or jurisdictionStateOrProvinceName and/or jurisdictionCountryName (only in case of qualified server certificates, usage according to [CABROWSER-EV]) Each field can only be used for those inputs which are defined according to the applicable standards and norms.
Further information in the qualified certificate:
– X509v3 Key Usage: critical Digital Signature, nonRepudiation and Key Encipherment (in case of qualified server certificates)
– X509v3 Extended Key Usage: mandatory at least one entry, e.g. TLS Web Server Authentication and/or TLS Web Client Authentication AnyExtendedKeyUsage is not used.
– CA Issuers – URI:http://service.globaltrust.eu/static/globaltrust-NN-**-der.cer
– X509v3 CRL Distribution Points: Full Name: URI:http://service.globaltrust.eu/static/globaltrust-NN-**.crl
– OCA – URI:http://OCA-NN-**.globaltrust.eu
– X509v3 Certificate Policies: Policy: 1.2.40.0.36.1.1.##.1
– CPS: http://www.globaltrust.eu/certificate-policy.htm Policy:
– X509v3 Certificate Policies: Policy: 1.2.40.0.36.1.1.##.1
·         0.4.0.1456.1.1 (qualified certificates for electronic signatures issued before 15.12.2021)
·         0.4.0.194112.1.2 (qualified certificates for electronic signatures issued on or after 15.12.2021)
·         0.4.0.194112.1.3 (qualified certificates for electronic seals)
·         0.4.0.19431.1.1.3 (qualified remote signatures)
·         0.4.0.194112.1.4 (qualifizierte server certificates) and
·         2.23.140.1.1 (qualified server certificates, if also EV compliant)
– 1.2.40.0.36.4.1.3: [Serial number of the signature-creation device as ASN1 OCTET STRING]
– qcStatements:
– id-etsi-qcs-QcCompliance (OID 0.4.0.1862.1.1),
– id-etsi-qcs-QcLimitValue: QcEuLimitValue (OID 0.4.0.1862.1.2) (optional)
– id-etsi-qcs-QcRetentionPeriod: QcEuRetentionPeriod (OID 0.4.0.1862.1.3) (optional)
– id-etsi-qcs-QcSSCD (OID 0.4.0.1862.1.4)
– id-etsi-qcs-QcType (OID 0.4.0.1862.1.6)
– id-etsi-qct-esign (OID 0.4.0.1862.1.6.1)
– id-etsi-qct-eseal (OID 0.4.0.1862.1.6.2)
– id-etsi-qct-web (OID 0.4.0.1862.1.6.3)
– Administration attribute “Verwaltungseigenschaft” (OID 1.2.40.0.10.1.1.1): Administration identifier (optional)
– Operator attribute “Dienstleistereigenschaft” (OID 1.2.40.0.10.1.1.2): NULL (optional)
– Official attribute “Organwaltereigenschaft” (OID 1.2.40.0.10.3.4): Administration identifier (optional)
– Attribute of signature for electronic authority (OID 1.2.40.0.10.1.7.2): NULL (optional)
– further OID inputs if they are in accordance with the conditions for qualified certificates (optional)
Signature algorithm used: SHA2 (sha256WithRSAEncryption or higher)

Root certificate
A certificate that is used exclusively by the CA in the creation of Trust Services, which can only be signed by itself as the root of the certificate hierarchy (also self-signed certificate).
The root certificates of the issuer and user (applicant) have identical information.
The private key of the root certificate is generated for use using RSA and with a minimum length of 4096 bits. The hash algorithm used is for the root certificate SHA1. For root certificates that have been created since 1 October 2014, this is at least SHA256.
Root certificates are used only to sign CA certificates and revocation lists of the certification operations. Other uses are not allowed by the processes of the CA.

CA certificate
Certificates of the CA necessary to perform Trust Services. CA certificates can be self-signed certificates of the CA (root certificate) or sub-certificates issued under self-signed certificates that are intended for the performance of Trust Services. The fingerprints of the CA certificates and applicable policy are published on the website of the CA and the regulators responsible are notified (ð http://www.globaltrust.eu/certificate-policy.html).
The private keys of any CA certificates are generated using RSA and with a minimum length of 4096 bits. The hash algorithm used is at least SHA256.
CA certificates that are issued from February 1st, 2020, contain no more than the following subject data: two-digit country name according to ISO 3166-1 of the country in which the VDA is based, organization name of the VDA according to the commercial register entry and an a CN field eintry that allows precise differentiation from other CA certificates.
Further information in the certificate is at least:
– X509v3 Basic Constraints: critical, CA:TRUE
– X509v3 Key Usage: critical Certificate Sign, CRL Sign
CA-certificates (with the exception of root certifcates), created on or after 1st January 2019, contain a least one X509v3 Extended Key Usage entry that indicates the permitted EKU-entries in end user certificates. The anyExtendedKeyUsage must not be used. Id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning, id-kp-timeStamping must not be combined in the same CA-certificate.
CA certificates are used exclusively for signing (CA) certificates and revocation lists. Other uses are not allowed by the processes of the CA.
CA certificates may either be used as issuer for qualified, or non-qualified certificates.

End user certificate
A certificate that has been signed by a CA certificate and can be used for signature and/or encryption purposes. Such a certificate cannot be used for the issuance of further (subordinate) certificates.

Sub-certificate
A certificate that has been signed by a CA certificate and can be used by the VDA to issue further certificates.

enduser-sub-certificate
Certificate signed by a sub-certificate of the operator and made available to the subscriber for issuing own end user certificates. In any case, it contains technical limitations, such as the name of the issuing company, domain names that the company demonstrably owns or country restrictions. These restrictions can be assigned alone or in combination, but country restrictions alone are not sufficient. Further, at least one entry in the extension field extendedKeyUsage is present.

Time stamp
A signed data structure comprising the hash code of a document and the time of signature. The format and method of the generation of the time stamp complies with the standard [RFC3161] including the addition [RFC5816] oder dem Alternativstandard DSS XML. Information on the current operating data of the time stamp service (including accuracy and time stamp process) can be found on the website http://www.globaltrust.eu/produkte.html.

Qualified time stamp service
A service which generates time stamps using a qualified certificate or an equivalent process that ensures the correctness and authenticity of the time information contained.

Operation
All activities of the CA in performing Trust Services.

Operations concept
All documents on the operation of Trust Services that are audited and authorised by the ð regulator.

Certification system
Technical system that enables the processing of Trust Services, in particular the issuance or revocation of certificates.

Administrative system
Administrative system used for verifying and generating data that is necessary for the issuance or revocation of certificates.

Information Security Management System (ISMS)
All technical and organisational measures for the planning, establishment, maintenance and change of the information security of the operator.

Private, public and international organisations
Private organisations are entities that have been established according to applicable regulations of private and civil law.
Public organisations are entities that have been established by the law of their respective lands, such as authorities, state administrations, municipal, regional or national offices.
International organisations are entities that have been established on the basis of treaties in the realm of public international law.

Signature creation data
Distinct data such as codes or private cryptographic keys that are used by the subscriber to create an electronic signature.

Seal creation data
Distinct data such as codes or private cryptographic keys that are used by the creator of a seal to create an electronic signature.

Activation data
Information belonging to the subscriber that is necessary for the implementation of a signature, at least a part of which is confidential and only known to the subscriber or is only in the possession of the subscriber (for example, signature PIN or password).

Signature-creation device
Configured software, hardware or a combination of the two that is used to implement signature creation data.

Seal creation device
Configured software, hardware or a combination of the two that is used to implement seal creation data.

HSM
A Hardware Security Module (HSM), a hardware ð signature-creation device.

qualified signature- and seal creation device, secure key
A state-of-the-art signature-creation device that fulfils the requirements in EU signature regulation [eIDAS-VO] Appendix II (qualified signature creation device, QSCD), the comments of the BSI, A-SIT, similar entities and regulators are noted).

qualified remote Signautre creation device
qualified signature-creation device for remote signatures and seals (QRSCD)

Signature verification data
Data such as codes or public cryptographic keys that are used to verify an electronic signature.

Product for electronic signatures
Hardware or software or their specific components that are used by the certificate authority (CA) for the provision of services for electronic signatures or for the creation and verification of electronic signatures.

Seal verification data
Data such as codes or public cryptographic keys that are used to verify an electronic seal

Product for electronic seals
Hardware or software or their specific components that are used by the certificate authority (CA) for the provision of services for electronic seals or for the creation and verification of electronic seals.

Signature regulations
All documents applicable to the Trust Services described, in particular provisions formulated in [SVG], [SVV], [eIDAS-VO], including documents cited in the provisions.

Conformity Documents
All documents containing requirements for the Trust Services that are issued by third parties, are not legally binding and with which the operator seeks conformity, in particular the provisions formulated by software manufacturers including the documents cited in the provisions.

24/7/365, round-the-clock service, office hours
Services are provided all year round, seven days a week and 24 hours a day. Service disruptions or failures are documented. In isolated cases, additional limitations on availability can be defined, such as a tolerated disruption period of 1% per month or year.
Where not otherwise described in the respective GLOBALTRUST Certificate Practice Statement, published on the website of the operator or one of the websites referred to in the respective certificate policy, the following minimum office hours apply for every kind of query, application or order, including applications for suspension and revocation: working days, Monday to Friday 9:00 – 17:00.
Outside of these times an on-call service is available to address technical disruptions, defects or other emergencies that are critical to Trust Services.

Cross certification
The confirmation of the certificate of another certification authority, from a regulator by the CA or vice versa.
End user key, end user signature-creation device
A key for end users (subscriber) from the CA, which is created and issued for creating electronic signatures. In the case of asymmetric encryption, “end user key” describes a pair of keys comprising a private and a public key.

Secure environment
All technical and organisational measures that enable controlled operation of Trust Services.

Product addition
Additional information that describes the Trust Services and types of certificate and is a part of the certificate issued by the CA. In connection with the certificates issued according to the standard X.509v3, this is an additional part of the CN of a CA certificate following the term GLOBALTRUST, for example, GLOBALTRUST ADVANCED. Product additions can be defined and assigned in the framework of the business activity of the operator, as long as they are not misleading or potentially in conflict with the product additions used in this policy.

EV certificates
Specific certificates that have been issued based on guidelines published by the CA/browser forum, “CA/Browser Forum Guidelines for Extended Validation Certificates” ([CABROWSER-EV].
The terms are otherwise used corresponding to [SVG], [SVV], [eIDAS-VO], [X.509v3], [CWA‑14167-1], [ETSI EN 319 401], [ETSI EN 319 411-1], [ETSI EN 319 411-2], [RFC3161], [RFC3739] and [RFC3647] or others named in ð Appendix A: 1 Bibliography (p202).

2. Publication and repository responsibilities / Veröffentlichung und Aufbewahrung

2.1 Repositories / Aufbewahrung

The current version of this document is available on the website of the operator on a 24/7/365 basis (ð https://www.globaltrust.eu/certificate-policy.html).
Previous versions of this document are available from the regulator or on the website of the operator under the OID 1.2.40.0.36.1.1.8.99.
Changes made to the GLOBALTRUST Certificate Policy will be announced in a timely fashion on the website or by email, if provided by the certificate holders.

2.2 Publication of certification information / Veröffentlichung von Zertifizierungsinformationen

All documents necessary to perform Trust Services are published on the website of the operator, as well as the CA certificates used and their hash sums.
Information on services offered and procedures used is made available.
Testwebsites are available via the operator’s website at http://globaltrust.eu/certificate-policy/
The CA makes conditions for the use of certificates available to the subscribers and other users who place their trust in the services of GLOBALTRUST by publishing the following documents on the website:
1. the certificate policy. If necessary, additional certificate policies described in this document
2. general terms and conditions of use
3. additional descriptions of individual Trust Services
4. where applicable – a reference to the notification of Trust Services at the regulating authority
5. other communications
6. all cross-certificates that identify the CA as the holder and have been issued according to an agreement with the CA or have been accepted by the CA
The subscriber is notified of changes through announcement on the website of the CA or by email or post as circumstances require.
Further, CA certificates including technically constrained ones, are disclosed via the Common CA Database (https://www.ccadb.org/) within 7 days of their creation.

2.3 Time or frequency of publication / Häufigkeit der Veröffentlichung

Binding agreements are published before they enter into force and are valid until revoked. Any limitations on time, in particular the validity of certificates, are communicated in an appropriate fashion. Other information is published promptly during office hours.
Changes are published promptly.

2.4 Access controls on repositories / Zugangsbeschränkungen

No measures are taken to restrict access to public information.
Internal information is safeguarded according to the GLOBALTRUST Certificate Security Policy.

3. Identification and authentication / Identifizierung und Authentifikation

All certification data is verified according to plausibility, factual and technical correctness and compliance with legal and other juridical requirements, in particular information on signature creation devices used, information on the issuance of private keys, certificate requirements (for example a certificate signing request) and applicable policies.
In addition, the CA can make use of external services and experts. If evidence of legitimate control of individual components and confidential information is necessary (in particular signature creation devices, private keys, etc), the subscriber must produce this. If the CA has good reason to question the explanations provided, it can request additional confirmation and credentials. Certificates cannot be delivered before this has been successfully verified.

3.1 Naming /Benennung

Names are chosen so that they express facts or correspond to the name of the person or entity. They can be in any preferred language. Misleading, erroneous or unlawful names and designations are not accepted by the operator.

3.1.1 Types of names / Arten der Benennung

Certificate names will be checked for uniqueness for one applicant. Certification applications from different applicants with identical certificate names will not be accepted. Certification applications from the same applicant with the same certificate names will be accepted, if the information is still correct at the date of the reissue.
Names will only be accepted in certificates that
– are legitimately available to the applicant or
– in the case of other unprotected terms and names, as long as they are not misleading or breach legal regulations.

3.1.2 Need for names to be meaningful / Notwendigkeit für aussagekräftige Namen

Names in certificates must be meaningful if intended to fulfil a purpose.
Suitable names are:
– the proven name of the applicant including titles, professional titles and academic titles
– the proven name of the organisation for which the applicant gets issued the certificate, including proven details of the organisational unit
– legally required information
– trade names and product names, that verifiably belong to the applicant or the applying organisation, including domain, eMail and server names
– technical data (e.g. serial number of the smartcard) that are obviously connected to the certificate and that can be assigned or checked by the VDA,
– Functional and organisational names that inform about the use and/or the meaning of a certificate.

3.1.3 Anonymity or pseudonymity of subscribers / Behandlung von Anonymität oder Pseudonymen von Antragstellern

Trust Services can be performed so that persons, organisations or organs of organisations making an application are not publicly named, as long as this is permitted by legal and technical standards. In this event, internal documentation clearly matches the Trust Services provided to the individual or organisation making the application.
Pseudonyms are designated as such in qualified certificates, according to technical standards.
In the event of a certified or proven legal interest or obligation, the identity of the individual or organisation making an application is made available, including organs and representative entities.

3.1.4 Rules for interpreting various name forms / Interpretationsregeln für verschiedene Benennungsformen

If several name forms are equally valid, it is left to the applicant to choose.
This procedure is abandoned if a name form is essentially simpler and clearer.
In the event of disagreement over names, the operator suggests the most appropriate name.

3.1.5 Uniqueness of names / Einmaligkeit von Benennungen

Certificates are not provided for different subscribers using one and the same name. It is ensured that Trust Services are differentiated using at least a serial number or equivalent identifier.

3.1.6 Recognition, authentication and role of trademarks / Berücksichtigung und Authentifikation von Markennamen

It is permitted to enter a publically registered trademark as the name of an organisation, provided that the applicant can demonstrate that the trademark may be used and that the official name of the company holding the trademark is given afterwards in brackets. In the interest of limiting the length of the field organizationName, abbreviations are permitted, provided that they are not misleading.

3.2 Initial identity validation / erstmalige Identitätsfeststellung

All information on the certificate holder that is contained in the certificate, in particular their identity, is verified for accuracy in every form of certification. In the event that an applicant appears as a representative or organ of a certificate holder, in particular in connection with the issuance of certificates for particular organisations or domain names, the capacity of this person to act as a representative or organ is verified.Upon the initial application for a qualified, advanced or EV certificate, personal identity is confirmed by the CA or a person authorised by the CA.

3.2.1 Method to prove possession of private key / Nachweis über den Besitzes des privaten Schlüssels

Provided that the private key has not been issued by the operator, the operator requires proof from the subscriber that they are indeed in possession of the private key. Proof can be provided by technical procedures. Suitable technical methods are in particular the transmission of a Certificate Signing Request (CSR) signed with the private key.

3.2.2 Authentication of organizational identity / Authentifikation der Organisation

If an application contains information about an organisation, this data is verified. Likewise, it is verified as to whether the person making the application is authorised to request certificates for the organisation.
The measures and procedures to identify and register the applicant depend on the respective Trust Service and its juridical and in particular its legal requirements. They can also differ functionally as well as regionally.
All authorities and organisations recognised by the state that maintain public registers and verify identity before recording an entity in these registers are qualified to confirm the validity of an organisation. In case of EV certificates, the public registers used for organization authentifaction are disclosed at: http://www.globaltrust.eu/certificate-policy.html

3.2.3 Authentication of individual identity / Identitätsprüfung von Personen

The applicant must provide information about the type of official identification document, its number, information on the issuing authorities and the date of issuance.

a) Case Verification in person
If the identity of the applicant is verified by an authorised person (for example, the applicant is personally present in the offices of the CA or registration authority), the official identification document must be presented in original or as a notarised copy. Notarised copies must be submitted. The identity of the applicant, the kind of official personal document, its number, the issuing authority and the date of issue of the original documents are recorded. A submitted document can be rejected if it does not unequivocally establish the identity of the person, if it is not valid or no longer valid, or if the official character of the document is questionable. If the applicant cannot produce any suitable documents, the application is rejected on the basis that the authentication of identity has failed.
Requires the applicant informations about an organisation in the certificate and he isn’t authorizied to act for the organisation, it’s mandatory to obtain an authority by an official representant of the organisation, which should included in the certificate.

b) Case Verification not in person
If the identity of the applicant cannot be verified by their presence, the identity information and the information contained in the identification document, such as the type of official personal document, its number, the identity of the issuing authority and the date of issuance is collected. Furthermore, the information is checked for plausibility using submitted copies of the documents (an attestation is not necessary). If the plausibility check is not successful or concerns persist regarding the submitted documents, additional documents and contact points can be submitted or enquiries can be made at trustworthy public sources. If the applicant cannot sufficiently clarify this in spite of requests, the application is rejected on the basis that plausibility checks have failed.
The following information is obligatory for qualified certificates in addition to the minimum information described above:
– date and place of birth
– a nationally recognised identification number or an equivalent attribute which can be used to distinguish the person from another person with the same name.
Authentication of identity is completed when the application takes place in person at a registration authority and the applicant submits an official personal document in original or validation of identity can be confirmed by a certified legal opinion, especially authenticated validation of identity in original submitted by a court or notary (ð a) verification in person).
In all other cases of (b) verification not in person) the authentication of identity is completed during the processing of the application (ð 6.1.2 Private key delivery to subscriber / Zustellung privater Schlüssel an den Signator, p140) or through videobased online-identification (ð GLOBALTRUST Certificate Practice Statement 3.2.3 Authentication of individual identity / Identitätsprüfung von Personen).
The certificate can contain additional information on the subscriber: telephone number, fax number and e-mail address, information on profession and qualifications, and if necessary, further information. Individual information can be optional or obligatory depending on the Trust Service.

3.2.4 Non-verified subscriber information / Nicht-verifizierte Antragstellerdaten

The certificates inludes
a) Either certificates do not contain non-verified information (required in the case of qualified or EV certificates) or
b) if non-verified information is permitted (for example, the certificates are marked as test certificates), the Certificates are issued under separate test-CAs.
However, all designations are excluded that are misleading or evidently not permitted for other legal reasons. If the subscriber wishes to enter a trademark, the right to use the trademark is verified.

3.2.5 Validation of authority / Nachweis der Vertretungsbefugnis

The registration authority conducts the verification of authority and information/documents of the persons named in the application.

If the Trust Services have been requested on behalf of persons or organisations or evidence should be given of the power of authority to act for a third party, this is only possible if the requested representations on behalf of the third party are verified. The scope of authority and proof of authority for this kind of representation must comply with the law of the state in which the person or organisation, for which the Trust Services are undertaken, has domicile.
The CA or persons authorised to perform the certification will reject an application if doubt exists regarding the legal power of the agent to act on behalf of a third party. If the CA or persons authorised to perform the certification are informed after the fact of reasons that mean the agent cannot act as a representative, the Trust Services will be immediately suspended and the certificates revoked.

3.2.6 Criteria for interoperation / Kriterien für Interoperabilität

All cross certifications are disclosed if the CA has initiated and/or accepted the cross certification.

3.3 Identification and authentication for re-key requests / Identifikation und Authentifikation für Schlüsselerneuerung

All information on the certificate holder, in particular identity information, will be verified for correctness when the key is renewed.
Provided that the applicant does not request any changes, only the information that is subject to change since the initial application is verified for correctness, in particular control of domain names, design and trademark rights, place of business and the existence of the company.
Changes requested by the applicant will be treated the same as an initial application (ð 3.2 Initial identity validation / erstmalige Identitätsfeststellung, p54).

3.3.1 Identification and authentication for routine re-key / Identifikation und Authentifikation für routinemäßige Schlüsselerneuerung

Procedures as in ð 3.3 Identification and authentication for re-key requests / Identifikation und Authentifikation für Schlüsselerneuerung (p59).

3.3.2 Identification and authentication for re-key after revocation / Identifikation und Authentifikation für Schlüsselerneuerung nach Widerrufen

Procedures as in ð 3.3 Identification and authentication for re-key requests / Identifikation und Authentifikation für Schlüsselerneuerung (p59).

3.4 Identification and authentication for revocation request / Identifikation und Authentifikation für Widerrufsanträge

ð 4.9.2 Who can request revocation / Berechtigte für Antrag auf Widerruf

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS / Anforderungen Zertifikatslebenszyklus

Trust Services take place exclusively on the basis of defined business processes. The status of a certificate, a Trust Service and the status of the issuance of a certificate are documented using defined status values and is clearly documented at every point during the life cycle.
Critical disruptions, interruptions and failures are handled according to defined, internally documented business processes approved by the management. Irrespective of the remedy, an analysis and development of improvement measures to avoid such incidents in the future takes place in any case. In any case, in the event of any type of CA key being compromised (including algorithm compromise), the measures also include the revocation of the affected CA certificates.
A certificate, a signature creation device or equivalent product is only personalised and delivered after the administrative activities necessary for this service have been completed, in particular the successful completion of the necessary identity authentication.
The issuing of certificates to organizations that for whatever reason could lead to conflicts of interest is excluded.

4.1 Certificate Application / Antragstellung

The existing policy describes the basic application process, which can be elaborated upon pursuant to practical or legal circumstances. Every certificate issuance is preceded by an application.

4.1.1 Who can submit a certificate application / Berechtigung zur Antragstellung

Natural persons und organisations (especially corporations, societies, authorities, businesses) can submit applications or orders for Trust Services as they wish. There are no regional or practical limitations.
Requests for issuance of EV certificates must be made by a Certificate Requester and approved by an Certificate Approver. The policy and any other provisions (general terms and conditions, individual agreements) for the use of the certificate must be signed electronically or in writing by Contract Signatory. One person can also be designated to act in more roles, one role can also be occupied by more persons.
If the identity of the applicant has not yet been established, the applications are handled as anonymous. Authentication of identity takes place before a certificate is issued. The scope of this authentication is defined by the applicable certificate policy.
The time at which the application was made and the method by which the certificate data has been distributed (publicly accessible or not) is recorded in the application data.
In order to provide access to Trust Services for persons with disabilities in accordance with ETSI EN 319 549, applications can be submitted in any form (web form, email, port, telephone, fax …). There is no support for the use of signature products.

4.1.2 Enrollment process and responsibilities / Anmeldungsverfahren und Verantwortlichkeiten

Applications from organisations must be submitted by an authorised person. Persons submitting an application from the same address as the organisation concerned are presumed to have authority to act on behalf of the organisation. If the person making the application and the organisation concerned have different addresses, a person authorised to represent the organisation externally must confirm the authority of the person making the application.
Before the contract between the subscriber and the CA is completed, the policy and all other possible conditions (general terms and conditions, individual agreements) on the use of the certificate will be made available to the subscriber electronically or in written documents.
The following information will be retained:
– all documents und other information that concern the application process, including applications for the issuance or renewal of a certificate.
– all information that concern the approval of applications.

4.2 Certificate application processing / Bearbeitung von Zertifkatsanträgen

The data of the applicant will be verified on the basis of the following documents and sources of information[6]:
(1) confirmation by the applicant
(2) legal opinion
(3) confirmation from an auditor
(4) QIIS – Qualified independent information service [CABROWSER-EV]
(5) QGIS – Qualified government information service according to [CABROWSER-EV]
(6) QTIS – Qualified tax information service according to [CABROWSER-EV]
(7) Other reliable information sources according to
Before making use of any kind of information source, the operator reviews the quality applying the following criteria:
Publicliy available data sources must be updated at least anually
The operator of the data source has to verify the data in case it is self reported.
The acurracy of information has to be ensured
Resistance against falsification and alteration shall be ensured
In case of QIIS, QGIS and QTIS: further characteristics required by [CABROWSER-EV]
The operator never uses information sources that have not been designated as reliable.
The registration authority undertakes the following review of applications:
– Examination of the organisation and trademarks used by the organisation (according to credible certificates submitted by the applicant, as per disclosure (inc. requests to databases) from a qualified official source of information or with the assistance of a qualified independent source of information, especially the databases of trustworthy third parties)
– if a certificate can be used to sign emails, all email addresses entered in the certificate will be checked as to whether the applicant has control of these addresses or is authorised to use them by their owner. This can take place through sending a randomly generated 18-digit value to these addresses and obtaining a confirming response of the applicant, containing the value.
– if a certificate is suitable for SSL encryption on servers, all domain names entered in the certificate will be checked as to whether the applicant is the owner of the domain names or is authorised by the owner to use them. All IP addresses entered will be checked as to whether the applicant can use them. This can take place through direct communication with the owner of the domain or address according to publicly available databases. In any case specifications of the domain name records (DNS) observed. The check is in any case conducted by the operator itself.
– If a certificate is suitable for SSL encryption on servers, its contents will be verified for up-to-dateness and correctness at least every 825 days. For certificates issued on or after 1st September 2020, this verification will take place at least every 397 days.

4.2.1 Performing identification and authentication functions / Durchführung Identifikation und Authentifikation

For advanced signatures, governmental signatures or qualified certificates, authentication of the personal identity of the applicant is undertaken by the operator or by a person authorised by the operator or an entity that is authorised to authenticate identity, especially courts, notaries, delivery services that also offer authentication of identity for the delivery of documents (in Austria in particular, this is POST AG) or similar entities.
In all cases, authentication of identity of the applicant requires
– submission of official identification papers or
– personal recognition from the authority authenticating identity (persons authorised by the operator or employees of the authority), whereby the authority vouches for the identity of the person beyond doubt, documents the authentication and confirms this with a signature.
If the authentication is undertaken by an entity authorised to do so, this is regarded as completed when the necessary confirmation has been signed and returned to the operator with a memorandum provided by the authority.

4.2.2 Approval or rejection of certificate applications / Annahme oder Ablehnung von Zertifikatsanträgen / Approval or rejection of certificate applications

A certificate is issued only when the authentication procedures necessary for the respective type of certificate have been successfully completed.

After authentication, the application data is
(a) approved so that a certificate can be created or
(b) the applicant receives a request for further documents or
(c) the applicant is informed that the application has been rejected.
If the applicant does not meet the request to provide further documents even after a reminder, the application is rejected.
The operator rejects applications for the issuance of EV certificates if they involve an applicant, Certificate Requester, Certificate Approver or Contract Signer with whom the operator is prohibited from doing business by national or international regulations.

4.2.3 Time to process certificate applications / Fristen für die Bearbeitung von Zertifkatsanträgen

Applications for certificates are processed as per law, contractual agreements and the processing times given on the website.

4.3 Certificate issuance / Zertifikatsausstellung

The CA issues certificates based on a reviewed and approved application and the public key of the applicant.
Examination is understood to mean both the legal examination of the application and the technical examination of the application and issue data. The technical test is program-controlled and includes in particular test of X509v3 conformity, the use of the correct ASN1 syntax and all essential points according [CABROWSER-BASE] and [CABROWSER-EV].
The operator issues certificates as per the respective notice of the regulatory authority or based on the product description published on its website. In particular, these certificates are in X.509v3 format.
Certificates are only issued in a secure environment using predefined processes (security profiles and configurations) that check the authenticity of the certificate request and the integrity of the application data provided and proceed as per the applicable certificate policy.
The structure and content of the certificates comply with the applicable certificate policy. Qualified certificates for electronic signatures include all information necessary for electronic signatures and identification of the subscriber. Qualified server certificates include all information necessary for website authentication.
The certificate issuance procedures described in this section apply to
ð 4.6 Certificate renewal / Neuaustellung Zertifikat (p79)
ð 4.7 Certificate re-key / Neuausstellung des Zertifikats mit Erzeugung eines neuen Schlüsselpaares (p81)
ð 4.8 Certificate modification / Zertifikatsänderung (p83)

4.3.1 CA actions during certificate issuance / Vorgehen des VDA bei der Ausstellung von Zertifikaten

The processes (security profiles and configurations) necessary for the issuance of certificates are approved by the responsible authority as per ð GLOBALTRUST Certificate Security Policy.
The certificate is provided with the signature verification data of the operator[ and is electronically signed by the operator. The signature creation data used for this signature have been generated according to the requirements of [eIDAS-VO] and other legal and technical standards.
The formats of the certificates, especially qualified certificates, are defined in the applicable certificate policy. If there is no individual definition provided, [RFC5280] is applicable. Qualified certificates contain the information necessary as per [eIDAS-VO] Appendix I or Appendix IV and [ETSI EN 319 412]. In case of qualified server certificates, in addition [CABROWSER-EV] applies.
A protocol is created when issuing a certificate. The protocol can be submitted to regulatory authorities, accreditation organisations and other verification authorities upon request. Furthermore, all issuance procedures are logged that concern subscriber certificates, certificates and keys used by the operator for their signatures, cross-certificates and certificates containing identification and infrastructure keys.
An EV certificate or qualified certificate is always issued manually by an authorised person.
Data necessary for certification is transferred to the certification system via secure paths. The confidentiality and integrity of the information is also ensured. Secure paths include the use of, in particular, external data carriers intended solely for the purpose of delivering data, dedicated VPN tunnels between the administrative system and the certification system or equivalent, state-of-the-art measures. Requests for certificates are electronically signed.
All certificates are signed with a private key of the CA. Only CA certificates, cross-certificates, certificates for infrastructure assignments and internal certificates are issued with a root certificate.
According to Certificate Transparency (defined in [RFC6962]) server-certificates are disclosed on at least three audit-proof logservers operated by external entities. (Certificate Transparency according to [RFC6962]

4.3.2 Benachrichtigung des Signators über die Ausstellung des Zertifikats / Notification to subscriber by the CA of issuance of certificate

The subscriber is immediately informed by appropriate means that the certificate has been issued.
Appropriate means for informing the subscriber include, in particular
– by email (provided that an address has been given in the application or is known because of a previous business relationship) or
– by post or fax or
– on the phone or in person.
It is permitted to use more than one form of communication simultaneously.
This communication never contains confidential information that would allow use of the certificate on its own.

4.4 Certificate acceptance / Zertifikatsannahme

The subscriber should confirm that he has received the certificate and corresponding conditions of use, in particular this GLOBALTRUST Certificate Policy and the corresponding GLOBALTRUST Certificate Practice Statement.

4.4.1 Conduct constituting certificate acceptance / Verfahren zur Zertifikatsannahme

Confirmation that the certificate has been received is given either in written or electronic form, in compliance with the law.

4.4.2 Publication of the certificate by the CA / Veröffentlichung der Zertifikate

The necessary verification data, such as, in particular, the public signature key, hash values and further information on the operator, are published on the website of the operator (ð http://www.globaltrust.eu/certificate-policy.html)or in the link given in the applicable GLOBALTRUST Certificate Practice Statement. Every certificate contains a reference to the publicly accessible authority where the verification data can be accessed and requested.

4.4.3 Notification of certificate issuance by the CA to other entities / Benachrichtigung von Dritten über die Zertifikatsaustellung

Other organisations are informed immediately by the operator,
– if the certificate issued affects their activities or
– this has been contractually agreed or
– other legal conditions necessitate that they be informed.

4.5 Key pair and certificate usage / Schlüsselpaar und Zertifikatsnutzung

4.5.1 Subscriber private key and certificate usage / Nutzung des privaten Schlüssels und des Zertifikates durch den Signator

The CA contractually obligates the subscriber to comply with the following commitments.
All contractual conditions will be made available to the applicant on the website of the CA Website. The applicant confirms that he has received and accepted these simultaneous to sending the order form.
The subscriber is obligated to:
1. input complete and correct information in compliance with the requirements of this policy, especially during the registration procedure.
2. verify that all information in the certificate is correct directly after successful delivery.
3. retain the private key to a hardware unit to which the subscriber has sole access (for example, encrypted storage of a private key using a password, signature PIN or passphrase, special signature creation devices that prevent or essentially complicate the reading of a private key). For simple signatures, for example GLOBALTRUST CLIENT, limitations on access and organisational measures that limit access to the computer that contains the key and the certificate are also understood to be sufficient security measures for the purpose of this policy.
3a. In the case of private key management by the operator or a third party on behalf of the signatory in the context of server-based signature services, the signatory shall keep all components, information and procedures for the use of the private key under its sole control and protect them from access by unauthorised third parties.
3b. Insofar as a mobile telephone number is required for the use of the private key, the signatory shall use a telephone number at his sole disposal.
3c. retain the private key to a hardware unit to which the only duly mandated representatives of the subscriber (creator of a seal) have access. For example, encrypted storage of a private key using a password, signature PIN or passphrase, special seal creation devices that prevent or essentially complicate the reading of a private key. For simple seals, for example GLOBALTRUST CLIENT, limitations on access and organisational measures that limit access to the computer that contains the key and the certificate are also understood to be sufficient security measures for the purpose of this policy.
3d. In the case of private key management by the operator or a third party on behalf of the subscriber in the context of server-based signature services, the signatory shall keep all components, information and procedures for the use of the private key under their control and protect them from access by unauthorised third parties.
3e. Insofar as a mobile telephone number is required for the use of the private key, the creator of a seal shall use a telephone number that only can be used by duly mandated representatives..
3f. Insofar as a mobile telephone number is required for the use of the private key, the signatory shall use a telephone number at his sole disposal.
4. in the case of self-generation of a private key, appropriate secure procedures should be applied to ensure a sufficient quality of randomness in the generation of keys. In particular, these are hardware components explicitly intended for this purpose, such as HSM modules, or software components, which allow their user to increase the quality of randomness through system events (in particular the entry of files with random numbers, the performance of movements of the mouse or keystrokes during key generation). The CA reserves the right to require full disclosure of information on the key generation procedure from the subscriber and to reject a certification application if concerns arise over the quality of randomness of the key. Inappropriate key procedures are detailed on the website of the operator and may not be used.
5. use appropriate caution to prevent the unauthorised use of the private key.
6. use server certificates exclusively on devices that are accessible from the addresses listed in the certificate (for X.509v3 in the subjectAltName extension).
7. inform the operator immediately if one or more of the following circumstances arise before the validity of the certificate has expired:
– The transport-protection (e.g. the TransportPIN) for the signature creation device is not usable,
– the private key or its activation data has been lost,
– the private key of the subscriber or its activation data may have been compromised,
– The mobile phone has been stolen or otherwise got lost, in case a mobile phone is required as a signature activation component
– exclusive control over the private key has been lost,
– the information in the certificate is incorrect or has changed,
8. completely remove the key from operation immediately as soon as the subscriber becomes aware that it has been compromised.
9. completely remove the keyfrom operation if informed by the operator that the CA key has been compromised.
10. the secure safekeeping of the key remains the sole responsibility of the subscriber.
11. destroy invalid keys. This also applies for keys saved on signature creation devices. An appropriate method of destruction includes returning the signature creation device to the operator with a request to destroy the invalid key.
12. The subscriber should inform the user of signed data of his obligations for the purpose of this policy in a suitable way. He may not conclude agreements or provide explanations to a third party that contradict this policy, the applicable standards, the valid juridical, in particular legal, conditions, or the GLOBALTRUST Certificate Practice Statement.
13. The following limitations apply to the issuance of qualified certificates for electronic signatures:
The key pair may only be used for the generation of electronic signatures. All further limitations on the administration of keys of which the subscriber is informed should likewise be observed.
The certificate may only be used for electronic signatures that have been generated with the QSCD or QRSCD corresponding to the certificate.
14. In the event that the CA key or subscriber key has been compromised, the subscriber should follow the instructions of the CA within 48 hours. This time span is shortened if specific security risks are expected. In this event, the subscriber will be informed of the shortened reaction time by telephone, email or other suitable means.
15. The subscriber accepts that the CA can revoke a certificate in the event of a violation of the conditions of this policy, other agreements concluded with the subscriber, or the use of the certificate for criminal or fraudulent activities. Compensation will not be paid for a certificate revoked on these grounds or for resulting damages.
16. The signatory accepts that:
– In case the signatory looses his password, there is no possibility for reconstruction at the CA and therefore a chargeable new key generation and certificate issuance must take place.
– Five password misentries lead to account ban that only will be reversed in case the signatory can credibly assert that he caused the misentries himself
Enduser-sub-certificates whose private keys are under the control of the subscriber must fulfill additional conditions below the restrictions listed in ð 7.1.2 Certificate extensions / Zertifikatserweiterungen (p168).
These certificates contain an OID as a policy entry, with which it is shown that the user complies with the conditions and policies of a third party with whom the CA has concluded an agreement to recognise the CA certificates in advance. These are at least the [CABROWSER-BASE] and [MS‑CA] conditions. In this document, the subscriber also declares his EV policy (either a declaration that no certificate of this type has been issued or a declaration that conditions of [CABROWSER-EV] are observed). Furthermore, there is no “anyPolicy” entry in the certificate, in particular for x.509v3 certificates.
If the subscriber can issue certificates in the context of a enduser-sub-certificate assigned to him using an automated process, all inputs for email addresses, domain names and IP addresses may only originate from a predefined range that has been verified and agreed by a registration authority.
Additional conditions for the use of readable data carriers for private keys:
If the private key is stored in readable data carriers (floppy disk, USB stick, hard drive, etc), the subscriber is obligated to keep the necessary passwords separately and to take particular care of the data carrier. Transportable data carriers (floppy disk, USB stick, CD, …) should be kept in secure containers that are only accessible to the subscriber. Built-in, fixed data carriers (hard drive) should only be usable by the subscriber. System administrators should be contractually obligated to secure the confidentiality of the private key. It should be ensured that copies are only made when requested by the subscriber (this also applies for back-up copies).
Furthermore, the subscriber should ensure as per the current state of the art that the data carrier is free from malware that could read, copy or otherwise change the private key. In particular, the subscriber should undertake sufficient protection measures against malware of any kind, especially viruses, worms, programmes with trapdoor functions or spyware programmes that could compromise the private key, the certificate or another part of the signature process.

4.5.2 Relying party public key and certificate usage / Nutzung des öffentlichen Schlüssels und des Zertifikates durch Nutzer

Electronic signatures that use certificates that have been issued by the CA are only valid in the framework of this policy. Electronic signatures in this meaning are also timestamps, issued from the CA. Users of certificates and electronically signed information (including Timestamps) must therefore observe the following verification procedures:
– the verification will be documented to the extent necessary to record the facts,
– binding transactions of a value more than 100 000 EUR require a qualified signature.
– The user of the electronic signature must document the verification in written form and the verification should be performed by at least two persons working independently from one another.
The revocation status of a certificate is to be checked by the services provided by the CA.
– if the verification of a certificate for an electronic signature is not possible, it is the responsibility of the user whether he recognises the validity of the signatures. The CA or a third party is explicitly not responsible for this.
– Observance of the limitations on the use or validity of the certificate (especially observance of upper limits for amounts for which valid signatures can be issued), as given in the certificate (inc. reference to the applicable certificate policy) or in the published terms and conditions. The liability of the CA is also limited as per these limitations and upper limits.
– All precautions prescribed in agreements or elsewhere must be observed.
The user registers, that because of the fast progress of the cryptography technique and the improvement of computer systems, signatures and keys may get uncertain, even if at the time of issuing, the security of the signature was certain. It is advised to check the VDA website on “limits” to find constraints of the validity of signatures and certificates, that can not be published by revocation and / or the certificate content. This regards especially older signatures, in any case signatures that are older than 12 months.
In case of receiving a time stamp, the user has the same check duties as for other signatures. Furthermore, possible technical limitations that result from the issuing of the time stamp (ð 6.8 Time-stamping / Zeitstempel p160 and ð GLOBALTRUST Certificate Practice Statement 6.8 Time-stamping / Zeitstempel) must be considered.
If doubts over the validity of the certificate arise, especially if the means provided to request the status of suspension and revocation are not available, the CA should be contacted directly. The appropriate measures will then be taken to clarify the validity of the certificate.
The VDA registers all of the issued time stamps. In case of doubt about the validity of a time stamp, the VDA can check if the time stamp for a specific document was really issued by its service. For this purpose, the user only has to send the hash value of the document to the VDA. Than the user receives information whether and when a time stamp had been requested for this hash value.

4.6 Certificate renewal / Neuaustellung Zertifikat

The CA issues certificates as part of the renewal of a certificate on the basis of a reviewed and approved application and the public key of the applicant.
An existing certificate is not extended. It is however permitted to make a new certificate with a new duration and new certificate data using an existing key or an existing CSR (Certificate Signing Request), provided that the algorithms used comply with the current state of the art.

4.6.1 Circumstance for certificate renewal / Umstände für Neuaustellung eines Zertifikats

The renewal of a certificate is permitted if
– the kind of certificate allows this legally and
– there are no distinct reasons against renewal.

4.6.2 Who may request renewal / Berechtigte für Antrag auf Neuaustellung Zertifikat

The original applicant is authorised to apply for a renewal.

4.6.3 Processing certificate renewal requests / Bearbeitung eines Antrags auf Neuausstellung Zertifikat

It is ensured that applications from applicants who are already registered from a previous certificate issuance are complete, correct and properly authorised using the following measures:
– The registration authority verifies the data in the certificate for its current validity.
– Possible changes to the existing policy, terms and conditions and other agreements will be communicated.
– In case of renewal of a server certificate, a full validation without any reuse of completed prior validations takes place.
Information for server certificates issued before 1st September 2020 may be used again without renewed verification, provided that it is not older than 825 days.
Information for server certificates issued on or after 1st September 2020 may be used again without renewed verification, provided that it is not older than 397 days.
The CA renews certificates for which the key pair is retained on the basis of a reviewed and approved application and the public key of the applicant.

4.6.4 Notification of new certificate issuance to subscriber / Benachrichtigung des Signators über die Neuausstellung Zertifikat

Notification of a renewal is subject to the same procedures and restrictions as ð 4.3.2 Benachrichtigung des Signators über die Ausstellung des Zertifikats / Notification to subscriber by the CA of issuance of certificate (p70).

4.6.5 Conduct constituting acceptance of a renewal certificate / Verfahren zur Annahme nach Neuausstellung Zertifikat

The procedure for accepting certificates after renewal is subject to the same procedures and restrictions as in ð 4.4.1 Conduct constituting certificate acceptance / Verfahren zur Zertifikatsannahme (p70).

4.6.6 Publication of the renewal certificate by the CA / Veröffentlichung der Neuausstellung Zertifikat durch VDA

Publication of renewal is subject to the same procedures and restrictions as in ð 4.4.2 Publication of the certificate by the CA / Veröffentlichung der Zertifikate (p71).

4.6.7 Notification of certificate issuance by the CA to other entities / Benachrichtigung von Dritten über die Ausstellung eines Zertifikates

Notification of renewal is subject to the same procedures and restrictions as in ð 4.4.3 Notification of certificate issuance by the CA to other entities / Benachrichtigung von Dritten über die Zertifikatsaustellung (p71).

4.7 Certificate re-key / Neuausstellung des Zertifikats mit Erzeugung eines neuen Schlüsselpaares

Certificate re-key is subject to the same procedures and restrictions as in ð 4.6 Certificate renewal / Neuaustellung Zertifikat (p79).

4.7.1 Circumstances for certificate re-key / Umstände für Neuausstellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares

Certificate re-key is permitted if
– the type of certificate allows this legally and
there are no distinct reasons against a renewal.

4.7.2 Who may request certification of a new public key / Berechtigte für Antrag auf Neuaustellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares

The subscriber is authorised to make an application for renewal.

4.7.3 Processing certificate re-keying requests / Bearbeitung eines Antrags auf Neuausstellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares

The processing of an application for re-keying is subject to the same procedures and restrictions as in ð 4.6.3 Processing certificate renewal requests / Bearbeitung eines Antrags auf Neuausstellung Zertifikat (p80).

4.7.4 Notification of new certificate issuance to subscriber / Benachrichtigung über die Neuausstellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares

Notification of the renewal of a re-keyed certificate is subject to the same procedures and restrictions as 4.6.4 Notification of new certificate issuance to subscriber / Benachrichtigung des Signators über die Neuausstellung Zertifikat (p80).

4.7.5 Conduct constituting acceptance of a re-keyed certificate / Verfahren zur Zertifikatsannahme nach Neuausstellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares

The procedure for accepting a certificate after renewal is subject to the same procedures and restrictions as in ð 4.6.5 Conduct constituting acceptance of a renewal certificate / Verfahren zur Annahme nach Neuausstellung Zertifikat (p81).

4.7.6 Publication of the re-keyed certificate by the CA / Veröffentlichung der Neuausstellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares durch VDA

Publication of a re-keyed certificate is subject to the same procedures and restrictions as in ð 4.6.6 Publication of the renewal certificate by the CA / Veröffentlichung der Neuausstellung Zertifikat durch (p81).

4.7.7 Notification of certificate issuance by the CA to other entities / Benachrichtigung von Dritten über Neuausstellung Zertifikat mit Erzeugung eines neuen Schlüsselpaares

Notification of the issuance of a re-keyed certificate is subject to the same procedures and restrictions as in ð 4.6.7 Notification of certificate issuance by the CA to other entities / Benachrichtigung von Dritten über die Ausstellung eines Zertifikates (p81).

4.8 Certificate modification / Zertifikatsänderung

Certificate modification is subject to the same procedures and restrictions as in ð 4.6 Certificate renewal / Neuaustellung Zertifikat (p79)
An existing certificate is not modified. It is however permitted to make a new certificate with new certificate data using an existing key or an existing CSR (Certificate Signing Request).

4.8.1 Circumstances for certificate modification / Umstände für Zertifikatsänderung

Certificate modification is permitted if
– the type of certificate legally permits this and
– there are no distinct reasons against a renewal.

4.8.2 Who may request certificate modification / Berechtigte für Antrag auf Zertifikatsänderung

The subscriber and persons authorised to represent the company as listed in the certificate are authorised to make an application for a modification.

4.8.3 Processing certificate modification requests / Bearbeitung eines Antrags auf Zertifikatsänderung

Certificate modifications are subject to the same procedures and restrictions as in ð 4.6.3 Processing certificate renewal requests / Bearbeitung eines Antrags auf Neuausstellung Zertifikat (p80)
In addition, modified data is reviewed in the same way as new certificate applications.

4.8.4 Notification of new certificate issuance to subscriber / Benachrichtigung über die Zertifikatsänderung

Notification of certificate modification is subject to the same procedures and restrictions as in 4.3.2 Benachrichtigung des Signators über die Ausstellung des Zertifikats / Notification to subscriber by the CA of issuance of certificate (p38).

4.8.5 Conduct constituting acceptance of modified certificate / Verfahren zur Zertifikatsannahme nach Zertifikatsänderung

The procedure for accepting certificates after modification is subject to the same procedures and restrictions as in ð 4.4.1 Conduct constituting certificate acceptance / Verfahren zur Zertifikatsannahme (p70).

4.8.6 Publication of the modified certificate by the CA / Veröffentlichung der Zertifikatsänderung

Publication of the certificate modification is subjected to the same procedures and restrictions as in ð 4.4.2 Publication of the certificate by the CA / Veröffentlichung der Zertifikate (p71).

4.8.7 Notification of certificate issuance by the CA to other entities / Benachrichtigung über die Zertifikatsänderung

Notification of certificate modification is subject to the same procedures and restrictions as in ð 4.4.3 Notification of certificate issuance by the CA to other entities / Benachrichtigung von Dritten über die Zertifikatsaustellung (p71).

4.9 Certificate revocation and suspension / Zertifikatswiderruf und -sperre

A two-tier revocation concept is used to ensure the most practical usage of the certificate possible:
– suspension of the validity of the certificate
– declaration of invalidity of the certificate (revocation)
Applications for suspension and revocation are made through the published channels and the subscriber must make sure that the application has been received.

The CA makes the follow options available:
(a) Suspension
The validity of a certificate is temporarily suspended. This can be prompted manually or automatically and is at maximum valid for the legally and technically permitted duration.
(b) Revocation
This leads to the certificate being declared invalid early.
(c) Deactivation
Upon the signatory’s request it is possible to only deactivate the second authentication factor instead of certificate suspension or revocation. This procedure only applies if the private key is not compromised, but the signatory otherwise has doubts about the signing process (e.g. in case a mobile phone used as signature activation component gets lost)

A revocation leads to the early termination of the validity of a certification. Reactivation is not possible. The revocation is performed under the control of at least two people as per the role concept as defined in ð GLOBALTRUST Certificate Security Policy.
Certificate suspensions can be recorded in a suspension list. The suspension indicates that the certificate may have been compromised. A suspension can be lifted. A subscriber is informed that a certificate suspension has been received and is requested to confirm or lift the suspension.
Electronic signatures that have been issued before suspension or revocation retain their validity.
The information that a certificate has been suspended or revoked is publicly available.
Server certificates cannot be suspended.

The third party may report suspected problems or abuse of the certificates. The CA follows up on this report and revokes or suspends the corresponding certificates if needed.
If an event that could make a revocation necessary has not been conclusively verified, an application for suspension of the certificate should be made.
If a certificate is to be revoked, a revocation protocol is generated (ð Appendix / Anhang A: 2 Content Certification-Protocols / Inhalt Ausstellungs-, Sperr-, Entsperr- und Widerrufs-Protokoll für Zertifikate) (p219). The revocation protocol can be submitted to regulatory authorities, accreditation organisations or other authorised authorities if necessary. Furthermore, all procedures relevant to revocation of subscriber certificates, certificates and keys used by the CA for signature purposes, cross certificates and the certificates for identification and infrastructure keys will be recorded.
Subscribers are informed of the suspension or revocation of their certificate by appropriate means. Appropriate means include, in particular, information sent to a verified email address that the subscriber has given and that has not been documented as invalid, information given by telephone using a telephone number given by the subscriber or by fax, if a fax number has been provided by the subscriber. In all other cases, the subscriber is informed by post.

4.9.1 Circumstances for revocation / Umstände für Zertifikatswiderruf

A certificate is revoked if the further use of the key in the sense of this policy is no longer ensured.

Reasons for revocation include:
1. The subscriber or applicant makes a written application.
2. A communication from the applicant that the original certificate application was not sufficiently authorised and that he has not subsequently granted this authorisation.
3. The operator receives proof that the private key used has been compromised or no longer complies with current technical requirements.
4. The operator receives proof that the certificate has been misused.
5. The operator becomes aware that the subscriber has violated the terms of use, the Certificate Policy, the Certificate Policy Statement or another contractual agreement.
6. The operator becomes aware that the subscriber is no longer legally authorised to use a designation in the certificate, in particular an email address, domain name or an IP address.
7. The operator becomes aware that a wild card certificate has been used to authenticate a subdomain with fraudulent intent or intent to deceive.
8. The operator becomes aware of a significant change to the information recorded in the certificate.
9. The operator establishes that the information recorded in the certificate is inaccurate or misleading.
10. The CA discontinues its operations and has not concluded an agreement with another operator to continue operations.
11. The operator loses the right to issue the respective type of certificate, unless it has concluded an agreement to continue the revocation status service.
12. The operator receives proof that the private key of a CA certificate has been compromised.
13. Circumstances arise that make the technical content or format of the certificate an unacceptable security risk.
14. The operator has evidence of use of the certificate by the subscriber that is contrary to the contract. In particular, this includes breaches of this policy, the GLOBALTRUST Certificate Practice Statement, the agreed GTCs or other individual agreements (inc. service and payment obligations).
15 The operator obtains evidence that a validation that had been performed in order to issue a certificate can not be relied upon.
16 The operator becomes aware that a certificate has been issued in violation of this policy, the GLOBALTRUST Certificate Practice Statement or any of the then current requirements listed in (ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen, p178
The subscriber accepts that the operator can revoke a certificate in the event of the violation of the conditions of this policy, other agreements concluded with the subscriber or the use of the certificate for criminal or fraudulent activities at any time. Compensation for certificates revoked on these grounds or resulting damages will not be paid.
Certificates for keys that have been issued according to procedures that are no longer seen as secure as defined by legal conditions, especially the Signature Act ([SVV]) or a decision of a regulatory authority or recognised standardisation regimes (in particular as per the special recommendations [ETSI TS 119 312]) or on the grounds of internal knowledge, will be revoked by the operator and all affected parties will be informed of this.
The operator has the right to revoke a certificate for organisational or technical reasons at any time. If a certificate is revoked on these grounds prior to the contractually agreed duration of validity of the certificate and the subscriber is not responsible for this, the subscriber is entitled to an equivalent certificate to be issued using secure procedures for the remaining duration of the contractually agreed term. Other reimbursement or compensation is not envisaged.

A CA-certificate or enduser-sub-certificate will be revoked within 7 days (unless shorter time limit is mandatory in this policy specified) if one of the following criteria has been fulfilled:
1. A written application by the applicant.
2. A communication from the applicant that the original certificate application was not sufficiently authorised and that he has not subsequently granted authority.
3. The operator receives credible evidence that the private key used has been compromised or no longer complies with current technical requirements.
4. The operator receives evidence that the certificate has been misused.
5. The operator becomes aware that the subscriber has violated the terms of use, the Certificate Policy, the Certificate Practice Statement, the agreement on the use of the enduser-sub-certificate, a compulsory technical standard (especially [CABROWSER-BASE]) or another contractual agreement.
6. The CA establishes that the information in the certificate is erroneous, incorrect or misleading.
7. The operator of the enduser-sub-certificate discontinues his activities and has not made provisions for them to be transferred elsewhere.
8. The agreement with the operator that the enduser-sub-certificate can be used to issue certificates has expired, unless an additional agreement is made that the revocation service will continue.
9. A further item in this Certificate Policy or GLOBALTRUST Certificate Practice Statement requires the revocation.
10. Circumstances arise that make the technical content or format of the certificate an unacceptable security risk.
11 The operator becomes aware that a certificate has been issued in violation of this policy, the GLOBALTRUST Certificate Practice Statement or any of the then-current requirements listed in (ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen, p178
4.9.2 Who can request revocation / Berechtigte für Antrag auf Widerruf
The following are authorised to revoke and suspend certificates:
– the subscriber,
– the applicant,
– in all cases in which the subscriber is acting on the behalf of another person or an organisation and the certificate has been issued for this purpose, this person or an authorised representative of the organisation,
– the operator, as per the conditions in ð 4.9.1 Circumstances for revocation / Umstände für Zertifikatswiderruf (p46),
– other regulatory or control entities, if this is necessary because of compulsory requirements.
If an application for revocation is made by someone other than the operator, a complete verification of identity and authorisation to request revocation is compulsory.

4.9.3 Procedure for revocation request / Stellung eines Widerrufantrages

A revocation request can be made on the telephone, by fax, by email, in written form (ð Contact information/ Contact: http://www.globaltrust.eu/impressum.html) or on the website (ð Suspension or revocation/ Suspension(Sperre) / Revocation(Widerruf): http://www.globaltrust.eu/revocation.html), stating the relevant certificate information and identifiers (product name, serial number, fingerprint, ..) that clearly identify the certificate and sufficient proof of authorisation to make the request.
The CA retains the right to request further proof of authorisation and to suspend a certificate rather than revoke it, if there is doubt as to whether the person making the request is authorised to do so.
The authorised applicant may request the certificate to be revoked immediately.
The authorised applicant may request the certificate to be revoked at a future date.

4.9.4 Revocation request grace period / Informationsfrist für Antragstellung auf Widerruf

If a natural or legal person as per ð 4.9.2 Who can request revocation / Berechtigte für Antrag auf Widerruf (p91) has information that could lead to revocation as per ð 4.9.1 Circumstances for revocation / Umstände für Zertifikatswiderruf (p87), this should be provided to the operator. For qualified certificates this should be done immediately. For all other kinds of certificates operated in accordance [ETSI EN 319 411-1], this should be done as soon as possible. A certificate can be suspended independently of this, at any time and without reason.
In such a case, the VDA will decide within 24 hours whether a revocation or other action should be taken, taking into account the nature of the reported circumstance, the number of reports on a particular certificate, the organization that issues the report and the relevant legislation.

4.9.5 Time within which CA must process the revocation request / Reaktionszeit des VDAs auf einen Widerrufsantrag

Requests by telephone, fax, post and email will be received and processed within the office hours given in the GLOBALTRUST Certificate Practice Statement and will be subject to all necessary reviews after completion.
Revocation requests can be made via a web interface around the clock.
The maximum duration permitted between receiving the request and performing it depends on the current legal conditions, but is less than 24 hours.
For qualified certificates, the revocation is executed within three hours of the request on business days from 9am to 5pm, with the exception of Saturdays. Outside of these times, a suspension is performed within six hours.
If the applicant cannot provide sufficient information to reliably confirm his identity and authorisation to request a revocation between the time of the request and the maximum permitted response time, the revocation will be rejected and a suspension performed instead.
The applicant must provide sufficient information to reliably confirm his identity and authorisation to request a revocation within the maximum permitted duration of suspension (ð(a) Suspension, p85). If this is not possible within this time, the suspension will be lifted.
In the processing of revocation and suspension requests, individual cases may be treated with priority due to their underlying risk. If proof of prosecutable behaviour is found, the relevant authorities may be notified.
Confirmation of receipt may be delivered automatically or manually during the subsequent office hours. In the event of doubt, the subscriber should repeat his request for suspension or revocation. Confirmation of receipt is not confirmation that the request has been processed. Confirmation that the revocation has been processed can be obtained from the CA manually during the office hours subsequent to the request, is automatically available as an entry in the corresponding revocation list and takes place – if applicable – via an eMail to the subscriber Confirmation of the rejection of a revocation request requires a review by authorised personnel and takes place during the office hours following the request.

4.9.6 Revocation checking requirement for relying parties / Verpflichtung der Nutzer zur Widerrufsprüfung

Revoked (or suspended) certificates can be confirmed using the associated suspension or revocation lists.
The user must carefully examine the validity of the certificate by looking at the suspension and revocation status and using the request channels provided by the CA (ð 4.5.2 Relying party public key and certificate usage / Nutzung des öffentlichen Schlüssels und des Zertifikates durch Nutzer, p77).
The relying party must treat a certificate as revoked, if a single certificate status service among multiple certificate status services provided by the operator, reponses so.

4.9.7 CRL issuance frequency (if applicable) / Frequenz der CRL-Erstellung

Suspension and revocation lists (CRL, Certificate Revocation List) are updated according to technical standards, the law, the GLOBALTRUST Certificate Practice Statement and the applicable certificate policy. If conditions given in these sources contradict each other, the lists will be updated according to the shortest time necessary. Updated revocation information is available at the latest within an hour.
Suspension or delta revocation lists (if available) are issued on a daily basis or more often, as far as technically and legally required. As a rule, the delta revocation lists are empty and serve to document the up-to-dateness of the CRL. The revocation lists for root certificates (CARL) are issued for a period of one year and renewed within this period, at least if a revocation occurs.
In the case of cross certificates, the CARL will be created for at least 31 days and renewed within this period, or at least if a revocation occurs. If the cross-certified CA is no longer active, all certificates and CRLs relating to it will be revoked immediately.
Suspension and revocation lists are updated immediately after a suspension or revocation of a qualified certificate has been completed. This also automatically updates the OCSP[8] answers.
Revocation and suspension lists for server-certificates (EV included) are valid for a maximum of 10 days (and updated at least every 7 days). OCSP answers are valid for 10 days (the data for which is updated every 4 days).
Revocation and suspension lists for CA certificates that issue EV certificates are valid for 12 months and are updated within 24 hours of a processed revocation. The data for the OCSP answers for these certificates is updated at least every 12 months, and within 24 hours of a processed revocation.
Information on revoked certificates is kept until at least the expiry of the certificate.
The time used for revocation services is synchronized with public time servers at least every hour by appropriate technical procedures.

4.9.8 Maximum latency for CRLs (if applicable) / Maximale Verzögerung der Veröffentlichung der CRLs

Suspension and revocation lists accessible on the internet are updated after every suspension and revocation.

4.9.9 On-line revocation/status checking availability / Möglichkeit der online Widerrufsprüfung

The registry for suspension and revocation lists is publically and internationally available. It is not possible to prevent the publication of revocations and suspensions.

4.9.10 On-line revocation checking requirements / Voraussetzungen für die online Widerrufsprüfung

It is ensured that the entire revocation list chain for EV certificates can be downloaded over an analogue telephone line within 3 seconds under normal circumstances. The response times for CRL and OCSP requests remain under 10 seconds under normal circumstances.

4.9.11 Other forms of revocation advertisements available / Andere verfügbare Widerrufsdienste

The operator reserves the right to provide further revocation services. These are announced on the website of the operator.
The current status of a qualified certificate can be requested using OCSP. OCSP Stapling is not supported.
Users can request the current status of an issued certificate from the operator, regardless of the technical availability of revocation services.

4.9.12 Special requirements related to key compromise / Spezielle Anforderung bei Kompromittierung des privaten Schlüssels

If it is suspected that a private key has been compromised, this must be reported to the CA immediately. Revocation of compromised private keys is given priority.

4.9.13 Circumstances for suspension / Umstände für Zertifikatssperre

Reasons for suspension include:
1. The subscriber or applicant makes a written request.
2. A communication from the applicant that the original certificate application was not sufficiently authorised and that he has not subsequently granted authorisation.
3. The operator receives notice that a used private key has been compromised or no longer complies with current technical requirements.
4. The operator receives notice that the certificate has been misused.
5. The operator receives notice that the subscriber has violated the terms of use, the Certificate Policy, the Certificate Practice Statement or another contractual agreement.
6. The operator receives notice that the subscriber is no longer legally authorised to use a name that has been entered into the certificate.
7. The operator receives notice that a certificate has been used with fraudulent intent or intent to deceive.
8. The operator receives notice of a significant change that affects the information in the certificate.
9. The operator suspects that the information in the certificate is incorrect or misleading.
10. The operator receives notice that the used private key of a CA certificate has been compromised.
11. The operator has evidence that the subscriber has used the certificate contrary to the contract. Use contrary to the contract includes, in particular, breaches of this policy, the GLOBALTRUST Certificate Practice Statement, the agreed GTCs or other individual agreements (inc. service and payment obligations).

4.9.14 Who can request suspension / Berechtigte für Antrag auf Sperre

The following are authorised to request suspension:
– the subscriber or applicant
– if the subscriber is acting on the behalf of another person or an organisation and the certificate has been issued for this purpose, this person or an authorised representative of the organisation,
– the operator, as per the conditions ð 4.9.1 Circumstances for revocation / Umstände für Zertifikatswiderruf (p87),
– other regulatory or control authorities, if this is legally required according to compulsory requirements

4.9.15 Procedure for suspension request / Stellung eines Antrages auf Sperre

A suspension request can be made by giving the relevant certificate information and identifiers (product identifier, serial number, fingerprint) and credible proof of authorisation.
Suspension requests made via the web interface are automatically processed, if they are sufficiently specific and the relationship between the applicant and the certificate concerned can be established (otherwise they will be treated like emails).
A suspension comes into effect automatically after the suspension request has been made. Identity can also be automatically verified, for example, using login data that has been issued by the CA or data that is known or accessible only to the subscriber. If the certificate is not suspended or suspended late or otherwise erroneously, the applicant can contact the CA, who will examine the cause of the erroneous suspension.
The procedure is otherwise identical to the ð 4.9.3 Procedure for revocation request / Stellung eines Widerrufantrages (p91).

4.9.16 Limits on suspension period / Dauer einer Zertifikatssperre

A suspension becomes a revocation if the suspension is confirmed, there is no response or there is no request made to lift the suspension within the legal maximum suspension period.
If a suspension is lifted, a protocol will be issued with the same information as in the case of a suspension.

4.10 Certificate status services / Zertifikatsstatusdienste

The operator provides sufficient services to establish the status of the certificate.
Apart from the standardised provision of the registry and revocation services, the status of an issued certificate can be obtained on a case-by-case basis. This can be obtained orally, by phone, by email or by other electronic means. Further standards can be provided according to legal, customer-specific or other requirements. The reliability and integrity of this disclosure is also given together with the status of the certificate. Disclosures electronically signed by the CA are binding until their expiry or revocation.
The CA can confirm the subscriber for whom a qualified certificate has been issued and the validity of the certificate within the duration legally provided for, which is at least 35 years after issuance.
All certificates issued by GLOBALTRUST will be made available to subscribers and users using the following means:
1. On principle, all certificates are published in the registry of the CA. User details are published on the website of the CA (ð http://www.globaltrust.eu/directory.html).
2. The CA makes all parties concerned aware of the conditions of use of a certificate through the GLOBALTRUST Certificate Policy together with the corresponding GLOBALTRUST Certificate Practice Statement.
3. The registry is a ð permanent service. Interruptions of more than 24 hours will be logged as failures. Interruptions for qualified certificates of more than 30 minutes will be logged as failures. This documentation is available to regulatory authorities and auditors. The documents will also be made available to a third party within a relevant timeframe, if they possess a legitimate interest.
4. The registry is publicly and internationally accessible.
An omission is made from the registry if
– the subscriber wishes this or other substantial reasons exist and
– the type of Trust Service permits this (as constrained by the content of the announcement at the regulatory authority and the requirements of standards and laws or other binding legal requirements)
Information on the holder of a certificate that has not been automatically published in the registry will be disclosed if the person requesting the information proves that they have a legitimate interest.
It is not possible to prevent suspended or revoked certificates from being published in the registry.

4.10.1 Operational characteristics / Betriebliche Voraussetzungen

Access to publicly accessible data, such as the registry, revocation lists, suspension lists, certification status services, information on the applicable certificate policy, information services etc, is controlled and uses a firewall configured to the state of the art.

4.10.2 Service availability / Verfügbarkeit

Certificate status services, and in particular suspension and revocation lists, are available 24/7/365.

4.10.3 Optional features / Zusätzliche Funktionen

The operator reserves the right to specify further features in the GLOBALTRUST Certificate Practice Statement.

4.11 End of subscription / Vertragsende

Certificates are issued with a limited validity period. The maximum duration possible is the duration of the certificate that signs the issued certificate. The maximum duration of qualified certificates is set by legal requirements.
Changes are permitted if they are set out in the applicable GLOBALTRUST Certificate Practice Statement and do not contradict legal or technical requirements. If the duration of a certificate is longer than the duration of the signing certificate, it retains its validity, as long as it was issued during the validity period of the signing certificate and has not been revoked.
Expired certificates are not revoked. Electronic signatures that were generated during a certificate’s validity period retain their validity after the certificate has expired.
The obligations for the CA, operator and subscriber that come from this GLOBALTRUST Certificate Policy and the GLOBALTRUST Certificate Practice Statement persist after the end of the validity period of the certificate for the applicable duration.

4.12 Key escrow and recovery / Schlüsselhinterlegung und -wiederherstellung

Features for recovery or archiving of keys are not provided. Keys suitable for qualified electronic signatures are saved only in the appropriate security hardware and provided to the subscriber. All other keys are kept as encrypted data only until delivery to the subscriber is complete.

4.12.1 Key escrow and recovery policy and practices / Policy und Anwendung von Schlüsselhinterlegung und -wiederherstellung

Key escrow features are not provided.

4.12.2 Session key encapsulation and recovery policy and practices / Policy und Anwendung für den Einschluß und die Wiederherstellung von Session keys

Session key encapsulation and recovery features are not provided.

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS / Anforderungen Standort, Management und Betrieb

The CA is responsible for the organisation and documentation of all processes in the context of Trust Services (including time stamp services). This also applies to services outsourced to a contracted partner. The documentation formats used are a part of the GLOBALTRUST Certificate Security Policy. The documentation method used is internally documented.
The tasks and assigned responsibilities of the contracted partner are clearly regulated. In addition, controls are established to check that activities are performed properly.
The Trust Service includes the technical (automated) permanent availability of the revocation list. This also applies to the automated acceptance of revocation requests.
The availability of central Trust Services
– distribution of CA certificates
– suspension and revocation management and
– distribution of revocation statuses
uses redundant system components and is subject to continual supervision. The availability target of the central Trust Services is 99.9% in a month. Availability is measured and recorded by the operational monitoring. The records are kept for at least a year and register the start and end points of failures. If the availability target has not been reached in a particular month, additional organisational and technical measures are deployed to improve availability.
If availability does not comply with the requirements of the regulatory authority or the law, this will be communicated according to legal requirements and agreements. Failures are documented internally and, as far as possible, measures are developed to prevent them in the future.
Approaches fundamental to security are documented in this policy. In addition to this, the CA deploys specific security measures as set out in the non-public GLOBALTRUST Certificate Security Policy. These security measures are deployed in compliance with security targets and guidelines as per the GLOBALTRUST Certificate Practice Statement.

All operational procedures are documented and are subject to this GLOBALTRUST Certificate Policy, the GLOBALTRUST Certificate Security Policy and the applicable GLOBALTRUST Certificate Practice Statement.

5.1 Physical controls / Bauliche Sicherheitsmaßnahmen

The Trust Services are conducted only in appropriate premises. The details are as set out in the GLOBALTRUST Certificate Security Policy.

5.1.1 Site location and construction / Standortlage und Bauweise

The management of the CA decides where the Trust Services take place, taking the requirements of the GLOBALTRUST Certificate Security Policy into account.

5.1.2 Physical access / Zutritt

It is ensured that access to the premises in which functions critical to security are performed is restricted and that the risk of physical damage to facilities is minimised.
In particular, the following security measures apply:
1. Access to devices upon which certification and revocation services are performed is restricted to authorised personnel only. The systems that issue certificates are physically protected from the threat of environmental disasters.
2. Security measures are taken to prevent the loss, damage or compromising of facilities and interruption of operations.

5.1.3 Power and air conditioning / Stromnetz und Klimaanlage

Power and air conditioning are available in sufficient quantity. Details are given in the GLOBALTRUST Certificate Security Policy.

5.1.4 Water exposures / Gefährdungspotential durch Wasser

The location of components critical to certification is selected so that water damage is unlikely. Details are provided in the GLOBALTRUST Certificate Security Policy.

5.1.5 Fire prevention and protection / Brandschutz

Sufficient precautions are made to protect against fire. Details are given in the GLOBALTRUST Certificate Security Policy.

5.1.6 Media storage / Aufbewahrung von Speichermedien

Media is stored securely away from components critical to certification. Necessary measures are detailed in the GLOBALTRUST Certificate Security Policy.

5.1.7 Waste disposal / Abfallentsorgung

Waste is disposed according to local legal requirements.
Technische Systems and Documents that – for whatever reason – are to be taken out of service are disposed of securely. This includes the separation of parts containing confidential data (e.g., disks such as hard disks, …) and other hardware components. Those parts which contain confidential data are so far destroyed under the supervision of an employee of the operator that a data reconstruction is impossible. All components are disposed of in accordance with existing waste management regulations.

5.1.8 Off-site backup / Offsite Backup

Backups are stored away from components critical to certification. Necessary measures are given in the GLOBALTRUST Certificate Security Policy.

5.2 Procedural controls / Prozessanforderungen

Trust Services (particularly application, issuance, processing and revocation of certificates) are performed under a strict separation of administrative and technical operations.
Organisational measures for secure management are of central importance to the operator. Particularly in the event of failure or unforeseen events (“stress” situations), appropriate strategies and general measures should cover instances that could not fully be defined as business processes beforehand.
Main general measures include:
a) four-eyes principle for critical processes
b) motivated employees
c) clear and distinct distribution of responsibilities
d) comprehensive documentation of operational events
e) cooperative exchange of information in the context of an institutionalised certification committee
All administrative business processes relevant to certification are documented in an internal content management and monitoring system. These processes are described, administered and used in internal documentation.
All management activities involving category 1 keys, in particular the activation of the systems required for certification, key generation, backup, activation, deactivation and destruction of keys, are based on protocols, audits, defined roles and four-eyes principle, and are subject to specific internal policies documentation. Reports are signed by the responsible persons. Before starting any activity, it is checked to see if the system is in an intact, correct and untampered status.

5.2.1 Trusted roles / Rollenkonzept

The role concept, role description and role responsibilities are defined in the ð GLOBALTRUST Certificate Security Policy. Changes in the distribution of roles are to be carried out so that all the activities necessary in this practice statement and in the certificate policies can be fulfilled and a satisfactory replacement provided.

5.2.2 Number of persons required per task / Mehraugenprinzip

Critical processes are subject to the four-eyes principle. The persons involved are documented.

5.2.3 Identification and authentication for each role / Identifikation und Authentifikation der Rollen

Employees authenticate themselves clearly during Trust Services. If an employee has been logged out, they must re-authenticate. All authentication identifiers are unique and only assigned once. The authentication identifiers of former employees are deactivated and documented.
Authorised employees identify themselves to the certification system using multi-factor-autentication, at least a hardware token (with an identification key) and a password. This fulfils the requirements described in ð 6. TECHNICAL SECURITY CONTROLS / Technische Sicherheitsmaßnahmen (p128) for identification keys (ð Category/Kategorie 3, p129)

5.2.4 Roles requiring separation of duties / Rollenausschlüsse

All employees are engaged only in the roles that have been defined for them and are briefed and trained in the necessary operational procedures. They receive only the access rights and tokens necessary to undertake their role.

5.3 Personnel controls / Mitarbeiteranforderungen

All employees engaged in Trust Services have the necessary expertise, in particular employees who administer the orders of signature products, supervise technical operations and conduct development of certification products.
The management of the CA can task suitable authorised persons or suitable contractors according to the role concept in this policy (ð GLOBALTRUST Certificate Security Policy) for the purpose of performing Trust Services. These persons or contractors plan and implement all operative measures including the establishment of necessary documentation, certification guidelines and operational premises.
In any case, the role concept describes the roles Security Officer, Registration Officer (including revocation), System Auditor and System Administrator. The functions are staffed separately. Details and actual responsibility are documented internally.
All employees working in connection with Trust Services only perform the tasks assigned to them in the context of the role concept and are independent, in particular free of pressure from the management.
The system administrators and other persons charged with certification tasks are contractually obliged to comply with data security requirements as per the existing laws and standards.
The employees of the CA are particularly suitable as qualified personnel to implement and secure the requirements anchored in this policy.
A certificate committee is established to govern Trust Services and meets on request. More detailed criteria regarding the composition and calling of meetings are defined in the role concept (ð GLOBALTRUST Certificate Security Policy).
The employees of the TSP receive only the necessary user and administrator rights for their work. The rights granted are reviewed at least quarterly and adjusted if necessary. Rights not needed are deactivated promptly.
All employees involved in Trust Services are independent of other companies and organizations.

5.3.1 Qualifications, experience, and clearance requirements / Anforderungen an Qualifikation, Erfahrung und Zuverlässigkeit

The requirements are described in the role concept (ð GLOBALTRUST Certificate Security Policy).
– Functions and responsibilities relevant to security are documented in internal job descriptions and in the internal role plan. Functions that are essential for the security of Trust Services are clearly defined.
– Job descriptions stating responsibilities, access rights and competences are developed for all employees of the CA.
– All management functions are occupied by persons who have experience in the technology of electronic signatures and encryption.
– The CA does not employee persons who have committed prosecutable acts that indicate that they would be unsuitable for a position of trust.
– The identity and trustworthiness of all people involved in the operation of Trust Services is checked before they are employed.
– The identity of employees, others contracted by the operator and persons involved in the issuance of certificates is checked.
– Employees, others contracted by the operator, and persons involved in the issuance of certificates undergo a background check, in which previous employees, references and the highest level of or most relevant education is checked.
– In the role plan, roles designated as essential or key roles are always occupied.
– Care is taken to ensure that there are no conflicts of interest or incompatibilities in functions and responsibilities relevant to security.

5.3.2 Background check procedures / Durchführung von Backgroundchecks

Employees undergo satisfactory and effective security checks depending on requirements and roles.
All employees must also provide a binding declaration of their integrity, the scope of which can be limited as per legal requirements to specific prosecutable offences. Sentences that have been erased, reversed or cleared according to relevant provisions are not considered.

5.3.3 Training requirements / Schulungen

Employees are entrusted with certification tasks only after sufficient training.
Prior to perform any tasks in the issuance of server-, EV- and qualified certificates have to pass a special training covering the applicable requirements.

5.3.4 Retraining frequency and requirements / Häufigkeit von Schulungen und Anforderungen

Operations personnel are continually trained in the use of monitoring tools and other tools necessary for Trust Services.
In addition, ad hoc training is provided, in particular in the event of an incident relevant to security, a change in legal or technical requirements or the introduction of a new procedure.

5.3.5 Job rotation frequency and sequence / Häufigkeit und Abfolge Arbeitsplatzrotation

Job rotation is not envisaged, but new employees go through all positions necessary to complete their tasks.

5.3.6 Sanctions for unauthorized actions / Strafmaßnahmen für unerlaubte Handlungen

Unauthorised actions by employees are penalised according to the requirements of employment law. For other contracted persons, punishment and damages are decided appropriately according to the risk ensuing from the activities of this person.
In the case of unauthorized actions, the employee is deducted from activities related to the certification. In case of suspicion of unauthorized actions, the deduction is in any case until the clarification of the incident.

5.3.7 Independent contractor requirements / Anforderungen an Dienstleister

The operator can employ a service-provider for all of its Trust Services (fully or partially). In this instance, the contractor will be subject to all the requirements applicable for the respective Trust Service.
service-providers are chosen with care and are bound contractually to comply with the requirements applicable for their task.
Depending on the nature of the agreement, the obligations incumbent upon the service provider are written maintained, in particular compliance with the requirements set out in 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen, p178.
The CA retains in any case responsibility for the proper performance of Trust Services.
If the contractor is involved in the issuance of server certificates, the operator conducts an annual internal examination as to whether the contractor is complying with the requirements of [CABROWSER-BASE] and [CABROWSER-EV]. Domain validation, including validation of the domain portion of an eMail address, and the authentication for an IP address are in any case conducted by the operator itself and may not be transferred to a contractor.
A contractor may never conduct an identity check for the certificate application of an organisation over which it has influence.
The transmission of registration data to or from contractors acting as registration authority is done exclusively encrypted through secure connections.

5.3.8 Documentation supplied to personnel / Zur Verfügung gestellte Unterlagen

Employees are demonstrably made aware of the necessary documents and processes for Trust Services.
The management of the CA approves the necessary documentation and certification guidelines and appoints those persons and external contractors responsible for the implementation of Trust Services as per the internal role concept (ð GLOBALTRUST Certificate Security Policy). If guidelines are established or authorisation is granted to persons, this is documented in written form.

5.4 Audit logging procedures / Betriebsüberwachung

5.4.1 Types of events recorded / Zu erfassende Ereignisse

The issuing of private keys for a root certificate that has been issued since 9.7.2013 and is used for the issuance of certificates is observed by a competent and independent auditor.
Audit reports from a competent and independent auditor contain the following information:
a) The procedure for root certificate key issuance and the corresponding protection measures are documented as per the GLOBALTRUST Certificate Policy, and where necessary, the applicable Certificate Practice Statement (CPS).
b) The procedural protocol contains sufficient details on key generation (inc. technical scripts used).
c) Item a) is observed and fully and correctly performed.
The following events are subject to special documentation:
– Exceptional situations in operation (inc. maintenance, system failures,…) are documented by the monitoring system and additional comments and explanations can be added if required. The monitoring data is regularly signed and archived.
– All relevant events that occur in the course of certificate issuance are logged, in particular all events that concern the life cycle of issued certificates and cross-certificates.
– All events that concern applications for new certificates, applications for the renewal of certificates and the approval of applications are documented.

5.4.2 Frequency of processing log / Überwachungsfrequenz

Monitoring tools that continually show operational status are made available to operational personnel. These monitoring tools are continually adapted and optimised according to current requirements and operational experiences.
The monitoring frequency is oriented to the operational requirements of individual processes and is documented internally. This can be adapted if required.

5.4.3 Retention period for audit log / Aufbewahrungsfrist für Überwachungsaufzeichungen

Records necessary for auditing are retained for as long as necessary until the audit has been completed and confirmed. This does not affect longer legal or contractual retention periods.

5.4.4 Protection of audit log / Schutz der Überwachungsaufzeichnungen

Failures and other operational incidents are documented as a security precaution in static data formats or in data formats without dynamic elements, in particular text formats, graphic formats, for example JPG, TIFF, GIF or PNG, or PDF formats without dynamic elements (in particular PDF/A format). Documentation data with special requirements is provided with a time stamp or another suitable form of electronic signature, especially if this is specified in the GLOBALTRUST Certificate Security Policy or the applicable Certificate Policy.
The precise configuration of the monitoring system is documented internally. In this monitoring system, verification measures that can be manually implemented in the event of the failure of the automated monitoring system are also documented.
The monitoring system is monitored as per the role concept (ð GLOBALTRUST Certificate Security Policy) during regular office operations. In the event that critical services fail, on-call staff are informed by SMS. The on-call service reacts according to a defined escalation strategy as per the GLOBALTRUST Certificate Security Policy. In particular, the section “failure scenarios” establishes that critical services for qualified services (signature, revocation, certificate, time stamp services…) have a maximum reaction time of three hours within office hours and a maximum reaction time of six hours otherwise. In any event, reaction times as required by law are observed, especially if they are shorter.
Security incidents are passed on to supervisory authorities, audit offices, partners, customers and other relevant bodies immediately after ascertaining the exact facts. If an issue can not be conclusively assessed, a preliminary notification to the supervisory authorities will be issued within 24 hours.
Access to certification facilities is logged and regularly checked. In addition, monitoring services are activated that report implausible or critical access attempts.

5.4.5 Audit log backup procedures / Sicherung des Archives der Überwachungsaufzeichnungen

Archives for the audit log are securely stored away from components critical to Trust Services. The necessary measures are given in the GLOBALTRUST Certificate Security Policy.

5.4.6 Audit collection system (internal vs. external) / Betriebsüberwachungssystem

The operator uses a system for collecting the operationally relevant data, which is activated at system startup. This system allows detection of system states and malfunctions, unauthorized or irregular access and incidents. The monitoring is continuous, redundant and includes also the start and stop of the monitoring system itself. The testing and monitoring cycles are based on the requirements of the respective services and are regulated in the GLOBALTRUST Certificate Security Policy. In the event of certification-critical incidents, a notification is sent to the responsible persons. Communication channels are in particular website, email and SMS.

5.4.7 Notification to event-causing subject / Benachrichtigung des Auslösers

Not applicable

5.4.8 Vulnerability assessments / Gefährdungsanalyse

Trust Services undergo an annual risk analysis. The risk analysis is carried out by identifying, naming and describing threats, by identifying weak points and by determining the likelihood of occurrence and potential damage.

The risk assessment is carried out by estimating the impact of an incident on the operator’s business, taking into account the legal obligationsThe results and necessary measures are documented in the GLOBALTRUST Certificate Security Policy.
An inventory of the material and intangible assets of the TSP takes place at least once a year. Certification-relevant contracts and agreements are audited once every quarter. The GLOBALTRUST Certificate Security Policy is approved by the management

5.5 Records archival / Aufzeichnungsarchivierung

All certification-relevant information, data, measures, decisions, agreements, instructions etc, including every key pair generation that is induced by the CA, are documented in written form. “Written form” is understood to mean all record formats that permit the documentation to be safely reconstructed later, in particular written records (inc. print-outs), entries in appropriate databases intended for this purpose, electronic log records of systems used or emails.
Depending on individual requirements, these documents can be signed electronically or by hand or their integrity can be established using other measures, such as time stamping.
Logs and historical versions are stored in an archive system for which access is restricted. When data is removed from storage in backup systems (for example, tape library), it is subject to a verification procedure.
In the backup plan, electronically administered documents and information are administered by the person responsible as per the role concept (ð GLOBALTRUST Certificate Security Policy). Data secured in this way is sufficient to restore the system.
The availability of the backups is tested in a regularly manner and documented internaly.

Incident and Trust Service logs (ð Appendix / Anhang A: 2 Content Certification-Protocols / Inhalt Ausstellungs-, Sperr-, Entsperr- und Widerrufs-Protokoll für Zertifikate) that concern the operation of Trust Services are kept for 35 years.

5.5.1 Types of records archived / Zu archivierende Aufzeichungen

Processes and procedures relevant to certification, orders and contracts, are logged and subject to a change log, where reasonable. This affects, in particular, developments in Trust Services and their technical documentation.
Documents and data necessary for the verification of existing, expired or revoked certificates, data necessary to check timestamps, including certificates, revocation status information and the documentation of failures and special operational incidents are archived as per the requirements of the respective certification policy, in particular information requirements concerning duration and form of filing. This can be in databases intended for this purpose, on central servers, on external data carriers or manually filed.
Archived documents are filed in a structured way and are searchable.

5.5.2 Retention period for archive / Aufbewahrungsfristen für archivierte Daten

The retention period is 35 years from the issuance of the document/occurrence of the event, unless otherwise noted in the applicable GLOBALTRUST Certificate Practice Statement.
A legally stipulated minimum retention time applies to documents important for qualified certificates. All archived documents are marked with a time, which refers to the documented event.
Audit and log data from operations are kept for three months online in operative systems, after them as long as they are needed for the monitoring of operations. In any case, certification-relevant files that are stored on backed-up data carriers are kept for 7 years beyond the validity of the respective certificate.

5.5.3 Protection of archive / Schutz der Archive

Documents are stored according to the current state of the art. If kept, print-outs (paper print-outs, hard copies) are kept in lockable premises. Electronically archived documents are kept in common data formats (plain text, XML, PDF (inc. PDF/A, TIFF, JPG, GIF, PNG etc) which can be viewed and read in the future. If it is foreseeable that a particular format will not be readable in the future, a document will be converted in a timely fashion into a format that will be readable in the future.
Private information, in particular passwords and private keys for Trust Services, is not archived. Confidential information, in particular information necessary for operations, is archived and access to it is restricted as per ð “Confidential” level / Stufe “vertraulich” (p186)

5.5.4 Archive backup procedures / Sicherung des Archives

The fundamental principles of archiving are:
– Functionality: backups are only made with a view to specific, defined uses.
– Integrity: Backups are secured in the same way as archives, using appropriate measures, in particular electronic signature of archived data, restricted access (authentication procedures), reference documents/ hash procedures or a combination of these methods.
– Confidentiality: As a principle, keeping backups of private information (such as passwords, private keys etc) is avoided. If this is unavoidable, this information is stored in encrypted form. The algorithms used comply with the state of the art, in particular the requirements of [ETSI TS 119 312] and legal requirements.
– Reliability: backups are made using suitable software and hardware components that allow the data to be stored safely over the necessary time period.
– External storage: backups are stored externally according to their functionality in such a way as to ensure sufficient secure storage and availability. On principle, backup data is stored at a sufficient distance away from the original copies. Long-term backups are stored in premises other than those in which the server is operated. Online security and operation backups are stored on systems other than the systems that contain the original data. In any event, access is restricted and physical and technical barriers must be surmounted to access the backup data.
– Reconstructability: random samples of backups are tested for their reconstructability and availability. This can also be requested by management. The procedure for requesting this is internally documented.

5.5.5 Requirements for time-stamping of records / Anforderungen zum Zeitstempeln von Aufzeichnungen

Depending on operational requirements, these documents can be signed electronically or by hand or their integrity can be ensured using other measures, such as timestamping.
Electronic documents are administered in appropriate systems that use integrity checks to recognise data errors and avoid data loss. A timestamp is generated for electronically archived documents soon after they are issued. This timestamp documents the time of documentation and integrity of the document. The time of the timestamp is synchronized with public time servers at least once per hour by appropriate technical measures. Data is otherwise secured as per the GLOBALTRUST Certificate Security Policy.

5.5.6 Archive collection system (internal or external) / Archivierung (intern/extern)

The integrity of all operational data, especially orders, log files and certification data is ensured through the use of non-rewritable data carriers and by electronically signing archived data, restricting access (authentication procedures), and reference documentation/hash procedures or a combination of these methods.

5.5.7 Procedures to obtain and verify archive information / Verfahren zur Beschaffung und Verifikation von Aufzeichungen

The restore mechanisms are constructed so that the certification system can be restored from backup copies.
Restore measures are initiated by the person responsible as per the role concept (ð GLOBALTRUST Certificate Security Policy).
If it is necessary to restore data from a backup, all data necessary for this is restored in its own area, and after the data is checked for accuracy and necessity, only the data that is actually required is transferred into the production system.

5.6 Key changeover / Schlüsselwechsel des Betreibers

The changeover of keys by the operator is planned in good time and is subject to all necessary audits. Third parties affected by a planned changeover are informed in a timely fashion.

5.7 Compromise and disaster recovery / Kompromittierung und Geschäftsweiterführung

The compromising of a CA key is considered a worst-case scenario. A compromise is the transfer of the CA private key to third parties in a form that makes use / exploitation possible.
In this event, the CA immediately briefs and informs the regulatory authority, the subscribers, persons who rely on the Trust Services, and if necessary other Trust Service providers and organisations with whom the CA has relevant agreements (such as software- and browser vendors), that the revocation and certificate information can no longer be seen as reliable. If necessary, the public is informed via the website http://www.globaltrust.eu/limitation.html.
Certificates and revocation lists will immediately be marked as no longer valid. The subscriber will be issued with a new certificate with the aid of a newly generated secure CA key.

5.7.1 Incident and compromise handling procedures / Handlungsablauf bei Zwischenfällen und Kompromittierungen

The operator has taken precautions in case of the failure of individual operational components. Trust Services will then be in failure operation (partial functionality is available) instead of normal operation (full functionality is available). Details are described in the GLOBALTRUST Certificate Security Policy.
The transition from normal operation (“primary”) to failure operation (“disaster recovery”) is mostly automatic and takes five minutes including delays. The maximum permitted outage that still allows an automated transition from normal operation to failure operation is described in the internal GLOBALTRUST Certificate Security Policy as a worst-case scenario. Additional failures require manual intervention by authorised staff. The response time for manual intervention is a maximum of 24 hours, but a response is made within the time requirements of the regulatory authority at least.
Where alternative services or systems are used, these comply with the same security requirements as the main system.
The transition from normal operation to failure operation and other failure procedures are tested at regular intervals to an extent that is reasonable and economically acceptable.

5.7.2 Computing resources, software, and/or data are corrupted / Wiederherstellung nach Kompromittierung von Ressourcen

There is a risk analysis for all central components of certification operations, which is described in the GLOBALTRUST Certificate Security Policy. In this risk analysis, the procedures for restoring normal operation after resources have been compromised are also described.

5.7.3 Entity private key compromise procedures / Handlungsablauf Kompromittierung des privaten Schlüssels des VDA

Internal documentation exists on the applicable steps and measures in case of compromise of a private key belonging to a CA-certificate. The certificate is revoked in any case. The status information is disseminated via a CRL which is signed by the root certificate. Further, all end-user-certificates that have been issued under the comrpomised CA-certificate are revoked. The status information is disseminated via a CRL that is signed by another, non-compromised key.

5.7.4 Business continuity capabilities after a disaster / Möglichkeiten zur Geschäftsweiterführung im Katastrophenfall

Measures for business continuity in the event of a disaster are documented in the GLOBALTRUST Certificate Security Policy.

5.8 CA or RA termination / Einstellung der Tätigkeit

The CA immediately announces the termination to the regulatory authority and other participants, if planned, and ensures that any resulting impairment of its services for subscribers as well as parties who rely upon the services is kept to a minimum. The detailed procedure (including takeover costs) is documented internaly and approved by the management.
Apart from this, all subscribers and any third parties with whom the CA has relevant agreements are informed. The authorization of service providers to perform certification-related tasks on behalf of the CA is revoked. All private keys available at the CA are destroyed or removed from circulation in a way, that they cannot be retrived.
Further efforts are made so that a minimal amount of services can be undertaken by a third party, in particular the distribution of revocation statuses and the further archiving of legally required documents.
If possible, arragements with supervisory bodies or other appropriate entities are made to continue the Trust Services.

If the VDA is no longer able to provide the trust services, in particular due to non-fulfilment of technical, economic or legal requirements, all parties involved will also be informed. Certificates are – if necessary – revoked. Compensation for any remaining term is not due.
The CA has an agreement to cover cost in case of transfer or termination of the Trust Services.

6. TECHNICAL SECURITY CONTROLS / Technische Sicherheitsmaßnahmen

The operational infrastructure of the operator is checked and adjusted to changed requirements regularly. Changes that affect the extent to which security is achieved must be approved by the certification committee as per the role concept (ð GLOBALTRUST Certificate Security Policy). In the event of a change of the GLOBALTRUST Certificate Security Policy, the responsible regulatory authorities are informed.
Technical operations are conducted in the offices of the operator or a sufficiently qualified contractor. Current contractors are fully documented and can be disclosed to the regulatory authority at any time. All contractors are bound to protect data security in accordance with this policy, [DSG 2000], signature requirements and other relevant legal requirements and technical standards, as it concerns the activity assigned to them.
The operator uses signature and cryptographic keys to perform Trust Services and internal (administrative) business processes where technically possible, technically necessary for security and economically acceptable.
These keys are administered and made available in the following categories:
Category 1: Signature keys for Trust Services. This includes Trust Services that concern qualified, as well as non-qualified certificates.
Category 2: Infrastructure keys for protecting individual processes, devices or objects of Trust Services. In particular, these are keys for the secure transmission of data between the certification data centre and the office of the CA or mobile access devices, or for the signature (inc. timestamping) of log data, programmes or other data relevant to certification.
Category 3: Identification keys for protecting communication between technical systems and employees and for authenticating employees.
Category 4: Session keys, exclusively temporarily generated keys for protecting communication between technical systems.

The keys from categories 1 to 3 are issued according to the state of the art in consideration of national and international requirements, for example [ETSI TS 119 312]. Keys in category 1 comply with the legal requirements for Trust Services.
Category 1 keys (including neccesary random numbers) are generated on systems meeting the requirements of FIPS 140-2 level 3 or higher [FIPS-140-2], CMCSOB PP [CWA 14167-2], CMCKG PP [CWA 14167-3], CMCSO PP [CWA 14167-4], EAL 4 or higher in accordance with ISO / IEC 15408 [CC-ITSE], or is a system that, according to a risk analysis according to [ETSI EN 319 411-2], meets the safety objectives or safety profiles through physical and / or other non-physical measures.
Access to signature creation data is restricted as per the GLOBALTRUST Certificate Security Policy. Access to signature creation data that is intended for Trust Services or serves as infrastructure or identification keys are subject to access controls.

6.1 Key pair generation and installation / Erzeugung und Installation von Schlüsselpaaren

The operator makes available signature creation devices as per legal requirements and current technical standards for qualified electronic signatures and qualified certificates as well as for advanced or other signatures.
In case of server certificates (EV and qualified server certificates included) the key generation has to be undertaken by the applicant.
For the issuance of signature creation devices suitable for electronic signatures, the following processes must be ensured:
(a) standard process
(b) producer process
(c) policy process

(a) Standard process

To issue signature creation devices that are secure and suitable for qualified electronic signatures, a suitable security certification of the operating system is necessary for the technical components. A security certification is particularly suitable if it complies with regulations as per [EG-REF] or [CWA-14169] or has been confirmed as suitable by the regulatory authority responsible.
Signature creation devices are issued in an environment secured by the CA according to the following mandatory steps:

(i) Delivery of the signature creation devices

is performed
(a) personally in the offices of the producer, an authorised reseller or the operator by a person authorised by the producer,
(b) by courier or post. The signature creation devices are transported in packaging or a container which can be checked for integrity upon delivery,
(c) using another form of delivery, provided that it can be established beyond doubt that every single signature creation device has originated from the producer (for example using an origin or production certificate that clearly refers to the producer).
(d) in case of signature creation devices for non-qualified signatures, using another form of delivery according to this Policy.

(ii) Pre-personalisation

In the case of signature creation devices for qualified signatures, a pre-personalisation takes place. Information about a particular person cannot be deduced from a pre-personalised signature creation device.
Pre-personalisation is understood to be the advance determination of a data structure on the signature creation device. This data structure can have different structures according to individual requirements. For secure signature creation devices suitable for qualified signatures, this always contains a secure key as per this document (ð 6.1.2 Private key delivery to subscriber / Zustellung privater Schlüssel an den Signator, p140). If the signature creation device contains additional data, this should be stored separately from the secure key and qualified certificate so that the secure key and qualified certificate can be used independently of this data and does not interfere with it.
Pre-personalisation is performed
(a) either at the offices of the producer due to the requirements of the CA or
(b) at the offices of the producer due to a security certification or approval from a regulatory authority or
(c) at the offices of the operator as per documented requirements. The requirements could be of a general nature (for example, because of product-specific definitions) or the individual wishes of the customer.

(iii) Key generation

In signature creation devices, end user keys suitable for electronic signatures are generated according to the state of the art (including run-time-recommandations), taking legal and technical requirements into account. The keys can be generated at the offices of the operator, the producer of the signature creation devices, the subscriber or a contractor of the operator.
In any event, the requirements of the applicable certificate policy should be observed.
If the end user key is not generated in the signature creation device, it is generated in a secure environment that has the following characteristics:
– the secure environment ensures the confidentiality and integrity of the end user key throughout the duration of the check,
– the secure environment ensures the confidential transfer of the end user key to the secure signature creation device,
– the secure environment ensures the integrity of the public end user key if it is going to be exported into another system or application,
– the secure environment is used only by identified and authorised users,
– access to the services is limited,
– the functionality of the secure environment can be checked and tested and returns to a defined original state if errors occur,
– the secure environment is secured against physical attacks (damages) and returns to a secure original state if such an attack is detected.
The evaluation of these requirements complies with the regulations [CWA‑14167-3] or an equivalent legally and technically acceptable procedure. The end user key is transferred by secure means. After successful transfer the end user key is irreversibly deleted in the secure environment.

(iv) Storage

If signature creation devices are stored at the offices of the CA (kept in stock), they are stored in pre-personalised or earlier state and not personalised.
The keeping of personalised signature creation devices to be delivered or picked up by the subscriber does not count as storage.
In any event, signature creation devices intended for qualified certificates for electronic signatures are stored in locked facilities. Access to these facilities is restricted to authorised personnel who have been entrusted with issuing signature creation devices.

(v) Issuance of certificates

To issue a certificate, if asymmetric encryption of public end user keys is used, data is extracted from the signature creation device and signed by the operator with his key in the secure environment. Certificates are otherwise issued as per the requirements in ð 4.3 Certificate issuance / Zertifikatsausstellung (p67) and ð 7.1 Certificate profile / Zertifikatsprofile (p164) and the applicable GLOBALTRUST Certificate Practice Statement.
The duration and content of the certificate, process of identity verification, contractual obligations of the subscriber, CA and operator are defined in the applicable certificate policy.

(vi) Input of additional signature generation data

Additional data can be entered into a signature creation device for reasons specific to the product, legal reasons or according to the customer’s wishes.
The following data structures are permitted and do not interfere with signature creation devices intended for qualified signatures:
– The storage of references to secure keys (public and private components) deposited in the signature creation device, in particular in the format of a PKCS#15 container [PKCS15] (u.a. auch ISO 7616-15).
– Additional certificates and end user keys that can be used for other signatures or encrypting data.
– Additional (cross) certificates that refer to the secure keys of the signature creation device and do not contravene the requirements of the GLOBALTRUST Certificate Practice Statement,
the GLOBALTRUST Certificate Security Policy,
this GLOBALTRUST Certificate Policy or compulsory legal or technical requirements.

– Data necessary for the use of a signature creation device as a citizen card as defined by the Austrian E-Government Law [BÜRGERKARTE].
– Every additional data structure that is seen as suitable by a regulatory authority, taking into account restrictions on permitted signature creation devices and uses where applicable.
– Every additional data structure that does not allow a signature creation device for qualified signatures to be interfered with.

(vii) Protection from misuse

All information put into the signature creation device, in particular end user keys for qualified electronic signatures and qualified certificates, is put in in such a way that it is impossible to corrupt the data.
Protection from misuse does not prevent the subscriber from transferring additional information to the signature creation device, deleting individual information or re-initialising the entire signature creation device.
These changes can only be made to the extent that they are permitted by the applicable GLOBALTRUST Certificate Practice Statement and do not lead to misleading information in the certificate or on the subscriber.

(viii) Transport protection

Signature creation devices for qualified signatures are provided with a confidential initialisation PIN. In addition, the signature creation device is provided with protection during transport. The security creation device can be used for the first time only by using the initialisation PIN or by breaking or removing the protection.
Suitable transport protection measures are
(a) technical containers, for which only the subscriber has the key
(b) packaging or containers, damage to which can be unfailingly detected by a third party
(c) protection of the subscriber key with a password or
(d) data transferred directly into the signature creation device, which must be removed by the subscriber before the signature creation device can be used for the first time.
An appropriate measure for the purpose of (c) is to attach a transport PIN that can only be used once and must be entered before the signature creation device is used for the first time. In case of qualified certificates for electronic signatures, (c) is a suitable method of securing during transport.
Transport protection can be omitted. The criteria for this are listed in ð 6.1.2 Private key delivery to subscriber / Zustellung privater Schlüssel an den Signator (p140).
If confidential information is used for transport protection (in particular a transport PIN), this will be delivered in a form that allows the recipient to determine if unauthorised persons have been able to access the confidential information. Suitable forms of delivery are, in particular, the use of closed envelopes and the protection of confidential information using high-security labels.
If the integrity of the signature creation device or transport unit during transfer cannot be established, the subscriber is obliged to inform the CA. The CA must then revoke the issued certificate. The subscriber is made aware of his responsibility to check integrity and report possible violations of integrity before the contract is signed in the applicable certificate policy.

(ix) General framework

If work is conducted at the offices of the producer or other contractor at the request of the CA for which a confirmation by the confirmation authority is not available, adequate supervision is agreed in accordance with this GLOBALTRUST Certificate Policy together with the applicable GLOBALTRUST Certificate Practice Statement.
Adequate supervision is agreed if
(a) the producer names responsible supervisors who are appropriately qualified,
(b) qualified employees of the operator supervise the production process or
(c) the operator names a qualified third party to oversee the production process.
In any event, the production process must be supervised and documented by the supervising personnel.
Certificates can be issued by the operator, a contractor or the producer of the signature creation device at the request of the operator.
The entire process of initialising the signature creation devices is logged.

(b) Producer requirements

Signature creation devices for qualified signatures can be fully or partially issued using a process defined by the producer, if this process is recognised or approved by a regulatory authority responsible for the issuance of qualified certificates or generation of qualified electronic signatures.

(c) Policy requirements

The issuance of signature creation devices can be defined in the applicable GLOBALTRUST Certificate Practice Statement. In this event, it should be made clear whether the devices are only issued according to these requirements or whether the requirements of the GLOBALTRUST Certificate Practice Statement are to be applied alternatively (optionally) as per the GLOBALTRUST Certificate Policy.
The issuing of signature creation devices based on CompanyCAs can also be regulated by supplementary, end-customer-specific issuing processes. These are reviewed by the operator and it is ensured that they do not conflict with the operator’s security requirements. 169/5000
The issuing process is described in a publicly accessible document, which is entered in the certificate by an OID from the number range 1.2.40.0.36.1.1.999.***. *** means numbered consecutively and the number is internally attached an organisation.

6.1.1 Key pair generation / Erzeugung von Schlüsselpaaren

Generation of private keys and certificates for CA certificates

The necessary keys for Trust Services as per this policy are generated in a dedicated system according to the four-eyes principle and documented, including the methods and formats applied. If these keys are used to issue qualified certificates or are necessary to issue qualified timestamps or for other services, they are generated in systems that comply with the requirements [ETSI TS 101 456] inclusive successor: [ETSI EN 319 401], [ETSI EN 319 411-1], [ETSI EN 319 411-2] that are in force at the time that the keys are generated, in particular [SVV]. The keys are generated according to the rules that apply at the time. In particular, be supervised by an independent person or recorded on video. The adherence of these rules is confirmed by an independent person.
The operator’s signature keys used for Trust Services, in particular for the issuance of end user certificates, are generated on secure HSM hardware. They are not publicly available or given to a third party.
The technical requirements for security that must be fulfilled for HSM modules and the signature server system are specified in the GLOBALTRUST Certificate Security Policy. In particular, the HSM modules for RootCAs are operated offline or airgapped in a high security zone.
Generation of the subscriber’s private key
The subscriber’s key is generated either by the subscriber or the operator depending on the Trust Service.
In case of server certificates, the key generation has to be performed by the subscriber
If keys are generated for qualified certificates for electronic signatures, appropriate qualified signature creation devices must be used. The names of appropriate signature creation devices can be requested from the CA or found on its website. The requirements and generation process are described in ð 6.1 Key pair generation and installation / Erzeugung und Installation von Schlüsselpaaren (p129).

6.1.2 Private key delivery to subscriber / Zustellung privater Schlüssel an den Signator

Private keys are never distributed in clear text format. They must be stored and distributed at least as encrypted data or they must be distributed over password-protected encrypted

connections or using another transfer method compliant with the current state of the art.

Signature keys for qualified electronic signatures are only delivered to the applicant with the appropriate signature creation device. A signature creation device is delivered using the applicable processes. It is ensured that only the authorised subscriber receives the signature creation device.
In case of qualified certificates for electronic signatures, the receiving according to Art. 24/1 lit. a
[eIDAS regulation] takes place by checking the identity of the personally
present person or the representative of a legal person by an official ID or by
another equivalent proof that must be documented:
[1] the VDA or one of its authorized employees
[2] a representative of the VDA
[3] other identification methods that provide an equivalent level of security
as personal presence (Article 24 (1) (d) [eIDAS regulation]
In the case of [3] letters within Austria will be delivered by POST AG
to adressee only („Ident.Brief“).
– qualified certificates for electronic signatures can be delivered using the same methods as advanced signatures and official signatures, but with the restriction that the appropriate signature creation devices produced by the operator must be delivered using transport protection (ð (viii) Transport protection, p135). The necessity of transport protection can be anticipated if the signature creation device is given personally by an authorised person to a subscriber and if the signature creation device has been produced by the operator under the supervision of the subscriber. In this event, the subscriber is obligated to check the integrity of the signature creation device immediately (in the presence of the authorised person) and to secure it using an authorisation code known only to himself. The signature function can only be initiated using the authorisation code. The use of the authorisation code can be subject to additional restrictions, for example [eIDAS-VO] or the specific requirements of the regulatory authority.
Other keys (not intended for qualified certificates) are delivered using appropriate transport protection, in person or using secure (encrypted) data transfer paths. At no point during delivery can a private key be accessed without a password.
A certification confirmation is delivered to the subscriber befor the certificate has been issued. The confirmation contains, at a minimum, the name of the applicant, signatory of the contract and a reference to the requirements of the policy.
The certification confirmation contractually obligates the subscriber to adhere to the applicable policy and must be returned with the signature of an authorised person (ð 4.2 Certificate application processing / Bearbeitung von Zertifkatsanträgen, p64)

Depending on the application, delivery proceeds according to the following rules:
– certificates for advanced signatures and official signatures can be delivered by ordinary post (if possible also by electronic post, inc. email or fax), if identity verification for the application has been completed.
– advanced signatures and official signatures can be delivered by a courier that offers identity verification upon delivery (in Austria this is, in particular, POST AG), if the identity check has not yet been completed or only consists of a plausibility check. Items of post can be delivered by POST AG to addressee only (“Ident.Brief”). If delivered by other delivery services, equivalent procedures are used. The identity check is concluded when the delivered certification confirmation has been returned with a signature which matches the signature on previously submitted official documents. If the signature substantially differs, a signature sample sheet with the current signature of the applicant is requested.
– advanced signatures and official signatures can be picked up in person at the offices of the CA or another registration office, if the identity check has not yet been completed. The identity check is concluded when the submitted certification confirmation has been signed in front of an authorised person and the applicant has proved identity using an official document in original. The process must be confirmed by the authorised person.
– Certificates on signature creation devices that are intended for simple signatures are delivered by ordinary post, as long as there is no reasonable doubt as to the identity of the applicant. The CA reserves the right to apply the same delivery requirements as those for certificates for advanced signatures due to technical or legal requirements.
– Other certificates intended for simple signatures are delivered using a reliable and secure method (if appropriate, also as electronic post inc. email or fax). The CA reserves the right to apply the same delivery requirements as those for certificates for advanced signatures due to technical or legal requirements.
After the certification confirmation has been received and the subscriber’s signature has been checked, access to the simple certificates and/or private keys is made available. If a private key is not delivered as signature creation device hardware, the key must be downloaded over a secure connection that fulfils the following minimum criteria:
– End-to-end encryption of the transfer path,
– Authentication of the applicant (at least with the activation password given by the applicant and the reference number given in the certification confirmation ð GLOBALTRUST Certificate Practice Statement section 4.1 7.,
– Encryption of the key using a password given by the applicant.

6.1.3 Public key delivery to certificate issuer / Zustellung öffentlicher Schlüssel an den VDA

Certificate data generated in a registration office is signed and transferred to the operator’s certification office in an encrypted form. Confidentiality and integrity of all data is ensured. Encryption and signature are not necessary if the data transmitted is only the basis of the application and will only be entered into the certificates after the content and format has been checked by the CA.
Non-certified public keys are not distributed and are administered in a secure certification environment only.
The integrity and authenticity of a public key during distribution is maintained using the following measures:
– transfer of the public root CA and sub CA key to be released to the regulatory authority through the submission of a signed PKCS#10 certificate request,
– issuance and publishing of root CA and sub CA certificates on the website or registry of the CA,
– voluntary certification using recognised (private or public) audit entities,
– publication and integration in the software of trustworthy third party companies. The current state of integration of the root certificate at a third party company can be accessed on the website of the CA.
For certificates for advanced and simple signatures, at least one method of publication must be used. For qualified certificates, publication through the designated regulatory authority is necessary.
Integrity is ensured in the transfer of the data described above to third parties, in particular through the use of signatures or check sums.

6.1.4 CA public key delivery to relying parties / Verteilung öffentliche CA-Schlüssel

Information relevant to certificates (items of information of any kind) is provided, accessed and distributed as per the requirements
of this GLOBALTRUST Certificate Policy,
the applicable GLOBALTRUST Certificate Practice Statement and
the GLOBALTRUST Certificate Security Policy.
It is ensured that authorised users can read the information provided and can edit it only in compliance with defined certification processes and distribution of roles as per the role concept (ð GLOBALTRUST Certificate Security Policy).
Certificates are distributed to third parties as per the requirements of the applicant and the compulsory legal requirements. The CA uses the appropriate technical procedures.

6.1.5 Key sizes / Schlüssellängen

At the time of their issuance, the standards, algorithms and key sizes used for certificates and keys comply – regarding the run-time – with the applicable technical recommendations of the relevant regulatory authority, national or international requirements, ETSI standards, requirements of those documents with which the Trust Service conforms (ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen, p178) or the requirements of other (private or public) entities that are consulted on the examination of the Trust Services of the CA. If different recommendations describe differing requirements and security levels, the approach that complies with the minimum requirement of all relevant recommendations is selected.
If differing requirements for the use of certificates or keys at different times arise, for example because of new security requirements, the updated requirements are published on the website of the CA and made public according to the wishes of the regulatory authority, auditor or other partners of the CA.

6.1.6 Public key parameters generation and quality checking / Festlegung der Schlüsselparameter und Qualitätskontrolle

Key parameters are subject to the same procedures and measures as in ð 6.1.5 Key sizes / Schlüssellängen (p145).
The quality of keys generated is continually checked as per the current state of the art.

6.1.7 Key usage purposes (as per X.509 v3 key usage field) / Schlüsselverwendung

The only intended use of the key for electronic signature is to be made known in the certificate, where technically possible and reasonable. In any other event, this is made known using the appropriate reference to the applicable GLOBALTRUST Certificate Practice Statement.
The private key of the CA is used only for the generation of certificates explicitly intended for this purpose and the signature of the corresponding revocation lists within the premises used for certification.

6.2 Private Key Protection and Cryptographic Module Engineering Controls / Schutz des privaten Schlüssels und Anforderungen an Signaturerstellungseinheiten

All measures that concern signature keys, in particular the generation of the keys, export and import procedures where applicable, backup and restoration, are taken by authorised persons only and are logged according to the four-eyes principle. The log contains information on procedures, hardware used and persons responsible. Generation is logged according to internal documentation.
The operator can use signature creation devices for different Trust Services. Valid and expired signature creation data (inc. certificates and other signature creation data, in particular hash values) are published on the website of the operator without the private signature key. All issued certificates contain a link to corresponding signature creation data and the applicable certificate policy of the operator.
Separate signature creation data must be generated to issue qualified certificates. This signature creation data is only used to issue and revoke qualified certificates.
Depending on the category of the key, there are different risk assessments and security measures. There are rules for the following points for all keys:
– key generation and distribution
– key use
– change of keys
– key destruction if compromised or the end of life cycle is reached
– key storage, backup and restoration
– key archiving
The signature keys in ð Category/Kategorie 1 / Category 1 (p128) have the longest duration and the greatest risk. They undergo a specialised assessment as per the GLOBALTRUST Certificate Security Policy and are subject to special security measures. The life cycle of these keys is documented
Where applicable, necessary additional security requirements for keys in ð Category/Kategorie 2 / Category 2 (p128, “infrastructure keys”) are handled in the context of the security measures of the office where they are deployed, as per the GLOBALTRUST Certificate Security Policy. If technically possible and organisationally reasonable, different infrastructure keys are used for different services/purposes. These keys are not identical to the signature keys in ð Category/Kategorie 1 / Category 1 (p128).
The keys in ð Category/Kategorie 3 / Category 3 (p129, “identification key”) are issued to authorised personnel only and are used to support and simplify identification and authorisation processes.
All private keys are kept securely. The keys in ð Category/Kategorie 2 and 3 (p128) are generated and administered in hardware suitable for cryptography. If keys are issued by the CA, the same requirements apply to the issuance of certificates as those described in ð 4.3 Certificate issuance / Zertifikatsausstellung (p67). If keys are used by a third party, they are equivalent to those issued by the CA. Keys are distributed according to the same criteria as those for issuing certificates intended for the advanced electronic signatures of applicant. When certificates are used based on keys in ð Category/Kategorie 2 and 3 (p128), it is ensured that they are still valid. This can be done by checking the relevant revocation status information or using other appropriate technical or organisational measures, in particular operation supervision measures. The keys in Category/Kategorie 2 and 3 (p128) are changed using a secure method before they expire or if there is clear evidence that the algorithms used are no longer sufficiently secure or if the are being regenerated for other reasons.
The keys in ð Category/Kategorie 4 (p129) that are only used for a short time are not subject to specialised documentation or supervision.

6.2.1 Cryptographic module standards and controls / Standards und Sicherheitsmaßnahmen für Signaturerstellungseinheiten

Secure signature creation devices are made available for qualified electronic signatures.
The CA provides a list of suitable signature creation products upon request and/or on its website.
A part of this documentation is which algorithms and parameters are used to fulfil the requirements that comply with a secure signature creation device. These specifications are defined as per the credentials that come with the signature creation devices. Alternatively, a reference to publicly accessible credentials (certification) that contains the necessary information is permitted.
Private keys are used to sign certificates as long as the algorithms used are seen as secure in the sense of the definition in ð secure signature creation device, secure key (p45).
The operator uses an HSM system with redundancy for Trust Services. Synchronization of data between individual hardware modules uses a secure format that is part of the security certification of the used hardware.
The list of HSM products used by the operator is documented internally. Operation is initiated using a written protocol. The form and content of the protocol are internally documented.
For the signature creation devices and procedures, the certification statements and confirmation authority upon which the fulfilment of requirements for qualified electronic signature are based are documented.
If certifications only refer to individual technical components, these may only be used for qualified signatures in combinations of components that together fulfil the security requirements for qualified signatures. Appropriate combinations of technical components can be listed in ð Appendix / Anhang A: 3 supported signature creation unitS / Unterstützte Signaturerstellungsprodukte (p221)
Certifications from the regulatory authority can be kept in copy. Alternatively, the operator can keep a reference to where they are kept at the regulatory authority.
If only individual technical components fulfil these requirements, they can only be used in a secure environment. The specifications for this secure environment are given in the GLOBALTRUST Certificate Security Policy.

6.2.2 Private key (n out of m) multi-person control / Mehrpersonen-Zugriffssicherung zu privaten Schlüsseln (n von m)

The operator’s private keys for CA certificates are managed according to the four-eyes principle.

6.2.3 Private key escrow / Hinterlegung privater Schlüssel (key escrow)

Not applicable

6.2.4 Private key backup / Backup privater Schlüssel

The operator’s private keys for CA certificates are stored redundantly in a system intended for Trust Services.
Private keys for CA certificates belonging to the operator that no longer comply with security requirements, or can no longer be used for other reasons, are deleted. Keys that are no longer active are not archived.
If the subscriber’s private keys do not comply with security requirements fitting the purposes for which they were issued, the subscriber is informed immediately and requested to cease using and delete the key.

6.2.5 Private key archival / Archivierung privater Schlüssel

The operator’s private keys for CA certificates are stored in a system intended for Trust Services. Nothing is archived outside of the certification system.
Where applicable, available archive copies of private keys belonging to the subscriber are securely stored so that it is not possible for them to be transferred to a productive system unobserved.
Copies of private keys belonging to the subscriber are deleted at the office of the operator after they have been transferred to the subscriber.
Never private keys are stored in a nonencrypted format, like text / “plain-text”.

6.2.6 Private key transfer into or from a cryptographic module / Transfer privater Schlüssel in oder aus Signaturerstellungseinheiten

It is not possible to transfer private keys for CA certificates belonging to the operator or private keys for qualified signatures from signature creation devices.

6.2.7 Private key storage on cryptographic module / Speicherung privater Schlüssel auf Signaturerstellungseinheiten

All private keys are stored on appropriate signature creation devices.
If keys in ð categories 1 to 3 have to be stored outside of their intended secure systems (“key export”), their confidentiality is secured as per the current state of the art, for example, using cryptographic measures that fulfil the requirements of [ETSI TS 119 312] and accord with the security measures of the secure module.
To ensure the authenticity of publicly availalble verification data, keys in ð Category/Kategorie 1 (p128) can be cross-certified using the CA’s other certificates of the same level of confidentiaity, certificates from the regulatory office, authorities and other trustworthy third parties. This applies particularly to protecting the continuity of the confidentiality of expired or new signature certificates belonging to the CA. A cross-certification only takes place if the specification is sufficently authenticated, integrity is protected and it is ensured that no specifications can be falsified, particularly through replay attacks. Specifications are checked as per ð 4.1 Certificate Application / Antragstellung (p61).
If private keys are available in clear text, their storage space can be rewritten with zeroes.

6.2.8 Method of activating private key / Aktivierung privater Schlüssel

To issue qualified certificates, the keys for CA certificates necessary for Trust Services must be used by two authorised persons. In other cases, certificates can be issued by one authorised person.

6.2.9 Method of deactivating private key / Deaktivierung privater Schlüssel

The signature creation devices that contain the private keys of the operator’s CA certificates are automatically deactivated when the certification system is terminated.

6.2.10 Method of destroying private key / Zerstörung privater Schlüssel

Private keys for CA certificates that do not comply with the requirements of the operator are immediately deleted in such a way that it is not possible to reconstruct them with the current state of the art. The following measures are taken:
– signature creation devices that contain private keys are taken out of operation.
– certificates that have been issued on the basis of a private key are revoked.
– technical and organisational measures are taken that prevent certifications from being issued by a deactivated private key.
If private keys on signature creation devices cannot be sufficiently securely deleted, the entire signature creation device is destroyed.

6.2.11 Cryptographic Module Rating / Beurteilung Signaturerstellungseinheiten

Signature creation devices are rated as per ð secure signature creation device, secure key (p45).

6.3 Other aspects of key pair management / Andere Aspekte des Managements von Schlüsselpaaren

6.3.1 Public key archival / Archvierung eines öffentlichen Schlüssels

The CA’s and subscriber’s public keys are archived in such a way to ensure that they can be reconstructed and checked for the agreed duration of the certificate.

6.3.2 Certificate operational periods and key pair usage periods / Gültigkeitsdauer von Zertifikaten und Schlüsselpaaren

The signature key can be used for electronic signatures from the time that the transport protection is removed or the signature creation device is transfered to the subscriber, but not before the starting date of validity as given in the certificate. It can be used until the end date of validity as given in the certificate but not after the certificate has been revoked.
The maximum permitted duration of validity for qualified certificates is determined by legal requirements and the requirements of regulatory authorities. For other certificates, this is determined by the product description and the individual requirements of the subscriber. For simple certificates, it is possible to have a different validity period than as stipulated in the policy: this must be agreed with the subscriber and cannot be longer than the maximum permitted validity period of the issuing CA certificate.
For server certificates with a validity starting date on or after 1.3.2018, the maximum validity period is 825 days. For server certificates with a validity starting date on or after 1st September 2020, the maximum validty period is 397 days.
For S/MIME certificates with a validity starting date on or after 1st April 2022, the maximum validty period is 800 days.
An electronic signature issued within the validity period remains valid after the validity period has expired or the certificate has been suspended of revoked.

6.4 Activation data / Aktivierungsdaten

6.4.1 Activation data generation and installation / Generierung und Installation von Aktivierungsdaten

Advanced signatures or signatures that have been provided with a qualified certificate can only be created using activation data.

6.4.2 Activation data protection / Schutz von Aktivierungsdaten

Activation data must be kept confidential and stored in such a way that illegitimate use to the current state of the art is not possible.

6.4.3 Other aspects of activation data / Andere Aspekte von Aktivierungsdaten

The operator obligates the subscriber to handle the activation data confidentially and helps the subscriber to select the data, where legally permitted and explicitly desired.

6.5 Computer security controls / Sicherheitsmaßnahmen IT-System

Technical components necessary for the operation of Trust Services are separated from the operator’s other (office) facilities in terms of hardware and software. Organisational and administrative measures necessary for Trust Services are documented. The steps taken can be reconstructed if required.
If communication with a certification component installed in a data centre is necessary to issue signature creation data, this communication takes place as per the requirements of the GLOBALTRUST Certificate Security Policy in a way that effectively prevents Trust Services from being compromised, in any case using a secure virtual private network (VPN). Alongside technical security, organisational measures are taken to restrict access to technical devices, such as restriction to authorised persons.
The integrity of computer systems and information is protected against viruses and malicious or unauthorised software.
Capacity needs are monitored and future developments predicted so that appropriate bandwidths, processing capacity and other IT resources are available.
Functions critical to security for certification and revocation services are separated from ordinary administrative functions. Functions critical to security can be seen as all IT measures that maintain the operational capability of Trust Services. This is in particular
– the planning and acceptance of security systems,
– protection from malicious software and attacks,
– active checking of log files and reports, analysis of incidents,
– general system maintenance activities,
– network administration,
– data management, data carrier administration and security,
– software updates.

6.5.1 Specific computer security technical requirements / Spezifische technische Sicherheitsanforderungen an die IT-Systeme

The necessary security requirements are defined and implemented specific to each component and are documented in the GLOBALTRUST Certificate Security Policy.
All technical components of the certification operation are operated in secure environments. Entrance and access are only available through authorized users. The networks of the VDA are physically and logically separated. The communication of the various segments is limited to what is necessary for operation. Critical systems are located in specially protected zones. Networks for system administration and operations are separated. Productive systems are separated from development and test systems. The communication between different trustworthy systems takes place exclusively through distinct protected connections. Where high availability is required, systems are redundant. The VDA regularly conducts vulnerability scans and penetration tests. Timetables are internaly documented.

6.5.2 Computer security rating / Beurteilung der Computersicherheit

The security of the entire certification system has undergone risk analysis. The approch of the analysis, results and measures are internally documented, in particular in the GLOBALTRUST Certificate Security Policy and are regularly evaluated during audits.

6.6 Life cycle technical controls / Technische Maßnahmen während des Lebenszyklus

All technical components relevant to certification are subject to continual monitoring throughout their entire life cycle and documented throughout their entire life cycle.

6.6.1 System development controls / Sicherheitsmaßnahmen bei der Entwicklung

System developments are made in development systems separate from real operations.
The processes necessary for Trust Services are continually developed and optimised. Optimisation of security as well as improvement of user friendliness determines system development.
Development will be based on security requirements in accordance with the GLOBALTRUST Certificate Security Policy.
Software modules used in operations are electronically signed. The signatures are continually checked and unwanted changes can be recognised.
There are transfer procedures for the installation of new software.

6.6.2 Security management controls / Sicherheitsmaßnahmen beim Computermanagement

The necessary security controls are documented in the GLOBALTRUST Certificate Security Policy.

6.6.3 Life cycle security controls / Sicherheitsmaßnahmen während des Lebenszyklus

The appropriate publications, recommendations and manufacturer information regarding the cryptographic keys are continuously evaluated and implemented. This is done at least once a year, but in any case on an ad hoc basis, for example in case of changes in the procedures of the CA, notifications by the supervisory authorities or other qualified third parties. The necessary security controls are documented in the GLOBALTRUST Certificate Security Policy.

6.7 Network security controls / Sicherheitsmaßnahmen Netzwerke

The necessary security controls are documented in the GLOBALTRUST Certificate Security Policy.

6.8 Time-stamping / Zeitstempel (gemäß [SigV] § 12 Abs. 2 Z 3,4)

Qualified and non-qualified time-stamping is conducted as per the GLOBALTRUST Certificate Practice Statement ð 6.8 Time-stamping / Zeitstempel.
Qualified timestamps are issued using a certificate with the additional qualification ” QUALIFIED TIMESTAMP ” and a number to distinguish different versions.
Time-stamping is performed on the basis of [eIDAS-VO] and [ETSI 319 421]. The accuracy of time information (maximum deviation from the actual time) fulfils the legal requirements for qualified timestamp services and is specified in the GLOBALTRUST Certificate Practice Statement.
Timestamp services are offered as server services, the technical facilities for which are subject to the same security and operational requirements as those for the issuance of certificates. The servers are operated in a secure environment and are physically, technically and organisationally secured against unauthorised changes. These requirements are described in the GLOBALTRUST Certificate Security Policy.
The operator uses a timestamp to confirm the existence of a particular hash value at the time that is shown in the timestamp. Hash values are accepted that are generated with algorithms that comply with the current state of the art, taking into consideration national and international requirements, for example from [ETSI TS 119 312]. The hash procedures accepted are particularly SHA-256, SHA-512 and RIPEMD-160. Further procedures are published on the website http://www.globaltrust.eu/produkte.html, for which the CA explicitly reserves the right to exclude particular procedures (without giving reasons) and/or accept new, appropriate procedures.
Timestamps are confirmed using an electronic signature generated by mechanism that comply with legal requirements and current technical standards (in particular [ETSI TS 119 312]). Timestamps are generated using keys intended only for timestamp services which are generated and administered in hardware that is suitable for cryptography Products are used to administer the keys that are appropriate for issuing qualified certificates. These are operated in a way that allows them to issue mass signatures. These products are secured against unauthorised reading and changes of the keys.
The keys and certificates necessary for the timestamp service are generated in the same way as described for the issuance of end user keys for the subscriber (ð4.1 Certificate Application / Antragstellung, p61). All relevant timestamping processes are documented, in particular with relation to key generation, key life cycle management and failures inc. deviations from the guaranteed time.
The timestamp service is available during the business hours of the CA and, at the least, during the legally stipulated minimum hours. Changes or exceptions to this availability, especially additional availability, is published on the website of the operator http://www.globaltrust.eu/auditreport.html or agreed individually with the users of the timestamp service.
The operator aims for 99% availability of the timestamp service (fewer than 88 hours of outage per year) and provides a report on the outage times for registered users of the timestamp service and regulatory authorities on an annual basis. However, the minimum availability time alone does not constitute a guarantee.
Every timestamp is provided with a distinctive serial number, the issuing certificate, an accuracy statement (or a reference to the relevant policy in which accuracy is defined) and the conditions of the timestamp allocation (or a reference to the relevant policy in which the conditions are described).
In addition, every timestamp contains information on which request (hash value) it corresponds to. Every valid timestamp assigned is archived. The time information for which a hash value is signed and the hash tag itself are an integral part of the data structure signed by the timestamp service (ð Timestamp).
The current signature verification data necessary to establish a valid timestamp can be determined using the certificate that issues the timestamp. Timestamp certificates contain references to one or more CA certificates. In any event, the highest certificate is the GLOBALTRUST root certificate, an earlier or succeeding root certificate, for which the operator is responsible. The certificate verification data for the timestamp (inc. the current timestamp procedure) is published on the website of the CA at http://www.globaltrust.eu/certificate-policy.html or in one of links listed in the applicable certificate policy. A timestamp issued by the CA can be verified using any software that conforms to the standard [RFC3161]. In addition, the CA makes verification software available for download free from its website http://www.globaltrust.eu/certificate-policy.html. If the correctness of the timestamp cannot be established beyond doubt by the user, the CA offers individual verification of timestamp data by the CA.
A timestamp is verified by comparing the hash values of an existing document with the signed hash value from the data structure of the time stamp. If the hash values are identical, the existence of the document at the time given in the time-stamp is confirmed.
Regarding timestamps that are generated according to procedure and can no longer be definitely seen as reliable as per the decision of the regulatory authority or recognized standardization committees (in particular as per the recommendations [ETSI TS 119 312]), the requester will be informed, if their identity is known and valid contact details are available.
The operator ensures the accuracy of the timestamp with a maximum deviation from the actual time of 1 second. If European legal requirements or international standards require greater accuracy, this will be ensured. Current information on time accuracy is made available on the website of the CA http://www.globaltrust.eu or upon request. The actual time is defined as UTC. Measures to ensure adherence to the actual time are described in the GLOBALTRUST Certificate Practice Statement.

7. CERTIFICATE, CRL, AND OCSP PROFILES / Profile der Zertifikate, Widerrufslisten und OCSP

The content and technical description of the certificate can be read from the respective announcements and notices on the website of the CA.
In addition, the following applies for server certificates (EV included):
– further information on the applicant is only admissable if it has been checked during an application review. If necessary because of missing information, fields in the subject string are left completely blank.
– the issuer string contains the same data as the issuing CA-certificate’s Subject String data.
Essentially standardised directory and revocation services are provided for issued certificates as per the following technical standards and technical norms:
– directory service as LDAP service as per [RFC4511] and the relevant standards.
– revocation service as OCSP service as per [RFC2560] and the relevant standards.
– revocation service as CRL service as per [RFC5280] and the relevant standards distributed.
The scope and technique of the registry and revocation services provided come from the individual entries in the certificate, the applicable certificate policy, the legal requirements and individual agreements.

7.1 Certificate profile / Zertifikatsprofile

All certificate formats described in the respective GLOBALTRUST Certificate Practice Statement are supported, at least certificates as per X.509v3. The procedures and algorithms used for X.509v3 certificates are documented in [ITU‑X509v3] and [RFC5280]. In addition, restrictions and the requirements of standards and documents that conform to the Trust Service are observed, in particular requirements that come from the requirements of the regulatory authority [CABROWSER‑BASE] or [CABROWSER-EV].
Qualified certificates contain information as per [ETSI EN 319 412]. Additional information is possible in the certificates, if they are not misleading, are factually correct and do not breach any compulsory legal requirements.
Qualified certificates for electronic signatures are issued so as to comply with the requirements in [eIDAS-VO] Appendix I, [ETSI EN 319 412]. In countries where [eIDAS-VO] is not in effect, they are issued as per the national regulations of the country where the applicant has domicile.

Qualified certificates for remote signatures are issued so as to comply with [eIDAS-VO] Appendix I, recital 51 and 52, [ETSI EN 319 412].
Qualified server certificates are issued so as to comply with the requirements in [eIDAS-VO] Appendix IV, [ETSI EN 319 412] and [CABROWSER-EV]. In countries where [eIDAS-VO] is not in effect, they are issued as per the national regulations of the country where the applicant has domicile.
In addition to this, a permissible qualified certificate can contain information (additional or optional) that is admissable on the basis of other regulations.
EV certificates fulfil the critera of [CABROWSER-EV] and [WEBTRUST-EV].
Every certificate is issued with a distinct serial number.
The serial number of a certificate contains an entropy of at least 64 bits and is generated by a cryptographically secure pseudo-random number generator (CSPRNG)
For all issuance of certificates, including re-certification und re-key, certificates are issued with a new distinct number. An exchange of certificates with the same number is not anticipated and is prevented with technical and organisational measures. The requirements for the issuance of certificates for re-certification and re-key are the same as those for the original issuance.
The certificates contain at least the following information:
– name or identifier of the subscriber. Identifiers are selected so as not to be confused with the name of a third party,
– where applicable, pseudonyms are specially marked so that they are not confused with first names or surnames, or official company or organisation names.
– the public key that is assigned to the private key of the subscriber,
– the advanced signature of the CA,
– the distinct identifier and serial number of the Trust Service,
– the start date of the validity of the certificate,
– the end date of the validity of the certificate, which cannot be before the start date,
– a reference to the applicable certificate policy.
– If a certificate is issued to a person who belongs to an organization, the personal and organizational data are entered in the fields provided, so that the Subject Distinguished Name identifies person and organization correctly.
In addition, the following applies for EV and qualified server certificates:
– Attributes not permitted by [CABROWSER-EV] are rejected by technical means.
– the certificate contains a verified organisation name.
– wild card entries are not allowed in subjectAltName or in commonName.
– the subject string contains the field businessCategory with the content “Private Organization”, “Government Entity” or “Non-Commercial Entity”, depending on the categorisation of the organisation of the applicant (ð 3.2.5 Validation of authority / Nachweis der Vertretungsbefugnis, p58).
– the subject string contains a selection of fields jurisdictionOfIncorporationLocalityName, jurisdictionOfIncorporationStateOrProvinceName, jurisdictionOfIncorporationCountryName. The selection is defined by the jurisdiction of the organisation registration.

– the subject string contains the field serialNumber which contains the verified registration number of the organisation. If this is not available, the dat of registration can also be entered.
– the verified address of the organisation is shown in the subject string in the fields countryName, stateOrProvincename (if applicable for that country) and localityName. The fields postalCode and streetAddress are optional.
– If an organizationIdentifier (OID: 2.5.4.97) containing a registration number according to [ETSI 319 412-4] is present, also a cabfOrganizationIdentifier (OID: 2.23.140.3.1) entry according to [CABROWSER-EV] is used.
The root certificates of the issuer and user (applicant) have identical information. They can be verified on the basis of the information in the certificate, in particular on the basis of the policy reference.
The private key of the root certificate is generated for use using RSA and with a minimum length of 4096 bits. The hash algorithm used is for the root certificate SHA1. For root certificates that have been created since 1 October 2014, this is at least SHA256.
The private keys of any CA certificates are generated using RSA and with a minimum length of 4096 bits. The hash algorithm used is at least SHA256.

7.1.1 Version number(s) / Versionsnummern

The version number 3 according to [RFC5280] (X509v3) is supported.

7.1.2 Certificate extensions / Zertifikatserweiterungen

Certificates in X.509 format can contain arbitrary technically and legal permitted extensions that do not contradict the purpose of the certificate and are not misleading. The applicant or the CA can initiate the adding of extensions. Care is taken to sufficiently document the identifiers and content of the extensions and to ensure that conditions and restrictions on use are observed.
If server certificates are issued in X.509v3 format, they always contain the extension subjectAltName [RFC5280]. This contains entries of the dNSName (in the preferred syntax according to [RFC 5280]) or iPAddress type only. If the subject contains the field commonName, its content is always an entry (domain name or IP address) from subjectAltName.
The commonName or subjectAltName extension field of a server certificate never contains an IP adress that the IANA has marked as reserved, or a Domain name that can not be seen as globallly unique because it does not end with a Top Level Domain that has been registered with the IANA Root Zone Database.
For the distribution of revocation status information, all certificates contain the following extensions:
1. a crlDistributionPoint extension that is not marked as critical and that contains a HTTP URL for the relevant revocation list
2. an authorityInformationAccess extension that is not marked as critical and that contains a HTTP URL to the relevant OCSP responder
Point 2 is not necessary if “OCSP stapling”(as per [RFC4366]) is deployed and is either technically examined or contractually required by the operator.
Similarly, all other CA, sub- and end user certificates contain these extensions if they do not contradict technical or legal reasons.

The CA can issue enduser-sub-certificates especially for a subscriber. The private key can remain in the sole control of the CA or be administered by the user.
A enduser-sub-certificate is technically restricted as far as is possible. This means that:
– A enduser-sub-certificate in X.509v3 format contains an ExtendedKeyUsage extension that contains possible EKU values of end user certificates. The extension never contains the value anExtendedKeyUsage.
– If a enduser-sub-certificate in X.509v3 format is allowed the EKU id-kp-serverAuth, the option to issue dNSName entries must be restricted to confirmed domains (ð 7. CERTIFICATE, CRL, AND OCSP PROFILES / Profile der Zertifikate, Widerrufslisten und OCSP, p164) using a NameConstraints extension or entries of the dNSName type must be completely prohibited.
– If a enduser-sub-certificate in X.509v3 format is allowed, the EKU id-kp-serverAuth, the option to issue iPAddress entries must be restricted to confirmed address ranges (ð 7. CERTIFICATE, CRL, AND OCSP PROFILES / Profile der Zertifikate, Widerrufslisten und OCSP, p164) using a NameConstraints extension or entries of the iPAddress type must be completely prohibited (IPv4 as well as IPv6 addresses).
– If a enduser-sub-certificate in X.509v3 format is allowed the EKU id-kp-emailProtection, the option to issue email address entries must be restricted to confirmed address ranges (ð 7. CERTIFICATE, CRL, AND OCSP PROFILES / Profile der Zertifikate, Widerrufslisten und OCSP, p164).
– If a enduser-sub-certificate in X.509v3 format is allowed the EKU id-kp-codeSigning, the possible directoryName must be restricted to a verified organizationName and countryName as well as an optional localityName and stateOrProvinceName entries using the NameConstraints extension.
If the enduser-sub-certificate is not restricted due to the above criteria, the following organisational requirements are fulfilled together:
– The certificate in X.509v3 format is published in the DER format before the user can issue certificates with it.
– The Certificate Policy and the Certificate Practice Statement of the enduser-sub-certificate is published if available. At least one of the documents must exist.
– The certifcate policy/certificate practice statement of the enduser-sub-certificate fulfils the criteria of [MOZILLA-CAPOL].
– The certificate policy of the enduser-sub-certificate is audited at least once a year by a competent independent auditor. The audit must at a minimum comply with the criteria [CABROWSER-BASE]. The audit report is published.
All publications named above are available on the website of the CA and are available without restriction.

7.1.3 Algorithm object identifiers / Algorithmen OIDs

Certificates contain a reference to the algorithm of the public key and the method with which it was signed by the CA certificate. All methods specified or referenced in [RFC5280] and other compatible algorithms that satisfy the technical requirements of the respective Trust Service are permitted:
– Server certificates and S/MIME certificates as well as the corresponding CA certificates contain information about the parameters of the public key and the signature algorithm used. In the case of RSA keys, the minimum length must be 2048 bits with a modulus size divisible by 8. Used is rsaEncryption OID 1.2.840.113549.1.1 with a NULL parameter. CA certificates sign using the algorithm RSASSA-PKCS1-v1_5 with SHA-256, RSASSA-PKCS1-v1_5 with SHA-384, RSASSA-PKCS1-v1_5 with SHA-512. In the case of ECDSA keys, the curves P-256 and P-384 are supported. The encodings consist of an ecPublicKey-OID (1.2.840.10045.2.1) with a named curve parameter of the corresponding curve OID. According to [RFC5758], no NULL parameter is used. CA certificates sign using SHA256 (in the case of P-256) or SHA384 (in the case of P-384).
– Certificates for qualified remote signatures exclusively use RSASSA-PKCS1-v1_5 according to PKCS#1 v2.2 (RFC 8017) with key lengths of 2048, 3072 or 4096 bits, RSASSA-PSS according to PKCS#1 v2. 2 (RFC 8017) with key lengths of 2048, 3072 or 4096 bits or ECDSA according to FIPS PUB 186-4 and the NIST curves P-256, P-384 or P-521 with lengths of the parameters p, q of 256, 384 or 512 bits. Only the hash functions SHA-256, SHA-384 and SHA-512 according to ISO32/IEC33 10118-3 or FIPS 180-4 are supported for calculating the hash value. All algorithms used and associated parameters are represented by suitable OID entries in the certificate.

– For all other certificates, the following applies: the signature algorithm (in case of elipitic curves, including Curve Parameters) used and information on the public key parameters aredescribed in the certificate via an OID entry. They must comply with the current state of the art. It must comply with national and international requirements. In the case of RSA keys the minimum length is 2048 bits with a modulus divisble by 8 For ecliptical curves (EC) the minimum length is 256 bits, and one of the following Curve Parameters has to be used: FR, Brainpool or NIST, each with a hash algorithm of the SHA2 family (from SHA256).

7.1.4 Name formats / Namensformate

The naming in certificates complies with the rules set forth in [ITU-X500], [ITU-X509v3] and [RFC5280] and, if applicable, with further Conformity Documents.
Certificates always identify the subscriber (subject) and the respective CA (issuer).
If an attribute field is present in a certificate, it always contains a substantial entry, but never a mere indication of absence or inapplicability.
If the identity of the applicant has been verified for a server certificate, the certificate contains the organisation name according to registration documents. If server certificates in X.509v3 format are issued, the subject contains the entries: organizationName and also a countryName, a localityName and/or a stateOrProvince Name. In this event, an organizationalUnit entry can also exist, as long as this does not contain misleading or unverified information. The country in countryName refers to the IP address of the applicant, the IP address of their website, the country code of the contained domain or a valueconfirmed in the course of identity verification.
If the addresses entered were only technically verified and identification verification was not carried out, the subject of the certification does not contain any of the following fields: organizationName, localityName, stateOrProvinceName, postcalCode. If the subject has a domainComponent entry, this contains all sorted parts of the domain name entered in the certificate in reverse order.

7.1.5 Name constraints / Namensbeschränkungen

For all certificates, the same name (eg. distinguishedName) is never used for two different applicants within the same respective CA-certificate or enduser-sub certificate.

7.1.6 Certificate policy object identifier / Certificate Policy Object Identifier

Certificates with the exception of root certificates from 2015, contain a reference to the applicable Certificate Policy under which they were issued. For this GLOBALTRUST Certificate Policy, there is the OID-Number 1.2.40.0.36.1.1.8.1 In addition, certificates can contain a reference to the specifications of a third party that are observed when subscriber certificates are issued, in particular those given in [CABROWSER-BASE] and [CABROWSER-EV]. Server certificates contain the additional OID entry 2.23.140.1.2.2 (OV) or 2.23.140.1.1 (EV)
Subscriber certificates issued on or after 1.1.2021 contain a notice if the key resides in hardware signature creation device. In particular the following rules shall apply:
– In case of signature creation devices conformant to FIPS-2 Level 3 or CC EAL 4 Protection Profile CEN EN 419221-5:2018, the Certificate Policy OID 0.4.0.19431.1.1.3 or 0.4.0.19431.1.1.2 or 0.4.0.19431.1.1.1 is demonstrated.
– In case of signature creation devices conformant to FIPS-2 Level 2 or CC Protection Profile CWA 14169 or in case of signature creation devices confirmed as a Qualified Signature Creation Device, Certificate Policy OID 0.4.0.2042.1.2 or 0.4.0.194112.1.2 or 0.4.0.194112.1.3 is demonstrated.
Certificates that were issued between 1.7.2014 and 1.1.2020 and whose keys have not been generated in a signature creation device that complies with at least FIPS-140 2 L2 or CC Protection Profile CWA 14169 can contain the policy OID entry 1.2.40.0.36.4.1.10. This OID is not in use anymore and has no impact on the validity of the respective certificates.

Certificates for remotes signatures contain a policy-OID withing the range 0.4.0.194112.*

7.1.7 Usage of Policy Constraints extension / Nutzung der Erweiterung „PolicyConstraints“

This extension can be used according to the specifications of [RFC5280] if required.

7.1.8 Policy qualifiers syntax and semantics / Syntax und Semantik von „PolicyQualifiers“

This extension can be used according to the specifications of [RFC5280] if required.

7.1.9 Processing semantics for the critical Certificate Policies extension / Verarbeitung der Semantik der kritischen Erweiterung CertificatePolicies

Critical and non-critical extensions are used according to the specifications of [RFC5280].

7.2 CRL profile / Sperrlistenprofile

A reference to the applicable standards is sufficient for the use of standardised certificate formats (eg. X509v3). The content of the revocation list for certificates suitable for qualified signature, official signature or advanced signature complies with [RFC5280].
The issued certificate states which revocation and suspension service may be used. The subscriber’s individual technical requirements can be considered if they do not contradict the standards used, legal requirements or applicable GLOBALTRUST Certificate Practice Statement.
The scope of the revocation and/or suspension list can be found in the Trust Service’s notices at the regulatory authority or in the documentation on the website of the CA.

7.2.1 Version number(s) / Versionsnummern

Each CRL is provided with a version number.

7.2.2 CRL and CRL entry extensions / Erweiterungen von Widerrufslisten und Widerrufslisteneinträgen

Revocation lists can contain extensions that are specified in [RFC5280] or are compatible with [RFC5280].
Effective 30st September 2020, Certificate Revocation Lists for end user certificates may, Certificate Revocation Lists for CA certificates must contain the non critical extension reasonCode (OID 2.5.29.21) demonstrating the appropriate value according to [RFC5280], whereas the value unspecified is not not supported at all and the value certificateHold is not supported for server certificates.
Certificate Revocation Lists for qualified certificates contain the X509 extension “expiredCertsOnCRL” which correspondends to the OID string 2.5.29.60.

7.3 OCSP profile / Profile des Statusabfragedienstes (OCSP)

The operator’s OCSP service is operated as per [RFC6960].
OCSP responses for CAs that issue server certificates in X.509v3 format are signed by either the CA certificate itself or by a dedicated OCSP responder certificate that contains the extension id-pkix-oCA-nocheck (according to [RFC2560]).
An OCSP responder never delivers a “good” status back to an unknown certificates.
Effective 30st September 2020, OCSP responses for revoked end user certificates may, OCSP responses for revoked CA certificates must present the appropriate reason in the field revocationReason, as specified for CRLs in 7.2.2.

7.3.1 Version number(s) / Versionsnummern

The OCSP responses have a version number as per [RFC6960].

7.3.2 OCSP extensions / OCSP-Erweiterungen

The OSCP responses can contain extension as per [RFC6960], including but not limited to:
– ArchiveCutOff extension with the archiveCutOff date set to the CA’s certificate “notBefore” time and date value.

8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen

The operator declares that this document, together with the GLOBALTRUST Certificate Practice Statement (OID: 1.2.40.0.36.1.2.3.1) and the GLOBALTRUST Certificate Security Policy (OID: 1.2.40.0.36.1.2.2.1), fulfils the requirements of the following regulations in their current version:
– REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC [eIDAS-VO]
– Austrian Signature Law [SVG] together with the Signature Act [SVV]
– ETSI Policy and security requirements for Trust Service Providers issuing certificates EN 319 411 (Part 1: General Requirements and Part 2: Requirements for trust service providers issuing EU qualified certificates)
ETSI Policy and Security Requirements for Trust Service Providers issuing Time-Stamps EN 319 421 – Best practises policy for time-stamp (OID: 0.4.0.2023.1.1)
– Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures – Part 1: System Security Requirements [CWA-14167-1]
– Microsoft Root Certificate Program [MS-CA]
– CA/Browser Forum: Baseline Requirements [CABROWSER-BASE] published at https://www.cabforum.org
– [CABROWSER-EV] Guidelines For The Issuance And Management Of Extended Validation Certificates published at https://cabforum.org/extended-validation/
[CABROWSER-NETSEC] CABForum Network Security Controls
published at: https://cabforum.org/documents/#Network-and-Certificate-System-Security
– Mozilla CA Certificate Inclusion Policy [MOZILLA-CAPOL]
– Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework [RFC3647]
– Trust Service Principles and Criteria for Certification Authorities [WEBTRUST-CA]
– Webtrust for Certification Authorities – Extended Validation Audit Criteria [WEBTRUST-EV]
– Conformity with [ADOBE‑TRUST]
– Conformity with [MOZILLA-CAMAINT]
– Conformity with [APPLE-CA]
– Conformity with [ENISA-ALG]
Regular audits that comply with the conformity requirements of the documents cited ensure that the requirements are observed.
In the event of inconsistencies between the Trust Service’s documents and the documents which the Trust Services comply with, or in case of Conformity Documents being inconsistent with one another, the following rules apply:
a) legal requirements are immediately effective over the requirements of the Trust Service’s documents,
b) inconsistencies without a direct effect on the policy of the Trust Service are interpretively clarified on the website of the CA,
c) inconsistencies that directly affect the policy of the Trust Servicelead to adjustments of the documents concerned to establish consistency,
d) in all other cases, the requirements of the Conformity Documents take precedence over the Trust Service’s documents-
e) In case of Conformity Documents being inconsistent with one another, the stricter rule applies.

8.1 Frequency or circumstances of assessment / Häufigkeit und Umstände für Beurteilungen

Audits are conducted on principle once a year or as frequently as legally provided for or as provided for on the basis of the documents named in ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen with which this GLOBALTRUST Certificate Policy conforms.

8.2 Identity/qualifications of assessor / Identifikation/Qualifikation des Gutachters

External assessors are only consulted if they have an acceptable qualification in the sense of the definition of a ð competent independent auditor (p27). For internal assessors, in particular for self-assessments, the operator ensures they have the acceptable qualification and are reponsible for their activity.
In each case, it is documented which person is actually active as the assessor.

8.3 Assessor’s relationship to assessed entity / Beziehung des Gutachters zur geprüften Einrichtung

In the case of an internal assessor, an employee of the operator is nominated as per the role concept (ð GLOBALTRUST Certificate Security Policy). This person is independent in their audit activity and is not bound to any instructions.

8.4 Topics covered by assessment / Behandelte Themen der Begutachtung

The topics covered are documented in the assessment, in particular the standards or requirements under which an audit has been conducted, in the sense of the documents listed in ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen (p178).

8.5 Actions taken as a result of a deficiency / Handlungsablauf bei negativem Ergebnis

If a particular attribute or quality of Trust Services in the sense of this GLOBALTRUST Certificate Policy cannot be confirmed by an assessment, adjustments will be immediately made to technical and organizational procedures in order to achieve the necessary attribute or quality.
If a particular attribute or quality of Trust Services cannot be achieved even after adjustment of technical and organizational procedures, it will be assessed as to whether an equivalent attribute or quality of Trust Services can be achieved. In this event, and if necessary, affected documents are adjusted, in particular the GLOBALTRUST Certificate Policy or the GLOBALTRUST Certificate Practice Statement.
If there are no alternatives available, the attribute or quality concerned is removed from the applicable documents.

8.6 Communication of results / Mitteilung des Ergebnisses

Audit Attestation are published on the operator’s website within a maximum of three months.
If necessary because of a negative result, all ð affected parties are informed of the relevant results and measures in an appropriate fashion.

9. OTHER BUSINESS AND LEGAL MATTERS / Regelungen für sonstige finanzielle und geschäftliche Angelegenheiten

9.1 Fees / Kosten

Certificates are issued and Trust Services are performed subject to a fee.
The operator reserves the right to offer individual services for free, particularly for testing purposes.
Time-stamping services are offered both at a cost and free of charge. Timestamps can be retrieved with authentication or anonymously. In all cases, timestamping fulfils the same technical security requirements. In the case of authenticated retrieval, it is noted which office has made the request.

9.1.1 Certificate issuance or renewal fees / Kosten für Zertifikatsaustellung und -erneuerung

The applicable costs and conditions for each situation are published on the website of the CA or provided upon request.

9.1.2 Certificate access fees / Kosten für den Zugriff auf Zertifikate

Access to public certificates on the website of the operator is free-of-charge and not subject to non-technical restrictions.
Reimbursement can be requested for individual information disclosures and confirmations, in particular about certificates that are no longer in use and no longer available online. The reimbursement is at most the actual cost of this activity.

9.1.3 Revocation or status information access fees / Kosten für Widerruf oder Statusinformationen

The applicable costs and conditions for each situation are published on the website of the CA or provided upon request.

9.1.4 Fees for other services / Kosten für andere Dienstleistungen

The applicable costs and conditions for each situation are published on the website of the CA or provided upon request.

9.1.5 Refund policy / Kostenrückerstattung

The CA refunds the purchase costs of its products if they cannot be used due to errors in its work. If a product can only be used for part of the agreed period, the refund will only be made aliquot for the period in which the product cannot be used.
Furthermore, the CA offers free replacement for products that no longer meet the technical standards and at the time the product was made available the end of the validity of the technical standard was certain before the end of the product’s validity.
No reimbursement of the procurement costs of its products is due if the products can no longer be used due to changed technical or legal framework conditions and these changed framework conditions did not exist at the time the products were issued.
Any further reimbursement of costs and expenses, in particular consequential costs, resulting from the installation or operation of certificates is expressly excluded.

9.2 Financial responsibility / Finanzielle Verantwortung

The CA is aware of its responsibility to have sufficient financial means available and ensures that the financing of Trust Services is secure over the long term using appropriate operational activities and financial resources.

9.2.1 Insurance coverage / Versicherungsdeckung

The CA has arranged indemnity insurance with an insurance company of sufficient solvency that complies with legal requirements and if applicable with [CABROWSER-EV] and [WEBTRUST-EV]. The insurance arranged is documented internally.

9.2.2 Other assets / Andere Ressourcen für Betriebserhaltung und Schadensdeckung

The CA conducts an intensive exchange of experiences with equivalent entities to minimise and recognise (technical) threats early.

9.2.3 Insurance or warranty coverage for end users / Versicherung oder Gewährleistung für Endnutzer

The CA does not provide insurance for end users. The warranty covers the features promised in the GLOBALTRUST Certificate Policy. This does not affect or restrict warranties based on legal regulations.

9.3 Confidentiality of business information / Vertraulichkeit von Geschäftsdaten

9.3.1 Scope of confidential information / Definition vertrauliche Geschäftsdaten

Four security levels are applied to all information for the governance of operations. These levels lead to different appropriate security controls.
– “Public” level: includes all data that is intended or suitable to be published. Access to this data is not restricted, but controls are used to ensure availability and maintain data integrity .
All further levels include data that is not suitable for publication. Access is restricted to the intended users of the data. The levels result from the scope of technical controls to maintain availability and data integrity.
– “Internal” level (administration, “restricted access”): includes all data used for orderly operations in a commercial sense, inc. documentation, accounting, administration of customers and potential customers, offers and billing. Access to this data is regulated with instructions and/or activity descriptions and restricted to employees and persons authorised by the operator.
– “Confidential” level (system administration, “confidential information”): includes all data used to maintain and continue operations. Access is restricted using instructions and/or activity descriptions and technical restrictions (eg. passwords).
– “Secure” level (“private information”): includes all data subject to special certification processes, in particular data that is directly connected to key and certificate generation. Access is restricted using instructions and/or activitiy descriptions, increased technical access restrictions (eg. password + token) and specific secure hardware components.

9.3.2 Information not within the scope of confidential information / Geschäftsdaten, die nicht vertraulich behandelt werden

Non-confidential business data is handled as per ð “Public” level / Stufe “öffentlich”.

9.3.3 Responsibility to protect confidential information / Zuständigkeiten für den Schutz vertraulicher Geschäftsdaten

The protection of confidential business data is seen as a part of the comprehensive information security concept (ð Management-Statement p11) and is conceptually governed in security goals and guidelines as per the GLOBALTRUST Certificate Practice Statement and technically as per the GLOBALTRUST Certificate Security Policy. The responsibilities come from the role concept (ð GLOBALTRUST Certificate Security Policy).

9.4 Privacy of personal information / Datenschutz von Personendaten

All information kept on persons in the context of Trust Services is handled as confidential and is only used for the purposes of the Trust Service and for communication purposes in connection with the Trust Services of the CA.
Legal obligations to store and transfer data remain unaffected. Data is never transmitted to a commercial data seller (address publishers, list brokers,…)
Certification data, that is personal in the sense of the General Data Protection Regulation 2016/679, is being deleted after the expiry of the legal retention obligation.
Service providers have no direct access to personally identifiable information but only receive data previously released by the management and the service provider have the right to dispose about them.

9.4.1 Privacy plan / Datenschutzkonzept

The CA fulfils all requirements as per the applicable Austrian and European data protection laws. If not otherwise regulated, the regulations of the Austrian data protection law applies in its current version on the basis of the data protection guidelines of the General Data Protection Regulation 2016/679 of the European Union or successor regulation of the European Union.

9.4.2 Information treated as private / Definition von Personendaten

The CA understands private data as data on persons as per the current applicable European data protection law. If Austrian laws provide an extended scope, these data categories are also included in the scope of definition of private data.

9.4.3 Information not deemed private / Daten, die nicht vertraulich behandelt werden

The data of the subscriber is published only as necessary for the respective Trust Service (directory service, revocation service), for legal or other acceptable juridical reasons or at the explicit wish of the subscriber.

9.4.4 Responsibility to protect private information / Zuständigkeiten für den Datenschutz

Data protection laws are observed on the basis of the role concept (ð GLOBALTRUST Certificate Security Policy).

9.4.5 Notice and consent to use private information / Hinweis und Einwilligung zur Nutzung persönlicher Daten

The CA meets all necessary information, declaration and consent obligations of the applicable data protection regulations.

9.4.6 Disclosure pursuant to judicial or administrative process / Auskunft gemäß rechtlicher oder staatlicher Vorschriften

The CA guarantees the fulfillment of information obligations towards ð affected parties and in the context of obligations towards authorities and third parties, if they can prove a legitimate legal interest.

9.4.7 Other information disclosure circumstances / Andere Bedingungen für Auskünfte

The CA does not pass on data on persons if it is not explicitly obligated or is not explicitly authorised by an ð affected party to do so.

9.5 Intellectual property rights / Schutz-und Urheberrechte

The operator observes all necessary copyright laws and ensures in particular that it only uses or offers products or services for which it has the necessary copyright or license.

9.6 Representations and warranties / Zusicherungen und Garantien

9.6.1 CA representations and warranties / Leistungsumfang des VDA

The scope of services of the CA is fully described in this GLOBALTRUST Certificate Policy, the applicable GLOBALTRUST Certificate Practice Statement and on the website of the operator

9.6.2 RA representations and warranties / Leistungsumfang der Registrierungsstellen

The current scope of services of the registration offices is described on the website of the operator and in no event exceeds the GLOBALTRUST Certificate Policy.

9.6.3 Subscriber representations and warranties / Zusicherungen und Garantien des Signators

The general terms and conditions of the operator, this policy and the GLOBALTRUST Certificate Practice Statement apply.

9.6.4 Relying party representations and warranties / Zusicherungen und Garantien für Nutzer

Because there is no contractual relationship, there are no warranties or guarantees for the user.

9.6.5 Relying party representations and warranties of other participants / Zusicherungen und Garantien anderer Teilnehmer

Because there is no contractual relationship, there are no warranties or guarantees for other parties.

9.7 Disclaimer of warranties / Haftungsausschlüsse

The CA is not liable if it can demonstrate that it is not responsible for breaching the obligations detailed above and has not acted negligently. This applies particularly if
– applicants or subscribers use issued certificates contrary to the applicable policy or
– users of signatures, certificates and public keys neglect to observe validity periods, existing suspensions, revocations or other restrictions on a signature confirmed by a certificate from the CA or
– the applicant submits falsified or otherwise manipulated documents and this manipulation or falsification is not conspicuous.

9.8 Limitations on liability / Haftungsbeschränkungen

The CA is responsible
– for observing this policy in its own realm of responsibility, in particular for the measures contained within for the prompt publication of suspension and revocation lists and for the maintenance of suspension and revocation standards named in this policy.
– for informing applicants, subscribers and users of signatures, certificates and public keys of their obligations to observe the policy. It is proved that this has been communicated if the certificates issued by the CA contain clear reference to the location of documentation for the applicable policy.
– for ensuring that the applicant data contained in a certificate is verified at the time that the certificate is issued and that the data does not differ from the data in registries used for verification or from documents submitted. Verification measures are documented in this policy. The registries used for verification depend on the kind of applicant and can include technically or regionally different sources. Which sources are used for which applicant is documented in detail in CA internal process documentation.
– for following up on evidence that a registration office or other persons or organisations authorised by the CA have established a deficiency in verification of identity and ensuring that certificates are not issued without sufficient identification of the subscriber and that certificates are immediately revoked if there is reason to doubt that an identity verification has not been conducted properly.
– that a qualified certificate for electronic signatures matches the signature creation data in a signature creation device, if this has been issued by the CA. Otherwise that the subscriber was in the possession of the SSCD at the time that the qualified certificate for electronic signatures was issued.
This responsibility applies similarly for all certificates that have been issued using enduser-sub-certificates.
Software producers that distribute the root certificates of the CA are not responsible for the content of the certificates. They are held harmless by the CA where this is legally permitted and does not affect procedures for which the software producer is responsible. The software producer is responsible for ensuring that validity status is displayed correctly in the certificates of the CA.

9.9 Indemnities / Schadensersatz

The CA guarantees indemnities for proven damages for which it is responsible.

9.10 Term and termination / Gültigkeitsdauer der CP und Beendigung der Gültigkeit

9.10.1 Term / Gültigkeitsdauer der CP

The GLOBALTRUST Certificate Policy is valid until revoked.

9.10.2 Termination / Beendigung der Gültigkeit

The validity of the GLOBALTRUST Certificate Policy is terminated by
– revocation or
– notice of termination of the activity of the CA at the regulatory authority or
– the issuance of a new GLOBALTRUST Certificate Policy
In all cases, ð affected parties are informed in an appropriate fashion and the information is published on the website of the operator.

9.10.3 Effect of termination and survival / Auswirkung der Beendigung

Consequences of termination depend on the kind of termination and are stated in the communication to ð affected parties and the publication on the website of the operator.

9.11 Individual notices and communications with participants / Individuelle Mitteilungen und Absprachen mit Beteiligten

Individual communications will not be exchanged and agreements will not be made with ð involved parties who contravene the GLOBALTRUST Certificate Policy, the GLOBALTRUST Certificate Practice Statement or other conditions necessary for Trust Services.

9.12 Amendments / Änderungen

9.12.1 Procedure for amendment / Verfahren bei Änderungen

Amendments are assigned, planned and implemented as per the role concept (ð GLOBALTRUST Certificate Security Policy).
Changes, revisions and updates to the GLOBALTRUST Certificate Policy, the GLOBALTRUST Certificate Practice Statement, and the GLOBALTRUST Certificate Security Policy are approved by the Board. The review take place at least once a year. Even if the review reaches the conclusion that no substantial changes are to be made, a new document with no other changes than an incremented version number and a dated changelog entry is published.

9.12.2 Notification mechanism and period / Benachrichtigungsmechanismen und –fristen

Changes are communicated electronically, where permitted and technically possible. If the changes affected many ð parties, the changes are published on the website of the operator.
If it is not possible or not permitted to communicate the change electronically and the information on the website of the operator is not sufficient, other suitable methods of communicate are used, in particular post or courier services.
Changes are communicated to ð parties as early as possible. It is likewise communicated to the ð parties how they can respond.

9.12.3 Circumstances under which OID must be changed / Bedingungen für OID-Änderungen

Changes of OID, in particular changes in meaning, are only anticipated in the event of compulsory legal requirements or the requirements of the responsible standardisation committee.

9.13 Dispute resolution provisions / Bestimmungen zur Schlichtung von Streitfällen

The CA reserves the right to suggest arbitration services out of court. These arbitration services are published on the website of the operator.
Complaints can be submitted in any way communicated by the TSP (including telephone and email). They are documented internally, checked by responsible positions, observed and used to improve services.
In case of questions about interpretation or implementation of this GLOBALTRUST Certificate Policy, all parties have the right to consult experts or institutions. The VDA will answer to their proposals and include them in its decisions.
Attention is invited to the fact that all parties at any time have the right to call the RTR GmbH, which is the inspecting authority, to clarify open questions. The VDA will consider the opinions and proposals of the RTR GmbH

9.14 Governing law / Gerichtsstand

The operator is a company registered in the Austrian commercial register.
Its place of jurisdiction is in Vienna. Austrian law applies.
The CA is subordinate to the regulatory authorities responsible as per the following regulations:
– REGULATION (EU) No 910/2014 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC in its current version or a succeeding (superseding or additional) regulation of the European Union
– the Signature Law [SVG] together with the Signature Act [SVV] in the respectively current versions
technical standards and legal requirerments as per ð 8. COMPLIANCE AUDIT AND OTHER ASSESSMENTS / Prüfung der Konformität und andere Beurteilungen (p178)
The contact data of the regulatory authorities responsible and the registration information of the CA are published on the website of the CA.
9.15 Compliance with applicable law / Einhaltung geltenden Rechts

All Trust Services described in this document are performed as per the Austrian Signature Law, including the Signature Act [SVG] + [SVV] or the EU signature regulation [eIDAS-VO] or a national law of another state of the European Union or another state with an agreement with the European Economic Area, so that the assessment of security requirements for secure signature creation devices is appropriate as per the EU signature regulation [eIDAS-VO] or another law equivalent to the EU signature regulation [eIDAS-VO].
Technical implementation is performed as per ETSI standard [ETSI TS 101 456] including successors: [ETSI EN 319 401], [ETSI EN 319 411-1], [ETSI EN 319 411-2]. Extensions for the issuance of qualified certificates are performed as per [ETSI EN 319 412] or equivalent standards. In addition, the [CWA‑14167‑1] requirements for the operation of Trust Services and the [EG-REF] requirements for issuing secure signature creation devices are fulfilled.
The security concept fulfils the requirements of the EU signature regulation [eIDAS-VO], [SVG], [ETSI TS 101 456] including successors: [ETSI EN 319 401], [ETSI EN 319 411-1], [ETSI EN 319 411-2] and [CWA-14167-1] and is declared in the GLOBALTRUST Certificate Security Policy. It applies for all Trust Services run by the operator, including the timestamping service, mobile signatures and server-based signature services.
All Trust Services described in this GLOBALTRUST Certificate Policy are performed as per the requirements of the EU signature regulation [eIDAS-VO], the Austrian Signature Law [SVG], the Austrian Signature Act [SVV], the [ETSI TS 101 456] including successors: [ETSI EN 319 401], [ETSI EN 319 411-1] and (QCP Public + SSCD) policy requirements relating to the performance of Trust Services and [ETSI EN 319 411-2] relating to other certificate services and the [CWA-14167-1] security requirements, as well as the [ETSI EN 319 412] requirements for issuing qualified certificates. If individual regulations contradict one another, the regulation that comes closest to the technical and legal requirements of a secure Trust Service will be adopted.
This policy has been drafted in compliance with signature regulations and constitutes the basis of the subscriber’s usage of GLOBALTRUST certificates together with applicable agreements and the notices of the regulatory authority, as necessary according to [eIDAS-VO], [SVG] or other laws.
Trust Services are operated as per [CWA-14167-1] for all certificates and services governed by this policy. The operational technical details are documented in the GLOBALTRUST Certificate Practice Statement. If specific precautions relevant to security must be met, these are documented in the GLOBALTRUST Certificate Security Policy.

9.16 Miscellaneous provisions / Sonstige Bestimmungen

9.16.1 Entire agreement / Vollständigkeitserklärung

The CA is obligated to ensure that all requirements that arise from Trust Services are documented and the requirements stated in ð 4.5.1 Subscriber private key and certificate usage / Nutzung des privaten Schlüssels und des Zertifikates durch den Signator (p71) are brought to the attention of the subscriber and that it is contractually agreed that these requirements will be fulfilled.
The CA is responsible for observing all business processes for Trust Services.

9.16.2 Assignment / Abgrenzungen

The GLOBALTRUST Certificate Security Policy, the GLOBALTRUST Certificate Practice Statement and the GLOBALTRUST Certificate Security Policy are together the basis of the business concept submitted to the regulatory authority for approval. Other conditions not described in this document do not apply.

9.16.3 Severability / Salvatorische Klausel

If parts of this agreement are void and legal requirements change, this affects only those parts of this agreement. Other parts of the agreement remain in force.

9.16.4 Enforcement (attorneys’ fees and waiver of rights) / Vollstreckung (Anwaltsgebühren und Rechtsmittelverzicht)

Certification services based on this GLOBALTRUST Certificate Policy are undertaken only after approval by the responsible regulatory authority.

9.16.5 Force Majeure / Höhere Gewalt

The CA and the operator are not liable in the event of force majeure.

9.17 Other provisions / Other provisions

No change is made to this GLOBALTRUST Certificate Security Policy if
– it is an editorial correction only (correction of spelling, numbering, reference, link or grammar mistakes)
– individual fragments of text are moved to other sections or chapters, or explanatory subheadings or comments are inserted.
Changes of this kind will be noted on the website.

Appendix A – Documentation

1     [OBSOLETED]

2     [ADOBE-TRUST] Adobe Approved Trust List Technical Requirements Version 2.0 Stand: 2017/06/28
Original-Site: https://helpx.adobe.com/acrobat/kb/approved-trust-list2.html
Adobe Systems Inc. (Corporate headquarters), USA-95110-2704 San Jose, CA, 345 Park Avenue

3     [APPLE-CA] Program Requirements Stand: 2022/02/01
Original-Site: https://www.apple.com/certificateauthority/ca_program.html

4     [ASIG-EXT] Hollosi A., X.509 Zertifikatserweiterungen für die Verwaltung, X509ext – v1.0.3 Stand: 2005/02/21
Original-Site: http://www.cio.gv.at/it-infrastructure/pki/X509ext-1.0.3-20050221.pdf
Stabsstelle IKT-Strategie des Bundes (CIO Chief Information Officer), A-1010 Wien, Ballhausplatz 2

5     [ASIG-LAY] Layout Amtssignatur v2.0.1 Stand: 2014/12/31
Original-Site: http://www.ref.gv.at/AG-RS-Amtssignatur-las-2-0-1.3100.0.html
Stabsstelle IKT-Strategie des Bundes (CIO Chief Information Officer), A-1010 Wien, Ballhausplatz 2

6     [ASIG-LTF] Leitfaden Amtssignatur v1.0.0 Stand: 2009/01/13
Original-Site: http://www.ref.gv.at/AG-RS-Amtssignatur-las-1-4-0.2195.0.html
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

7     [ASIG-MOA] MOA-Amtssignaturen – MOA-AS Spezifikation Version 1.0.1 Stand: 2008/02/11
Original-Site: https://demo.egiz.gv.at/plain/content/download/454/2634/file/Spezifikation-MOA-AS.pdf
EGIZ E-Government Innovationszentrum, A-8010 Graz, Inffeldgasse 16a

8     [ASIT-QSEE-2020] Merkblatt Bescheinigungsverfahren – bildet Grundlage für Bescheinigungsbericht, wird von RTR als Evaluierungsdoku akzeptiert Stand: 2020/11/16
A-SIT Zentrum für sichere Informationstechnologie – Austria, A-1030 Wien, Seidlgasse 22/9

9     [ASIT-VIG-20-105] Angebot QSCD-Bestätigung TRUST2GO Stand: 2020/11/26
A-SIT Zentrum für sichere Informationstechnologie – Austria, A-1030 Wien, Seidlgasse 22/9

10    [ASR] Richtlinien der Österreichischen Notariatskammer vom 19.10.2006 für die Ausstellung und die Ausgabe von Ausweisen und Signaturkarten für die elektronische Notarsignatur, elektronische Kandidatensignatur und elektronische Beurkundungssignatur idF 21. Stand: 2016/10/21

11    [ASZ] Karlinger G., Amtssignaturzertifikate (ASZ) – Allgemeine Richtlinien für Amtssignaturzertifikate in der Verwaltung, Version 1.0.0 Stand: 2005/04/06
Original-Site: http://reference.e-government.gv.at/Amtssignaturzertifikate-erarb.1095.0.html
Stabsstelle IKT-Strategie des Bundes (CIO Chief Information Officer), A-1010 Wien, Ballhausplatz 2

12    [BMI-SZR] SZR 2.0 Anwendungsdokumentation extern Version 2.0 Stand: 2014/12/05
IT-Service – BM für Inneres (BMI), A-1090 WIEN, Berggasse 43

13    [BNA-IDV] Bestätigte Identifizierungsverfahren nach Art 24 Abs 1 litera d) eIDAS Stand: 2019/05/06
Original-Site: bundesnetzagentur.de

14    [BSI-100-1] BSI-Standard 100-1: Managementsysteme für Informationssicherheit (ISMS) v1.5 Stand: 2008/05/01
Original-Site: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1001_pdf.pdf?__blob=publicationFile
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

15    [BSI-100-2] BSI-Standard 100-2: IT-Grundschutz-Vorgehensweise v2.0 Stand: 2008/05/01
Original-Site: https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzStandards/Standard201/ITGStandard201_node.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

16    [BSI-100-3] BSI-Standard 100-3: Risikoanalyse auf der Basis von IT-Grundschutz v2.5 Stand: 2008/05/01
Original-Site: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1003_pdf.pdf?__blob=publicationFile
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

17    [BSI-100-4] BSI-Standard 100-4 Notfallmanagement v1.0 Stand: 2008/11/01
Original-Site: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/ITGrundschutzstandards/standard_1004_pdf.pdf?__blob=publicationFile
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

18    [BSI-GRUND] BSI – IT Grundschutz – Beschreibung Stand: 2010/04/07
Original-Site: https://www.bsi.bund.de/cln_174/DE/Themen/ITGrundschutz/StartseiteITGrundschutz/startseiteitgrundschutz_node.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

19    [BSI-TR-02102-2] BSI TR-02102-2 Technische Richtlinie – Kryptographische Verfahren: Empfehlungen und Schlüssellängen Version: 2019-01 Stand: 2019/02/22
Original-Site: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

20    [BSI-TR-03116] Technische Richtlinie BSI TR-03116 Kryptographische Vorgaben für Projekte der Bundesregierung Stand: 2019/05/02

21    [BSI-TR-03125] BSI TR-03125 Beweiswerterhaltung kryptographisch signierter Dokumente Stand: 2008/05/01
Original-Site: https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03125/index_htm.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

22    [BSI-TR-03147-ANFORDERUNGEN] Anforderungskatalog zur Prüfung von Identifikationsverfahren gemäß TR-03147 in Version 1.0 Stand: 2018/12/11

23    [BSI-TR-03147-PRÜFBERICHT] Prüfberichtsvorlage zur Prüfung von Identifikationsverfahren gemäß TR-03147 in Version 1.0 Stand: 2018/12/11

24    [BSI-TR-03147] Technische Richtlinie TR-03147 Vertrauensniveaubewertung von Verfahren zur Identitätsprüfung natürlicher Personen Version 1.0.5 Stand: 2018/12/05
Original-Site: https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/tr03147/index_htm.html

25    [BSI-TR-CRYPTO] Kryptographische Verfahren – Empfehlungen und Schlüssellängen, Version 2019 02 Stand: 2019/02/01
Original-Site: https://www.bsi.bund.de/DE/Publikationen/TechnischeRichtlinien/technischerichtlinien_node.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

26    [BÜRGERKARTE-STD] Standardisierte Key- und Infoboxen der österreichischen Bürgerkarte Stand: 2005/03/01
Original-Site: http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/infoboxes/infoboxes.html
IT-Service – BM für Inneres (BMI), A-1090 WIEN, Berggasse 43

27    [BÜRGERKARTE] Die österreichische Bürgerkarte – Dokumentation und Spezifikation Version 1.2.0 Stand: 2014/01/14
Original-Site: http://www.buergerkarte.at/konzept/securitylayer/spezifikation/aktuell/

28    [CABROWSER-BASE] CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates v1.8.2 Stand 2022/10/26
Original-Site: https://cabforum.org/baseline-requirements-documents/
CA/Browser Forum

29    [CABROWSER-EV] Guidelines For The Issuance And Management Of Extended Validation Certificates v1.7.8 Stand: 2021/11/28
Original-Site: https://cabforum.org/extended-validation/
CA/Browser Forum

30    [CABROWSER-NETSEC] CABForum Network Security Controls v1.1 Stand: 2017/10/31
Original-Site: https://cabforum.org/documents/#Network-and-Certificate-System-Security
CA/Browser Forum

31    [CARDOS53-ASIT-QES] Bestätigung A-SIT-1.108 Sichere Signaturerstellungseinheit CardOS V5.3 QES, V1.0 Stand: 2016/06/24
Original-Site: http://www.a-sit.at/de/bestaetigungsstelle/bescheinigungen_sigg/veroeffentlichungen.php
Atos IT Solutions and Services GmbH, D-81739 München, Otto-Hahn-Ring 6

32    [CARDOS53-CC-CR] Certification Report “CardOS V5.3 QES, V1.0” (BSI-DSZ-CC-0921-2014) Stand: 2014/08/06
Original-Site: https://www.bsi.bund.de/SharedDocs/Zertifikate_CC/CC/Digitale_Signatur-Sichere_Signaturerstellungseinheiten/0921.html
Atos IT Solutions and Services GmbH, D-81739 München, Otto-Hahn-Ring 6

33    [CARDOS53-CC-ST] Security Target ‘CardOS V5.3 QES, V1.0’, Rev. 1.61, Edition 07/2014 Stand: 2014/07/23
Original-Site: https://www.bsi.bund.de/SharedDocs/Zertifikate_CC/CC/Digitale_Signatur-Sichere_Signaturerstellungseinheiten/0921.html
Atos IT Solutions and Services GmbH, D-81739 München, Otto-Hahn-Ring 6

34    [CC-ITSE] Common Criteria for Information Technology Security Evaluation v3.1 – Revision 3 (ISO 15408) Stand: 2009/07/01
Original-Site: http://www.commoncriteriaportal.org/cc/
Common Criteria – Management c/o GCHQ – Government Communications Headquarters, GB-GL51 0EX Cheltenham, Gloucestershire, Room A2b, Hubble Road

35    [CEM-ITSE] Common Methodology for Information Technology Security Evaluation v3.1 – Revision 3 (ISO 15408) Stand: 2009/07/01
Original-Site: http://www.commoncriteriaportal.org/cc/
Common Criteria – Management c/o GCHQ – Government Communications Headquarters, GB-GL51 0EX Cheltenham, Gloucestershire, Room A2b, Hubble Road

36    [CEN EN 419221-5] EN 419221-5:2018 Protection Profiles for TSP Cryptographic Modules – Part 5: Cryptographic Module for Trust Services Stand: 2018/01/01
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

37    [CEN-419241-1] CEN EN 419 241-1 (ÖNORM EN 419241-1) – Trustworthy Systems Supporting Server Signing – Part 1: General System Security Requirements Stand: 2019/03/15
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

38    [CEN-419241-2] CEN EN 419 241-2 (ÖNORM EN 419241-2) – Trustworthy Systems Supporting Server Signing – Part 2: Protection profile for QSCD for Server Signing Stand: 2019/06/01
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

39    [CHROMIUM-CA] Root Certificate Policy Chrome + Android Stand: 2020/06/09
Original-Site: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/root-ca-policy
Google Inc., USA-94043 Mountain View, CA, 1600 Amphitheatre Parkway

40    [CWA 15579] CWA 15579 – E-invoices and digital signatures (Dezember 2007) Stand: 2007/12/01
Original-Site: https://www.cen.eu/work/areas/ICT/eBusiness/Pages/eInvoicing.aspx
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

41    [CWA-14167-1] CWA 14167-1 – Security Requirements for Trustworthy Systems Managing Certificates for Electronic Signatures – Part 1: System Security Requirements Stand: 2004/02/13
Original-Site: ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

42    [CWA-14167-2] CWA 14167-2 – Cryptographic module for CSP signing operations with backup – Protection profile – CMCSOB PP Stand: 2004/05/28
Original-Site: ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

43    [CWA-14167-3] CWA 14167-3 – Cryptographic module for CSP key generation services protection profile – CMCKG PP Stand: 2004/05/28
Original-Site: ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

44    [CWA-14167-4] CWA 14167-4 – Cryptographic module for CSP signing operations – Protection profile – CMCSO PP Stand: 2004/05/28
Original-Site: ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

45    [CWA-14169] CWA 14169 – Secure signature-creation devices “EAL 4+” Stand: 2004/05/28
Original-Site: ftp://ftp.cenorm.be/PUBLIC/CWAs/e-Europe/eSign/
CEN-CENELEC Management Centre, B-1000 Brussels, Avenue Marnix 17

46    [DSG-2018] Bundesgesetz zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten (Datenschutzgesetz – DSG) – RIS-Zusammenstellung Stand: 2018/05/25
Original-Site: http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=10001597&FassungVom=2018-05-25
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

47    [E-GOVG] Bundesgesetz über Regelungen zur Erleichterung des elektronischen Verkehrs mit öffentlichen Stellen (E-Government-Gesetz – E-GovG) – StF: BGBl. I Nr. 10/2004 Stand: 2013/05/23
Original-Site: http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20003230
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

48    [EBA-OP] EBA Opinion on the use of eIDAS certificates under the RTS on SCACSC Stand: 2019/05/02

49    [eBillVO] Verordnung der Bundesministerin für Finanzen, mit der die Anforderungen an eine elektronische Rechnung bestimmt werden (E-Rechnung-UStV) – RIS-Version Stand: 2012/12/28
Original-Site: http://ftp.freenet.at/privacy/gesetze/ebilling-verordnung-2013.pdf
BM für Finanzen (BMF), A-1010 Wien, Johannesgasse 5

50    [EG-REF] 2003/511/EG: Entscheidung der Kommission vom 14. Juli 2003 über die Veröffentlichung von Referenznummern für allgemein anerkannte Normen für Produkte für elektronische Signaturen gemäß der Richtlinie 1999/93/EG Stand: 2003/07/14
Original-Site: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32003D0511:DE:HTML
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

51    [EG-SSCD] 2009/767/EG Maßnahmen zur Erleichterung der Nutzung elektronischer Verfahren über „einheitliche Ansprechpartner“ gemäß der Richtlinie 2006/123/EG Stand: 2009/12/28
Original-Site: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:299:0018:01_DEC_2009_767_54:DE:HTML
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

52    [EGOV-DOK] Übersicht E-Government-Dokumente Stand: 2015/12/31
Original-Site: https://www.ref.gv.at/KONVENTIONEN.1116.0.html
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

53    [eIDAS-IMPL] Abl. L 235/37 Durchführungsbeschluss (EU) 2015/1506 zur Festlegung von Spezifikationen für Formate fortgeschrittener elektronischer Signaturen und fortgeschrittener Siegel, die von öffentlichen Stellen gemäß Artikel 27 Absatz 5 und Artikel 37 Stand: 2015/09/08
Original-Site: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:JOL_2015_235_R_0006
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

54    [eIDAS-SEC] DURCHFÜHRUNGSVERORDNUNG (EU) 2015/1502 DER KOMMISSION vom 8. September 2015 zur Festlegung von Mindestanforderungen an technische Spezifikationen und Verfahren für Sicherheitsniveaus elektronischer Identifizierungsmittel gemäß Artikel 8 Absatz Stand: 2015/11/08

55    [eIDAS-VO] Abl. L 257/73 VERORDNUNG (EU) 910/2014 elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt (“eIDAS-Verordnung”) Stand: 2014/08/28
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32014R0910
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

56    [ENISA-ALG] Algorithms- key size and parameters report – 2014.pdf Stand: 2014/01/01
Original-Site: https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014
European Network and Information Security Agency (ENISA), GR-700 13 Heraklion, Vassilika Vouton (P.O. Box 1309)

57    [EREGV-2009] Ergänzungsregisterverordnung 2009 – ERegV 2009 – RIS-Version Stand: 2015/08/26
Original-Site: http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20006490
Stammzahlenregisterbehörde, A-1010 Wien, Hohenstaufengasse 3

58    [ETOKEN-CC-CR] CC EAL4+ Certification Report: SafeNet eToken – Athena IDProtect/OS755 Java Card on Atmel AT90SC25672RCT-USB Microcontroller embedding IDSign applet Stand: 2011/03/04
Original-Site: http://www.commoncriteriaportal.org/files/epfiles/ANSSI-CC_2011-03fr.pdf
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

59    [ETOKEN-CC-ST] CC EAL4+ Security Target: SafeNet eToken – Athena IDProtect/OS755 Java Card on Atmel AT90SC25672RCT-USB Microcontroller embedding IDSign applet v1.2 Stand: 2011/02/16
Original-Site: http://www.commoncriteriaportal.org/files/epfiles/ANSSI-CC-cible_2011-03en.pdf
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

60    [ETOKEN-FIPS-L2-CERT] FIPS 140-2 L2 Zertifikat #1135 Aladdin eToken PRO (Java), Aladdin eToken Anywhere and Aladdin eToken PRO (Java) SC Stand: 2011/10/26
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm#1135
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

61    [ETOKEN-FIPS-L3-CERT] FIPS 140-2 L3 Zertifikat #1136 “Aladdin eToken PRO (java) HD” Stand: 2011/10/26
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1136.pdf
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

62    [ETOKEN-FIPS-L3-SP] FIPS 140-2 L3 Security Policy #1136 “Aladdin eToken PRO (java) HD” Stand: 2011/10/18
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1136.pdf
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

63    [ETSI EN 301 549] ETSI EN 301 549 – V2.1.2 Accessibility requirements for ICT products and services Stand: 2018/08/28
Original-Site: https://portal.etsi.org/webapp/workProgram/Report_WorkItem.asp?wki_id=50127
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

64    [ETSI EN 319 122-1] ETSI EN 319 122-1 V1.1.1 CAdES digital signatures; Part 1: Building blocks and CAdES baseline signatures Stand: 2016/04/08
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39473
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

65    [ETSI EN 319 122-2] ETSI EN 319 122-2 V1.1.1 CAdES digital signatures; Part 2: Extended CAdES signatures Stand: 2016/04/01
Original-Site: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/e-Signature+standards
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

66    [ETSI EN 319 132-1] ETSI EN 319 132-1 V1.1.1 XAdES digital signatures; Part 1: Building blocks and XAdES baseline signatures Stand: 2016/04/29
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39476
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

67    [ETSI EN 319 132-2] ETSI EN 319 132-2 V1.1.1 XAdES digital signatures; Part 2: Extended XAdES signatures Stand: 2016/04/29
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39477
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

68    [ETSI EN 319 142-1] ETSI EN 319 142-1 V1.1.1 PAdES digital signatures; Part 1: Building blocks and PAdES baseline signatures Stand: 2016/04/12
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39485
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

69    [ETSI EN 319 142-2] ETSI EN 319 142-2 V1.1.1 PAdES digital signatures; Part 2: Additional PAdES signatures profiles Stand: 2016/04/12
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39479
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

70    [ETSI EN 319 401] ETSI EN 319 401 – V2.2.1 Electronic Signatures and Infrastructures (ESI); General Policy Requirements for Trust Service Providers Stand: 2018/04/01
Original-Site: http://www.etsi.org/deliver/etsi_en/319400_319499/319401/02.02.01_60/en_319401v020201p.pdf
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

71    [ETSI EN 319 403] ETSI EN 319 403 V2.2.2 Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment – Requirements for conformity assessment bodies assessing Trust Service Providers Conformity Assessment of Trust Service Stand: 2015/08/27
Original-Site: https://portal.etsi.org/webapp/workProgram/Report_WorkItem.asp?wki_id=39371
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

72    [ETSI EN 319 411-1] ETSI EN 319 411-1 v1.2.2 Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General Requirements Stand: 2018/04/01
Original-Site: https://portal.etsi.org/tbsitemap/esi/trustserviceproviders.aspx
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

73    [ETSI EN 319 411-2] ETSI EN 319 411-2 V2.2.2 (2018-04) Electronic Signatures and Infrastructures (ESI) Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified Stand: 2018/04/01
Original-Site: https://portal.etsi.org/tbsitemap/esi/trustserviceproviders.aspx
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

74    [ETSI EN 319 412-1] ETSI EN 319 412-1 V1.1.1 (2016-02) Electronic Signatures and Infrastructures (ESI);Certificate Profiles; Part 1: Overview and common data structures Stand: 2016/02/26
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39367
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

75    [ETSI EN 319 412-2] ETSI EN 319 412-2 V2.1.1 (2016-02) Electronic Signatures and Infrastructures (ESI);Certificate Profiles; Part 2: Certificate profile for certificates issued to natural persons Stand: 2016/02/01
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

76    [ETSI EN 319 412-3] ETSI EN 319 412-3 V1.1.1 (2016-02) Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 3: Certificate profile for certificates issued to legal persons Stand: 2016/02/01
Original-Site: http://www.etsi.org/deliver/etsi_en/319400_319499/31941203/01.01.01_60/en_31941203v010101p.pdf

77    [ETSI EN 319 412-4] ETSI EN 319 412-4 – V1.1.1 – Electronic Signatures and Infrastructures (ESI); Certificate Profiles; Part 4 Stand: 2016/02/01
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

78    [ETSI EN 319 412-5] V2.2.1 Part 5: QCStatements Stand: 2017/11/01
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=51426

79    [ETSI EN 319 421] ETSI EN 319 421 V1.1.1 (2016-03) Electronic Signatures and Infrastructures (ESI); Policy and Security Requirements for Trust Service Providers issuing Time-Stamps Stand: 2016/03/01
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39366

80    [ETSI EN 319 422] ETSI EN 319 422 V1.1.1 – Electronic Signatures and Infrastructures (ESI); Time-stamping protocol and time-stamp token profiles Stand: 2016/03/01
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=39370
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

81    [ETSI TS 102 778-1] ETSI TS 102 778-1 V1.1.1 Part 1: PAdES Overview – a framework document for PAdES Stand: 2009/07/31
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=31003

82    [ETSI TS 103 123] ETSI TR 103 123 V1.1.1 Electronic Signatures and Infrastructures (ESI); Guidance for Auditors and CSPs on ETSI TS 102 042 for Issuing Publicly-Trusted TLS/SSL Certificates Stand: 2012/11/16
Original-Site: http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?wki_id=38245
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

83    [ETSI TS 119 312] ETSI TS 119 312 1.2.2 Electronic Signatures and Infrastructures (ESI); Cryptographic Suites Stand: 2018/09/20
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=56375
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

84    [ETSI TS 119 312] ETSI TS 119 312 1.3.1 Electronic Signatures and Infrastructures (ESI); Cryptographic Suites Stand: 2019/02/01
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=56375
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

85    [ETSI TS 119 403] ETSI TS 119 403 V2.1.1 (2014-11) Electronic Signatures and Infrastructures (ESI); Trust Service Provider Conformity Assessment – Requirements for conformity assessment bodies assessing Trust Service Providers Stand: 2014/09/16
Original-Site: http://webapp.etsi.org/workprogram/Report_WorkItem.asp?WKI_ID=44560
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

86    [ETSI TS 119 431-1] ETSI TS 119 431-1 V1.1.1 (2018-12) Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers; Part 1: TSP service components operating a remote QSCD / SCDev Stand: 2018/12/01
Original-Site: https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=47242
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

87    [ETSI TS 119 431-2] ETSI TS 119 431-2 V1.1.1 (2018-12) Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service providers; Part 2: TSP service components supporting AdES digital signature creation Stand: 2018/12/01
Original-Site: https://portal.etsi.org/webapp/workprogram/Report_WorkItem.asp?WKI_ID=52778
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

88    [ETSI TS 119 432] ETSI TS 119 432 V1.1.1 (2019-03) Electronic Signatures and Infrastructures (ESI); Protocols for remote digital signature creation Stand: 2019/03/01
Original-Site: https://www.etsi.org/standards#page=2&search=&title=1&etsiNumber=1&content=0&version=0&onApproval=1&published=1&historical=1&startDate=2015-01-15&endDate=2019-08-06&harmonized=0&keyword=&TB=607&stdType=&frequency=&mandate=&collection=&sort=2
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

89    [ETSI TS 119 461] DRAFT ETSI TS 119 461 V0.0.5 Electronic Signatures and Infrastructures (ESI); Policy and security requirements for trust service components providing identity proofing of trust service subjects Stand: 2020/12/01
Original-Site: https://portal.etsi.org/
European Telecommunications Standards Institute (ETSI), F-06921 Sophia-Antipolis Cedex, 650, route des Lucioles

90    [ETSI TS 119 495] V1.3.2 Electronic Signatures and Infrastructures (ESI); Sector Specific Requirements; Qualified Certificate Profiles and TSP Policy Requirements under the payment services Directive (EU) 2015/2366 Stand: 2019/06/01
Original-Site: https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=58043

91    [EU-QSCD-LIST] Qualified Signature Creation Devices under Article 31(1)-(2), and Certified Qualified Seal Creation Devices under Article 39(3) of Regulation 910/2014 Stand: 2019/05/08
Original-Site: https://ec.europa.eu/futurium/en/content/compilation-member-states-notification-sscds-and-qscds
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

92    [EU-RICHT-ZAHL] Zahlungsdienste im Binnenmarkt, zur Änderung der Richtlinien 2002/65/EG, 2009/110/EG und 2013/36/EU und der Verordnung (EU) Nr. 1093/2010 Stand: 2015/11/25
Original-Site: https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=celex:32015L2366

93    [FIPS-140-2] FIPS 140-2 Security Requirements for Cryptographic Modules inkl. Annex A-D Stand: 2002/03/12
Original-Site: http://csrc.nist.gov/publications/PubsFIPS.html
NIST – National Institute of Standards and Technology, USA-MD 20899-107 Gaithersburg, 100 Bureau Drive, Stop 1070

94    [FMA-IDV] Online-Identifikationsverordnung – Online-IDV Stand: 2019/04/01
Original-Site: https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20009774

95    [FORTIOS-CC-CR] Certification Report: EAL 4+ evaluation of Fortinet FortiGate Unified Threat Management Solutions and FortiOS 4.0 CC compliant firmware v1.0 Stand: 2012/01/23
Original-Site: http://www.commoncriteriaportal.org/files/epfiles/383-4-133%20CR%20v1.0e.pdf
Fortinet Inc, USA-CA 94086 Sunnyvale, 1090 Kifer Road

96    [FORTIOS-CC-ST] Fortinet FortiGate Unified Threat Management Solutions and FortiOS 4.0 CC Compliant Firmware Stand: 2011/12/06
Original-Site: http://www.commoncriteriaportal.org/files/epfiles/383-4-133%20ST%20v1.2.pdf
Fortinet Inc, USA-CA 94086 Sunnyvale, 1090 Kifer Road

97    [FORTIOS-FIPS-CERT] Fips 140-2 (Level 1) Certificate #1754: FortiOS v4.0MR3 Stand: 2012/07/17
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/FIPS140ConsolidatedCertList0019.pdf
Fortinet Inc, USA-CA 94086 Sunnyvale, 1090 Kifer Road

98    [FORTIOS-FIPS-SP] Fips 140-2 (Level 1) Security Policy #1754: FortiOS 4.0 MR3 Stand: 2012/04/13
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1754.pdf
Fortinet Inc, USA-CA 94086 Sunnyvale, 1090 Kifer Road

99    [HB-SICHERHEIT] Österreichisches Informationssicherheitshandbuch – Version 4.0.0 (Hrsg. Bundeskanzleramt) Stand: 2014/09/23
Original-Site: https://www.sicherheitshandbuch.gv.at/2013/index.php
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

100  [ISO-7816-10] ISO/IEC 7816-10:1999: Identification cards — Integrated circuit(s) cards with contacts — Part 10: Electronic signals and answer to reset for synchronous cards Stand: 1999/11/01
Original-Site: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=35&ics2=240&ics3=15&csnumber=30558
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

101  [ISO-7816-11] ISO/IEC 7816-11:2004: Identification cards — Integrated circuit cards — Part 11: Personal verification through biometric methods Stand: 2004/04/01
Original-Site: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=35&ics2=240&ics3=15&csnumber=31419
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

102  [ISO-7816-12] ISO/IEC 7816-12:2005: Identification cards – Integrated circuit cards — Part 12: Cards with contacts — USB electrical interface and operating procedures Stand: 2005/10/01
Original-Site: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=35&ics2=240&ics3=15&csnumber=40604
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

103  [ISO-7816-13] ISO/IEC 7816-13:2007: Identification cards — Integrated circuit cards — Part 13: Commands for application management in a multi-application environment Stand: 2007/03/15
Original-Site: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=35&ics2=240&ics3=15&csnumber=40605
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

104  [ISO-7816-15] ISO/IEC 7816-15:2004: Identification cards — Integrated circuit cards — Part 15: Cryptographic information application inkl. Ergänzung Stand: 2008/12/15
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

105  [ISO-7816-1] ISO/IEC 7816-1:2011 Identification cards — Integrated circuit(s) cards with contacts — Physical Charcteristics of Integrated Circuit Cards ISO Stand: 2011/02/15
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

106  [ISO-7816-2] ISO/IEC 7816-2:2007 Identification cards — Integrated circuit cards — Dimensions and Location of the Contacts ISO Stand: 2007/10/15
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

107  [ISO-7816-3] ISO/IEC 7816-3:2006 Identification cards — Integrated circuit cards — Electronic Signals and Transmission Protocols ISO Stand: 2006/11/01
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

108  [ISO-7816-4] ISO/IEC 7816-4:2005 Interindustry Commands for Interchange + Korrektur Stand: 2013/04/15
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

109  [ISO-7816-5] ISO/IEC 7816-5:2004: Identification cards — Integrated circuit cards — Part 5: Registration of application providers Stand: 2004/12/01
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

110  [ISO-7816-6] ISO/IEC 7816-6:2004: Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for interchange inkl. Korrektur Stand: 2004/05/15
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

111  [ISO-7816-7] ISO/IEC 7816-7:1999: Identification cards — Integrated circuit(s) cards with contacts — Part 7: Interindustry commands for Structured Card Query Language (SCQL) Stand: 1999/03/01
Original-Site: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=35&ics2=240&ics3=15&csnumber=28869
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

112  [ISO-7816-8] ISO/IEC 7816-8:2004: Identification cards — Integrated circuit cards — Part 8: Commands for security operations Stand: 2004/06/01
Original-Site: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?ics1=35&ics2=240&ics3=15&csnumber=37989
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

113  [ISO-7816-9] ISO/IEC 7816-9:2004: Identification cards — Integrated circuit cards — Part 9: Commands for card management Stand: 2004/06/01
International Organization for Standardization (ISO), CH-1211 Geneva 20, 1, ch. de la Voie-Creuse CP 56

114  [ISO27-A1TEL] A1 Telekom Austria – ISO 27001 Zertifikat 15/0 ISO/IEC 27001:2005 – pdf-Version deutsch + englisch Stand: 2012/11/28
A1 Telekom Austria AG, A-1020 Wien, Lassallestraße 9

115  [ITSEM] Handbuch für die Bewertung der Sicherheit von Systemen der Informationstechnik Stand: 2003/09/01
Original-Site: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/ITSicherheitskriterien/itsem-dt_pdf.html
Bundesamt für Sicherheit in der Informationstechnik (BSI), D-53175 BONN, Godesberger Allee 185-189

116  [ITU-509] ITU-T Recommendation X.509 : Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks Stand: 2019/08/02
Original-Site: https://www.itu.int/rec/T-REC-X.509-201610-I/en
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

117  [ITU-X501] ITU-T Recommendation X.501: Information technology – Open Systems Interconnection – The Directory: Models Stand: 2016/10/14
Original-Site: https://www.itu.int/rec/T-REC-X.501/en
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

118  [ITU-X509v3-ERR] ITU-T Recommendation X.509v3 Fehlerbehebung Stand: 2011/02/01
Original-Site: http://handle.itu.int/11.1002/1000/11735
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

119  [ITU-X509v3] ITU-T Recommendation X.509v3 – Open systems interconnection – The Directory: Public-key and attribute certificate frameworks Stand: 2016/10/01
Original-Site: https://www.itu.int/rec/T-REC-X.509/en
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

120  [ITU-X520] ITU-T Recommendation X.520: Information technology – Open Systems Interconnection – The Directory: Selected attribute types Stand: 2016/10/14
Original-Site: https://www.itu.int/rec/T-REC-X.520/en
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

121  [ITU-X660] ITU-T Recommendation X.660: Information technology – Procedures for the operation of object identifier registration authorities: General procedures and top arcs of the international object identifier tree Stand: 2011/07/29
Original-Site: https://www.itu.int/rec/T-REC-X.660/en
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

122  [ITU-X680] ITU-T X.680 (08/2015), Information technology – Abstract Syntax Notation One (ASN.1): Specification of basic notation Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.680
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

123  [ITU-X681] ITU-T X.681 (08/2015), Information technology – Abstract Syntax Notation One (ASN.1): Information object specification Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.681
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

124  [ITU-X682] ITU-T X.682 (08/2015), Information technology – Abstract Syntax Notation One (ASN.1): Constraint specification Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.682
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

125  [ITU-X683] ITU-T X.683 (08/2015), Information technology – Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.683
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

126  [ITU-X690] ITU-T X.690 (08/2015), Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.690
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

127  [ITU-X691] ITU-T X.691 (08/2015), Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.691
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

128  [ITU-X692] ITU-T X.692 (08/2015), Information technology – ASN.1 encoding rules: Specification of Encoding Control Notation (ECN) Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.692
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

129  [ITU-X693] ITU-T X.693 (08/2015), Information technology – ASN.1 encoding rules: XML Encoding Rules (XER) Stand: 2015/08/13
Original-Site: https://www.itu.int/ITU-T/recommendations/rec.aspx?rec=x.693
International Telecommunication Union (ITU), CH-1211 Geneva 20, Place des Nations

130  [JAVA-CRYPTO] Class SecureRandom + Java Cryptography Architecture (JCA) Reference Guide Stand: 2018/01/01
Original-Site: https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html

131  [KEY-RECO] Key Length Recommendations https://www.keylength.com/en/compare/ Stand: 2021/04/28
Original-Site: https://www.keylength.com/en/compare/

132  [LUNAK3-FIPS-CERT] FIPS 140-2 (L3) Zertifikat #685 “Luna PCI Cryptographic Module V2” (Hardware Version: VBD-01-0104; Firmware Version: 4.5.3) Stand: 2006/07/14
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm#685
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

133  [LUNAK3-FIPS-SP] FIPS 140-2 (L3) Security Policy #685 “Luna PCI Cryptographic Module V2” (Hardware Version: VBD-01-0104; Firmware Version: 4.5.3) Revision 8 Stand: 2006/06/09
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-historical.htm#685
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

134  [LUNAK5-FIPS-CERT] FIPS 140-2 (L3) Zertifikat #2486 + #2487 12/15/2015 Luna® Backup HSM Cryptographic Module (Firmware Versions: 6.10.7 and 6.10.9) Stand: 2016/01/04
Original-Site: https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2489
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

135  [LUNAK5-FIPS-SECURITY-POLICY] FIPS 140-2 (L3) SECURITY POLICY #2489 Luna® PCI-E Cryptographic Module for Luna® SA (Firmware Versions: 6.10.7 and 6.10.9) Stand: 2016/01/04
Original-Site: https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/2489
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

136  [LUNAK7-CC-CERT] Thales Luna K7 Cryptographic Module CC Certificate CC-20-195307 Stand: 2020/10/06
Thales SA, F-92098 Paris La Defense, Tour Carpe Diem 31 Place des Corolles CS 2000

137  [LUNAK7-CC-SECTARGET] Thales Luna K7 Cryptographic Module SECURITY TARGET Stand: 2020/09/25
Thales SA, F-92098 Paris La Defense, Tour Carpe Diem 31 Place des Corolles CS 2000

138  [LUNAK7-CC-SECURITY] Thales Luna K7 Cryptographic Module SECURITY TARGET CC/ISO 15408, EAL4+ Stand: 2020/09/25
Original-Site: https://www.commoncriteriaportal.org/products/
Thales SA, F-92098 Paris La Defense, Tour Carpe Diem 31 Place des Corolles CS 2000

139  [MOBILE] Grundsatzpapier Mobile Signatur – Schwerpunktthema Bürgerkarte und eID – Version 1.0, 22.04.2008 Stand: 2008/04/22
Original-Site: https://demo.egiz.gv.at/plain/content/download/583/3362/file/Grundsatzpapier-Mobile-Signatur.pdf
EGIZ E-Government Innovationszentrum, A-8010 Graz, Inffeldgasse 16a

140  [MOZILLA-CAPOL] Mozilla Root Store Policy Version 2.7.1 Stand: 2021/04/28
Original-Site: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
Mozilla Foundation, USA-CA 94041-112 Mountain View, 1350 Villa Street, Suite C

141  [MOZILLA-CHECK] CA/Subordinate CA Checklist Stand: 2021/04/28
Original-Site: https://wiki.mozilla.org/CA/Subordinate_CA_Checklist
Mozilla Foundation, USA-CA 94041-112 Mountain View, 1350 Villa Street, Suite C

142  [MOZILLA-PROB] CA/Forbidden or Problematic Practices Stand: 2021/04/28
Original-Site: https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
Mozilla Foundation, USA-CA 94041-112 Mountain View, 1350 Villa Street, Suite C

143  [MOZILLA-REC] CA/Required or Recommended Practices Stand: 2021/04/28
Original-Site: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
Mozilla Foundation, USA-CA 94041-112 Mountain View, 1350 Villa Street, Suite C

144  [MS-CA-AUDITREQ] Microsoft Trusted Root Certificate Program Audit Requirements Stand: 2021/04/28
Original-Site: https://social.technet.microsoft.com/wiki/contents/articles/31635.microsoft-trusted-root-certificate-program-audit-requirements.aspx
Microsoft Corporation, USA-WA 98052-639 Redmond, One Microsoft Way

145  [MS-CA] Microsoft Trusted Root Certificate: Program Requirements Stand: 2021/04/28
Original-Site: https://docs.microsoft.com/en-us/previous-versions//cc751157(v=technet.10)?redirectedfrom=MSDN
Microsoft Corporation, USA-WA 98052-639 Redmond, One Microsoft Way

146  [MS-OID] Object IDs associated with Microsoft cryptography Stand: 2017/03/30
Original-Site: https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-
Microsoft Corporation, USA-WA 98052-639 Redmond, One Microsoft Way

147  [NIST-RANDOM] NIST Special Publication 800-90A Revision 1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators Stand: 2015/06/01
Original-Site: http://dx.doi.org/10.6028/NIST.SP.800-90Ar1
SafeNet, Inc., USA-MD 21017 Belcamp, 4690 Millennium Drive

148  [NO] Notariatsordnung (NO) idF 18.7.2019 StF: RGBl. Nr. 75/1871 Stand: 2019/07/18
Original-Site: https://www.ris.bka.gv.at/

149  [OID-T1] Object Identifier der öffentlichen Verwaltung (Teil 1 – Allgemeine Beschreibung) V1.0.0 Stand: 2009/02/27
Original-Site: http://www.ref.gv.at/AG-II-BK-OID-T1_OID-T2-1-0-0.2230.0.html
Stabsstelle IKT-Strategie des Bundes (CIO Chief Information Officer), A-1010 Wien, Ballhausplatz 2

150  [OID-T2] Object Identifier der öffentlichen Verwaltung (Teil 2 – Taxative Definition) – Version 1.0.3 Stand: 2015/07/28
Original-Site: http://www.ref.gv.at/AG-II-BK-OID-T1_OID-T2-1-0-0.2230.0.html
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

151  [OSSL-FIPS-CERT] FIPS 140-2 certificate #1747 for OpenSSL FIPS Object Module Stand: 2012/07/16
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/FIPS140ConsolidatedCertList0018.pdf
OpenSSL Software Foundation, Inc., USA-MD 21710 Adamstown, 1829 Mount Ephraim Road

152  [OSSL-FIPS-DOC] User Guide 2.0 for the OpenSSL FIPS Object Module v2.0 Stand: 2017/03/14
Original-Site: https://www.openssl.org/docs/fips.html
OpenSSL Software Foundation, Inc., USA-MD 21710 Adamstown, 1829 Mount Ephraim Road

153  [OSSL-FIPS-SP] OpenSSL FIPS 140-2 Security Policy Version 2.0.1 Stand: 2012/07/09
Original-Site: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf
OpenSSL Software Foundation, Inc., USA-MD 21710 Adamstown, 1829 Mount Ephraim Road

154  [PERSBIND-XML] XML-Spezifikation der Personenbindung v1.2.2 – pdf-Version Stand: 2005/02/14
Original-Site: http://www.buergerkarte.at/konzept/personenbindung/spezifikation/20050214/

155  [PKCS01] PKCS #1: RSA Cryptography Standard v2.1 Stand: 2002/06/14
Original-Site: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf
RSA The Security Division of EMC, USA-MA 01730 Bedford, 174 Middlesex Turnpike

156  [PKCS08] PKCS #8: Private-Key Information Syntax Standard Stand: 1993/11/01
Original-Site: http://www.rsa.com/rsalabs/node.asp?id=2130
RSA The Security Division of EMC, USA-MA 01730 Bedford, 174 Middlesex Turnpike

157  [PKCS10] PKCS #10: Certification Request Syntax Standard Stand: 2000/05/26
Original-Site: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-10/pkcs-10v1_7.pdf
RSA The Security Division of EMC, USA-MA 01730 Bedford, 174 Middlesex Turnpike

158  [PKCS11] PKCS #11 v2.20: Cryptographic Token Interface Standard – pdf-Version Stand: 2004/06/28
Original-Site: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf
RSA The Security Division of EMC, USA-MA 01730 Bedford, 174 Middlesex Turnpike

159  [PKCS12] PKCS #12: Personal Information Exchange Syntax Standard Stand: 1999/06/24
Original-Site: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf
RSA The Security Division of EMC, USA-MA 01730 Bedford, 174 Middlesex Turnpike

160  [PKCS15] PKCS #15: Cryptographic Token Information Format Standard (v1.1) Stand: 2000/06/06
Original-Site: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-15/pkcs-15v1_1.pdf
RSA The Security Division of EMC, USA-MA 01730 Bedford, 174 Middlesex Turnpike

161  [RFC2595] rfc2595 – Using TLS with IMAP, POP3 and ACAP Stand: 1999/06/01
Original-Site: https://www.rfc-editor.org/info/rfc2595
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

162  [RFC2818] rfc2818 – HTTP Over TLS Stand: 2000/05/01
Original-Site: https://www.rfc-editor.org/info/rfc2818
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

163  [RFC2986] rfc2986 – PKCS #10: Certification Request Syntax Specification Version 1.7 Stand: 2000/11/01
Original-Site: https://www.rfc-editor.org/info/rfc2986
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

164  [RFC3161] rfc3161 – Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) Stand: 2001/08/01
Original-Site: https://www.rfc-editor.org/info/rfc3161
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

165  [RFC3174] rfc3174 – US Secure Hash Algorithm 1 (SHA1) Stand: 2001/09/01
Original-Site: https://www.rfc-editor.org/info/rfc3174

166  [RFC3279] rfc3279 – Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Stand: 2002/04/01
Original-Site: https://www.rfc-editor.org/info/rfc3279
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

167  [RFC3447] rfc3447 – Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 Stand: 2003/02/01
Original-Site: https://www.rfc-editor.org/info/rfc3447
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

168  [RFC3647] rfc3647 – Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework Stand: 2003/11/01
Original-Site: https://www.rfc-editor.org/info/rfc3647
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

169  [RFC3709] rfc3709 – Logotypes in X.509 Certificate Stand: 2020/09/08

170  [RFC3739] rfc3739 – Internet X.509 Public Key Infrastructure: Qualified Certificates Profile Stand: 2004/03/01
Original-Site: https://www.rfc-editor.org/info/rfc3739
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

171  [RFC4511] rfc4511 – Lightweight Directory Access Protocol (LDAP): The Protocol Stand: 2006/06/01
Original-Site: https://www.rfc-editor.org/info/rfc4511
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

172  [RFC4517] rfc4517 – Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules Stand: 2006/06/01
Original-Site: https://www.rfc-editor.org/info/rfc4517
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

173  [RFC4519] rfc4519 – Lightweight Directory Access Protocol (LDAP): Schema for User Applications Stand: 2006/06/01
Original-Site: https://www.rfc-editor.org/info/rfc4519
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

174  [RFC4524] rfc4524 – COSINE LDAP/X.500 Schema Stand: 2006/06/01
Original-Site: https://www.rfc-editor.org/info/rfc4524
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

175  [RFC5246] rfc5246 – The Transport Layer Security (TLS) Protocol Version 1.2 Stand: 2019/12/27
Original-Site: https://www.rfc-editor.org/info/rfc5246

176  [RFC5280] rfc5280 – Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Stand: 2008/05/01
Original-Site: https://www.rfc-editor.org/info/rfc5280
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

177  [RFC5288] rfc5288 – AES Galois Counter Mode (GCM) Cipher Suites for TLS Stand: 2019/12/27
Original-Site: https://www.rfc-editor.org/info/rfc5288

178  [RFC5289] rfc5289 – TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) Stand: 2019/12/27
Original-Site: https://www.rfc-editor.org/info/rfc5289

179  [RFC5424] rfc5424 – The Syslog Protocol Stand: 2009/03/01
Original-Site: https://www.rfc-editor.org/info/rfc5424
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

180  [RFC5652] rfc5652 – Cryptographic Message Syntax (CMS) Stand: 2009/09/01
Original-Site: https://www.rfc-editor.org/info/rfc5652
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

181  [RFC5754] rfc5754 Using SHA2 Algorithms with Cryptographic Message Syntax Stand: 2010/01/01
Original-Site: https://www.rfc-editor.org/info/rfc5754

182  [RFC5758] rfc5758 Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA Stand: 2010/01/01
Original-Site: https://www.rfc-editor.org/info/rfc5758
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

183  [RFC5816] rfc5816 – ESSCertIDv2 Update for RFC 3161 (“Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)”) Stand: 2010/04/01
Original-Site: https://www.rfc-editor.org/info/rfc5816
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

184  [RFC5905] rfc5905 – Network Time Protocol Version 4: Protocol and Algorithms Specification Stand: 2010/06/01
Original-Site: https://www.rfc-editor.org/info/rfc5905
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

185  [RFC6066] rfc6066 – Transport Layer Security (TLS) Extensions: Extension Definitions Stand: 2011/01/01
Original-Site: https://www.rfc-editor.org/info/rfc6066
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

186  [RFC6655] rfc6655 – AES-CCM Cipher Suites for Transport Layer Security (TLS) Stand: 2019/12/27
Original-Site: https://www.rfc-editor.org/info/rfc6655

187  [RFC6818] rfc6818 – Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Stand: 2013/01/01
Original-Site: https://www.rfc-editor.org/info/rfc6818
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

188  [RFC6960] rfc6960 – X.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP Stand: 2013/06/01
Original-Site: https://www.rfc-editor.org/info/rfc6960
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

189  [RFC6962] rfc6962 – Certificate Transparency Stand: 2013/06/01
Original-Site: https://www.rfc-editor.org/info/rfc6962
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

190  [RFC7159] rfc7159 – The JavaScript Object Notation (JSON) Data Interchange Format Stand: 2014/03/01
Original-Site: https://www.rfc-editor.org/info/rfc7159
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

191  [RFC7230] rfc7230 – Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing Stand: 2014/06/01
Original-Site: https://www.rfc-editor.org/info/rfc7230
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

192  [RFC7235] rfc7235 – Hypertext Transfer Protocol (HTTP/1.1): Authentication Stand: 2014/06/01
Original-Site: https://www.rfc-editor.org/info/rfc7235
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

193  [RFC7251] rfc7251 – AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS Stand: 2019/12/27
Original-Site: https://www.rfc-editor.org/info/rfc7251

194  [RFC7515] RFC 7515 – JSON Web Signature (JWS) Stand: 2015/05/01
Original-Site: https://www.rfc-editor.org/info/rfc7515

195  [RFC7517] rfc7517 – The JavaScript Object Notation (JSON) Data Interchange Format Stand: 2015/05/01
Original-Site: https://www.rfc-editor.org/info/rfc7517
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

196  [RFC7518] rfc7518 – JSON Web Algorithms (JWA) Stand: 2015/05/01
Original-Site: https://www.rfc-editor.org/info/rfc7518
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

197  [RFC7519] rfc7519 – JSON Web Token (JWT) Stand: 2015/05/01
Original-Site: https://www.rfc-editor.org/info/rfc7519

198  [RFC8017] rfc8017 – PKCS #1: RSA Cryptography Specifications Version 2.2 Stand: 2020/11/11

199  [RFC8398] rfc6818 – Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Stand: 2013/01/01
Original-Site: https://www.rfc-editor.org/info/rfc6818
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

200  [RFC8398] rfc8398 – Internationalized Email Addresses in X.509 Certificates Stand: 2018/05/01
Original-Site: https://www.rfc-editor.org/info/rfc8398
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

201  [RFC8446] rfc8446 – The Transport Layer Security (TLS) Protocol Version 1.3, August 2018 Stand: 2018/08/01
Original-Site: https://www.rfc-editor.org/rfc/pdfrfc/rfc8446.txt.pdf

202  [RFC8725] BCP 225 rfc8725 – JSON Web Token Best Current Practices Stand: 2020/02/01
Original-Site: https://www.rfc-editor.org/rfc/rfc8725.txt

203  [RFC] 8017 rfc8017 – PKCS #1: RSA Cryptography Specifications Version 2.2 Stand: 2016/11/01
IETF – The Internet Engineering Task Force, USA-VA 20191-543 Reston, 1895 Preston White Drive, Suite 100

204  [RKS-V] Registrierkassensicherheitsverordnung, RKSV – konsolidiert RIS inkl Anlagen Stand: 2015/08/04
Original-Site: http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20009390
BM für Finanzen (BMF), A-1010 Wien, Johannesgasse 5

205  [RTS] Regulatory Technical Standards – EU-Verordnung technische Regulierungsstandards für die Authentifizierung und Kommunikation Stand: 2018/03/13

206  [SIGVO-DB-NOTIF-DE] Abl. L 289/18 Durchführungsbeschluss (EU) 2015/1984 Umstände, Formate und Verfahren der Notifizierung Stand: 2015/11/05
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1460296362627&uri=CELEX:32015D1984
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

207  [SIGVO-DB-NOTIF-EN] Abl. L 289/18 Commission Implementing Decision (EU) 2015/1984 circumstances, formats and procedures of notification Stand: 2015/11/05
Original-Site: http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1460296362627&uri=CELEX:32015D1984
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

208  [SIGVO-DB-SPEZF-DE] Abl. L 235/37 Durchführungsbeschluss (EU) 2015/1506 Spezifikation Formate fortgeschrittene Signaturen/Siegel Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015D1506
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

209  [SIGVO-DB-SPEZF-EN] Abl. L 235/37 COMMISSION IMPLEMENTING DECISION (EU) 2015/1506 specifications relating to formats of advanced electronic signatures Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015D1506
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

210  [SIGVO-DB-TRUST-DE] Abl. L 235/26 Durchführungsbeschluss (EU) 2015/1505 Vertrauenslisten Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015D1505
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

211  [SIGVO-DB-TRUST-EN] Abl. L 235/26 COMMISSION IMPLEMENTING DECISION (EU) 2015/1505 trusted lists Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015D1505
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

212  [SIGVO-DB-TRUST-EN] Abl. L 235/26 Durchführungsbeschluss (EU) 2015/1505 Vertrauenslisten http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015D1505 Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32015D1505&from=DE
RAT DER EUROPÄISCHEN UNION, B-1048 BRÜSSEL, Rue de la Loi 175

213  [SIGVO-DB-ZUSAMMMEN-DE] Abl. L 53/14 Durchführungsbeschluss (EU) 2015/296 Verfahrensmodalitäten Zusammenarbeit Mitgliedstaaten auf Gebiet elektronische Identifizierung Stand: 2015/02/25
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015D0296
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

214  [SIGVO-DV-INTER-DE] Abl. L 235/1 Durchführungsverordnung (EU) 2015/1501 Interoperabilitätsrahmen Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015R1501
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

215  [SIGVO-DV-INTER-EN] Abl. L 235/1 COMMISSION IMPLEMENTING REGULATION (EU) 2015/1501 interoperability framework Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015R1501
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

216  [SIGVO-DV-MINIMUM-DE] Abl. L 235/7 Durchführungsverordnung (EU) 2015/1502 Mindestanforderungen an technische Spezifikationen und Verfahren Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015R1502
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

217  [SIGVO-DV-MINIMUM-EN] Abl. L 235/7 COMMISSION IMPLEMENTING REGULATION (EU) 2015/1502 minimum technical specifications and procedures Stand: 2015/09/09
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015R1502
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

218  [SIGVO-DV-TRUSTQ-DE] Abl. L 128/13 Durchführungsverordnung (EU) 2015/806 Spezifikationen EU-Vertrauenssiegels qualifizierte Vertrauensdienste Stand: 2015/05/23
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015R0806
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

219  [SIGVO-DV-TRUSTQ-EN] Abl. L 128/13 COMMISSION IMPLEMENTING REGULATION (EU) 2015/806 EU specifications trust mark for qualified trust services Stand: 2015/05/23
Original-Site: http://eur-lex.europa.eu/legal-content/DE/TXT/?qid=1445168928138&uri=CELEX:32015R0806
EUROPÄISCHE KOMMISSION (COMMISSION OF THE EUROPEAN COMMUNITIES), B-1049 BRUXELLES, Rue de la Loi 200

220  [SOAP] SOAP Version 1.2 Stand: 2007/04/27
Original-Site: https://www.w3.org/TR/soap/
W3C – World Wide Web Consortium, F-06902 Sophia Antipolis Cedex, 2004, route des Lucioles

221  [SOG-IS] Crypto Evaluation Scheme Agreed Cryptographic Mechanisms v1.1 Stand: 2018/06/01
Original-Site: https://www.sogis.org/uk/supporting_doc_en.html

222  [STZREGBEHV-2009] Stammzahlenregisterbehördenverordnung 2009 – StZRegBehV 2009 – RIS-Version Stand: 2015/08/26
Original-Site: http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20006487
Stammzahlenregisterbehörde, A-1010 Wien, Hohenstaufengasse 3

223  [SVG] BGBl. I Nr.50/2016 Signatur- und Vertrauensdienstegesetz (SVG) Stand: 2016/07/01
Original-Site: http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20009585

224  [SVR] Richtlinien der Österreichischen Notariatskammer vom 19.10.2006 für das elektronische Verzeichnis für die Beurkundungs- und Notarsignaturen (Signaturverzeichnisrichtlinien, SVR 2006) Stand: 2018/02/01
Original-Site: notar.at

225  [SVV] BGBl. II Nr. 208/2016 Signatur- und Vertrauensdiensteverordnung – SVV sowie Verordnung über die Feststellung der Eignung des Vereins „Zentrum für sichere Informationstechnologie – Austria (A-SIT)“ als Bestätigungsstelle Stand: 2016/08/01
Original-Site: https://www.ris.bka.gv.at/eli/bgbl/II/2016/208/20160801
Bundeskanzleramt (BKA), A-1014 Wien, Ballhausplatz 2

226  [VKZ-EB] Ebenen- und Bereichskennungen für das VKZ v1.2.13 Stand: 2016/02/02
Original-Site: https://www.ref.gv.at/EP-VV-VKZ-Bereichskennungen.673.0.html
Stabsstelle IKT-Strategie des Bundes (CIO Chief Information Officer), A-1010 Wien, Ballhausplatz 2

227  [VKZ] Empfehlung Verwaltungskennzeichen (VKZ) 1.2.0 Stand: 2007/03/25
Original-Site: http://reference.e-government.gv.at/Veroeffentlichte-Informationen.203.0.html
Stabsstelle IKT-Strategie des Bundes (CIO Chief Information Officer), A-1010 Wien, Ballhausplatz 2

228  [WEBTRUST-CA] Principles and Criteria for Certification Authorities 2.2 Stand: 2019/06/01
Original-Site: https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria
THE CANADIAN INSTITUTE OF CHARTERED ACCOUNTANTS, CDN-ON M5V 3H2 West Toronto, 277 Wellington Street

229  [WEBTRUST-EV] WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL – Version 1.6.8 Stand: 2019/05/01
Original-Site: https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services/principles-and-criteria
THE CANADIAN INSTITUTE OF CHARTERED ACCOUNTANTS, CDN-ON M5V 3H2 West Toronto, 277 Wellington Street

230  [XMLSIG-XAdES] XML Advanced Electronic Signatures (XAdES) Stand: 2003/02/20
Original-Site: https://www.w3.org/TR/XAdES/
W3C – World Wide Web Consortium, F-06902 Sophia Antipolis Cedex, 2004, route des Lucioles

231  [XMLSIG] XML Signature Syntax and Processing (Second Edition) Stand: 2008/06/10
Original-Site: http://www.w3.org/TR/xmldsig-core/
W3C – World Wide Web Consortium, F-06902 Sophia Antipolis Cedex, 2004, route des Lucioles

232  [ZADIG] BGBl. I Nr. 17/2018 Bundesgesetz über die Erbringung von Zahlungsdiensten 2018 (Zahlungsdienstegesetz 2018, ZaDiG 2018) Stand: 2018/06/01