SIGNATURE POLICY for WizzAir Hungary Ltd's electronic invoicing system by eqi10659

VIEWS: 112 PAGES: 23

									               SIGNATURE POLICY
           for WizzAir Hungary Ltd's
            electronic invoicing system


Unique object ID (OID):   1.3.6.1.4.1.18665.1.2

Version:                  1.0

Effective as of:          10-01-2005
                                             2                           Signature Policy




                               Change management



Version     Date                                 Description of change
Draft1    07-01-2005   First draft version
Draft2    08-29-2005   Extended and more precise working version
  1.0     10-01-2005   First valid status
                                                                                      3                                                                     Signature Policy




                                                                             Contents


CHANGE MANAGEMENT.............................................................................................................................................. 1

1. INTRODUCTION............................................................................................................................................................ 5

2. SIGNATURE POLICY DATA....................................................................................................................................... 6

    2.1. SIGNATURE POLICY IDENTIFIER................................................................................................................................... 6
    2.2. SCOPE OF THIS SIGNATURE POLICY ............................................................................................................................. 6
        2.2.1. Physical scope of this policy .............................................................................................................................. 6
        2.2.2. Geographical scope of this policy...................................................................................................................... 6
        2.2.3. Temporal scope of this policy ............................................................................................................................ 6
        2.2.4. Personal scope of this policy.............................................................................................................................. 6
    2.3. MAINTAINING THIS SIGNATURE POLICY (CHANGE MANAGEMENT)............................................................................. 6
    2.4. PUBLISHING THIS POLICY ............................................................................................................................................ 7
    2.5. RELATED POLICIES AND DOCUMENTS ......................................................................................................................... 8

3. SIGNATURE VALIDATION POLICY ........................................................................................................................ 9

    3.1. TYPE OF ACCEPTANCE OF OBLIGATIONS OF ELECTRONIC SIGNATURES ...................................................................... 9
    3.2. RULES RELATED TO VALIDATION DATA ...................................................................................................................... 9
        3.2.1. Obligations of the signing party......................................................................................................................... 9
        3.2.2. Obligations of parties verifying signatures ..................................................................................................... 10
    3.3. RULES RELATED TO FORMATS ................................................................................................................................... 10
        3.3.1. Electronically signable formats ....................................................................................................................... 10
        3.3.2. Format of electronic signatures ....................................................................................................................... 10
    3.4. RULES RELATED TO THE USE OF CERTIFICATE AUTHORITIES .................................................................................... 10
        3.4.1. Rules related to the trust chain ........................................................................................................................ 10
        3.4.2. Rules of revocation........................................................................................................................................... 11
    3.5. RULES RELATED TO THE USE OF TIMESTAMP SERVICE PROVIDERS ........................................................................... 12
        3.5.1. Rules related to the trust chain ........................................................................................................................ 12
        3.5.2. Rules of revocation........................................................................................................................................... 12
        3.5.3. Rules related to waiting time............................................................................................................................ 12
        3.5.4. Rules related to delays of timestamps.............................................................................................................. 12
    3.6. RULES RELATED TO ALGORITHM RESTRICTIONS AND KEY LENGTHS ........................................................................ 13

4. CREATING SIGNATURES ......................................................................................................................................... 15

    4.1. PREPARING TO CREATE A SIGNATURE ....................................................................................................................... 15
        4.1.1. Installing Marketline Integrated Signing Module ........................................................................................... 15
        4.1.2. Generating keys ................................................................................................................................................ 15
                                                                                       4                                                                      Signature Policy




        4.1.3. Installing CA and root certificates................................................................................................................... 15
    4.2. THE PROCESS OF CREATING A SIGNATURE ................................................................................................................ 16
        4.2.1. Specifying activation data ................................................................................................................................ 16
        4.2.2. Creating a signature......................................................................................................................................... 16
        4.2.3. Initial verification of signatures by the signing party ..................................................................................... 16
        4.2.4. Validity of signatures........................................................................................................................................ 16
    4.3. SPECIAL RULES OF REVOCATION AND SUSPENSION ................................................................................................... 17

5. VERIFYING SIGNATURES........................................................................................................................................ 18

    5.1. PREPARING TO VERIFY A SIGNATURE ........................................................................................................................ 18
        5.1.1. Installing Verify ................................................................................................................................................ 18
        5.1.2. Installing CA and root certificates................................................................................................................... 18
    5.2. THE PROCESS OF VERIFYING SIGNATURES................................................................................................................. 19
        5.2.1. Signature validation data ................................................................................................................................. 19
        5.2.2. Validity of signatures........................................................................................................................................ 19

