22. April 2023 1

Jon Ølnes, Difi (Agency for Public Management and eGovernment), Norway... and the rest of the PEPPOL WP1 crew

PEPPOL eID and eSignature Validation Pilots

PEPPOL ConferenceMalmö, 10th Feb. 2010

22. April 2023 2

The Need

Signature Interoperability Goals

Interoperability – ultimate goals

• Goal of eID holder: Sign towards any relying party using a single eID (or the eID of own choice)

• Goal of relying party: Accept all signatures with assessed risk regardless of eID issuer

• Additional goal: Allow any other party to verify signatures (e.g. an auditor)

22. April 2023 3

Signatures and protocols

• Why sign?– Legal/regulatory requirements – mandatory to sign– Risk management decision – security, traceability– Signature protects against your legitimate counterpart

• Business protocol level– Signature in WP1 is a business protocol element– End-to-end between the communicating partners– The transport infrastructure is agnostic to signatures

• Signing binds to content and format– Format conversion kills signatures– Workaround: Send both original, signed format + format

after conversion (not recommended)

22. April 2023 4

22. April 2023 5

1. “Front-end” interoperability– Use my card everywhere. Online service provider to accept “any” card

or other suitable ID token

2. “Back-end” interoperability– Receiver (relying party) shall be able to validate and accept signatures

and eIDs from all relevant counterparts, no matter the eID issuer of the counterpart. Not “on-line”, rather asynchronous, message passing protocols.

3. Other parties: Verification of signed documents may (later) be required by parties not involved in the signing process– Not explicitly in scope of PEPPOL but ensure sufficient information is

available

eID/eSignature Interoperability

Out of scope of PEPPOL – actors sign inside their own infrastructure. Leave this to STORK.

Interoperability business case

• Real world interoperability happens if there is a business case• A technical solution in a pilot is not enough

• Deploy solutions targeting the business case• Public procurement is a good business case• PEPPOL as a pilot fuels the business case

• Make the solution applicable across other areas• “Long tail” market etc.

The real world challenge:

ALL TRUSTED ROLES MUST HAVE A SOUND BUSINESS MODEL

Government funding is one possible model

Commercial viability is the only alternative

22. April 2023 7

• Common legal framework across Europe– Qualified signature shall have a guaranteed legal value– Qualified eID has a particular status as supervised/accredited even when

not used for qualified signatures– European-wide interoperability intended – at least for qualified signatures

but preferably also for qualified eIDs– Quality: ETSI TS 101 456 QCP/QCP+ not mandatory but in practice always

used

• Qualified certificate only for signatures (?)– Some (but not all) countries: Only to be used for signing, certificates for

other purposes cannot be marked as qualified– What about certificates for authentication and encryption?

• Only European– Some uptake in Asia but not globally

The Qualified Term

22. April 2023 8

• No common legal framework, not even in Europe– Refer to certificate policy and thus national law of the eID issuer– Or establish an agreement-based system – contract law– (CROBIES suggests to expand scope of eSignature Directive)

• Certificates from outside of Europe• Certificates for other purposes than signing• Certificates issued to legal (not physical) persons• Non-qualified, lower quality eIDs in or outside Europe• Corporate PKIs and the like• .....

Non-Qualified

22. April 2023 9

• Signature and eID validation (cryptography, technical)– Complex cross-border in Europe (scaling) but achievable

• Signature and eID acceptance• Acceptance criteria: Legal/regulatory requirements and/or risk

assessment– eID quality sufficient?– Approval status (national/international) of eID?– Cryptographic quality sufficient?– Possibly other elements (quality of the CA itself and its owners?)– Not possible to assess using only “traditional PKI” elements

Signature policies to define acceptance criteria – quality being the main issue

“Rich validation interfaces” to assess policy fulfilment

Signatures and eIDs:Validation vs acceptance

22. April 2023 10

The Project

PEPPOLPan-European Public Procurement On-Linehttp://www.peppol.eu

22. April 2023 11

Scope of Work, Work Packages

Pre AwardTendering

Post AwardProcurement Payment

Open Infrastructure (WP 8)

eSignature (WP 1)

eC

ata

log

ues (

WP

3)

eO

rderi

ng

(W

P 4

)

eIn

voic

ing

(W

P 5

)

Vir

tual C

om

pan

y

Dossie

r (W

P 2

)

Project Management (WP 6)Awareness, Training, Consensus Building (WP7)

22. April 2023 12

High level project plan

• May 2008 – April 2009: Requirements and design

• May 2009 – April 2010 (or a bit later): Implementation

• May 2010 – November 2011: Pilots running

• Must take a rather pragmatic approach to make things work

in this time frame

• EU Commission points at PEPPOL as a promising approach

for e-signature interoperability across Europe

22. April 2023 13

