Advanced Search

Signature Ordinance 2008 - Sigv 2008

Original Language Title: Signaturverordnung 2008 - SigV 2008

Subscribe to a Global-Regulation Premium Membership Today!

Key Benefits:

Subscribe Now for only USD$40 per month.

Regulation of the Federal Chancellor on electronic signatures (signature regulation 2008-SigV 2008)

On the basis of § 25 of the Signature Act, BGBl. I n ° 190/1999, as last amended by the Federal Law BGBl. I n ° 8/2008, is being prescribed in agreement with the Federal Minister for Justice:

Oversight fees

§ 1. (1) The following fees shall be paid by the certification-service-providers (ZDA) for services in the context of supervisory activities:

1.

Examination of the safety and certification concept on the occasion of the admission of the activity (§ 6 para. 3 SigG)

EUR 4 500;

2.

Examination of the safety and certification concept of a ZDA, which provides qualified time stamp services

EUR 1 500;

3.

Examination of the change of the safety and certification concept (§ 6 para. 2 SigG)

a)

without any safety-related changes

700 euro;

b)

with safety-related changes

EUR 3 000;

4.

voluntary accreditation (§ 17 SigG), provided that these are not carried out in the course of the examination according to Z 1

EUR 4 500;

5.

Regular examination of the implementation of the information in the safety and certification concept per year

EUR 3 000;

6.

Regular examination of a ZDA, which provides qualified time stamp services per year

EUR 1 500;

7.

authorisation-related audit, which has led to supervisory measures after Z 8 due to a significant breach of the SigG or the regulations issued on its basis or because of the omission of the display of safety-related changes (§ 14 SigG)

EUR 4 500;

8.

Supervisory measures to be taken in the form of a decision (§ 14 SigG)

a)

Issue of requirements on the basis of safety-related defects in addition to Z

5

700 euro;

b)

Further exercise of the activity as ZDA in addition to Z

5

700 euro;

9.

Revocation of a revocation service by the supervisory authority (§ 12 and § 14 paragraph 5 SigG) per year and certificate, which is conducted in the revocation service

1 euro,

However, total no more per year than EUR 5 000;

10.

Management of the directories at the supervisory authority (Section 13 (3) and section 17 (1) of the German SigG Act):

per recorded ZDA and year EUR 300;

11.

Assessment of the equivalence of audit reports of a state-recognised body of a third country (§ 24 para. 3 SigG)

EUR 4 500.

(2) The fees shall be pre-written by the supervisory authority.

(3) If the supervisory authority is responsible for the supervision of a

1.

Confirmation body or

2.

serves as an expert for non-official persons or bodies;

The fees according to § 53a AVG are to be submitted to the affected ZDA as a cash outlay within the meaning of § 76 AVG.

(4) The fees referred to in paragraphs 1, Z 1 to 6, and 10 shall exempt the federal government, the Länder, municipal associations and municipalities, other public bodies and the social security institutions.

(5) In order to finance the necessary costs of the supervisory authority and the RTR-GmbH, which are not covered by fees in accordance with paragraph 1, RTR-GmbH is from the federal budget per year per 30 years. Jänner to pay a cost in the amount of EUR 90 000. Where the number of ZDA to be supervised is increased after the entry into force of this Regulation, the costs of additional activities of the Supervisory Authority and of RTR-GmbH, which are necessary as a result, shall be borne by the Supervisory Authority and the RTR-GmbH, which shall not be subject to a fee in be covered up to an additional amount of EUR 60 000 per year. The RTR-GmbH has to report annually to the Federal Chancellor on the use of these funds by 30 April of the following year and to present a closure of the accounts.

Financial equipment of the ZDA

§ 2. (1) The financial resources which are regularly available for the performance of the activity as ZDA are to be announced to the Supervisory Authority with the indication of the commencement of the activity pursuant to § 6 paragraph 2 SigG. At the same time, it must be demonstrated that liability insurance has been completed with a minimum insurance sum of EUR 700 000, covering at least three insurance cases per year. ZDA shall have a minimum capital of EUR 300 000 in the form of own funds in the sense of section 224 (3A) and (B) of the UGB (UGB) or have to prove a paid nominal capital within the meaning of section 224 (3A) of the UGB in the amount of 300 000 euros. In the second case, the annual accounts shall be considered by a statutory auditor. In the sense of Section 224 (3A) of the UGB, nominal capital is to be understood as meaning the paid-in capital in the sense of section 23 (3) BWG.

(2) The obligations laid down in paragraph 1 of this article exempt the federal government, the Länder, municipal associations and municipalities, other public bodies and the institutions of social security.