6. DEFINITIONS................................................................................................................................................................ 21
                                                   5                                        Signature Policy




1.      Introduction

This document is the signature policy of WizzAir Hungary Ltd's electronic invoicing system and its
transaction environment, concerning signature and signature control of those participating in issuing
and accepting invoices.

This signature policy defines requirements primarily for the following two modules of the invoicing
system:

•    T-Online Hungary Ltd's certified product called Marketline Integrated Signing Module
     (hereinafter MIAM) that performs signing, initial verification supporting subsequent
     verification of signatures, and archiving of electronic invoices, and

•    MultiSigno's freely downloadable (non- certified) product called Verify (hereinafter Verify),
     using which, the recipient of an invoice can verify the signature of an electronic invoice.
                                                 6                                       Signature Policy




2.     Signature policy data

       2.1.    Signature policy identifier

Unique identifier of this signature policy:          see the value indicated on the cover page

Date of issue of this signature policy:              see the date indicated on the cover page

This signature policy has been issued by:            WizzAir Hungary Ltd


       2.2.    Scope of this signature policy

               2.2.1. Physical scope of this policy

The physical scope of this policy covers WizzAir Hungary Ltd's electronic invoicing system and
electronic transactions performed within it, in particular the Marketline Integrated Signing Module
and MultiSigno's Verify program.

               2.2.2. Geographical scope of this policy

The geographical scope of this policy encompasses the entire area of Hungary.

               2.2.3. Temporal scope of this policy

This signature policy shall be valid for an indeterminate term as of the date it becomes effective, as
indicated on the cover page and applicable for this version in the change management table.

The effectiveness of this signature policy shall be terminated when this signature policy is revoked
or a new version becomes effective.

               2.2.4. Personal scope of this policy

The personal scope of this signature policy covers persons working with WizzAir Hungary Ltd's
electronic invoicing system (those responsible for signing invoices electronically) and recipients of
invoices issued (customers accepting WizzAir Hungary Ltd's electronic invoices, who verify
electronic signature of their invoices).
                                                  7                                      Signature Policy




       2.3.    Maintaining this signature policy (change management)

WizzAir Hungary Ltd may modify this signature policy at any time, without prior notification.

WizzAir Hungary Ltd shall publish modified policies to its customers accepting signed invoices at
least two days before such policy becomes effective, and notify such customers thereupon.

WizzAir Hungary Ltd shall preserve previous, expired versions of this policy and, if requested,
provide copies thereof to interested parties.

Customers accepting WizzAir Hungary Ltd's electronic invoices hereby accept, and regard as
binding upon them, the present (current) signature policy. In the event of this policy being
modified, customers accepting WizzAir Ltd's electronic invoices may take exception until the new
policy becomes effective, however, failure to do so shall constitute acceptance of the policy.


       2.4.    Publishing this policy

The current version of this signature policy shall be published on WizzAir Hungary Ltd's web site.

The policy shall be published in PDF format.
                                                 8                                    Signature Policy




       2.5.   Related policies and documents

This signature policy has been prepared in accordance with Matáv's Certification Service Policy,
the Certificate Policy of Matáv’s certificate types and the Timestamp Service Policy of Matáv's
timestamp service.

An individual internal policy applies to the rules of generating and storing certain cryptographic
keys used in WizzAir Hungary Ltd's electronic signing system (Key Management Policy of
WizzAir Hungary Ltd's Electronic Invoicing System).

Use of the Marketline Integrated Signing Module is described in the MIAM operating manual.

Use of Verify is presented in the PDF file enclosed with the application.

Matáv policies

Matáv Ltd issues and manages the certificates used by WizzAir Hungary Ltd to issue invoices, in
accordance with Matáv Ltd's Certification Service Policy and the „e-Szignó” High Grade Business
Certificate Policy.

Matáv Ltd provides its timestamp service in accordance with Matáv Ltd's Timestamp Service
Policy and the „e-Szignó” Certification and Timestamp Service Policy.

The above mentioned public policies are available at the eSzignó web site.
                                                    9                                       Signature Policy




3.       Signature validation policy

         3.1. Type of acceptance of obligations of electronic signatures

Every electronic signature also means the acceptance of an obligation.