Public Procurement as a Case Study

PEPPOL eSignature Interoperability

22. April 2023 14

The Public Procurement DirectivesNote: Cover tendering only

“Directives oblige any public purchaser in the EU to effectively recognize, receive and process tenders submitted, if required, with a qualified signature and their accompanying certificates, regardless of their origin within the EU or their technical characteristics”“The existing significant differences between qualified signatures …. should therefore be reason for great concern. The interoperability problems detected despite the existence of standards …. pose a real and possibly persistent obstacle to cross-border e-procurement.”

Qualified signatures not available in all member states and use limited in many member states.

And qualified is a European term.

And not all eIDs will be qualified even in Europe

22. April 2023 15

• Public Procurement Directives cover tendering only

• Service Directive requires e-signatures• E-invoicing – e-signature primary mechanism

• Can be avoided (“EDI Clause” of VAT Directive) if other mechanisms are guaranteed to provide authenticity and integrity end to end

• Can e-signatures be avoided in the PEPPOL case?• Note: European e-invoicing landscape is changing

• Order process, catalogue etc. not covered by EU defined legal requirements for e-signature

• May be national, legal requirements

Other Procurement Processes

22. April 2023 16

• Qualified eID must be issued to a natural person– Only a person can produce a qualified signature

• But e-invoices are usually not signed in a user interface– Personal signature is a problem

• An e-signature binds to the name in the eID– Why does that name have to be a person name?– E.g. corporate signatures on e-invoices (person is not relevant)– What about automated orders/invoices between systems with no

person involved?

• But we are largely stuck with personal signatures in Europe– Possible compromise: Inner, personal signature, outer corporate

signature (e.g. invoice issuer)

Paper-Based E-signature Paradigm

22. April 2023 17

• Functional specifications for cross-border use of eSignatures in public procurement – 7 parts:

1. Background and Scope2. E-tendering Pilot Specifications3. Signature Policies4. Architecture and Trust Models5. XKMS v2 Interface Specification6. OASIS DSS Interface Specification7. eID and e-Signature Quality Classificationhttp://www.peppol.eu/deliverables/wp-1

PEPPOL Deliverable D1.1

22. April 2023 18

• Commitment rules – binding of person names to enterprises, roles and authorizations

• Alternative 1: Accept signed documents (optimistic approach)• Alternative 2: Registration procedure to establish bindings• Alternative 3: Virtual Company Dossier (VCD) and attestations• Alternative 4: Corporate eID (not acceptable in many countries)• Alternative 5: Employee eID (not widely deployed)• Alternative 6: Inner personal + outer corporate signatures (requires

solutions for issuing of corporate eIDs)• Business protocols

• Which documents shall/should/can be signed in an eCommerce protocol?• Implications of these signatures – might be from authentication and

integrity protection to a legally binding offer or contract• Adding signatures to business protocol specifications

Signature Policies (1)Commitment Rules and Protocols

22. April 2023 19

• Signature validation policy elements (ETSI TR 102 038)• Rules to be followed by signer• Rules to be followed by verifier• Rules for use of certification authorities (CA)• Rules regarding time stamps and TSAs (Time Stamp Authority)• Rules on use of AAs (Attribute Authority)• Rules on use of algorithms

• Quality and procedural requirements for these elements• Receiver (relying party) sets policy requirements

• May be determined by legislation/regulations• Transparent, non-discriminatory rules needed

• E.g. not just a list of accepted CAs – today’s usual situation

Signature Policies (2)Signature Validation Policy

22. April 2023 20

• Signature policy according to ETSI• Shall have a unique OID (Object Identifier)• Always in human readable form• Parts may be machine processable

• According to PEPPOL (pragmatic due to pilot scope)• Define the relevant parts, not necessarily complete• Never mind the OID• Quality parts must be made machine processable

• PEPPOL is largely about automated system-system interactions

• Procedural rules must be transparent and may be processable

Pragmatic approach

22. April 2023 21

• Signature formats (SDO – Signed Data Object)• Few requirements on sender, receiver must cope• Longer term: XAdES/CAdES/PAdES (lack software support at present)• Include certificates, possibly path, in SDO

• Requirements for signature verification process• Define certificate validation process (path validation etc.)• Revocation checking at receiver, no OCSP required from sender

• Requirements for quality and approval status of eIDs and eSignatures• Do not use a TSA on sending side! Receiver may use Time Stamp Auth.

• Sending side TSA means a huge interoperability problem on mutual recognition of TSAs across Europe – role not defined in all MSs

• Logging, archival, records creation• Local matter to receiver – information must be available

Procedural Rules, PEPPOL

Sending side must comply with these

22. April 2023 22

• Certificate validation: Profile of XKISS part of XKMS v2• Based on German profile• Returns assertion on certificate(s)• Quality assertions• Procedural rules (path validation, revocation checking)