Technical security requirements for signature creation data and devices for qualified signatures

§ 3. (1) The technical components and procedures for the processing of the signature creation data must comply with the requirements of § 6 with regard to the requirement of the examination in accordance with § 18 paragraph 5 SigG.

(2) Only those algorithms and parameters that meet the requirements of the Annex may be used. The framework conditions for technical safety must be chosen in such a way that they correspond to the respective state of the art.

(3) The signature creation data may be distributed among several separate components. In this case, the security requirements must be met by the signature-creation unit as a whole of the components.

Technical security requirements for the system environment of the signature-creation device for qualified signatures

§ 4. (1) The specification of a format for data to be signed must be generally available and ensure that the signed data can be displayed without any doubt and with the same result, both during signature creation and signature verification. . If dynamic changes can be coded in a format, those elements that can cause dynamic changes are not allowed to be used.

(2) The signature function in the signature-creation unit of the Signator may only be triggered after the use of authorization codes (e.g. PIN-input, fingerprint). The authorization codes entered must not remain in memory from the system elements used beyond the signature process. Reentry of authorization codes must be excluded if you are repeatedly entering authorization codes. The unauthorized experience of the authorization codes must be effectively excluded by its design and by blocking mechanisms.

Qualified certificate signatures

§ 5. (1) In the case of the issuing of qualified certificates, the signature creation data used by the ZDA must be generated in a signature-creation unit audited in accordance with § 6 and must not be available outside of the signature-creation unit. The algorithms and parameters used must be in accordance with the Annex.

(2) The ZDA shall be able to verify qualified electronic signatures produced on the basis of a qualified certificate issued by the ZDA. The procedures and algorithms for signature verification and signature creation are to be documented together.

(3) The ZDA shall take appropriate measures to ensure that the signature creation data and the technical components used for the preparation of the certificates and the technical components used for the retrieval of the directory and revocation services are compromised, and protecting unauthorized access. Unauthorized access must be recognizable.

Testing of technical components and procedures

§ 6. (1) In the course of the examination of the technical components and procedures for the production of qualified signatures, security requirements are to be applied which are recognized as suitable by a confirmation body (§ 19 SigG). In particular, it is possible to use protection profiles according to the " common criteria for the examination and evaluation of the security of information technology (Common Criteria for Information Security Evaluation-ISO/IEC). 15408) "or according to the" criteria for the evaluation of the security of information technology security evaluation criteria (ITSEC) ". The same applies to the verification of trustworthy systems, products and procedures that are used for the creation of qualified certificates, for the storage of signature-creation data for qualified certificates or for qualified Time stamp services are used.

(2) In the case of the tests referred to in paragraph 1, reference numbers must be observed in particular, which are published in the Official Journal of the European Communities in accordance with Article 3 (5) of the Signature Directive 1999 /93/EC for secure signature creation units (Secure Signature-Creation) Devices-SSCD) or trusted systems or products of the ZDA have been published.

(3) If technical components and processes are used in a controlled environment, safety requirements which must be technically ensured in accordance with paragraph 1 may also be organised by qualified and qualified staff. can be met with appropriate access and access control measures, or technically and organizationally. The fulfilment of these safety requirements shall be examined by a confirmation body.

(4) In the certificate of the confirmation body on the fulfilment of the security requirements for secure signature-creation units (§ 18 paragraph 5 SigG), it shall be stated under which conditions of use and up to which date it shall apply. Copies of the certificate and any test reports shall be sent to the supervisory authority.

(5) The documents with technical content cited in paragraphs 1 to 4 are to be made available electronically via the website of the supervisory authority.

Provision of signature and certification services for qualified certificates and qualified electronic signatures

§ 7. (1) Where the facilities of a ZDA are conducted separately or technically separately, security measures shall ensure that the transfer of the data between the sub-devices does not result in a compromise of the signature or certification services.

(2) The technical equipment of a ZDA shall be designed in such a way that its functions and applications, belonging to the provided signature and certification services, are separated from other functions and applications and that they are influenced by is excluded. This must be ensured both for regular operation, for special operating situations and outside the operation. Special operating situations, such as maintenance, must be documented.

(3) A ZDA shall take appropriate measures to protect its facilities for the provision of signature and certification services against unauthorised access.

(4) A ZDA may not, within the framework of the provided signature and certification services, employ persons who are sentenced to imprisonment for more than one year or for criminal acts on account of a criminal offence committed with a prior sentence. have been sentenced to a custodial sentence of more than three months against the assets or against the reliability of documents and evidence. Convictions subject to the provisions of the 1972 Tilgungsgesetz or subject to limited information shall be disregarded.