The present signature policy assigns the following type of acceptance of obligations to all electronic
signatures covered by it:

By signing an electronic invoice, the signer (WizzAir Hungary Ltd, on behalf of which a duly
authorised employee performs the act of signing) acknowledges that it has prepared, approved and
sent the invoice on the date and time indicated by the signature, on behalf of WizzAir Hungary Ltd,
indicated in the certificate used to verify the signature. Electronic signatures created in this manner
are to be regarded as WizzAir Hungary Ltd's official, corporate signatures.

Since the present signature policy prescribes the same type of acceptance of obligation for all
signatures covered by it, rules related to the validity (creation and verification) of signatures will
apply uniformly to the signature of every electronic invoice.


         3.2. Rules related to validation data

The following requirements apply to the responsibility of the parties creating and accepting
signatures governed by the present signature policy:

                3.2.1. Obligations of the signing party

In addition to creating a signature, the party signing an electronic invoice (WizzAir Hungary Ltd)
shall perform initial verification of the signature and provide all validation data required for the
subsequent undeniability of the electronic signature through the carrying out of these two activities.

When creating a signature, the signing party shall add the following data to the electronic signature:

     •   identifier of the present signature policy (as a signed signature property),
     •   the end-user certificate used for signing (as a signed signature property),
     •   timestamp (as an unsigned signature property).
When performing initial verification of a signature (to be carried out after the waiting time set forth
in 3.5.3), the signing party shall add the following data to the electronic signature:

     •   valid revocation list issued within 24 hours following the time of signature,
     •   the CA certificate used for signing the revocation list (as an unsigned signature property).
The process of creating a signature is described in detail in Chapter 4.
                                                   10                                         Signature Policy




               3.2.2. Obligations of parties verifying signatures

Parties accepting electronic invoices (and verifying signatures) can verify the validity of electronic
signatures following receipt of invoices.

Verifying parties do not need to collect validation data during this process, they can perform
verification based exclusively on the validation data found in signatures and placed there by signers
and trusted certificates previously installed in their certificate repository (that is, they do not need to
perform an initial verification, they can perform a subsequent verification directly).

The process of verifying signatures is described in detail in Chapter 5.


       3.3. Rules related to formats

               3.3.1. Electronically signable formats

Exclusively Pdf format electronic invoices (invoice images) may be signed in WizzAir Hungary
Ltd's electronic invoicing system.

               3.3.2. Format of electronic signatures

Signers shall create signatures in a format complying with the XML-Signature RFC 3275 (XML-
Signature Syntax and Processing) standard. Electronic invoices contain one signature; it is not
required to prepare for the creation of multiple signatures in the system.

Initial verifications performed by the signing party after the waiting time (see 3.5.3) following
creation of a signature may not modify the above standard format; they may only replace the
revocation list with the current revocation list.

Verifying parties shall perform subsequent verification of signatures based on obtained electronic
signatures containing single signatures and in a format complying with the XML-Signature RFC
3275 standard.


       3.4. Rules related to the use of certificate authorities

               3.4.1. Rules related to the trust chain

The only certificates that may be used in WizzAir Hungary Ltd's electronic invoicing system are
end-user certificates issued by Matáv Ltd within the framework of its „eSzignó” service, registered
by Matáv Ltd.

These end-user certificates can be identified based on the following:

   •   Issuer (CN = Matav Shared CA / OU = Matav Trust Center / O = Matav Rt. / C = HU),
   •   Serial Number.
                                                   11                                       Signature Policy




These end-user certificates have high security grade and are valid for one year.

End-user certificates issued in the system are signed (certified) by the Matáv issuing certificate
authority using its CA certificate.

CA certificates can be identified based on the following data:

   •   Serial number (0084)
   •   Issuer (CN = Deutsche Telekom Root CA 1 / OU = T-TeleSec Trust Center / O = Deutsche
       Telekom AG / C = DE)
   •   Subject (CN = Matav Shared CA / OU = Matav Trust Center /
       O = Matav Rt. / C = HU)
   •   SHA1 fingerprint: DF62 0A85 75A4 62AC 77E6 CDA0 AD5D AB2A A41B 0B2A
The CA certificate has high security grade and is valid for five years.

The Matáv issuing certificate authority's certificate is verified by the Deutsche Telekom root
certificate authority's certificate using its own signature.