• Entire, signed document: Profile of OASIS DSS validation• Based on earlier work in Norway • Whole signed document or pairs of signatures and hash values

• Not necessary to send document content

• Returns overall assertion on document and individual assertions on each signature and certificate

Rich Service Interfaces

Interoperability levels

• Legal interoperability - ensure legal acceptance across borders– Qualified eID/signature, agreements based, policy based– Qualified is not non-discriminatory today since not available in all MSs

• Organisational interoperability– Use of signatures in (business) processes– Binding to (organisational) roles and authorisations– Signature acceptance (quality etc.) criteria– Business process standards/specifications, (business) registers or attribute

certificates, standard/transparent risk management criteria and quality assessments

• Semantic interoperability– Making use of names and identifiers– Alignment/standardisation, normalisation, translation, identity management

• Technical interoperability– Signature processing requirements– Formats, communication protocols, interfaces, algorithms– Standardisation

22. April 2023 24

Signer

XKMS or OASIS DSS

Country 1 Receiver

ValidationService

ValidationService

Signer’s CA

Federated Validation Services

Country 2

XKMS

OCSP (or CRL)

Trust status list service

…

…Qualified CAs

Other CAs

Response signed by ”local” VS

22. April 2023 25

• Service: Process eIDs (and signatures), issue assertion, responsible only for its own actions

• Assertions are validation responses• Refer to CAs (their policies and national laws) for liability• Sufficient for qualified level (?)

• Authority: Independent liability for validation assertion• Assertions are authority statements• One trust anchor for the relying party• Uniform liability for all eIDs of same quality• From national law (of the CAs) to contract law

• Very important for scaling – globally and not only Europe• May be very important for non-qualified eIDs/eSignatures

Validation Service vs Authority

22. April 2023 26

Validation Service vs Local

• VS used to handle all eID issuers that are not handled locally• Tune this as desired from 100 % locally to 100 % by VS

• Pure add-on to existing solutions• Add a VS interface to handle all not handled locally

• VS may issues “external” validation assertion• An advantage in some cases even for “local” eID issuers

22. April 2023 27

Piloting eSignatures

Pilots scheduling

• 1st May 2010 – ready for test pilots– XKMS responders from bos (Bremen Online Services)– “National” responders for some countries– Request chaining

• Autumn 2010 – until production pilots 1st November– Expanding the above to more countries and CAs– Planned addition of commercial validation service and the

OASIS DSS interface

• Until end October 2011– Testing, refinement, further development

22. April 2023 28

Current Test Pilot

Certigna

BANQUE POPULAIRE

TeleSec

TC-Trust

Bundesnotarkammer

InfoCert

Actalis

LISIT

Commfides

Buypass

XKMS Responder• The XKMS responder was delivered to partners end of

January by Bremen Online Services• This is version 0.9 (test pilot version)

– Software components/libraries (workshop on January 27th)– VMWare Image (DVD)

• Configuration according to documentation was done by bos• Example: the German responder:

http://212.48.116.113:8080/PeppolWebAdmin/WebAdmin • Version 1.0 will be delivered by May 1st 2010 for production

pilot

Validation Software

• First version of validation software client is available from Bremen Online Services

• PEPPOL Signer 2.2.0.0– Certificate validation via XKMS responders – HTML inspection sheet – Handling of signatures: PKCS#7 detached and enveloped

and PDF inline– German qualified signatures

• Next version with XAdES support by end of march

Need real pilot cases

• Co-operate with PEPPOL WP3-5 on signed orders, order confirmations, invoices, catalogues

• Ongoing co-operation with PEPPOL WP2 on signatures for VCD (Virtual Company Dossier)

• Need to test signed tenders due to the EU Directives on public procurement

22. April 2023 32

22. April 2023 33

Basis for signature policies

Quality Classification of eIDs and eSignatures

22. April 2023 34

• Signer’s environment– Only to the extent described by the certificate policy– E.g. use of SSCD or not

• Quality of certificate– Described by certificate policy (possibly also CPS etc.)

• Assurance – is CA operation compliant with its policy?• National (international?) approval status

– E.g. is the CA listed as supervised issuer of qualified certificates?

• Cryptographic quality– Hash algorithm– Public key algorithm and key size

• Receiver should not be forced to read certificate policies or examine trust status lists

What can be ObjectivelyVerified at Receiving Side?

22. April 2023 35

6: QCP+ – qualified signature level5: QCP – qualified certificate but not qualified signature(4+: NCP++ – NCP with certified SSCD)4: NCP+ – highest available for authentication and legal persons3: NCP2: LCP1: Low but policy exists or other assessment possible0: Very low or not assessable (e.g. no policy exists)