(5) The technical staff of a ZDA must have sufficient expertise in the following areas:

1.

general computerised training,

2.

security technology, cryptography, electronic signature and public key infrastructure,

3.

technical standards, in particular evaluation standards, and

4.

Hard-and software.

At the request of the supervisory authority, the ZDA shall provide information on the necessary expertise of the staff. The necessary expertise of the staff may, in particular, be

1.

Completion of a relevant Higher Technical Institute of Technology (HTL),

2.

of such a college,

3.

a relevant course of studies, or by

4.

a professional activity in the duration of at least three years

is acquired.

(6) If the signature creation data is generated at the ZDA or in the production of the signature creation unit, the ZDA must ensure that the signature creation data is only handed out to the Signator. The possibility of using the signature creation data prior to the handout to the Signator must be excluded. In any case, the ZDA has to make sure that the signature creation data of the signator and the signature verification data of the corresponding certificate are applicable in a complementary manner.

(7) The ZDA shall inform the certificate advertiser in writing or using a durable medium in a clear and intelligible form before the conclusion of the contract in accordance with § 20 SigG, the information on the contents of the security and security system being kept clear and intelligible. In any case, the certification concept shall contain explanations of all applicable information in accordance with § 12 (1) and (2).

Application for issuing a qualified certificate

§ 8. (1) In order to determine the identity of the certifier, a

1.

Official photo ID or

2.

proof that the identity has been tested at least with that reliability, as it is to be observed in the case of delivery to one's own handees (§ 21 ZustG).

The data of the photo ID or of the proof (§ 8 para. 1 SigG) must be recorded and documented with the application if they have not already been documented. The collection and documentation can also be done in electronic form only.

(2) If information on the power of representation for a third party is to be included in a qualified certificate, the representative power must be reliably demonstrated and a written or qualified electronic signature provided by the third party. This is to be informed about the content of the qualified certificate in writing or using a durable medium and to indicate the possibility of revocation in accordance with § 9 paragraph 1 Z 1 SigG. Prior to their inclusion in a qualified certificate, professional or other approval must also be reliably proven. If the Signator is subject to a registered professional qualification of a public-law professional supervisor, the institution which exercises the professional supervision shall be informed in writing or in writing of the content of the qualified certificate. by using a durable medium.

Qualified certificates

§ 9. (1) If a ZDA, in addition to qualified certificates, also issues other certificates, it must use separate signature creation data for the signature of the qualified certificates.

(2) The formats for qualified certificates shall be specified in a clear and complete manner, so that their automatic verification shall be possible.

(3) The period of validity of a qualified certificate shall not exceed five years.

(4) Until the expiry of the validity of a qualified certificate, it is permissible, with the exception of the period of validity and the unique identifier, to re-certify the same content together with the same signature verification data and in this way to a new Issue a certificate. In all other cases, the circumstance that qualified certificates issued for signature purposes have the same signature verification data, but different contents, will result in a compromise of the certificates concerned.

(5) A ZDA shall be entitled to certify its certificate or the certificates issued by it with the consent of another ZDA. The certificates issued in this manner shall not have any modifications; it shall also ensure the provision of the directory and revocation services and, where appropriate, make direct the revocation of the other ZDA.

Directory and revocation services for qualified certificates

§ 10. (1) The ZDA shall ensure that the formats of the revocation services are suitable for their continued operation by the supervisory authority. The formats of the revocation services may not be changed during the period of validity of the certificate. In any case, revocation services must allow the determination of whether the certificate has been revoked at a certain point in time. The revocation services must be freely accessible in general. The inquiry of the revocation services must be possible free of charge and without identification.

(2) The ZDA shall disclose to the Signators and to third parties, for which information on the representative power of the Signator has been included in a certificate, appropriate means of communication with which they shall at any time provide an immediate revocation of the Obtain the certificate. An authentication mechanism must be provided for this. In any case, the revocation of a certificate must also be possible in paper form.

(3) The directory and revocation services must be sufficiently protected against forgery, falsification and unauthorised access. It is necessary to ensure that only authorized persons can make entries and changes in the directories. Furthermore, a lock or a revocation may not be undone unnoticed.

(4) The updating of the revocation services must be carried out on working days, excluding Saturday, from 9 a.m. to 5 p.m. at the latest within three hours of the notice of withdrawal being announced. At any rate, the ZDA shall ensure that a request for the revocation of a qualified certificate is automatically accepted at any time and that the lock triggers at the latest within six hours.

