eID-Validation, e-Signature Verification

The amount of user interactions being conducted via the web is ever-increasing in the drive to provide efficient and cost-effective services to customers, employees, partners, citizens etc.

However communicating over the internet requires trust in the electronic identity (eID) of the transacting parties. Only after such trust is established should access be granted to online systems and web-based resources, and only then should digitally signed agreements be accepted with confidence.

The use of PKI-based digital certificates is a long-accepted technique for managing electronic identities. It forms an essential element in securing communications channels within protocols such as SSL/TLS and IPSEC. Digital passports and citizen eID cards with embedded digital certificates that confirm the identity of the holder are becoming more common.

All these digital certificates need to be validated by relying parties since they may have been compromised or revoked after issuance. They also need to be checked because there may be a range of certificates issued by different issuers under different security policies to meet different trust levels. Deciding which digital certificates to trust can be a complicated task.

With regards to verification of e-signatures the complexities increase even further. There are many different signature and document formats, multiple ways of applying countersignatures, determining whether the signer was authorised to sign, historical verification of signatures, etc.

Ascertia provides products and solutions that answer these questions and remove the entire complexity of signature verification, certificate validation and trust management from business applications. Ascertia products and solutions are used internally with an organisation and by Managed Service Providers offering global verification services to multiple customer organisations.

SOLUTION DESCRIPTION

Data received from customers, suppliers, partners, Governments and financial and legal institutions that have signatures attached should be verified immediately on receipt to ensure that trust can be established and audit trails kept.

Signature Verification

Signatures may be in a variety of formats including PDF, XML or PKCS#7/CMS. Documents may also be in various formats and include multiple signatures.

E-Invoicing and E billing Statements

Used in this way ADSS Server can act as a pre-processor for existing business systems – checking that the data can be automatically processed or flagging via the business application that human intervention is required to resolve the trust issues found. Information can be returned from ADSS Server to the application showing the trust, quality status and other data from the digital signatures.

Systems that receive signed regulatory reports, e-invoices, orders, tender documents, etc need such a system to flexibly review and trust the signatures from various trust schemes.

Once the business application receives the signed data it can request ADSS Server to verify the signatures and establish the trust status for each of these. If they are good then automatic processing can be established with archived evidence of the verification process. If the signatures are unacceptable then the document can be filtered out for separate review.

Why Ascertia?

Verification / Validation Requirements

ADSS Server

Other Products

Can the solution process PDF, XML, S/MIME and other PKCS#7 and CMS signed documents?

Yes

Often limited to one or two formats

Can the solution handle basic signatures, timestamped signatures, long-term signatures, PDF certified signatures?

Yes

Usually a limited ability to cover this

Can the solution handle ETSI XAdES, CAdES and PAdES signed documents with support for multiple extended signature formats?

Yes

Often a limited capability

Does the solution allow the organisation to easily define the trust anchors (Root CAs and Issuer CAs) that are trusted?

Yes

Often limited to Windows trust lists

Can the solution verify multiple signatures in a single call and return information on each of the signers?

Yes

Detailed information is rarely returned

Does the solution support OASIS DSS protocol and DSS-X Verification Reports with the ability to offload application from complex coding?

Yes

A limited capability at best

Can the solution check both current and historic signatures and after a grace period, using a specified time in the past?

Yes

Historic signatures are rarely handled

Can basic signatures be enhanced to long-term signatures (CAdES and XAdES) as part of the verification process?

Yes

Usually a limited ability to cover this

Can the solution keep old CRLs from each trusted CA so that these can be used to check the signature status in the past?

Yes

Rarely seen

For long-term signatures can the solution automatically use the embedded CRL/OCSP information if valid?

Yes

Often a limited capability

Does the solution have effective role based access security controls and maintain protected event and transaction logs?

Yes

Check carefully this is rarely seen!

Can a high availability load-balancing configuration be immediately deployed? On platforms other than Windows? and supporting a range of HSMs?

Yes

Most have issues being this flexible!

Can CRLs, OCSP, XKMS or even SCVP services be used to check the signer’s status? Can a sophisticated validation policy be configured to define the order in which these mechanisms are used, and how to locate and communicate with the back-end status providers?

Yes

CRL is common OCSP is rarer Support for XKMS and SCVP is very unusual

Can a copy of the original document be kept within the solution’s transaction logs as evidence?

Yes

Usually a completely separate action

Can a notary archive action be associated with the verification action such that a long-life archive signature and timestamp are applied within an LTANS compliant archive? Is a TSA and LTANS service provided as part of same product?

Yes

Usually a completely separate project or product Support for LTANS very unusual

Verification / Validation Requirements

Yes

Usually a completely separate project or product

Is there a solution option for extracting and sending only the signatures from documents to ensure privacy at the relying customer? I.e. is a gateway type product provided?

Yes

Most have issues being this flexible

Is the solution designed to be used by both end-users, business relying parties and managed service providers?

Yes

Often a limited capability

Does the solution provide detailed logging of each transaction, the evidential information & filtering/searching?

Yes

Often a limited capability

Does the solution provide an in-built capability for service reporting (detail and summary reports)?

Yes

Often a limited capability

Can the calling client applications be authenticated using request signing and/or SSL client certificates? Can these clients be limited to only use specific signature verification profiles?

Yes

Most have issues being this flexible

Can the solution provide a standard based approach to providing quality information on the signature algorithms, key lengths, hash algorithms and certificates associated with the signature and whether these meet the minimum local security policy requirements of the relying party? E.g. are the PEPPOL specifications supported?

Yes

Rarely seen

Does the solution provide a Client SDK for Java and .Net environments plus source code samples and example applications to make integration really simple?

Yes

Worth checking

Can the solution be created on Windows, Solaris and Linux platforms with support for 32 and 64 bit processing?

Yes

Worth checking

Are various FIPS 140-2 level 3 or CC EAL4 HSMs supported?

Yes

Worth checking

Is an effective security management environment maintained that protects the authentication mechanisms, the verification policies, the validation policies, the keys, certificates, operator and system event logs and the transactional logs? Is it compliant with CWA 14167-1 Requirements for Trustworthy Systems?

Yes

Worth checking

ADSS Server enables organisations to check transactional validity at the server. Some people advise allowing the end-user to determine if the data is to be trusted, however Ascertia does not recommend this approach – if the data cannot be trusted then why present it to busy managers?
As can be seen ADSS Server has been designed to cope with a changing e-business world in which multiple document formats will be used, with multiple signature formats and other properties. Although requirements may seem clear now there is usually a clear need for investment protection so that changing business requirements do not lead to a project being scrapped and restarted because of a lack of flexibility.
ADSS Server was selected as the core technology of the DNV Validation Authority Service (http:/www.dnv.com) after an open global tender – our approach and product functionality and flexibility was our key to success. BBS (http://www.bbs.no) now runs this service and has renamed it as the Global Verification Service.

Ascertia is a global leader in high-trust PKI and digital signature products, delivering essential trust services that keep citizens secure and business flowing. Ascertia’s products are easy to integrate and use across a range of business scenarios.

Ascertia is a global leader in high-trust PKI and digital signature products, delivering essential trust services that keep citizens secure and business flowing. Ascertia’s products are easy to integrate and use across a range of business scenarios.