• All policy indications are “or similar” to accommodate non-European certificates (e.g. map FBCA levels)

• Could add more levels if desired .....

Certificate Policy:Claimed Quality of Certificate

22. April 2023 36

Certificate Quality Classification

Does a Certificate Policy exist?

Is the CPcompliant with

standard for NCPor similar?

Can quality be assessed by other

means?

Is the use of certified SSCD mandated?

Evaluation of CP/CPS

Documentation

Yes

No

No

No

No

Yes

Yes

No

Yes

Evaluation

No

Yes

Is the CPcompliant with

standard for QCPor similar?

Is the CPcompliant with

standard for LCPor similar?

Is the use of certified SSCD mandated?

Yes

6,y

No

Yes

5,y

4,y

3,y

2,y

1,y

0,y

Note:y=INTEGER(0,7) defining the level of independent assurance in determining the certificate quality levels

eID quality levels: 0-6

22. April 2023 37

7: Accredited – external compliance audit6: Supervised – external compliance audit5: External compliance audit and certification4: External compliance audit3: Supervision without compliance audit2: Internal compliance audit at CA1: Independent document review 0: Self-assessment only

• 6-7 is the European regime for qualified certificates• Reuse assessments done in conjunction with FBCA, SAFE Bridge-CA

and others

Certificate Assurance Leveland Legal Status

22. April 2023 38

Quality Classification – Assurance

Accreditationw/ external compliance

audit?Documentation

Supervisionw/ external compliance

audit?

Externalcompliance audit and

certification?

Externalcompliance audit?

Supervision(without external

compliance audit)?

Independentdocument review?

Internalcompliance audit?

x,7

Note:x=INTEGER(0,6) defining the quality level of certificates as claimed by the CA through the Certificate Policy.

x,6

x,5

x,4

x,3

x,2

x,1

x,0

Yes

Yes

Yes

Yes

Yes

Yes

Yes

No

No

No

No

No

No

No

Approval status levels: 0-7

22. April 2023 39

• Cryptographic Quality• Hash quality for signatures (note: controlled by signing software)• Public key algorithm and key length quality• Based on recommendations from ETSI, NIST and other sources

• Quality 0: Inadequate – should not be trusted• E.g. MD5 hash

• Quality 1: Reasonably secure for 3 years• E.g. SHA-1 hash, RSA-1024

• Quality 2: Regarded as trustworthy for 5-10 years• E.g. SHA-224, RSA-2048

• Quality 3-5: Increasing levels of security

Quality Classification – Crypto

22. April 2023 40

• eID quality (0-6)• 6: Qualified signature policy level• 5: Qualified certificate policy level

• eID assurance level (0-7)• 6-7: Supervised/accredited eID issuer

• Hash algorithm quality (0-5)• Controlled by signing software, not by eID issuer• 1: SHA-1 hash (up to 3 years perspective)• 2: SHA-224 (5-10 years perspective)

• Public key algorithm and key length quality (0-5)• 1: RSA-1024• 2: RSA-2048

Signature Quality

22. April 2023 41

• Public procurement is really B2B scenario• With public agency in “B” role

• Signatures required – validation and acceptance needed• Cryptographic validity• Signature policy adherence

• Names -> organization, roles, authorizations• What must be signed?• Signature formats and verification rules• Quality and assurance (approval status) requirements

• Trust models for validation “proofs”• Standards based interfaces – should be standardised• Quality classification scheme – should be standardised• Can we solve this scenario, we are near a general solution!

Conclusions

22. April 2023 42

Contact

Denmark, Estonia, Finland, Ireland, Iceland, Ireland

Lithuania, Latvia, Norway, Sweden, UK/Scotland

please contact:Mr. André HODDEVIK(Project Director)

Email: andre.hoddevik@peppol.no

Austria, Czech Republic, France, Hungary, Poland, Slovakia,

Slovenia, Switzerland and Western Balkan

please contact:Mr. Peter SONNTAGBAUER(Public Relation Director)

Email: peter.sonntagbauer@brz.gv.at

Bulgaria, Cyprus, Italy, Greece, Malta,

Portugal, Spain, Romaniaplease contact:

Mr. Giancarlo DE STEFANOEmail:

giancarlo.destefano@tesoro.it

Belgium, Germany, Luxembourg, Netherlands

please contact:Ms. Maria A. WIMMER

Email: wimmer@uni-koblenz.de

Further information can be obtained from the regional contact points below and at http://www.peppol.eu

22. April 2023 43

Jon ØlnesSenior AdvisorNational Programme for eID Infrastructure in Public SectorDifi – Agency for Public Management and eGovernmentP.O.Box 8115 Dep, N-0032 Oslo, Norway

http://www.difi.no jon.olnes@difi.no +47 478 46 094

Contact for presenter