(5) The time availability of the directory services must be at least according to the times specified in paragraph 4, first sentence, and specified in the security concept. The revocation services must be constantly available. A continuous interruption of the directory or revocation services of more than 30 minutes during the availability period is to be documented as a malfunction. A replacement system shall be provided for maintenance and outage situations of the revocation service. If the replacement system also fails, this shall be indicated within a calendar day of the supervisory authority. This shall restore the revocation service within three calendar days.

(6) A ZDA has to enable an examination of the certificates up to the expiry of the period specified in § 13 para. 2 in individual cases. The same applies to the continuation of the revocation services by the supervisory authority in the case of the cessation or discontinuation of the activity of a ZDA.

(7) The period during which a lock may be effective must be specified in the security concept and shall not exceed 10 days. A lock can be released during this period. A reed lock has no effect on the validity of the certificate. If a lock is not released during the period referred to above, the certificate shall be revoked. If the revocation of a certificate is blocked on the basis of a lock, the lock is already deemed to be a revocation.

(8) If the signature-creation data of the Signator are known or if these data are presented as signature-creation data or in another form other than with the Signator, then a compromise of the signature-creation data is present, which is used for revocation. of the Signator's certificate. The revocation must be requested by the Signator (§ 9 paragraph 1 Z 1 SigG) or by the ZDA itself (section 9 para. 1 Z 6 SigG), as soon as it has become aware of the compromise.

Qualified Time Stamp Services

§ 11. (1) Only systems, products and processes which are protected from change and which are technically and cryptographically secure may be used for the provision of qualified timestamping services. The time stamps must be generated in a signature creation unit tested in accordance with § 6. The algorithms and parameters used must be in accordance with the Annex. Where certificates are used for time stamp services, only those issued exclusively for this purpose may be used and specifically designated for this purpose.

(2) The certified time (date and time) shall be determined after the Central European Time (CET) in accordance with the daylight saving time; other time zones shall be explicitly stated. The deviation from the actual time may not exceed one minute for the time stamp service provider.

(3) The time availability of qualified time stamp services and the security measures for the automatic triggering of the time stamp function must be indicated in the security concept of the ZDA providing such services.

Safety and certification concept

§ 12. (1) The security and certification concept of the ZDA shall contain, in particular, the following information:

1.

The name of the ZDA,

2.

Address and State of the ZDA branch office,

3.

the nature, scope and provision of the signature and certification services provided;

4.

the procedure for submitting applications,

5.

where appropriate, the inclusion of pseudonyms, as well as information about a representative power or other legally significant characteristics of the signatory in the certificate,

6.

business hours,

7.

Creation of the signature creation data of the ZDA,

8.

Format of the ZDA signature creation data,

9.

signature verification data, if necessary the certificate of the ZDA,

10.

Generation of signature creation data of the Signators,

11.

Format of signature creation data of the Signators,

12.

procedures used to create the signatures provided (hashing and encryption of the hash value),

13.

List of deployed, provided and recommended signature products,

14.

Security of authorization codes,

15.

common formats which meet the requirements of Article 4 (1) and, where appropriate, methods for preventing dynamic changes,

16.

the formats and validity of certificates;

17.

technical standards, access arrangements and the updating and availability period for the directory and revocation services provided, including the period of the lock,

18.

time stamp services provided, where applicable,

19.

traceable and generally understandable method for secure signature verification,

20.

Format of documentation of safety precautions, incidents and special operating situations,

21.

Protection of technical components against unauthorized access,

22.

Protection of the devices of the ZDA against unauthorized access.

(2) The safety and certification concept for a qualified time stamp service shall contain, in particular, the following information:

1.

The name of the ZDA,

2.

Address and State of the ZDA branch office,

3.

the nature, scope and provision of the time stamp services provided;

4.

Time stamp service signature verification data,

5.

procedures used for the preparation of the time stamps provided,

6.

the formats of the time stamp,

7.

the availability period of time stamp services;

8.

traceable and generally comprehensible method for checking the time stamps,

9.

Form of documentation of safety precautions, incidents and special operating situations,

10.

Protection of technical components from unauthorised changes.

(3) The security and certification concept shall be submitted to the supervisory authority in electronic form in a common format. It must be provided with the electronic signature (§ 5 paragraph 3 SigG) of the ZDA. In addition, the ZDA has the security and certification concept as well as a clear and generally comprehensible summary of the concept in a common format ready to be kept ready.

Documentation

