View
3
Download
0
Category
Preview:
Citation preview
Meeting practicalities
• Meeting will be conducted in Norwegian /Nordic language
• Main part of the meeting material will be provided in English
• Presentation from the meeting will be uploaded at https://dfo.no/kurs/339847
• There will be no meeting-minutes provided after the meeting
• Meeting participant will be muted during presentations
• Please use the chat for comments, concerns or questions
• Questions raised in the chat will be consolidated and answered in writing after
the meeting if not addressed directly at the meeting
• Additional questions can be submitted after the meeting to
peppolmyndighet@dfo.no
• Meeting will be recorded for internal Peppol Authority purposes only
Agenda
• Welcome and practicalities - Wenche Ludviksen Sæther, DFØ
• Foreseen changes in the governance of the domain - Anna-Lis Berg, DFØ
• National eDelivery Architecture Advisory Board - Rune Kjørlaug, DFØ
• Next version of Bits MIGs ISO 20022 - Hanne Margrethe Sandernes, Bits
• Updates on Security Requirements - Andreas Havsberg, Bits
• CertPub update - Erlend Klakegg Bergheim, DFØ
• ELMA update - Espen Kørra, Digitaliseringsdirektoratet
• Questions and open floor discussion on the topics - facilitated by Wenche Ludviksen Sæther, DFØ
• Any other businesses, - Wenche Ludviksen Sæther, DFØ
Presentation of speakers
• Anna-Lis Berg, Norwegian Peppol Authority Lead, DFØ
• Wenche Ludviksen Sæther, Peppol Authority Coordinator, DFØ
• Rune Kjørlaug, Enterprise Architect, Avdeling for digital transformasjon, DFØ
• Hanne Margrethe Sandernes, Principal Advisor, Bits
• Andreas Havsberg, Principal Advisor, Bits
• Erlend Klakegg Bergheim, Senior Advisor, DFØ
• Espen Kørra, Digitaliseringsdirektoratet
Overview of foreseen changes to domain governance
• Implementation of a decentralized steady state environment for ePayment domain governance
- Less DFØ ANS ATS involvement in D2D activities
- Standardized procedures for collaboration & Communication with the Peppol Authority
- Peppolmyndighet@dfo.no as contact address to the Peppol Authority and DFØ ANS ADT
• Implementation of a decentralized governance structure in the Norwegian Peppol network
- Separation of duty for support , maintenance and further development of ISO 20022, Peppol eDelivery,
CertPub & ELMA
• Implementation of revised agreement framework in the Peppol Network
- Revised requirements to national domains
- Revised requirement to Peppol service providers
- Revised status of ELMA as national SMP
• Establishment of a separate governance environment for CertPub
Roadmap & timeline for changes
7
1/10 1/11 1/12 1/1 1/2 1/3 1/4 1/5 1/6 1/7 1/8 1/9 1/10 1/11 1/12 1/1 1/2 1/3 1/4
2020 2021 2022
Awaiting Peppol
Revised Peppol Service provider Agreements
Prep and planning Implementation _interim
set-up
Institutionalization of the PA Operation & decentralization of Domain governanceoperation _Interim set up Institutionalisation – to Steady state
Setady state operation/ ready to be handed
over
Migration to new Agreements
Revision of the Domain Governance model
Formalized Agreement for delegated domain leadership
Revision of the Steady state environment
Project mode transformationSteady state Phase 1- allined toTIA
requirementsstrategic alignment
to New Agreement Steady state phase 2
Identify Domain
leaderDefine & implement interim model Interim operation & governance Adjust and align
Define T&C Re evaluate T&CSign
DOU
Sign
agreementDev Agreement
Consul-
tation
Clarification on terminology
• ePeppol
- the name used for the project in the past
- Will not be used in OpenPeppol or by the Peppol Authority
• ePayment
- The name used as working title by OpenPeppol in the Past
• Norwegian Peppol Payment
- Domain name to be used going forward as label for the Peppol Domain
- status as National domain in Norway only
• Peppol
• Name of the specifications and of the network
• OpenPEPPOL
- The Asociacion owning and maintaining the Peppol network and specification
• Norwegian Peppol Authority /Peppolmyndighet
- National governance organisation for use of Peppol specification and Network
NATIONAL E-DELIVERY ARCHITECTURE ADVISORY BOARD
RUNE KJØRLAUG, DFØ
National eDelivery architecture
advisory board
Architecture advisory board?
(Enterprise) Architecture is the craft of identifying, assess impact and recommend solutions for change (to the enterprise).
The architecture advisory board is set up to advise the National Peppol Authority in Norway (DFØ) on eDelivery network
specific issues, such as:
- Assess impact of proposed changes to the overall eDelivery network to our national or domain specific use of the network
- Suggest how to respond to and implement new requirements from new or existing national domains. What requirements or functionality
should be implemented in the domain, as national cross domain services (common services), as national cross domain patterns (same
pattern, domain hosted services), as changes in the eDelivery network itself or in last instance, not possible to solve within PEPPOL.
- Suggest how to respond to and implement new requirements in regards of the EIF layers. Not everything has to be resolved in the
technical layer!
- Assess maturity of national common services and patterns – when are they ready to be proposed as new eDelivery features.
- Identify possibilities and potential of reusing domain specific shared services and identify how to align requirements to such solutions
cross-domain.
- Identify possibilities and potential of reusing domain security mechanisms and identify how to align requirements to those cross-
domain.
Interoperatbility governance with
OpenPeppol Governance
Architectural framework
Agreementframework
Message and network specifications
National Governance
PA Agreement
Service providers
SP Agreement
Peppol authorityNational coordination
Cross Domain Stakeholder fora
Shared national components
National Architecture
E-procurement fora
eDeliveryPost-Award
Domain specific Development, Governance & Support
ePayment eGovernment
EHF, processes
Domain user fora
ISO 20022, rulebook
Domain user fora
TBA?
OpenPeppol governed domain
“incubator” domain, governance delegated
Commercial Agreement
You
Output and organization
The advice given from the advisory board should be in the form of actions like:
- Recommendation on which fora(s) that should solve or be involved in solving the issue.
- Concrete changes needed to be done to specifications, agreements or services.
- Alternative routes to resolve an issue.
- Expert group needed to further investigate and detail the issue.
The advisory board consist of 1-2 architects from each of the national domains in
Norway and is chaired by architect from the national authority DFØ.
To start with the work will be ad-hoc and on demand, with the intent of having one
workshop per quarter.
Next version of Bits MIGs ISO 20022
Pepppol ePayment temamøte
■ Hanne Sandernes, Bits
■ 13. april 2021
15
Changes to the ISO 20022 MIG change management lifecycleWe follow EPC and NPC
■ EPC (European Payments Coucil) and NPC (Nordic Payments Coucil) have changed their
change management life cycles and their plans for introducing the 2019-verison of the ISO
20022 standard
■ Original plan: New version enter into effect by November 2022
■ New plan: New version enter into effect by November 2023
■ Bits has chosen to follow EPC/NPC
■ There will be no new version/updates of customer-bank Message Implementation
Guidelines in 2021
16
New dates for the next (2022) release of Bits cutomer-bank Message Implementation Guidelines, ISO 20022
Dato
Due date, Call for change requests to be concidered in the 2022-
relese
1. Oct 2021
Draft version of next release on public consultation 1. Dec 2021
Due date comments on draft version of next release 1. Mar 2022
New release published 1. Jun 2022
Due date «go live» for all participants, implementation of new
release
Nov 2023
17
Next release
ISO 20022
■ 2019-verion of ISO 20022
− Compare with the 2009-version
− Evaluate weather new elements should be allowed
− So far: No substantial changes
■ Evaluate possible other changes decided
in EPC and/or NPC’s next relese
− Not started
■ Evaluate all incoming change requests
(before Oct 1st 2021)
− Received some CR to allign Bits MIG with the
bank’s pratice
− No CR from Peppol ePayment participants so far
18
How to submit change requests?
■ Get a user on Bits ISO-portal https://www.bits-standards.org/
■ Send e-mail to Hanne Sandernes, hanne.sandernes@bits.no, to get correct user
credentials in the portal (get access to see and submit change requests)
− Note: all organizations must coordinate their change requests => we will give a maximum of 2 persons in the
same organization this credential
■ Click on the meny choice «CR C2B» and submit your change request
− Note: If the change requires changes in several index numbers in the MIG, please create one CR pr index
Updates on Security Requirements
ePeppol
■ Peppol Payment Workshop
■ 13th of April 2021
■ Andreas Havsberg
21
Background
■ Bits is responsible for ensuring safe and trustworthy requirements and the requirements are updated from time to time as the security landscape develops.
■ A needed change was identified, mainly based on encryption methods being outdated
− PKCS#1 v1.5 was introduced in 1993
− PKCS#1 v2.1 was introduced in 2002
− PKCS#1 v2.2 was introduced in 2012.
■ In addition to encryption requirements, we have chosen to clean up and update the requirements for signing.
■ Agility
22
6.1. Content signatures
Signatures are created and validated based upon cryptographic algorithms as described in ETSI TS 119 312 v1.3.1. and SOG-IS Agreed Cryptographic Mechanisms.
Note: These requirements only apply to the signature itself, not the signature of the signing certificate used.
# Status Requirements
6.1.1 M Signature suites can be any of the following:
1. “sha3-with-ecdsa” (recommended)
o Hashing function shall be SHA3-256
o Signature algorithm: ECDSA
o Elliptic curve parameters used shall be based on the NIST-curves (FIPS 186-4)
2. “rsa-pss with mgf1SHA-256Identifier”
o Hashing function shall be mgf1SHA-256Identifier
o Signature algorithm: RSA-PSS
6.1.2 M Implementations shall support validating signatures with any of these suites.
6.1.3 M The key size shall be minimum:
1. ECDSA: 256 bits (NIST P-256)
2. RSA: 3072 bits
23
6.2. Content encryption
# Status Requirement
6.2.1 M Key encryption with: “RSA-OAEP-256” - RSAES OAEP using SHA-256 and
MGF1 with SHA-256.
6.2.2 M Content encryption: AES with 256 bit keys
Mode of operation: GCM
6.2.3 M Minimum key size shall be 3072 bits for RSA keys
24
Needed changes and updates
■ What must be done
− Support decryption of PKCS#1 v2.x
− Update encryption to PKCS#1 v2.x
− Support validation of signatures with bothRSA-PSS or ECDSA
− Next time you order new certificates, ensure these have the sufficient key sizes.(It may take some time before ECDSA certificates are available)
− Generally ensure your implementationconforms to the requirements.
■ What can (or should) be done:
− Start using Elliptic Curve for signing
− Remove support for decryption usingPKCS#1 v1.5
25
Timeline for introduction of 6.1 requirementsSigning
■ June 15th 2021: Release of requirements.
■ January 15th 2022: Mandatory to support reception in addition to legacy algorithms (requirement 6.1.2).
■ February 15th 2022: Optional use in sending.
■ March 15th 2022: Mandatory use of 6.1.1. No more use of legacy algorithms. From this date requirements 5.1.13 and 5.1.14 are deprecated.
■ August 1st 2022: Mandatory use of 6.1.3 for new certificates. Certificates issued before this date may be used until they expire.
26
Timeline for introduction of 6.2 requirementsEncryption
■ June 15th 2021: Release of requirements.
■ January 15th 2022: Mandatory to support reception in addition to legacy algorithms.
■ February 15th 2022: Optional use in sending.
■ March 15th 2022: Mandatory use of 6.2.1 and 6.2.2. No more use of legacy algorithms.
■ August 1st 2022: Mandatory use of 6.2.3 for new certificates. Certificates issued before this date may be used until they expire.
27
Further process
■ External consultation
− Lasts from 15 Apr until 5 May
■ Where to find it
− Security requirements for secure file transactions (anskaffelser.dev)
■ We want input!!!
− Contact us for questions or disucissions
− Conrete suggestions and input shouldbe sent to ehf@dfo.no.
E-post:
Mobil:
Bits AS
Hansteens gate 2
P.O. Box 2644
N-0203 Oslo
www.bits.no
Andreas Havsberg
Andreas.havsberg@bits.no
91562515
Kort om CertPub (1)
For å bruke PKI til å kryptere meldinger til hverandre er avsender avhengig av å få
tilgang på mottaker sitt sertifikat. Denne utvekslingen foregår tradisjonelt bilateralt,
og det fordrer at den som har sendt sertifikatet sender oppdatert sertifikat til de det
gjelder når det trengs, og at mottaker oppdaterer sine systemer i tide.
Sender Mottaker
Sertifikat
Meldinger
Kort om CertPub (2)
CertPub er en desentralisert tjeneste hvor sertifikater kan oppbevares strukturert
så sender kan hente sertifikatet mottaker bruker for formålet ved behov. Mottaker
trenger nå å oppdatere sertifikatet sitt en plass.
CertPub
Sender MottakerMeldinger
CertPub og Peppol
• CertPub forvaltes fremover av DFØ for bruk innen flere domener i Peppol-
nettverket
• Løsningen benyttes som en av flere byggeklosser i Peppol Payment
Virksomhetssertifikater
• CertPub baserer seg på tilgjengeliggjøring av sertifikater av typen som i Norge
normalt refereres til som «virksomhetssertifikater»
• Av sikkerhetsgrunner må den som henter sertifikater gjennom CertPub-tjenester
verifisere sertifikatet før bruk.
• Dersom man mottar flere sertifikater kan man velge sertifikat basert på
validering og deretter egne preferanser.
• Domener som benytter CertPub kan velge å ha ytterligere krav til sertifikatene
som distribueres, eksempelvis sikkerhetsnivå, eller til valideringen av
sertifikatene, eksempelvis kontroll av organisasjonsnummer.
SEID 2.0-prosjektet
• Dokumentforvalter er Norsk kommunikasjonsmyndighet (NKOM) og de nye
spesifikasjonene er utarbeidet i et samarbeid mellom relevante private og
offentlige aktører
• Ferdigstilt i mars 2021
• Medfører endringer knyttet til bruken av «virksomhetssertifikater»:
- Plassering av metadata i sertifikatene
- Nye «statements» å verifisere
- Tydeligere identifisering av bruksområder
• Migrering:
- 1. september 2021 – påkrevd å støtte de nye sertifikatprofilene
- 1. juni 2022 – avslutte bruk av gamle sertifikatprofiler
SEID 2.0-prosjektet
• Oppdatert dokumentasjon er tilgjengelig på NKOM sine nettsider:
https://www.nkom.no/internett/elektronisk-id-og-tillitstjenester/seid-prosjektet
• De 4 første dokumentene er oppdatert:
- SEID Forvaltningsinstruks (med vedlegg)
- SEID Leveranse 1 (med vedlegg)
• Nettsiden oppdateres med nye tekster i disse dager
• Buypass og Commfides publiserer sine oppdaterte sertifikatprofiler i løpet av Q2
2021
Nye CA
• I forbindelse med innføring av SEID 2.0 vil også Buypass og Commfides
introdusere nye CA for utstedelse av «virksomhetssertifikater»
• Nye CA kommer i tillegg til eksisterende, og gjelder for både test/akseptanse og
produksjon
• Forventes å være tilgjengelig i løpet av Q2 2021
Kommende informasjon
• Det er ventet at Digitaliseringsdirektoratet (Digdir) i løpet av forholdsvis kort tid
begynner å kommunisere med markedet om overgangen.
• Kommunikasjon fra Digdir vil være i samarbeid med Buypass og Commfides.
Hva betyr det for Peppol Payment?
• Må sette av tid til endringer i programvare/planlegge med
systemleverandør/installasjon av oppdateringer
• Planlegge endringer i brannmurer
• Ta kontakt med din sertifikatleverandør for når du får tilgang på nye sertifikat
• Alle må oppdatere for både Buypass og Commfides uavhengig av hvem som er
sin sertifikatleverandør
• Følge med når Digitaliseringsdirektoratet begynner å kommunisere endringene
digdir.no
ANNEX 3• 4. PEPPOL SMP and PEPPOL AP Service availability
• 4.1. Access Point Services exposed to other PEPPOL Access Points must be available on average:
• • 99.5% of the time from Monday - Friday from 9:00 to 16:00 CET (business hours)
• • 99.5% of the remaining period.
• 4.2. Availability is measured monthly and service windows are included in "down time".
• 4.3. A PEPPOL Access Point Provider must have an escalation procedure and a contingency plan to handle service disruption.
• 4.4. PEPPOL Access Point Providers must log service downtime and document availability in monthly reports.
• 4.5. Major incidents as breaches in the security which could have an impact on other Service Providers have to be communicated within 4 hours to mailing list provided by the coordinating authority containing all support e-mail addresses.
• 4.6. Maximum loss of data is the last 24 hours for an SMP.
digdir.no
Down time
Antall
Totalt A - Critical B - Severe C – Less serious
Down time Info
2020 - Q1 1
0 1 0
2t 15 m Monday 13.01 - 22.58 - Tuesday 14. januar 00.15 - ddos-attack
2020 - Q2 1 0 0 1
2020 - Q3 1 0 0 1
2020 - Q4 2
0 1 1
21t 50m Sunday 01.11.2020 01.00 - 21.50. expired peppol-certificate
2021 - Q1 0 0 0 0
digdir.no
Upcomming changes
• Deprecation of the SOAP API
• Will be removed 31.08.2021
• Swedish receivers in ELMA
• Registration of new receivers will be halted 30.04.2020
• Existing receivers must be removed before 31.12.2020
• Reinforced authorization
• 2 factor authentication in the web ui
• New statuspage: https://status.digdir.no/
meeting schedule 2021
January February Marts April Mai June July August September October November December
16-02 2021
INFO meeting
16-03 2021
Theme :
eProcurement
domain
26-10 2021
INFO meeting
08-06 2021
INFO meeting
13-04 2021
Theme:
ePayment domain
11-05 2021
Theme :
OpenPeppol GA
preparation & eDelivery
open Issues
31-08 2021
Theme
28-09 2021
Theme
23-11 2021
Theme
To be decided and announced 08/06 at latest
• Agreement Migration
• CTC project result & next step
• EGovernment domain meeting?
• EDelivery domain meeting
• ????
Easter Whitsun & May 17th Summer Vacation Christmas
May 5TH 2021
eProcurement conference:
Digital Procurement
Oct/ Nov 2021
Procurement conferenceAug /Sep2021
DFØ conference
Topic relevant for theme meetings or to be addressed at Info meetings can be send to Peppolmyndighet@dfo.no
June 2021
OpenPeppol GA
Konferanse: Digitale anskaffelser - mer enn EHF! - DFØ (dfo.no)
Recommended