The root certificate can be identified based on the following data:

   •   Serial number (0024)
   •   Issuer (CN = Deutsche Telekom Root CA 1 / OU = T-TeleSec Trust Center / O = Deutsche
       Telekom AG / C = DE)
   •   Subject (CN = Deutsche Telekom Root CA 1 / OU = T-TeleSec Trust Center / O = Deutsche
       Telekom AG / C = DE)
   •   SHA1 fingerprint: 9E6C EB17 9185 A29E C606 0CA5 3E19 74AF 94AF 59D4
The root certificate has high security grade and is valid for twenty years.

               3.4.2. Rules of revocation

Revocation lists are also to be applied when the validity of end-user certificates is verified.

Revocation lists are signed and issued by the Matáv issuing certificate authority, every 24 hours at
maximum.

Revocation lists are available to the signing party from Matáv's certificate repository at the address
indicated in end-user certificates.

Revocation lists can be retrieved by verifying parties from electronic signatures.

Revocation lists are certified by the same certificate of the issuing certificate authority as end-user
certificates (see CA certificate in 3.3.1).

Revocation lists belonging to end-user certificates can and should be verified using this certificate.

No revocation lists are required for the verification of the validity of CA certificates or the root
certificate certifying the same.
                                                  12                                    Signature Policy




       3.5. Rules related to the use of timestamp service providers

The present signature policy also requires the use of timestamps.

               3.5.1. Rules related to the trust chain

Exclusively timestamps provided by Matáv Ltd may be used in WizzAir Hungary Ltd's electronic
invoicing system.

Matáv Ltd's CA certificate used to sign timestamps can be identified based on the following data:

   •   Issuer (CN = Matav Minositett Root CA / OU = Matav Trust Center / O = Matav / L =
       Budapest /C = HU)
   •   Extended key usage (1.3.6.1.5.5.7.3.8 /timestamps/)

The CA certificate used to sign timestamps is certified by the root certificate of Matáv as the root
certificate authority (using its signature).

This root certificate can be identified based on the following data:

   •   Serial number (01)
   •   Issuer (CN = Matav Minositett Root CA / OU = Matav Trust Center / O = Matav / L =
       Budapest /C = HU)
   •   Subject (CN = Matav Minositett Root CA / OU = Matav Trust Center / O = Matav / L =
       Budapest /C = HU)
   •   SHA1 fingerprint: 691D 25F1 298B 8ECC EF4E FC77 04CE D79F BDCA AE2D

               3.5.2. Rules of revocation

No revocation lists are required for the verification of the validity of CA certificate used to sign
timestamps or the root certificate certifying the same.

               3.5.3. Rules related to waiting time

The signing party may only perform initial verification after a waiting time of 24 hours following
creation of a signature.

The signing party may only make signed electronic invoices accessible to verifying parties after
performing an initial verification (and in a final format, complete with validation data).

               3.5.4. Rules related to delays of timestamps

The present signature policy does not expect time differences between signature times placed in
signatures and times indicated in timestamps to be investigated.
                                                  13                                  Signature Policy




Times indicated in timestamps shall be deemed as times of creation of a signature in the course of
both initial and subsequent verifications. (When verifying signatures, verifying parties shall
examine the validity of signatures and certificates based on these times).


       3.6. Rules related to algorithm restrictions and key lengths

Exclusively the following algorithms may be used in WizzAir Hungary Ltd's electronic invoicing
system for signatures, and with the following minimal key lengths:

To sign electronic invoices (end-user certificates):
   •   RSA signing algorithm with a key length of 1024 bits,
   •   SHA-1 fingerprint generating algorithm,
   •   PKCS #1 (emsa-pkcs1-v1_5) uploading algorithm.
To sign end-user certificates (CA certificate):
   •   RSA signing algorithm with a key length of 2048 bits,
   •   SHA-1 fingerprint generating algorithm,
   •   PKCS #1 (emsa-pkcs1-v1_5) uploading algorithm.
To sign revocation lists (CA certificate):
   •   RSA signing algorithm with a key length of 2048 bits,
   •   SHA-1 fingerprint generating algorithm,
   •   PKCS #1 (emsa-pkcs1-v1_5) uploading algorithm.
To sign timestamps (CA certificate):
   •   RSA signing algorithm with a key length of 2048 bits,
   •   SHA-1 fingerprint generating algorithm,
   •   PKCS #1 (emsa-pkcs1-v1_5) uploading algorithm.
                                                   14                                        Signature Policy