§ 13. (1) The documentation according to § 11 SigG, including the incidents and the special operating situations as well as the information of the certifying advertisers in accordance with § 20 SigG, must in any case take place in electronic form. To the extent that the generation of the signature creation data takes place outside the signature creation unit of the signator, this also applies to the time of the transmission of the signature creation data to the signature-creation unit. The data contained in the documentation of a ZDA must be provided with its electronic signature (§ 5 paragraph 3 SigG) and must contain dates according to § 11 paragraph 2.

(2) The documentation referred to in paragraph 1 shall be kept for at least 35 years from the date of the last entry and shall be secured in such a way as to remain readable and available within that period.

Supervision and accreditation

§ 14. (1) The indication of the acceptance of the activity of a ZDA in accordance with § 6 para. 2 SigG must be made in electronic form. To the extent that special contents of the display do not require a different format, a common format must be used. The display must be electronically signed. The supervisory authority must be able to convince itself of the authenticity of the data. For this purpose, it may also order the personal appearance of the ZDA or of a representative body responsible for representation. The supervisory authority has to ensure that the signature creation data of the ZDA and the signature verification data of the corresponding certificate are applicable in a complementary manner.

(2) In particular, the ad shall be connected:

1.

Safety and certification concept,

2.

Presentation of the specific security threats and risks associated with the ZDA,

3.

Proof of financial equipment and the necessary liability insurance, and

4.

Proof of the expertise of technical personnel.

(3) The provisions of Section 1 shall apply to the display of further safety and certification concepts as well as to the display of safety-relevant changes of existing safety and certification concepts in accordance with the sensual requirements.

(4) The Supervisory Authority shall examine ZDA at least at regular intervals of two years as well as in the case of safety-related changes in the safety and certification concept. In addition, the supervisory authority shall be entitled to carry out random checks of the ZDA at any time. In any event, the supervisory authority shall carry out an additional examination if there is a reasonable suspicion of the presence of safety-related defects.

(5) The supervisory authority, its institutions and the persons and entities working for them shall be subject to the secrecy of the office in the meaning of Article 20 (3) B-VG.

(6) Only those circumstances which have been checked for their correctness may be included in the lists kept by the supervisory authority. The supervisory authority shall have a generally accessible home page indicating its address, its signature verification data, and the formats of the directories and the access modalities for which it is located.

(7) In the case of a voluntary accreditation pursuant to § 17 SigG, the application for accreditation shall replace the indication of the inclusion of the ZDA's activity.

(8) The designation of accredited ZDA according to § 17 of the German SigG (SigG) has to contain the phrase "Accredited Certification Service Provider". Accredited ZDA are entitled to carry the federal coat of arms with the lettering "Accredited Certification Service Providers".

Notification of the notification

§ 15. (1) This Regulation has been adopted in compliance with the provisions of Directive 98 /34/EC of the European Parliament and of the Council establishing a procedure for the provision of information in the field of technical standards and regulations as amended by Directive 2006 /96/EC Notified to the Council (Notifying No 2007 /534/A).

entry into force

§ 16. This Regulation, together with the Annex, shall enter into force. At the same time, the Federal Chancellor's Regulation on electronic signatures, BGBl. II No 30/2000, in the version of the BGBl Regulation. II No 527/2004, together with the Annex.

Gusenbauer

ANNEX

Algorithms and parameters for qualified electronic signatures

1. Definitions

1. Signature suite: A signature suite consists of the following components:

-

a signature algorithm with parameters,

-

an algorithm for key generation,

-

a padding process and

-

a cryptographic hash function.

2. Bit length: The bit length of a natural number p is r, if shall apply.

3. Cryptographic hash function: The algorithm "hash function" is a non-reversible function, which maps an extensive amount of data (usually a text) to a generally smaller target set of fixed length (hash value).

2. Abbreviations

A9C

"Article 9 Committee" (Committee on Electronic Signatures pursuant to Article 9 of Directive 1999 /93/EC)

DSA

Digital Signature Algorithm

ECDSA

Elliptic Curve Digital Signature Algorithm

ECGDSA

Elliptic Curve German Digital Signature Algorithm

RSA

Procedures by Rivest, Shamir and Adleman

3. Permitted Signature Suites

Algorithms and parameters for qualified electronic signatures may only be used in pre-defined combinations, known as signature suites.

If a component of the suite is invalid, the entire suite is also invalid. If a component of the suite has been updated, the entire suite will also be updated.

Table 1a-List of acceptable signature-suites:

Signature Suite Entry Measure

Signature algorithm

Signature algorithm parameters

Key Generation Algorithm

Padding Method

Cryptographic hash function

001

rsa

MinModLen = 1024

rsagen1

See Table 3

See Table 2

002

dsa

pMinLen = 1024

qMinlen = 160

dsagen1

