1. No category

PEPPOL eID and eSignature
Validation Pilots
PEPPOL Conference
Malmö, 10th Feb. 2010
Jon Ølnes, Difi (Agency for Public Management
and eGovernment), Norway
... and the rest of the PEPPOL WP1 crew
11. Januar 2017
1
Signature Interoperability
Goals
The Need
11. Januar 2017
2
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)
11. Januar 2017
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)
11. Januar 2017
4
eID/eSignature Interoperability
1. “Front-end” interoperability
Out
scope
of PEPPOL
– actors
sign
inside to
their
– Use
myofcard
everywhere.
Online
service
provider
accept “any” card
Leave this to STORK.
or own
otherinfrastructure.
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
11. Januar 2017
5
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
The Qualified Term
•
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
–
11. Januar 2017
Some uptake in Asia but not globally
7
Non-Qualified
•
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
.....
11. Januar 2017
8
Signatures and eIDs:
Validation vs acceptance
• 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
11. Januar 2017
9
PEPPOL
Pan-European Public
Procurement On-Line
http://www.peppol.eu
The Project
11. Januar 2017
10
Scope of Work, Work Packages
Payment
eInvoicing (WP 5)
eOrdering (WP 4)
Post Award
Procurement
eCatalogues (WP 3)
Virtual Company
Dossier (WP 2)
Pre Award
Tendering
eSignature (WP 1)
Open Infrastructure (WP 8)
11. Januar 2017
Project Management (WP 6)
Awareness, Training, Consensus Building (WP7)
11
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
11. Januar 2017
12
PEPPOL eSignature
Interoperability
Public Procurement as a Case Study
11. Januar 2017
13
The Public Procurement Directives
Note: Cover tendering only
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
“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.”
11. Januar 2017
14
Other Procurement Processes
• 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
11. Januar 2017
15
Paper-Based E-signature Paradigm
• 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)
11. Januar 2017
16
PEPPOL Deliverable D1.1
•
Functional specifications for cross-border use of
eSignatures in public procurement – 7 parts:
1. Background and Scope
2. E-tendering Pilot Specifications
3. Signature Policies
4. Architecture and Trust Models
5. XKMS v2 Interface Specification
6. OASIS DSS Interface Specification
7. eID and e-Signature Quality Classification
http://www.peppol.eu/deliverables/wp-1
11. Januar 2017
17
Signature Policies (1)
Commitment Rules and Protocols
•
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
11. Januar 2017
18
Signature Policies (2)
Signature Validation Policy
•
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
•
11. Januar 2017
E.g. not just a list of accepted CAs – today’s usual situation
19
Pragmatic approach
•
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
•
•
11. Januar 2017
PEPPOL is largely about automated system-system interactions
Procedural rules must be transparent and may be processable
20
Procedural Rules, PEPPOL
•
•
•
•
•
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
Sending side must comply with these
11. Januar 2017
21
Rich Service Interfaces
•
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
•
•
11. Januar 2017
Not necessary to send document content
Returns overall assertion on document and individual assertions on
each signature and certificate
22
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
Federated Validation Services
Trust status
list service
…
Qualified CAs
Other CAs
OCSP (or CRL)
XKMS
Signer’s CA
Validation
Service
…
Validation
Service
XKMS or
OASIS DSS
Response signed
by ”local” VS
Signer
Country 1
Receiver
Country 2
11. Januar 2017
24
Validation Service vs Authority
•
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
•
•
11. Januar 2017
Very important for scaling – globally and not only Europe
May be very important for non-qualified eIDs/eSignatures
25
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
11. Januar 2017
26
Piloting eSignatures
11. Januar 2017
27
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
11. Januar 2017
28
Current Test Pilot
TeleSec
TC-Trust
Bundesnotarkammer
Commfides
Buypass
InfoCert
Certigna
BANQUE POPULAIRE
Actalis
LISIT
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
11. Januar 2017
32
Quality Classification of
eIDs and eSignatures
Basis for signature policies
11. Januar 2017
33
What can be Objectively
Verified at Receiving Side?
•
Signer’s environment
–
–
•
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
–
–
•
Only to the extent described by the certificate policy
E.g. use of SSCD or not
Hash algorithm
Public key algorithm and key size
Receiver should not be forced to read certificate policies or
examine trust status lists
11. Januar 2017
34
Certificate Policy:
Claimed Quality of Certificate
6: QCP+ – qualified signature level
5: QCP – qualified certificate but not qualified signature
(4+: NCP++ – NCP with certified SSCD)
4: NCP+ – highest available for authentication and legal persons
3: NCP
2: LCP
1: Low but policy exists or other assessment possible
0: Very low or not assessable (e.g. no policy exists)
•
All policy indications are “or similar” to accommodate nonEuropean certificates (e.g. map FBCA levels)
• Januar Could
add more levels if desired .....
11.
2017
35
Certificate Quality Classification
Documentation
Does a Certificate
Policy exist?
No
Can quality be
assessed by other
means?
Yes
No
0,y
Yes
1,y
Evaluation
Evaluation of
CP/CPS
Is the CP
compliant with
standard for QCP
or similar?
No
Is the CP
compliant with
standard for NCP
or similar?
Yes
No
Is the CP
compliant with
standard for LCP
or similar?
Yes
No
Yes
2,y
Is the use of certified
SSCD mandated?
eID quality levels: 0-6
No
3,y
Yes
4,y
Is the use of certified
SSCD mandated?
Yes
11. Januar 2017
6,y
No
5,y
Note:
y=INTEGER(0,7)
defining the level of
independent assurance in
determining the certificate
quality levels
36
Certificate Assurance Level
and Legal Status
7: Accredited – external compliance audit
6: Supervised – external compliance audit
5: External compliance audit and certification
4: External compliance audit
3: Supervision without compliance audit
2: Internal compliance audit at CA
1: Independent document review
0: Self-assessment only
•
•
6-7 is the European regime for qualified certificates
Reuse assessments done in conjunction with FBCA, SAFE
and others
11. Januar Bridge-CA
2017
37
Quality Classification – Assurance
Documentation
Accreditation
w/ external compliance
audit?
No
Yes
x,7
Supervision
w/ external compliance
audit?
No
Yes
x,6
External
compliance audit and
certification?
No
Approval status levels: 0-7
Yes
x,5
External
compliance audit?
No
Yes
x,4
Supervision
(without external
compliance audit)?
No
Yes
Internal
compliance audit?
No
11. Januar 2017
Note:
x=INTEGER(0,6)
defining the quality level of certificates as claimed
by the CA through the Certificate Policy.
x,3
Yes
x,2
Independent
document review?
Yes
No
x,0
38
x,1
Quality Classification – Crypto
•
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
•
•
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. MD5 hash
E.g. SHA-224, RSA-2048
Quality 3-5: Increasing levels of security
11. Januar 2017
39
Signature Quality
•
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)
•
•
11. Januar 2017
1: RSA-1024
2: RSA-2048
40
Conclusions
•
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!
11. Januar 2017
41
Contact
Further information can be obtained from the regional
contact points below and at http://www.peppol.eu
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, Romania
please contact:
Mr. Giancarlo DE STEFANO
Email: giancarlo.destefano@tesoro.it
Belgium, Germany,
Luxembourg, Netherlands
please contact:
Ms. Maria A. WIMMER
Email: wimmer@uni-koblenz.de
11. Januar 2017
42
Contact for presenter
Jon Ølnes
Senior Advisor
National Programme for eID Infrastructure in Public Sector
Difi – Agency for Public Management and eGovernment
P.O.Box 8115 Dep, N-0032 Oslo, Norway
http://www.difi.no
jon.olnes@difi.no
+47 478 46 094
11. Januar 2017
43