To sign CA certificates used to sign end-user certificates and revocation lists (First root certificate):
   • RSA signing algorithm with a key length of 1024 bits,
   • MD5 fingerprint generating algorithm,
   • PKCS #1 (emsa-pkcs1-v1_5) uploading algorithm.
To sign CA certificates used to sign timestamps (Second root certificate):
   • RSA signing algorithm with a key length of 2048 bits,
   • SHA-1 fingerprint generating algorithm,
   • PKCS #1 (emsa-pkcs1-v1_5) uploading algorithm.
                                                 15                                       Signature Policy




4.     Creating signatures

       4.1.    Preparing to create a signature

Numerous preparations are required in the signing party's (WizzAir Hungary Ltd) central system in
order to enable electronic invoices to be signed.

               4.1.1. Installing Marketline Integrated Signing Module

The Marketline Integrated Signing Module is to be installed in the central system performing
singing and initial verification of electronic invoices, with the cooperation of the developers of the
program.

In the course of installation, the version number of MultiSigno Developer, used by the Marketline
Integrated Signing Module, is to be checked.

               4.1.2. Generating keys

Keys used by the Marketline Integrated Singing Module are generated by the persons signing on
behalf of WizzAir Hungary Ltd in their browser in software and then installed on the server
computer running the Marketline Integrated Signing Module (DigSig). Rules of generating and
storing keys are set forth in detail in the „Key Management Policy of WizzAir Hungary Ltd's
Electronic Invoicing System”.

               4.1.3. Installing CA and root certificates

The CA and root certificates required for the creation and initial verification of signatures are to be
stored in the certificate repository of the Windows operating system of the computer running
Marketline Integrated Signing Module as trusted certificates so that it is not required to verify them
manually every time a signature is verified.

It is of critical importance to select and store these certificates securely from the aspect of system
security. The certificate repository may only contain CA and root certificates as trusted certificates
that are required for system operation and that can be unambiguously identified based on 3.4.1 and
3.5.1.

Any other pre-installed certificates are to be deleted from the certificate repository and no other
certificate can be installed on concerned computers later, either.

Security of the certificate repository is to be ensured on the computer running the Marketline
Integrated Signing Module through logical and physical protection of the computer and the
operating system. This protection is to guarantee that no certificate may be deleted from, and added
to, the certificate repository without authorisation.
                                                   16                                     Signature Policy




       4.2.    The process of creating a signature

               4.2.1. Specifying activation data
The Marketline Integrated Signing Module creates electronic signatures automatically, without
human intervention or approval.

Private keys are to be activated by owners knowing activation data when operation is started for the
first time, in compliance with the provisions set forth in the „Key Management Policy of WizzAir
Hungary Ltd's electronic invoicing system”.

               4.2.2. Creating a signature
The Marketline Integrated Signing Module creates electronic signatures through software, without a
separate singing device.

               4.2.3. Initial verification of signatures by the signing party

When the waiting time following creation of a signature (see 3.5.3.) has elapsed, the Marketline
Integrated Signing Module performs an initial verification of the signature. A signature (and,
through it, a signed electronic invoice) may only be finalised if this initial verification returns a
valid result.

               4.2.4. Validity of signatures
Initial signature verification and, through it, creation of that signature is „valid” if all of the
following conditions are met:
   •   The signing document is not a blank document.
   •   The signer has data for creating a signature (private key).
   •   The signer has a certificate.
   •   If the signer has several certificates and data creating signatures, and the signer has selected
       from among these previously.
   •   Signature verification returns a „valid” result.

Creation of a signature is „invalid”, if any of the following criteria are met:
   •   The signing document is a blank file.
   •   The signer does not have data for creating a signature (private key).
   •   The signer does not have a certificate.
   •   If the signer has several certificates and data creating signatures, and the signer has not
       selected from among these previously.
   •   Signature verification returns an „invalid” result.
   •   Downloading the revocation list fails and, therefore, signature verification returns
       „unfinished” results.
                                                  17                                       Signature Policy




In the event that creation of a signature is invalid, the data to be signed will not be forwarded from
the system and the signer receives a notification.


       4.3.    Special rules of revocation and suspension

If a signing party's (persons signing on behalf of WizzAir Hungary Ltd) certificate is revoked or
suspended, they are to notify Matáv Ltd's customer service and the organisational unit operating
WizzAir Hungary Ltd's electronic invoicing system, in compliance with Matáv's Certificate Policy.
If such revocation or suspension has occurred due to a reason that does not exclude abuse of the
signing party's signature, such signing party is to make all effort to exclude potential abuses.
                                                    18                                         Signature Policy