-

See Table 2

003

ecdsa-Fp

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen1

-

See Table 2

004

ecdsa-F2m

qMinlen = 160

r0Min = 10 4

MinClass = 200

ecgen2

-

See Table 2

005

ecgdsa-Fp

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen1

-

See Table 2

006

ecgdsa-F2m

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen2

-

See Table 2

Some of the algorithms listed in this Annex are registered by object identifiers. These are reproduced in the form of information in Table 1b.

Table 1b-Object identifiers (OID)

Object Short Label

object identifier OID

Name in this Annex

rsa

{joint-iso-ccitt (2) ds (5) module (1) algorithm (8) encryptionAlgorithm (1) 1}

rsa

rsaEncryption

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 1}

rsa

id-dsa

{iso (1) member-body (2) us (840) x9-57 (10040) x9cm (4) 1}

dsa

id-ecPublicKey

{iso (1) member-body (2) us (840) 10045 2 1}

ecdsa

ecgPublicKey

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsahrh (5) ecgKeyType (2) 1}

ecgdsa

id-sha1

{iso (1) identifiedOrganization (3) oIW (14) oIWSecSig (3) oIWSecAlgorithm (2) 26}

sha1

ripemd160

{iso (1) identifiedOrganization (3) teletrust (36) algorithm (3) hashAlgorithm (2) ripemd160 (1)}

ripemd160

id-sha224

{joint-iso-itu-t (2) country (16) us (840) organization (1) gov (101) csor (3) nistalgorithm (4) hashalgs (2) sha224 (4)}

sha224

id-sha256

{joint-iso-itu-t (2) country (16) us (840) organization (1) gov (101) csor (3) nistalgorithm (4) hashalgs (2) 1}

sha256

id-sha384

{joint-iso-itu-t (2) country (16) us (840) organization (1) gov (101) csor (3) nistalgorithm (4) hashalgs (2) 2}

sha384

id-sha512

{joint-iso-itu-t (2) country (16) us (840) organization (1) gov (101) csor (3) nistalgorithm (4) hashalgs (2) 3}

sha512

whirlpool

{iso (1) standard (0) encryption-algorithms (10118) part3 (3) algorithm (0) whirlpool (55)}

whirlpool

sha-1WithRSAEncryption

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 5}

rsa; emsa-pks1; sha1

sha224WithRSAEncryption

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 14}

rsa; emsa-pks1; sha224

sha256WithRSAEncryption

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 11}

rsa; emsa-pks1; sha256

sha384WithRSAEncryption

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 12}

rsa; emsa-pks1; sha384

sha512WithRSAEncryption

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 13}

rsa; emsa-pks1; sha512

id-RSASSA-PSS with mgf1SHA1Identifier,
mgf1SHA224Identifier,
mgf1SHA256Identifier;
mgf1SHA384Identifier or
mgf1SHA512Identifier

{iso (1) member-body (2) us (840) rsadsi (113549) pkcs (1) pkcs-1 (1) 10}

rsa; emsa-pss; sha1, sha224, sha256, sha384, sha512

rsaSignatureWithripemd160

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) rsaSignature (1) rsaSignatureWithripemd160 (2)}

rsa; ripemd160

id-dsa-with-sha1

{iso (1) member-body (2) us (840) x9-57 (10040) x9cm (4) 3}

dsa; sha1

id-dsa-with-sha224

{joint-iso-ccitt (2) country (16) us (840) organization (1) gov (101) csor (3) algorithms (4) id-dsa-with-sha2 (3) 1}

dsa; sha224

id-dsa-with-sha256

{joint-iso-ccitt (2) country (16) us (840) organization (1) gov (101) csor (3) algorithms (4) id-dsa-with-sha2 (3) 2}

dsa; sha256

ecdsa-with-SHA1

{iso (1) member-body (2) us (840) ansi-X9-62 (10045) signatures (4) sha1 (1)}

ecdsa; sha1

ecdsa-with-Recommended

{iso (1) member-body (2) us (840) ansi-X9-62 (10045) signatures (4) recommended (2)}

ecdsa; sha1, sha224, sha256, sha384, sha512

ecdsa-with-Sha224

{iso (1) member-body (2) us (840) ansi-X9-62 (10045) signatures (4) specified (3) 1}

ecdsa; sha224

ecdsa-with-Sha256

{iso (1) member-body (2) us (840) ansi-X9-62 (10045) signatures (4) specified (3) 2}

ecdsa; sha256

ecdsa-with-Sha384

{iso (1) member-body (2) us (840) ansi-X9-62 (10045) signatures (4) specified (3) 3}

