European Federated Validation Service Study
Solution Profile – BBS Global
Validation Authority Service
July 2009
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
This report / paper was prepared for the IDABC programme by:
Author’s name: Indicated in the solution profile below, under ‘contact information’
Coordinated by: Hans Graux (time.lex), Christian Staffe (Siemens), Eric Meyvis (Siemens)
Contract No. 1, Framework contract ENTR/05/58-SECURITY, Specific contract N°14
Disclaimer
The views expressed in this document are purely those of the writer and may not, in any
circumstances, be interpreted as stating an official position of the European Commission.
The European Commission does not guarantee the accuracy of the information included in this
study, nor does it accept any responsibility for any use thereof.
Reference herein to any specific products, specifications, process, or service by trade name,
trademark, manufacturer, or otherwise, does not necessarily constitute or imply its
endorsement, recommendation, or favouring by the European Commission.
All care has been taken by the author to ensure that s/he has obtained, where necessary,
permission to use any parts of manuscripts including illustrations, maps, and graphs, on which
intellectual property rights already exist from the titular holder(s) of such rights or from her/his or
their legal representative.
This paper can be downloaded from the IDABC website:
http://europa.eu.int/idabc/
http://ec.europa.eu/idabc/en/document/7764
© European Communities, 2009
Reproduction is authorised, except for commercial purposes, provided the source is
acknowledged.
2
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Executive summary
The European Federated Validation Service (EFVS) Study was initiated by IDABC in order to assess
the feasibility of specific measures to ensure the availability of a European scale federated electronic
signature verification functionality. As a first step in the EFVS Study, information has been collected on
twenty existing solutions that already provide all or some of the functionalities associated with
European signature verification functionality, or that could provide valuable insights on how such an
EFVS could be organised.
This has been done by drafting standardised profiles of the identified solutions, focusing specifically on
how each of these solutions (a) determine the validity of signature certificates; (b) verify electronic
signatures created using these certificates; and (c) provide specific guarantees to their customers on
the outcomes of these processes.
The present document contains the solution profile for: BBS Global Validation Authority Service.
3
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Table of Contents
EXECUTIVE SUMMARY
3
1
5
DOCUMENTS
1.1
APPLICABLE DOCUMENTS
5
1.2
REFERENCE DOCUMENTS
5
2
GLOSSARY
6
2.1
DEFINITIONS
6
2.2
ACRONYMS
8
3
SOLUTION PROFILE – BBS GLOBAL VALIDATION AUTHORITY SERVICE
4
9
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
1 Documents
1.1 Applicable Documents
[AD1]
Framework Contract ENTR/05/58-SECURITY
1.2 Reference Documents
[RD1]
Project Management and Quality Plan (EFVS SC14 PMQP)
[RD2]
DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE
COUNCIL of 13 December 1999 on a Community framework for electronic
signatures
http://europa.eu/information_society/eeurope/i2010/docs/esignatures/esignatures_e
n.pdf
[RD3]
Preliminary Study on Mutual Recognition of eSignatures for eGovernment
applications http://ec.europa.eu/idabc/en/document/6485/5938
5
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
2 Glossary
2.1 Definitions
In the course of this report, a number of key notions are frequently referred to. To avoid any ambiguity,
the following definitions apply to these notions and should also be used by the correspondents.
o
Entity: anyone or anything that is characterised through the measurement of its attributes in an
eIDM system. This includes natural persons, legal persons and associations without legal
personality; it includes both nationals and non-nationals of any given country.
o
eIDM system: the organisational and technical infrastructure used for the definition,
designation and administration of identity attributes of entities. This Profile will only elaborate
on eIDM systems that are considered a key part of the national eIDM strategy. Decentralised
solutions (state/region/province/commune…) can be included in the scope of this Profile if they
are considered a key part of the national eIDM strategy.
o
eIDM token (or ‘token’): any hardware or software or combination thereof that contains
credentials, i.e. information attesting to the integrity of identity attributes. Examples include
smart cards/USB sticks/cell phones containing PKI certificates, …
o
Authentication1: the corroboration of the claimed identity of an entity and a set of its observed
attributes. (i.e. the notion is used as a synonym of “entity authentication”).
o
Authorisation: the process of determining, by evaluation of applicable permissions, whether an
authenticated entity is allowed to have access to a particular resource.
o
Unique identifiers: an attribute or a set of attributes of an entity which uniquely identifies the
entity within a certain context. Examples may include national numbers, certificate numbers,
etc.
o
Official registers: data collections held and maintained by public authorities, in which the
identity attributes of a clearly defined subset of entities is managed, and to which a particular
legal of factual trust is attached (i.e. which are generally assumed to be correct). This includes
National Registers, tax registers, company registers, etc.
o
eGovernment application: any interactive public service using electronic means which is
offered entirely or partially by or on the authority of a public administration, for the mutual
1
For the purposes of this Profile, the notion of authentication is considered to be synonymous with ‘entity
authentication’, as opposed to ‘data authentication’. The notion of ‘identification should be avoided to avoid
confusion.
6
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
benefit of the end user (which may include citizens, legal persons and/or other administrations)
and the public administration. Any form of electronic service (including stand-alone software,
web applications, and proprietary interfaces offered locally (e.g. at a local office counter using
an electronic device)) can be considered an eGovernment application, provided that a certain
degree of interactivity is included. Interactivity requires that a transaction between the parties
must be involved; one-way communication by a public administration (such as the publication
of standardised forms on a website) does not suffice.
o
eSignature: data in electronic form which are attached to or logically associated with other
electronic data and which serve as a method of authentication with regard to this data. Note
that this also includes non-PKI solutions.
o
Advanced electronic signature: an electronic signature which meets the following
requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using means that the signatory can maintain under his sole control; and
(d) it is linked to the data to which it relates in such a manner that any subsequent change of
the data is detectable;
Again, this definition may cover non-PKI solutions.
2
o
Qualified electronic signature: advanced electronic signatures which are based on a qualified
certificate and which are created by a secure-signature-creation device, as defined in the
2
eSignatures Directive .
o
Validation: the corroboration of whether an eSignature was valid at the time of signing.
See http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31999L0093:EN:HTML
7
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
2.2 Acronyms
A2A.................................................Administration to Administration
A2B.................................................Administration to Businesses
A2C.................................................Administration to Citizens
CA...................................................Certification Authority
CRL ................................................Certificate Revocation Lists
CSP ................................................Certificate Service Provider
eID ..................................................Electronic Identity
eIDM ...............................................Electronic Identity Management
IAM .................................................Identity and Authentication Management
IDM .................................................Identity Management
OCSP .............................................Online Certificate Status Protocol
OTP ................................................One-Time Password
PKCS..............................................Public-Key Cryptography Standards
PKI..................................................Public Key Infrastructure
SA...................................................Supervision Authority
SOAP..............................................Simple Object Access Protocol
SCVP ..............................................Server-based Certificate Validation Protocol
SSCD..............................................Secure Signature Creation Device
USB ................................................Universal Serial Bus
TTP.................................................Trusted Third Party
XAdES............................................XML Advanced Electronic Signature
XML ................................................eXtensible Markup Language
XML-DSIG ......................................XML Digital Signature
8
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
3 Solution Profile – BBS Global Validation Authority Service
Name and organisation
The Validation Authority Service is operated Bankenes Betalingssentral AS (BBS)
The service is referred to below as the ‘validation authority’ or ‘VA’.
Det Norske Veritas AS (DNV) provides independent quality assessment.
Reference (on-line source)
http://www.bbs-nordic.com
http://www.bbs-nordic.com/en/Solutions-and-Services/eSecurity/Global-Validation-Service/
http://va.dnv.com
Contact information
Bishwajit Choudhary
FA BBS eSecurity
Haavard Martinsensvei 54
N-0045 Oslo
Norway
Tel: +47 22898098
Email: Bishwajit.choudhary@bbs.com
9
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Scope of the solution
Services offered
(What services does the solution offer to a relying party? This should include most notably the
three basic services above – validation of certificates, verification of the signature, and ensuring
trustworthiness and legal liability – but may also cover additional services – e.g. semantic services,
archiving of documents/signatures, maintenance, time stamping, security/reliability metrics for the
security level of the signature and the certificate,…Services that are not currently available but
which are planned for the future may also be indicated. )
BBS provides a neutral validation authority offering validation of certificates for electronic identity
(eID) and verification of digital signatures as a third party service. This is a continuation of the
VA service originally developed by DNV. For additional information, see:
http://www.dnv.com/binaries/DNV_VA_Service_Description_RP_v1%200_s_tcm4279045.pdf
Basic services:
The validation authority (VA) provides two basic service interfaces as web services:
•
•
Certificate validation (one certificate, possibly with chain of CA certificates,
multiple certificates in one request may be a future option)
Signature verification (all signatures on one document and the accompanying
certificates)
These are “rich” interfaces that can provide a service offering flexibility to customers
(see below). The VA covers all three basic services cited above due to:
•
The VA is defined as a separate trust anchor taking on legal liability for the
validation responses
The VA will independently sign each validation response. Liabilities and conditions
are further described in the customer contracts.
Further, the following must be regarded as basic services of the VA as the
information is always returned (refer security/reliability metrics above):
•
•
Quality classification of certificates (both interfaces)
Quality classification of signatures (signature verification interface)
BBS uses DNV (http://www.dnv.com) as subcontractor for independent quality
assessment. The certificate products of all supported CAs are classified according to
quality and national approval status (e.g. qualified). For signatures, the cryptographic
quality is additionally asserted.
10
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Responses from the VA will be related to the appropriate quality level profile. (For example, if a
signature is verified as valid but with parameters below the appropriate quality level profile, the VA
will return a response stating “not trusted”.) In special cases the customer may override the quality
level profile by specifying desired Certificate Quality Level and/or Signature Quality Level in the
request.
Existing additional services:
Due to the flexibility of the interfaces, several options are supported as indicated by
the customer in the request:
•
Additional information derived from certificates or signatures (content,
algorithms, CRL/OCSP information, etc.)
Note also the following:
•
Trusted archival (not yet integrated with the VA)
Trusted archival is at the core of BBS’ service offering, including existing archival services for
signed documents. Automated integration with the VA is not yet implemented. Improved signature
maintenance functionality is under implementation.
Future additional services:
The two following service options are not yet available to customers but are
supported by interfaces and by the service software through an archive of CRLs from
the CAs supported:
•
•
Historical validation of certificates (validity at time instant specified in request)
Historical verification of signatures (validity at time instant specified in request or given by
time stamp in the signed data object)
The following are fairly straightforward extensions that can be implemented given
customer demand:
•
•
•
Auxiliary information from other sources than the certificate itself (e.g. business or other
public registers)
Semantic interpretation of certificate attributes (returning information in a normalized form,
mapping individual certificate profiles to this form)
Time-stamping (would be a separate service interface) or integration towards external
time-stamping service
11
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Application domain (e.g. sector or application types)
(Is the solution usable in any sector or application field (i.e. is it generic in scope), or is it currently
limited to a specific sector, application or domain? If it is currently restricted, would it be possible to
extend the solution to other sectors, applications or domains? What would need to be changed?)
BBS can offer its solution in any sector or application field.
12
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
CAs covered by the solution
(How many CAs are presently covered by the solution, and which ones? Do they include CAs
established in multiple countries or states?)
The following Certificate Authorities are supported by the VA service in production:
• Actalis S.p.A (Italy - www.actalis.it)
• Buypass AS (Norway – www.buypass.no)
• Commfides Norge AS (Norway – www.commfides.com)
• GlobalSign Ltd (Global – www.globalsign.com)
• InfoCert (Italy – http://www.infocert.it)
• Population Register Center (Finland – www.vrk.fi/vrk/home.nsf/pages/index_eng)
• AS Sertifitseermiskeskos (Estonia – www.sk.ee)
• Skaitmeninio Sertifikavimo Centras (Lithuania – www.ssc.lt)
• TDC AS (Denmark – http://tdc.dk)
• TeliaSonera AB (Sweden- www.telia.se)
• ZebSign AS (Norway – http://www.zebsign.no)
Note that BBS requires a signed agreement with a CA before installing the CA in the production
environment. In the staging area for the VA, about 45 CAs are technically supported. When
agreements are obtained, these may immediately be installed in the production environment.
Some of the CAs may possibly be moved to production even without an agreement.
Extensibility of the solution
(Can additional CAs be integrated into the solution? If so, are there restrictions? Have such
extensions been done in the past yet, or are any extensions currently planned?)
Additional CAs can be integrated into the VA. In this case, BBS will normally enter an
agreement with a CA before including it in the list of CAs handled. As a minimum,
BBS needs to ensure that handling the CA is not a violation of the CA’s policies.
If a customer of the VA requires a specific CA to be included, the customer is
encouraged to notify BBS. BBS will then attempt to support the CA as soon as
possible.
Business model/cost model of the solution
13
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
(How is the solution funded? Is it envisaged as a for-profit model? Who pays contributions, and for
what type of services? What profits (if any) are made with the services provided by the solution?
Upon request of the correspondent, any communicated price information or other commercially
sensitive information will not be disclosed.)
For-profit model
Currently, BBS relies on business agreements with its customers (the users of the
VA, the relying parties of the certificates and signed documents to be validated) to
finance its operation, including to cover its responsibilities and liabilities. If payment
could be secured, some basic VA services could be provided openly. VA services to
the general public are possible, and even desired, but this is not the first market
segment targeted by BBS.
As regards the cost model, a suitable agreement is put in place with each customer
of the VA on a case by case basis (transaction based, volume based or fixed). The
VA in turn pays the CAs and other information providers. CAs are paid a fraction of
the income for certificate validation and signature verification, proportionate to their
share of the number of certificates validated.
14
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Technical approach
Validation approach
(Does the solution validate signature certificates, electronic signatures based on a hash value of
the signed document(s), or signed documents with embedded signatures?)
The service encompasses verification of digital signatures and validation of
accompanying signing certificates. Multiple signatures of types A (independent
signatures) and C (overall countersignatures) are handled – see below.
Enveloping, enveloped and detached signatures are supported.
Web Services
The VA services are implemented as Web Services, meaning:
•
Requests and responses are defined as XML structures with defined content.
•
Communication is based on the SOAP protocol.
•
Underlying SOAP is the HTTP protocol – in the VA case HTTPS (HTTP
secured by the SSL/TLS protocol).
A customer builds a request containing the desired parameters and sends this to
the VA. The response returned by the VA must be interpreted and used as basis for
further processing (or displayed to a human user). Requests and responses consist
of some mandatory and some optional elements, notably a set of optional “respond
with” parameters that can be populated.
The XML and the definitions for the elements of the XML structures are available
from the DNV VA web site. Future development of the interfaces are likely to follow
the specifications from the PEPPOL project (http://www.peppol.eu) Deliverable
D1.1, using a profile of the XKISS part of XKMS v2 for certificate validation and a
profile of OASIS DSS for signature verification.
A customer will typically implement work flows for specific business processes and
integrate calls to the VA services at defined steps or events of these processes.
15
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Typical steps/events are reception of a (signed) document or an eID certificate used
for other purposes than signing (e.g. authentication). The Signature Verification or
Certificate Validation service is then called to address the request.
Security and Access Control
The VA services are available only to registered customers. The customers are
authenticated by SSL client authentication. The SSL protocol by default also
authenticates the server side, i.e. the VA itself. Optionally, customers may also sign
requests. The VA signs all responses (detached XML DSIG). All communication is
encrypted and integrity protected by means of SSL.
All certificates, for customers as well as for the VA itself, are issued by a dedicated
CA in conjunction with the VA services. This is to pinpoint the VA’s position as an
independent trust anchor, not relying on any CA with respect to trust.
Customers must obtain and install client certificate(s) issued by this CA and must
install the certificate of the CA. If a VA Gateway is used, installation in the Gateway
is sufficient.
Test and Staging Environment
BBS operates a test and staging infrastructure for the VA services. On integrating
VA access in a customer system, an acceptance test has to be successfully
completed using this environment before access to the operational environment is
granted to the VA customer.
Quality Parameters
In the present version of the VA, certificate quality is indicated as a number from 0-6
with 6 as the best quality, as will be further commented below. Signature quality is
computed based on fixed parameters related to certificate quality and cryptographic
quality. The present quality levels are applicable in Europe, as they refer to the EU
Directive on electronic signatures and other EU regulation for qualified certificates
and qualified signatures.
A more comprehensive quality classification system is developed in the PEPPOL
project (Deliverable D1.1), and for future development the VA is likely to adopt this
scheme.
16
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Adaptation according to customer demands is possible, subject to agreements
between BBS and the customer.
More information on certificate quality is given in the document “DNV Validation
Authority - Quality Parameters, Certificate and Signature Quality” available from the
DNV VA web site (see http://www.dnv.com/binaries/VA-quality-parametersv2.0_tcm4-222724.pdf)
With regard to certificates
(How does the validation of certificates work – based on OCSP, CRLs, or both? What certificate
profiles are supported by the solution?)
For a certificate validation request, the certificate is a parameter of the request. For
signature verification, either the entire signed document or pairs of hash values and
signature fields are parameters of the request; certificates have to be present in the
signature fields (use of certificate referencing and directory lookup is for further
study).
The overall status of a certificate validation is trusted, not trusted, indeterminate
(meaning that the VA lacks information), or an error message, e.g. in case of a
malformed request. For signature verification, an overall assertion covering all
signatures is returned (trusted, not trusted, indeterminate) as well as individual
assertions for each signature and certificate, possible values being valid, invalid,
indeterminate, insufficient quality. Note that insufficient quality (meaning valid but
quality below the level specified) will yield an overall “not trusted” answer.
Due to its position as a separate trust anchor with individual agreements with the
CAs, the VA trusts each CA individually by having the CA’s root certificate(s)
configured into the VA. Certificate chains (and in the future Trust Status Lists) may
be used for internal processing. As a rule, chain validation is not performed but this
may be added in the future since it may emerge as a customer requirement.
Access to revocation information from CAs is configurable, the preferred mode
being OCSP with fallback to CRL if OCSP is unavailable. For historical validation,
CRLs are regularly downloaded from all CAs that issue CRLs into an archive in the
VA.
All CAs are contractually obliged to inform the VA about changes in operation or
other status changes.
17
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Quality of Certificate
The quality of the certificate (currently expressed in a rating from 0 to 6) is assessed
by DNV as subcontractor based on the applicable certificate policy and the CA’s
national accreditation/supervision status. The quality is assigned to the combination
of CA and policy meaning that two CAs with the same policy may obtain different
ratings if they differ in other aspects.
Note that in most legislations only certificates issued to natural persons may be
marked as qualified. Thus certificates issued to legal entities usually cannot be
assigned level 5 or 6 (the qualified levels), no matter their inherent quality.
The following values are assigned:
0. Inadequate or non-determined level: Very low confidence or assessment not
possible, usually because a certificate policy does not exist. Many corporate
PKIs will be placed in this category.
1. Low level: Low confidence in certificate but certificate policy exists or quality
assessment is possible by other means.
2. Medium non-approved level: Medium confidence certificates with no formal
registration/ approval status.
3. High non-approved level: Certificate quality is at or very close to qualified level
but certificate issuer is not registered/approved by assigned
inspectorate/authority according to applicable law to the issuer.
4. Non-qualified approved level: Certificate is not marked as qualified but
certificate issuer is registered/approved by assigned inspectorate/authority
according to applicable law to the issuer (according to a registration/approval
scheme for issuers of non-qualified certificates).
5. Qualified approved level: Certificates are marked as qualified and the issuer is
registered/ approved by assigned inspectorate/authority according to applicable
law to the issuer. Private key environment is not certified as SSCD (Secure
Signature Creation Device) according to CEN CWA 14169.
18
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
6. Qualified signature level: Certificates are marked and registered as for level 5,
and use of a certified SSCD according to CEN CWA 14169 is mandated. Thus,
this level supports qualified signatures according to the EU Directive on
electronic signatures.
The quality classification system developed by the PEPPOL project in Deliverable
D1.1 is likely to replace this system in the future.
BBS and DNV monitor the quality of the hash algorithm and size of the key pair
used by the CA to sign certificates and reserve the right to suspend or degrade a
CA whose certificates must be considered unreliable due to weaknesses in these
cryptographic parameters.
With regard to signatures
(What signature formats are supported by the solution - PKCS #7, CMS, XML signatures, PDF
signatures, XAdES, CAdES, or others?)
When using the VA Web Service, one signed document is taken as input, returning
the status of all signatures on the document, their quality, and the status and quality
of the eIDs used. As for certificate validation, the overall answer is trusted, not
trusted, indeterminate, or an error message. Answers are also provided for each
individual signature, values being valid, invalid, indeterminate, insufficient quality,
and for each eID with values valid, invalid, indeterminate, insufficient quality.
Insufficient quality yields a not trusted overall status.
The quality of a signature is computed based on the eID quality (i.e. the certificate
quality as commented above) and the cryptographic quality as described in “DNV
Validation Authority - Quality Parameters, Certificate and Signature Quality”
available from the DNV VA web site. (see http://www.dnv.com/binaries/VA-qualityparameters-v2.0_tcm4-222724.pdf)
Alternatively, when using the VA Gateway (see below) instead of the web services,
only signatures and corresponding hash values computed on the document can be
sent instead of the entire document. Thus, the document itself is removed from the
request, while only signatures and hashes are forwarded from the Gateway to the
VA.
The DNV validation authority service supports the following signature types:
• PKCS #7
19
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
• CMS
• XML Signatures
• PDF signatures
• XAdES and CAdES signatures
Quality of Signature
A signature is verified by the signer’s certificate. The certificate policy for this
certificate is assumed to capture most aspects of a signature quality, including use
of smart card or other hardware token and legal standing such as qualified level.
The remaining signature quality issues are related to cryptographic algorithms:
•
•
Hash algorithm used for the signature (i.e. by the signer). This depends on
the signer’s software and cannot in general be controlled by the CA.
The quality of the signer’s public key algorithm and key. This is in most cases
controlled by the CA, which must accept to issue a certificate for the public
key even when the signer has generated the key pair.
Only key length is considered with issues such as quality of random number
generator being for further study. For high quality certificates (level 3 and up), the
CA must be expected to take action in case key lengths (and algorithm) in issued
certificates are deemed to be unacceptable, i.e. revoke and issue new certificates.
However, for historical validation, a certificate for a public key of inadequate size
must still be checked.
Cryptographic algorithms are identified by OIDs (Object Identifier). OIDs are defined
both for individual algorithms and for combinations of hash and public key algorithm.
Both types of OIDs are used for signatures. Notably, PKCS#7 usually includes
separate OIDs for hash and public key algorithm, while a signature in CMS typically
uses one OID for the combination. The latter, one OID, is also normally used for a
CA’s signature on a certificate or CRL.
Further quality parameters for signatures may be the application of the algorithms,
such as PKCS#1 for RSA, and the encoding of the signed content, such as
PKCS#7 or CMS. These algorithms may have different quality aspects and potential
weaknesses, more or less independent from the cryptographic algorithms as such.
At present, such quality issues are not considered by the VA, e.g. in the sense that
RSA with a certain key size has the same strength for use with PKCS#7 and, say, a
PDF signature.
Multi-signatures
20
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
(Is the solution capable of validating multiple signatures on a document?)
Yes, validation of multiple signatures of types A (independent signatures) and C
(wrapping signatures) is supported. There is some but not full support for type B
(countersignatures, signing signature elements only).
Type
A
Type
B
Doc
Doc
Type
C
Doc
Sig3
Sig1
Sig1
Sig1
Sig2
Sig2
Sig2
Sig3
A
B
means A signs B
Sig3
Logging and auditing
(Is the use of the solution logged, and if so, to what extent? Do users of the solution have the
possibility to perform audits or to gain access to independent auditing reports?)
All requests and responses are logged as well as supporting actions such as the
download of a CRL or an OCSP request to a CA and all configuration actions (e.g.
adding a CA).
There is at present no independent auditing of the VA. BBS is aware that
requirements for auditing may come from authorities or customers. Note that BBS is
certified according to ISO 9001 and ISO 27001.
At present, customers do not have on-line access to logs. Information must be
provided by operators of the VA. On-line access is anticipated in future versions.
21
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Restrictions imposed on CAs
(What technical requirements are imposed on CAs, e.g. with regard to standards, formats or
certificate profiles that they need to adopt? This includes e.g. the inclusion of certain information
in signature certificates that is necessary in specific sectors.)
Only X.509 certificates are handled. Apart from this, no specific requirements are imposed. Key
usage settings are checked and can be returned to the customer. Sector specific information is
not treated. The VA does not rely on extensions such as QC statement, CRL distribution point,
and authority information. Rather, the information is configured in the VA.
Usage of the solution by relying parties
(How do relying parties use the solution? Are there software components which they need to
integrate into their own systems, is it a web service, etc.)
The VA provides the VA services as web services or optionally as a VA Gateway to
be installed in the customer’s network as illustrated in the figure below. The VA
Gateway is a software component that may be installed on a dedicated or shared
computer.
The purposes of the Gateway are threefold: request signature verification without
sending the document to the VA (only pairs of document hash values and signature
elements are sent), reduce need for bandwidth and response time since documents
do not have to be transmitted, provide a single point for authentication towards the
VA Services and for enforcement of (some) customer specific policies.
If a VA Gateway is used, this is the only customer-side component that needs SSL
client and/or request signing certificates and corresponding key pairs. The VA
Gateway is allowed to alter requests (for example to enforce common values for
minimum quality levels) before forwarding them to the VA, although limited
functionality is present to this effect at present.
The VA Gateway also contains an e-mail front-end, allowing a user to send an email containing a signed document to the Gateway for signature verification.
Response from the VA service will be provided to the user by e-mail. An
experimental web GUI interface also exists for upload of signed documents or
certificates but the program code for this interface is not provided to customers at
present.
Note that the VA Gateway deliberately does very limited logging, and notably that it
deletes documents as soon as the request to the VA has been created.
22
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
The VA Gateway is currently supported on the following operating systems (OS):
•
•
Windows Server 2003
Suse Linux 9.2 Enterprise
If desired, a customer may obtain administrator access rights to the VA Gateway.
Technical flexibility
(Given the technical characteristics outlined above, could the technical requirements of the
solution be changed to increase its flexibility (e.g. by supporting other signature standards,
validation methods, certificate profiles, etc.).
The approach and model applied by the VA is sufficiently generic to be able to integrate most if
not all existing approaches and standards for electronic signatures.
Status of the project/Actual usage of the solution
(What is the status of the project (e.g. in development, prototyped, in production, etc.).
What is the actual usage of the solution (e.g. in terms of relying parties adopting the solution to
validate electronic signatures) and what are the impacts of its use? How many transactions, how
many certificates does it handle?)
23
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
The VA is currently operational and in active use by pilot customers. The volume of use is
however limited at present.
Legal approach
3
Relationship with the CAs
(What requirements does a CA need to meet before being able to accede to the solution?
Specifically, which processes and procedures have been foreseen to ‘vet’ CAs? What kind of
agreements are put in place with the CAs, and what are the main issues addressed in these
agreements?)
CAs need to conclude an agreement with BBS before they can be integrated into
the VA. As a minimum, BBS needs to ensure that handling the CA is not a violation
of the CA’s policies, and a compensation model is put in place in which BBS
compensates the CA for the use of its validation facilities, if required.
Relationship with the relying parties
(How does a relying party get the right to use the solution? What kind of agreements are put in
place in relation with the relying parties, and which services can be offered to the relying parties
via these agreements?)
Relying parties (i.e. BBS’s customers) must conclude agreements with BBS to
address mainly the following points:
•
•
•
The services to be offered by the VA (including the integration of specific
CAs if needed).
Quality requirements with regard to certificates and electronic signatures (i.e.
the requirements the VA should apply to determine whether or not a
signature should be considered valid for the customer’s purposes). The
customer can override these requirements by specifying alternative
requirements in requests.
BBS’s liability for its services; exact levels of liability vary from agreement to
agreement, depending on the levels of services and needs of the customer,
3
Within the EU, the term ‘CA’ should be taken to mean a certification service provider as defined in article 2.11
of the eSignatures Directive (Directive 1999/93/EC) and outside the EU, this means a Certification Authority in
the technical sense, i.e. an entity issuing signature certificates to third parties.
24
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
•
but the liability provisions of the eSignatures Directive are always respected
in cases where qualified certificates are concerned. Use of the staging and
test environment is not covered by any liability.
The cost model/business model (i.e. costs per transaction, volume based or
fixed price), which vary from customer to customer.
Reliability of the signature certificates
(What procedures does the solution put in place to determine the reliability of signature
certificates? Are certificate policies checked? Are supervision/accreditation schemes
considered? Have specific security criteria been defined, and does the solution support multiple
levels of reliability? If so, can the solution distinguish between qualified and nonqualified
signature certificates?)
As noted above, a system of six levels of reliability have been defined, which are assessed per
CA depending on the applicable certificate policy, and assigned to the combination of
CA and policy. A particular element is assessment of compliance with national or
international legislation, e.g. that requirements for qualified certificates/ signatures
are met.
Additional elements which could be considered (but currently are not) may be an
assessment of the actor running the CA, e.g. to confirm that the CA is able to fulfil
its liability in case of errors, and the CA’s market share and reputation, e.g. as an
indicator of its chances of survival over time. Other documentation may also be of
relevance, such as certification practice statements and agreements with certificate
holders and other actors (including membership in hierarchies and crosscertification regimes).
It should be noted that the current system is mainly based on assurances provided
by the CA together with assessment of accreditation/surveillance status provided by
national authorities. More advanced approaches, such as the one proposed by the
PEPPOL project, may include an “assurance level” to indicate to what degree an
assessment of actual operation has been done.
Supervision and accreditation schemes are considered, since these are required for
certificates to reach level 4 or above. The VA has two quality levels for qualified
certificates, level 5 and 6, respectively without and with use of SSCD. A signature
produced by use of a certificate at level 6 will be identified as a qualified signature,
provided also that the cryptographic quality fulfils the requirements of the customer
in case.
BBS reserves the right to suspend or degrade a CA whose certificates must be
25
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
considered unreliable due to weaknesses in the quality of the hash algorithm and
size of the key pair used by the CA to sign certificates; thus, the policy of the CA is
not the only deciding factor.
Legal value of the signatures
(Can the solution make a statement on the legal value of signatures? If so, what factors are taken
into account? If multiple degrees of validity are supported by the system (i.e. a statement on the
reliability of the signature as a whole is provided), then how are these ‘reliability levels’ defined
and communicated to the relying party? Can the solution identify if a signature can be considered
a qualified signature (i.e. if it is an advanced electronic signature based on a qualified certificate
created by using a secure signature creation device, as defined in the eSignatures Directive)?
Finally, if the certificate policies contain restrictions on the use of the signatures (e.g. limitation to
transactions of a certain amount or exclusion of certain sectors), then are these restrictions taken
into account when communicating the legal value of the signature?)
As noted above, based on the quality of the certificate, the VA can identify qualified/ nonqualified
signatures as well as mediate other reliability levels. Current version of signature quality
calculation is as follows below – presumably this scheme will in the future be replaced by the
scheme devised by PEPPOL D1.1.
Based on certificate quality, hash algorithm quality, and public key algorithm / key
size, the signature quality level is calculated as follows:
Signature quality = certificate quality + hash algo. quality + public key algo.
and key size quality
This algorithm is amended as follows:
•
If any quality parameter is 0, signature quality is set to 0 regardless of the
values of the other two quality parameters. The signature is considered too
weak to be trusted.
•
If certificate quality level is 6, and both other quality parameters have value 1
or higher, the signature quality shall be set to 20. This value thus indicates a
qualified signature according to the EU Directive.
The acceptance of cryptographic quality 1 for a qualified signature may be
questioned, however the case today is that most qualified certificates use RSA with
1024 bit key size for the end user certificate and most cryptographic toolkits will use
SHA-1 as default hash algorithm. As these algorithms are neither insecure today
nor in the short term, this cryptographic quality is accepted. NIST’s advise on
terminating use of these algorithms by end of 2010 must be interpreted as an
advise to stop using them before they become insecure, i.e. there is a margin with
respect to security.
In the case of the VA, certificate policy limitations on transaction values are
26
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
considered to be overridden by the agreements customer – VA and VA – CA. These
agreements will contain explicit liability caps.
At present the VA does not support limitations regarding applicable community for
certificates. Future development may add support for customer specific
exclusion/inclusion rules (accept or reject certificates from particular CAs regardless
of fulfillment of the general quality requirements), and for CA specific exclusion rules
that can prohibit certain VA customers from being allowed to accep a particular CA’s
certificates.
Liability of the solution provider
(What liability (if any) does the solution provider accept with regard to its services? Specifically, if
the signatures rely on qualified certificates as defined under the European eSignatures Directive
(if this is applicable to the solution), then how does the solution address its liability for providing
guarantees to the public in relation to such certificates?)
Provisions with regard to the liability of the VA are addressed both in the
agreements with the CAs and with the customers.
In the relation with CAs, specific provisions are needed as final liability lies with
them (i.e. the VA assumes interim liability towards its customers insofar as this is
legally required and contractually agreed with the customers, but it should be able to
obtain compensation from the CAs if there was no material error on the VA’s part).
In this way, the VA transfers final liability to the CAs (or other information providers)
if an erroneous answer from the VA is caused by erroneous information from such
actors. To accomplish this, the VA will in most cases need agreements with the CAs
and other information providers, as relying on general statements in a CA’s policy is
too ambiguous and too risky.
In relation with the customers, the VA assumes responsibility insofar as legally
required and insofar as this is demanded by the customer. The VA should ideally
provide a one-stop shopping service, where all relevant liabilities related to
certificate/signature validation are taken on by the VA. However, the VA’s liabilities
must be clearly stated and accepted by its customers, and the cost to a customer
may depend on the level of risk that the VA takes with respect to the customer.
Thus, liability towards the customer can be customized, depending on the
requirements and willingness to compensate for this necessity on the customer’s
side.
Quality of service and availability
27
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
(Does the solution provide any guarantees with regard to the quality of its service (i.e. the
reliability of the information it provides) and its availability to relying parties, other than already
mentioned above?)
As was also the case in relation to liability in general, this can be determined in the specific
agreements with the customers, depending on the requirements and willingness to
compensate for this necessity on the customer’s side.
Independence of the solution
(Is the solution fully unaffiliated (legally unrelated) with all of the CAs that are integrated into the
solution? If not, then how is trust created towards the relying party for affiliated CAs?)
The BBS Validation Authority is fully independent. However, it should be noted that BBS owns the
ZebSign CA, which is supported by the VA. BBS also provides the operational infrastructure for
the Norwegian BankID (at present not supported by the VA), which is owned by Norwegian
banks.
To ensure a neutral quality classification, DNV is used as subcontractor for quality classification
of CAs and their certificates, ensuring equal treatment of ZebSign, BankID and other CAs.
Compliance with the provisions of the eSignatures Directive
(Does the solution support signatures from CAs established in countries that are not subjected to
the provisions of the eSignatures Directive (Directive1999/93/EC)? If so, how are they integrated
and how does the solution address their legal value?)
As noted above, the provisions of the Directive are applied to define and apply the
certificate quality classification system, and thus also to determine the signature
quality.
The quality classification system devised by the PEPOL project in Deliverable D1.1
is able to accommodate CAs in other countries such as the US or Asian countries.
28
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Suitability of the solution at the European level
Assessment of the solution owner
(Does the solution owner feel that the solution could be adapted to operate at the European level
– not applicable if the solution already functions at the European level?)
The VA already functions at the European level.
Issues to be addressed
(Which issues does the solution owner feel would still need to be addressed before the solution
could be made to operate at the European level?)
Actors in the public sector may in many European countries not be allowed to buy validation
services from a commercial provider. While national validation solutions is clearly an alternative,
one should also explore supervision/accreditation schemes for VAs, such as used for qualified
CAs in Europe.
Integration with other validation solutions
(Is there any strategy to allow the solution to interoperate with other validation solutions, i.e. can
the solution connect to other ‘islands of trust’?)
The first strategy is to devise a distribution architecture for the BBS VA itself, where BBS can
have multiple instances of the VA according to customer requirements for localization. These
instances should co-operate rather than being merely clones.
Interoperability with other validation solutions, such as the Spanish national validation service,
may be technically straightforward but may be complicated by legal and commercial issues. BBS
(and DNV at earlier stages) has maintained a good dialogue with other actors on the validation
scene and is in principle interested in co-operation and interoperability.
The XKMS v2 interface specified by PEPPOL D1.1 may provide a standard for cross-validation
interoperability.
29
EFVS Study
Framework contract ENTR/05/58-SECURITY, SC N°14 - SOLUTION PROFILE
July 2009
Market Impacts
(How could the solution impact or influence the European market?)
The main business case for the VA is assumed to be in cross-border B2B scenarios. While
governmental services seem to be much in focus at present, such services are only to a limited
extent cross-border, and the volume of use is less than for B2B. (Note that public procurement,
such as addressed by PEPPOL, is really B2B with the public sector in a ‘B’ – buying – role.)
Enabling e-signatures for B2B transactions across Europe is a bold vision for the VA.
VA services to the general public is an interesting case, e.g. if signed email becomes widely
used. This is not particularly addressed at present.
Any other comments?
(The solution owner can provide any other comments that (s)he feels were not adequately
covered elsewhere)
30