5.     Verifying signatures

       5.1.    Preparing to verify a signature

Numerous preparations are also required on verifying parties' (receiving electronic invoices)
computers in order to enable signature of electronic invoices to be verified.

               5.1.1. Installing Verify
MultiSigno's Verify program is to be installed on computers performing verification of electronic
invoices. The program can be downloaded from http://www.kopdat.hu/multisigno or
http://www.multisigno.hu.



               5.1.2. Installing CA and root certificates

The CA and root certificates required for the verification of signatures are to be stored in the
certificate repository of the Windows operating system of the computer running Verify as trusted
certificates so that it is not required to verify them manually every time a signature is verified.

It is of critical importance to select and store these certificates securely from the aspect of system
security. The certificate repository is to contain all CA and root certificates that are required for
system operation and that can be unambiguously identified based on 3.4.1 and 3.5.1.

These certificates can be downloaded from Matáv's web site and certificate repository (in PKCS#7
and CRT format) from the following web address: http://www.eszigno.matav.hu under the menu
item "Certificate repository and registries”.

The certificate repository of computers performing verification may contain other certificates
required by verifying parties for other purposes.

It is verifying parties' responsibility to maintain their certificate repositories. Verifying parties are to
ensure security of the certificate repository through logical and physical protection of their
computers and operating systems on computers running Verify. This protection is to guarantee that
no certificate may be deleted from, and added to, the certificate repository without authorisation.
                                                  19                                      Signature Policy




       5.2.    The process of verifying signatures

               5.2.1. Signature validation data

The following validation data, required for verification of signatures, shall be obtained by verifying
parties as part of signatures:
   •   end-user certificate,
   •   timestamp,
   •   revocation list.
The following validation data required for verification of signatures is available to verifying parties
as CA and root certificates and has previously been installed (see 5.1.2):
   •   CA certificate belonging to the key signing the end-user certificate and the revocation list
       (see 3.4.1),
   •   First root certificate belonging to the key signing the above CA certificate (see 3.4.1),
   •   CA certificate belonging to the key signing timestamps (see 3.5.1),
   •   Second root certificate belonging to the key signing the above CA certificate (see 3.5.1).

               5.2.2. Validity of signatures
Signature verification performed by verifying parties will only return a „valid” result if all of the
following conditions are met:
   •   The end-user certificate, the timestamp and the revocation list can be retrieved from the
       signed data set (these are to be used in further verification).
   •   Signature verification carried out using the private key and algorithms found in the end-user
       certificate returns a „valid” result.
   •   The appropriate CA and root certificate in the trust chain of the end-user certificate is
       available from the local certificate repository. (These are to be used in further verification).
   •   Verification of the signatures on the end-user, CA and root certificates returns a „valid”
       result.
   •   The date of issue of the revocation list concerning the end-user certificate is later than the
       date of signature (that is, the date in the timestamp).
   •   The CA and root certificates required for the verification of the revocation list are available
       from the local certificate repository. (These are to be used in further verification).
   •   Verification of the signatures on the CA and root certificates required for the verification of
       the revocation list returns a „valid” result.
   •   The revocation list does not contain the verified end-user certificate either in suspended or
       revoked status.
   •   The CA and root certificates required for the verification of the timestamp are available
       from the local certificate repository. (These are to be used in further verification).
   •   Verification of the signatures on the CA and root certificates required for the verification of
       the timestamp returns a „valid” result.
   •   The fingerprint value found in the timestamp is identical to the fingerprint in the signature.
In the course of the above verification process, the application is to verify the following data of
every certificate:
   •   Validity (Whether the date of signature falls between the validity dates of the certificate)
                                                 20                                     Signature Policy




   •   Subject (Whether it is identical with that specified in the signature policy)
Applications are not required to examine or consider financial limits possibly appearing in
certificates.

Prescriptions of Matáv's Authentication and Certificate Policies are to be observed when certificates
are verified and interpreted.
                                                 21                                         Signature Policy




6.       Definitions
The following concepts have the following meaning in this signature policy:


Data to be signed            Signer's document, signature properties and other, optional signed
                             information together.
Signature verification process A process that verifies an electronic signature in accordance with
                             requirements of the signature (or authentication or service) policy.