ecdsa; sha384

ecdsa-with-Sha512

{iso (1) member-body (2) us (840) ansi-X9-62 (10045) signatures (4) specified (3) 4}

ecdsa; sha512

ecdsa-plain-RIPEMD160

{itu-t (0) identified-organization (4) etsi (0) reserved (127) etsi-identified-organization (0) bsi-de (7) algorithms (1) id-ecc (1) signatures (4) ecdsa-signatures (1) 6}

ecdsa; ripemd160

ecgSignatureWithripemd160

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsaStd (5) ecgSignature (4) 1}

ecgdsa; ripemd160

ecgSignatureWithsha1

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsaStd (5) ecgSignature (4) 2}

ecgdsa; sha1

ecgSignatureWithsha224

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsaStd (5) ecgSignature (4) 3}

ecgdsa; sha224

ecgSignatureWithsha256

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsaStd (5) ecgSignature (4) 4}

ecgdsa; sha256

ecgSignatureWithsha384

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsaStd (5) ecgSignature (4) 5}

ecgdsa; sha384

ecgSignatureWithsha512

{iso (1) identified-organization (3) teletrust (36) algorithm (3) signatureAlgorithm (3) ecSign (2) ecgDsaStd (5) ecgSignature (4) 6}

ecgdsa; sha512

4. Permitted cryptographic hashing

Only collision-resistant hash functions may be used for qualified electronic signatures. This requirement is satisfied if it is not feasible to find two documents that provide the same hash value.

Table 2-List of currently allowed hash functions

Hash function measure

Hash function abbreviation

2.01

sha1

2.02

ripemd160

2.03

sha224

2.04

sha256

2.05

sha384

2.06

sha512

2.07

whirlpool

5. Allowable Padding

Table 3-List of permissible padding methods

Measure of the Padding Method

Short description of the filling process

Random number generation

Random number generator parameters

3.01

emsa-pkcs1-v1_5

-

-

3.02

emsa-pss

trueran or pseuran

Min 64 bit

3.03

emsa-pkcs1-v2_1

-

-

3.04

iso9796ds2

trueran or pseuran

Min 64 bit

3.05

iso9796-din-rn

trueran or pseuran

Min 64 bit

3.06

iso9796ds3

-

-

6. Permitted Signature Algorithms

Table 4-List of allowed signature algorithms

Signature algorithm measure

Signature algorithm short name

Signature algorithm parameters

Algorithm for key and parameter generation

1.01

rsa

MinModLen = 1024

rsagen1

1.02

dsa

pMinLen = 1024

qMinLen = 160

dsagen1

1.03

ecdsa-Fp

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen1

1.04

ecdsa-F2m

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen2

1.05

ecgdsa-Fp

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen1

1.06

Ecgdsa-F2m

qMinLen = 160

r0Min = 10 4

MinClass = 200

ecgen2

Table 5-List of allowed key generation algorithms for the signature algorithms listed in Table 4

Key generation algorithm measure

Abbreviated key generation algorithm

Signature algorithm

Method of random number generation

Parameters of the random number generation method

4.01

rsagen1

rsa

trueran or pseuran

EntropyBits 80 or SeedLen 80

4.02

dsagen1

dsa

trueran or pseuran

EntropyBits 80 or SeedLen 80

4.03

ecgen1

ecdsa-Fp, ecgdsa-Fp

trueran or pseuran

EntropyBits 80 or SeedLen 80

4.04

ecgen2

ecdsa-F2m, ecgdsa-F2m

trueran or pseuran

EntropyBits 80 or SeedLen 80

7. Explanatory notes on individual parameters of the allowed signature algorithms

7.1 RSA

The security of the RSA algorithm is based on the difficulty of factorizing large integers. In order to generate the signature creation data and signature verification data, two prime numbers are random and independent p and q , where the bit length of the module n = pq is at least MinModLen; its length is also called ModLen; each prime number must be effectively influenced by entropyBits bits of actual coincidence or an output value of the length SeedLen. p and q should be about the same length, for example, an area such as on the market.

7.2 DSA

The security of the DSA algorithm is based on the difficulty of the discrete logarithm in the multiplicative group of a prime body. F p to be calculated.

The signature creation data consists of

-

the public parameters p , q and g ,

-

a random or pseudo-randomly generated integer X , 0 < X < q , which is signator-specific, and

-

a random or pseudo-randomly generated integer K , 0 < K < q , which is to be recreated for each signature.

The public parameters p , q and g may be the same for a group of users. The prime module p must be at least pMinLen bits long. q , which is a prime factor of ( p -1) must be at least qMinLen bits long.

The signature verification data consists of p, q, g and a whole number Y , the Y = g X mod p is calculated.

7.2.1 DSA variants with elliptical curves based on a group E ( F p )

The security of the algorithm ecdsa-Fp is based on the difficulty of calculating the discrete logarithm over elliptical curves.

The public parameters are as follows:

-

p a large prime number,

- q a large prime number with a length of at least qMinLen bits, ;

-

E an elliptical curve over the finite body F p , whose order is q is divisible, and

-

P a fixed point on E with the order q .

The class number of the maximum order of the endomorphismenring of E must be at least MinClass. The value R 0 : = min ( R : q Shares p R -1) must be greater than r0Min.

The signature creation data consists of

-

the public parameters E , q and P ;

-

a statistically unique and unpredictable whole number X , 0 < X < q , which is signator-specific and

-

a statistically unique and unpredictable whole number K , 0 < K < q , which is to be recreated for each signature.

The signature verification data consists of E , q , P and one point Q on E , the Q = xP is calculated. The elliptical curve over F p must be chosen in such a way that their order by means of a prime number q the length shall be divisible.

7.2.2 DSA variants with elliptical curves based on a group E ( F 2m)

The security of the algorithm ecdsa-F2m is based on the difficulty of calculating the discrete logarithm over elliptical curves.

The public parameters are as follows:

-

M a prime number,

-

q a large prime number with a length of at least qMinLen bits,

-

E an elliptical curve over the finite body F 2m, whose order by q is divisible,

-

it must not be possible, E over F 2 , and

-

P a fixed point on E with the order q .

The class number of the maximum order of the endomorphismenring of E must be at least MinClass. The value R 0 : = min ( R : q Shares 2 mr -1) must be greater than r0Min.

The signature creation data consists of

-

the public parameters E, q and m;

-

a statistically unique and unpredictable whole number X , 0 < X < q , which is signator-specific, and

-

a statistically unique and unpredictable whole number K , 0 < K < q , which is to be recreated for each signature.

The signature verification data consists of E , q , P and one point Q on E , the Q = xP is calculated. The elliptical curve over F 2m must be chosen in such a way that their order by a prime number q the length shall be divisible.

7.2.3 EC-GDSA based on a group E ( F p )

The ecgdsa-Fp algorithm is a variant of the ecdsa-Fp algorithm with a modified equation for signature creation and modified procedure for signature verification. The parameters are the same as for ecdsa-Fp.

7.2.4 EC-GDSA based on a group E ( F 2m)

The algorithm ecgdsa-F2m is a variant of the algorithm ecdsa-F2m with modified equation for signature creation and modified procedure for signature verification.

8. Generating random numbers

Table 6-List of permitted methods for the generation of random numbers

Measure of random number generator

Random number generator short name

Random number generation parameters

5.01

Trueran

EntropyBits

5.02

Pseuran

SeedLen

5.03

cr_to_X9.30_x

SeedLen

5.04

cr_to_X9.30_k

SeedLen

8.1 Requirements for random number generators trueran

A physical random number generator is based on a physical noise source (primary noise) and a cryptographic or mathematical after-treatment of the primary noise. The primary noise must be regularly subjected to an appropriate statistical test. The expected expense of obtaining a cryptographic key should be at least equal to the expense of the rate of the rate of a random value of the length EntropyBits.

8.2 Requirements for random number generators pseuran

A pseudo-random number generator must be initialized with a real random number. The initial value is referred to as "seed" and has the length SeedLen. The output of the generator must meet the following requirements:

-

No information regarding the output bits generated can be determined in advance;

-

the knowledge of a subsequence of the output does not allow a conclusion to a remaining bit with a probability that is not-negligibly different from chance;

-

there is no usable method to remove from the output of the generator a previously generated or future output, an internal state, or the initial value ("seed") on the market.

The expected expense of obtaining any internal status of the generator should be essentially the difficulty of obtaining a random value of the length SeedLen bits.

If the generator has been initialized with at least SeedLen bits, then up to n = 100 as a result of generated signature creation data as if they had been produced by a generator trueran. For the mass production (through the ZDA) of K Keys, k > n It is permissible that in addition to the initial entropy requirement of real coincidence (from a trueran generator) slowly with a rate of j = 8 Bits per output value will be added, otherwise the generator should be completely re-initialized.

If re-initialization is applied, the security of the re-initialization process must be at least as strong as the original initialization and procedures that are similar to the creation of root keys. Smartcard re-initialization is not allowed.

No backups of the initial value ("seed") or internal stati of pseudo-random number generators are allowed. "