Signature properties         Supplementary data of a signature that are signed along with the
                             signer's document, in accordance with the signature policy.
Signature management application     An application supporting creation and/or verification of
                             signatures.
Signature creating data      A private key appropriate for the creation of electronic signatures
Signing algorithm            A public-key cryptographic procedure encrypting fingerprints using a
                             private key.
Signing device               A hardware device that creates electronic signatures using signature
                             creating data stored on that device. Typically an intelligent card.
Signing party                A natural person or an application that signs a transaction or a
                             document.
Signer's document            A document of any content that a signing party wishes to sign.
Signed data set              Electronic signature and fields of data to be signed, along with other,
                             unsigned information.
Applet                       An application that is downloaded on users' computers and run by
                             browsers.
Trust point                  A trust point is the top element of a trust chain. Practically, it consists
                             of a root certificate and other supplementary data. Trust in it means
                             trust in all (CA and end-user) certificates certified by it.
Digital signature            Value of a fingerprint encrypted using a signing algorithm.
Verifying party              A natural person or an application that verifies a signature on a
                             transaction or a document.
                                                22                                      Signature Policy




Validation data            Data added to signatures and required to decide whether an electronic
                           signature complies with requirements of the signature policy. May
                           contain certificates, revocation status information (related to the
                           signer and the certificate authority) and timestamps and time
                           indications prepared by timestamp service providers. It is the task of
                           validation data to testify that the full trust chain was valid when a
                           signature was created.
Formatted data to be signed Data to be signed and formatted in accordance with the signature
                           policy.
Root certificate unit      A (hardware-software) unit of a certificate authority that the service
                           provider uses to issue its own certificates and related revocation lists.
Root certificate           A certificate not certified by a further certificate. Can be verified
                           using the private key contained in it, which is why it is also called
                           self-certified certificate.
Certificate authority      An organisation issuing electronic certificates and supporting
                           management of certificates (in the case of the present signing system,
                           Matáv Ltd).
Timestamp service          A service related to electronic signature, in the course of which a
                           service provider attaches a timestamp to an electronically signed
                           electronic document.
Timestamp                  Data irrevocably assigned or logically linked to an electronic
                           document that testifies that the concerned electronic document existed
                           in the same form when the timestamp was placed.
Initial verification       A procedure to be carried out following creation of a signature in
                           order to confirm the signature by collecting additional information
                           required to support subsequent verifications.
Waiting time               An electronic signature may be deemed as valid if the verifying party
                           ensures that it really was the signer that possessed the private key at
                           the time of signature. However, it is unavoidable that some time
                           elapses between compromise, loss of a key and a report on it.
                           Therefore, the so-called waiting time is to elapse (the value of which
                           is prescribed by the signature policy) before initial verification of a
                           signature may be successfully performed.
                                                  23                                       Signature Policy




Fingerprint                   Short data unambiguously pertaining to a signer's document and
                              produced from it using a hash algorithm.
Private key                   A key required to create a signature, practically a unique file. See
                              signature creating data.
MultiSigno Developer          Basic procedures of signing and verifying signatures are implemented
                              in this application programming interface (API), implemented as a
                              DLL library. MultiSingo Developer is a product of Kopint-Datorg
                              Ltd.
CA issuing certificate unit   A (hardware-software) unit of a certificate authority issuing
                              certificates and revocation lists.
CA certificate                A file containing a public key required to verify the signature of the
                              end-user certificate and data required to use it, signed by the issuing
                              root certificate unit.
Trust chain                   A hierarchy (chain) of certificates certifying each other. The
                              certificate of the signer is at the bottom of the hierarchy, above it the
                              certificate of the certificate authority signing this certificate, above
                              this, the certificate of another certificate authority signing this
                              certificate. This series can go on until a root certificate unit, which is
                              found at the top of the chain
Transaction                   A business operation that appears in the IT system as a message (for
                              valid types in the ISZR system, see Chapter 3).
Subsequent verification       A procedure to be performed following the initial application of a
                              signature, with the purpose of evaluating the validity of a signature,
                              based on data collected during the initial verification.
End-user certificate          A file containing a private key required for the verification of the
                              signature and data required to use it, signed by the issuing certificate
                              authority.
Revocation list               An electronic list containing identifiers of end-user certificates
                              suspended or revoked for some reason, signed, issued and regularly
                              updated by certificate authorities.

								
To top