How to design a Public Key Infrastructure for a Central Bank Digital Currency

Lars Hupel; Makan Rafiee

REVIEW 2 major objections 4 minor 24 references

How to design a Public Key Infrastructure for a Central Bank Digital Currency

T0 review · 2 major / 4 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A staged rollover scheme lets a central bank replace its root certificate without ever interrupting offline CBDC payments.

desk verdict Solid CBDC PKI rollover design with an internally consistent timing model, but the seamless-offline-P2P claim needs an explicit cross-root pinning rule for new cards. read the letter →

arxiv 2412.04051 v2 pith:EMCES4DL submitted 2024-12-05 cs.CR cs.NI

Makan Rafiee , Lars Hupel This is my paper · ORCID

classification cs.CRcs.NI

keywords centralbankdigitalcurrencypublickeyinfrastructurecertificaterolloversmartcardofflinepaymentscardverifiablecertificateshierarchyrootCA

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that a Central Bank Digital Currency needs its own dedicated public key infrastructure and proposes a concrete certificate hierarchy rooted at the central bank. Its central contribution is a rollover concept: by adding a ramp-up phase in which the next Root CA certificate is installed in smartcards before it becomes active, and by deriving all subordinate certificate lifetimes as multiples of the smartcard validity period, the system can survive regular certificate expirations without service interruption, even for hardware wallets that stay offline for years. The paper derives minimum validity periods for every certificate type and shows a concrete instantiation. The significance is that a national payment infrastructure could avoid the certificate-expiry outages that have hit other systems, while keeping person-to-person offline payments functional.

What carries the argument

The central object is the certificate hierarchy with pinned certificates on smartcards: Root CA, Central Register, and Timestamp Service certificates are pinned, and each smartcard also carries its own chain of End-Entity, Manufacturer CA, and Hardware CA certificates. The rollover concept extends the standard three-phase rollover (old-only, overlap, new-only) with a ramp-up phase, so a new Root CA certificate is distributed and installed on all circulating smartcards before it starts signing anything. All validity periods are expressed as multiples of u, the smartcard validity period, with constraints such as Active(Manufacturer CA) ≥ u and Passive(Manufacturer CA) ≥ u, ensuring that cards manufactured throughout a CA's active period remain verifiable for their full lifetime.

What would settle it

Find any circulating smartcard whose pinned Root CA set does not already include the next-generation root during the previous generation's active phase; if such a card can be produced and issued, then offline payment between it and a card from the next generation will fail after the old root expires, disproving the continuous-operation claim.

Watch

Extended reading notes

Core claim

The paper's central claim is that a three-strand certificate hierarchy (Hardware CA, Operational CA, Financial CA) under a central-bank Root CA, combined with a rollover procedure that includes a ramp-up phase, guarantees continuous PKI operation across certificate generations. The load-bearing requirement is that every smartcard in circulation must already hold the next Root CA certificate before that certificate becomes active, which is achieved by making the ramp-up period at least one smartcard validity period u. All other certificate lifetimes are then derived so that each subordinate CA can issue certificates throughout its active phase and remain verifiable through the entire lifetime of every card manufactured under it.

Load-bearing premise

All smartcards in circulation can be made to know the new Root CA certificate during the ramp-up phase, before it becomes active; the paper assumes a delivery channel for this without specifying one for cards that never connect online.

Editorial extensions

If this is right

Certificate-expiry outages can be eliminated for the entire CBDC ecosystem if each new Root CA certificate is preloaded during a ramp-up phase of at least one smartcard validity period.
Smartcards that remain offline for their whole lifetime never need to connect to a backend to keep authenticating other cards and services; the only requirement is the initial preloading at manufacturing or issuance.
The timing rules give central banks a concrete planning table: once u is chosen, every certificate's ramp-up, active, passive, and total validity periods are determined.
The rollover concept is generic enough to be applied to other PKIs with large numbers of intermittently offline devices, not just CBDC wallets.
Revocation can be handled operationally rather than with CRLs or OCSP, because the relying parties are known and controlled, avoiding transaction slowdowns and privacy leaks.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The continuity guarantee depends on a distribution channel that can reach every smartcard before the old root expires; for cards that never connect online, that channel must be physical (at issuance or via the manufacturer), which the paper assumes but does not detail.
A natural stress test is a generation of cards manufactured near the end of a Manufacturer CA's active period: the paper's inequalities cover this, but an implementation should verify that the next Root CA certificate is already installed on that generation before the old one deactivates.
The same ramp-up logic could be applied to post-quantum key migration, where certificates under new algorithms need to coexist with old ones across many offline devices.
If offline P2P payments must work between cards of different generations, the pinned-certificate set must contain every root that could be active during any card's lifetime; specifying that set concretely is the main engineering follow-up.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Here's my take. The paper's substance is a concrete certificate hierarchy for a CBDC and a rollover schedule whose arithmetic is internally consistent. The ramp-up idea is real: because the ramp-up is at least one smartcard validity period (u), every card in circulation at activation already knows the new root, so the reader's concern about updating older offline cards is actually answered. That part works.

What's genuinely new is the three-armed hierarchy (Hardware, Operational, Financial CAs), the use of u as the base unit, and the resulting table of validity windows. It's the kind of thing a central bank engineer could take and instantiate. The revocation discussion is also sensible for offline use: CRLs and OCSP don't fit the connectivity model, and relying parties are known, so organizational revocation is a reasonable default.

The soft spot is in the overlap window. Cards manufactured during the ramp-up carry chains signed under the old root and stay valid for up to u after activation. Cards manufactured after activation, as specified, pin the new root. The paper never requires new-generation cards to also pin the old root. So when a new card meets a legacy card offline during that overlap, it cannot build a trust path to the old root, and verification fails. That directly undercuts 'continuous operation.' The fix is small: during the active phase of root n, cards must also carry root n-1 until all old-chain cards expire. The paper needs to state that as a requirement and adjust the pinning section. This is a load-bearing omission, not a nitpick.

Minor points: Table 1 and Figure 5 are consistent but dense; the derivation for the Root CA passive phase of 2u is fine. There is no code or data, but this is a design paper, so that isn't a flaw. The single self-citation [14] is background on post-quantum cryptography and doesn't do any load-bearing work.

Who this is for: PKI architects and central bank digital currency teams. It is not a cryptographic research result, but it is a useful systems design with a reproducible schedule. With the cross-pinning rule added, I'd be comfortable relying on the rollover design. As it stands, the central claim needs a revision.

Recommendation: send it to peer review, but with an explicit request that the authors address the cross-generation verification gap. It deserves referee time.

Referee Report

2 major / 4 minor

Summary. The paper argues that a CBDC requires a dedicated PKI and proposes a three-strand certificate hierarchy (Root CA with Hardware, Operational, and Financial CA strands), discusses the use of Card Verifiable certificates and revocation trade-offs, and introduces a certificate rollover concept with ramp-up, active, and passive phases measured in units of the smartcard validity period u. The central claim, stated in the abstract and Section 6, is that this rollover concept ensures continuous operation of the system across Root CA expirations, including for offline hardware wallets. The timing algebra in Section 5 and Table 1 is internally consistent and derived transparently from the u unit, and Figure 5 gives a concrete instantiation.

Significance. If the rollover claim were fully established, this would be a valuable design reference for central banks, and the unit-based timing framework is a useful, parameter-free way to reason about certificate lifetimes in offline-capable payment ecosystems. The paper is also honest about many practical constraints, and its lack of fitted parameters or circular reasoning is a strength. However, the central seamlessness claim is not currently established because the design omits a transition rule for cross-verification between old- and new-generation offline cards. The gap is concrete, local, and fixable, but it is load-bearing for the paper's main contribution.

major comments (2)

[§5.7, §5.2.1, Figure 5] The rollover timing ensures that at activation all circulating cards know the new Root CA certificate, because any card manufactured before the ramp-up phase has expired. However, cards manufactured during the ramp-up phase carry certificate chains signed under the old Root CA and remain valid for up to u after activation. The paper does not require cards manufactured after activation to continue pinning the old Root CA certificate alongside the new one. Consequently, during the u-long overlap window, a new-generation card cannot build a trust path to a legacy card's old-Root chain in an offline P2P exchange, so verification fails. This directly contradicts the abstract's and Section 6's claim of ensuring continuous operation. The manuscript needs an explicit transition rule, for example requiring cards issued during Active(Root n) to also pin Root n-1 until all Root n-1-based chains expire, and this rule should be reflected in Table 1 and Figure 5.
[§4.3] The proposed revocation approach, based on organizational handling and 'unplugging' compromised entities, is described only for FSPs and operational certificates. It does not address the large and autonomous population of offline smartcards, which the paper itself identifies as the main PKI complication. The manuscript does not explain how a compromised smartcard is invalidated in offline P2P scenarios, so the PKI design leaves a significant trust gap even if the rollover timing is corrected.

minor comments (4)

[Throughout] There are several typographical errors that should be fixed, including 'Carribean' in §1.2, 'thay' in §5.2.2, 'planed' in §5.2.3, 'hardware-baed' in §1.3, 'singe' in §4.3, and 'pecularities' in the introduction.
[§5.2.1, §5.2.2] Please clarify whether a smartcard pins one Root CA certificate or multiple Root CA certificates during a transition; the list of pinned certificates in §5.2.1 uses the singular, while §5.2.2 and §5.7 discuss installing the new certificate alongside old Root CA certificates.
[Figure 5] The notation '//' and the truncation of several certificate rows are not explained, which makes it hard to read the generation boundaries in the concrete instantiation.
[§5.3] The implicit assumption that smartcard manufacturers will install the ramp-up Root CA certificate on all cards produced during the ramp-up phase should be stated explicitly as a requirement, since it is essential to the timing argument.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the PKI design and rollover timing are derived from stated requirements, with the only self-citation serving as background context.

full rationale

The paper is a design and requirements analysis, not an empirical or predictive study. Its central claim, that a CBDC PKI with a rollover concept can ensure continuous operation, is supported by an explicit derivation of validity periods from the stated requirements in Section 5.3. For example, RampUp(Root CA) = u follows from the requirement that 'at the time of activation of the new Root CA certificate, all circulating smartcards must already know the new certificate.' No parameter is fitted to data, no quantity is renamed as a prediction, and no uniqueness theorem or ansatz is imported from the authors' prior work. The only self-citation, reference [14], appears in the introduction and related work as background on post-quantum cryptography and as a source of general CBDC launch criteria; those criteria are articulated as assumptions and the rollover design does not depend on the cited PQC analysis. The timeline values such as u, 2u, and 4u are derived from the requirements in Section 5.3 and Table 1, not recycled from the requirements themselves by definition. Therefore, no circular step reduces a claimed result to its input, and the design is self-contained as a construction.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The central claim rests on a CBDC model with known, controllable participants and on the delivery of new root certificates to offline smartcards. The latter is assumed without a mechanism. No new particles, forces, or unobservable entities are introduced; the proposed CAs are organizational roles.

free parameters (2)

u (smartcard validity period) = not specified; 'typically a few years' (Section 5.3)
Base time unit from which every certificate lifetime in Table 1 is derived; chosen by the central bank, not derived from external constraints.
Active(Root CA) = 3u in generation 1, 2u in later generations (Figure 5)
Free choice within the constraint Active + Passive >= 4u; affects the example schedule but not the core method.

assumptions (3)

domain assumption Two-tier CBDC distribution model: central bank issues money, commercial banks distribute it.
Section 3 defines the system characteristics; the PKI design (FSP CA, Hardware CA) depends on this structure.
domain assumption All relying parties are known and mostly controlled by the central bank, so organizational revocation can replace CRL/OCSP.
Section 4.3 argues operational revocation is sufficient because relying parties are known; this grounds the decision to skip technical revocation mechanisms.
ad hoc to paper New Root CA certificates can be distributed to circulating smartcards during the ramp-up phase.
Sections 5.2.2 and 5.7 require all circulated smartcards to know new roots before activation, but no delivery or update mechanism is described for offline devices.

how reviews work

0 comments

Cite this review

Pith. "Pith review of How to design a Public Key Infrastructure for a Central Bank Digital Currency." pith.science (2026). https://pith.science/paper/EMCES4DL

@misc{pith2026241204051,
  author       = {Pith},
  title        = {Pith review of: How to design a Public Key Infrastructure for a Central Bank Digital Currency},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EMCES4DL}},
  note         = {Machine review of arXiv:2412.04051}
}

read the original abstract

Central Bank Digital Currency (CBDC) is a new form of money, issued by a country's or region's central bank, that can be used for a variety of payment scenarios. Depending on its concrete implementation, there are many participants in a production CBDC ecosystem, including the central bank, commercial banks, merchants, individuals, and wallet providers. There is a need for robust and scalable Public Key Infrastructure (PKI) for CBDC to ensure the continued trust of all entities in the system. This paper discusses the criteria that should flow into the design of a PKI and proposes a certificate hierarchy, together with a rollover concept ensuring continuous operation of the system. We further consider several peculiarities, such as the circulation of offline-capable hardware wallets.

Figures

Figures reproduced from arXiv: 2412.04051 by the authors.

**Figure 1.** Participants and communication channels in a CBDC ecosystem • at least the payment scenarios C2B/B2C (customer-to-business/business-to-customer) and P2P (person-to-person) are supported; • a central bank ledger validates transactions, with the concrete operational model (DLT/non-DLT) abstracted for this paper [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗

**Figure 2.** Proposed PKI hierarchy Therefore, the central bank imposes requirements to these thirds parties and enforces compliance. Ideally, the processes carried out by third parties shall be audited by the central bank. The requirements in this policy could be published. This enables participants to understand how the PKI operates and establishes a factual basis for their trust. Certificates with similar security levels sho… view at source ↗

**Figure 3.** Conceptual CA rollover (standard case) Smartcards are offline entities which may, after production, rarely connect to an online service. This gives rise to some additional complication that go beyond normal rollover procedures. 5.1 Standard rollover Normally, a certificate rollover consists of three phases (see [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗

Figures from the paper (2 more)

**Figure 4.** Figure 4: Conceptual CA rollover (CBDC case with ramp up phase) 5.3 Solution requirements We define the validity period of a smartcard certificate, denoted as 1u, as the base unit in our concept. This can be defined by the central bank and will typically be a few years. All othe…

**Figure 5.** Figure 5: Example of a concrete rollover instantiation. Each certificate has a (light) active phase, and optionally a preceding (dark) ramp up phase and a succeeding (dark) passive phase. 19 [PITH_FULL_IMAGE:figures/full_fig_p019_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

24 extracted references · 20 canonical work pages

[14]

How Does Post-quantum Cryptography Affect Central Bank Digital Currency?

Lars Hupel and Makan Rafiee. “How Does Post-quantum Cryptography Affect Central Bank Digital Currency?” In: Ubiquitous Security. Springer Nature Singa- pore, 2024, pp. 45–62. isbn: 9789819712748. doi: 10.1007/978- 981- 97- 1274- 8_4

doi:10.1007/978- 2024
[1]

Microsoft Sharepoint outage caused by use of wrong TLS cer- tificate

Lawrence Abrams. “Microsoft Sharepoint outage caused by use of wrong TLS cer- tificate”. In: Bleeping Computer (July 2023). url: https://www.bleepingcomputer. com/news/microsoft/microsoft- sharepoint- outage- caused- by- use- of- wrong-tls-certificate/

work page 2023
[2]

Project Aurum: a prototype for two-tier central bank digital currency (CBDC)

BIS Innovation Hub. Project Aurum: a prototype for two-tier central bank digital currency (CBDC). Oct. 2022. url: https://www.bis.org/publ/othp57.pdf

work page 2022
[3]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Sharon Boeyen et al. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile . RFC 5280. May 2008. doi: 10.17487/ RFC5280

work page 2008
[4]

Transitioning to a Hyperledger Fabric Quantum-Resistant Clas- sical Hybrid Public Key Infrastructure

Robert Campbell. “Transitioning to a Hyperledger Fabric Quantum-Resistant Clas- sical Hybrid Public Key Infrastructure”. In: The Journal of the British Blockchain Association 2.2 (Nov. 2019), pp. 1–11. issn: 2516-3957. doi: 10.31585/jbba-2- 2-(4)2019

work page doi:10.31585/jbba-2- 2019
[5]

Cisco SD-W AN outage concerns users, impacts businesses

Emma Chervek. “Cisco SD-W AN outage concerns users, impacts businesses”. In: SDxCentral (May 2023). url: https://www.sdxcentral.com/articles/news/ cisco-sd-wan-outage-concerns-users-impacts-businesses/2023/05/

work page 2023
[6]

Towards a Two-Tier Hierarchical Infrastructure: An Offline Payment System for Central Bank Digital Currencies

Mihai Christodorescu et al. Towards a Two-Tier Hierarchical Infrastructure: An Offline Payment System for Central Bank Digital Currencies . 2020. doi: 10 . 48550/ARXIV.2012.08003

work page Pith review arXiv doi:10.48550/arxiv.2012.08003 2020
[7]

Review of Offline Payment Function of CBDC Considering Security Requirements

Yeonouk Chu et al. “Review of Offline Payment Function of CBDC Considering Security Requirements”. In: Applied Sciences 12.9 (Apr. 2022), p. 4488. issn: 2076-

work page 2022

Show all 24 references

[8]

Digital Currency Hit by Expired Certificate — Root Cause for Prolonged Outage

Brooke Crothers. “Digital Currency Hit by Expired Certificate — Root Cause for Prolonged Outage”. In: Venafi (Mar. 2022). url: https://venafi.com/blog/ digital-currency-slammed-expired-certificate-root-cause-prolonged- outage/

2022
[9]

Embracing diversity, advancing together – results of the 2023 BIS survey on central bank digital currencies and crypto

Alberto Di Iorio, Anneke Kosse, and Ilaria Mattei. “Embracing diversity, advancing together – results of the 2023 BIS survey on central bank digital currencies and crypto”. In: BIS Papers 147 (June 2024). url: https://www.bis.org/publ/ bppdf/bispap147.pdf

2023
[10]

Ford et al

Warwick S. Ford et al. Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework . RFC 3647. Nov. 2003. doi: 10 . 17487 / RFC3647

2003
[11]

A Blockchain-based Framework for Central Bank Digital Currency

Xuan Han, Yong Yuan, and Fei-Yue Wang. “A Blockchain-based Framework for Central Bank Digital Currency”. In: IEEE International Conference on Service Operations and Logistics, and Informatics (SOLI) . IEEE, Nov. 2019. doi: 10 . 1109/soli48380.2019.8955032. 20

2019
[12]

2023’s Biggest Certificate Outages & What We Can Learn From Them

Chris Hickman. “2023’s Biggest Certificate Outages & What We Can Learn From Them”. In: Keyfactor (Jan. 2024). url: https://www.keyfactor.com/blog/ 2023s-biggest-certificate-outages-what-we-can-learn-from-them/

2023
[13]

e-HKD: A technical perspective

Hong Kong Monetary Authority. e-HKD: A technical perspective. Oct. 2021. url: https : / / www . hkma . gov . hk / media / eng / doc / key - functions / financial - infrastructure/e-HKD_A_technical_perspective.pdf

2021
[15]

ISO/IEC 7816-8:2021 Identifica- tion cards — Integrated circuit cards, Part 8: Commands and mechanisms for se- curity operations

International Organization for Standardization. ISO/IEC 7816-8:2021 Identifica- tion cards — Integrated circuit cards, Part 8: Commands and mechanisms for se- curity operations. Apr. 2021. url: https://www.iso.org/standard/79893.html

2021
[16]

ISO/TR 24374:2023 Financial services — Security information for PKI in blockchain and DLT implementations

International Organization for Standardization. ISO/TR 24374:2023 Financial services — Security information for PKI in blockchain and DLT implementations . Apr. 2023. url: https://www.iso.org/standard/78510.html

2023
[17]

The State of Machine Identity Management: More Machines, More Certificates . . . More Problems?

Keyfactor. “The State of Machine Identity Management: More Machines, More Certificates . . . More Problems?” In: Keyfactor (May 2023). url: https://www. keyfactor.com/blog/the- state- of- machine- identity- management- more- machines-more-certificates-more-problems/

2023
[18]

Key management for blockchain technology

Om Pal et al. “Key management for blockchain technology”. In: ICT Express 7.1 (Mar. 2021), pp. 76–80. issn: 2405-9595. doi: 10.1016/j.icte.2019.08.002

2021 doi
[19]

What is PKI? Understanding Public Key Infrastructure

Secure Identity Alliance. What is PKI? Understanding Public Key Infrastructure
[20]

Secure Revocation Features in eKYC - Privacy Protec- tion in Central Bank Digital Currency

Kazuo Takaragi et al. “Secure Revocation Features in eKYC - Privacy Protec- tion in Central Bank Digital Currency”. In: IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences E106.A.3 (Mar. 2023), pp. 325–332. issn: 1745-1337. doi: 10.1587/tran...

2023 doi
[21]

DOT-M: A Dual Offline Transaction Scheme of Central Bank Digital Currency for Trusted Mobile Devices

Bo Yang, Yanchao Zhang, and Dong Tong. “DOT-M: A Dual Offline Transaction Scheme of Central Bank Digital Currency for Trusted Mobile Devices”. In: Lecture Notes in Computer Science. Springer Nature Switzerland, 2022, pp. 233–248. isbn: 9783031230202. doi: 10.1007/978-3-031-23020-2_13

2022 doi
[22]

CBDC Security

Zhijun William Zhang. “CBDC Security”. In: Web3 Applications Security and New Security Landscape . Springer Nature Switzerland, 2024, pp. 73–92. isbn: 9783031580024. doi: 10.1007/978-3-031-58002-4_5 . 21

2024 doi
[2022]

org / publications - docman / public/270-2022-11-25-what-is-pki-sia-f-smith/file

url: https : / / secureidentityalliance . org / publications - docman / public/270-2022-11-25-what-is-pki-sia-f-smith/file

2022
[3417]

doi: 10.3390/app12094488

doi

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.

[1] [14]

How Does Post-quantum Cryptography Affect Central Bank Digital Currency?

Lars Hupel and Makan Rafiee. “How Does Post-quantum Cryptography Affect Central Bank Digital Currency?” In: Ubiquitous Security. Springer Nature Singa- pore, 2024, pp. 45–62. isbn: 9789819712748. doi: 10.1007/978- 981- 97- 1274- 8_4

doi:10.1007/978- 2024

[2] [1]

Microsoft Sharepoint outage caused by use of wrong TLS cer- tificate

Lawrence Abrams. “Microsoft Sharepoint outage caused by use of wrong TLS cer- tificate”. In: Bleeping Computer (July 2023). url: https://www.bleepingcomputer. com/news/microsoft/microsoft- sharepoint- outage- caused- by- use- of- wrong-tls-certificate/

work page 2023

[3] [2]

Project Aurum: a prototype for two-tier central bank digital currency (CBDC)

BIS Innovation Hub. Project Aurum: a prototype for two-tier central bank digital currency (CBDC). Oct. 2022. url: https://www.bis.org/publ/othp57.pdf

work page 2022

[4] [3]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

Sharon Boeyen et al. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile . RFC 5280. May 2008. doi: 10.17487/ RFC5280

work page 2008

[5] [4]

Transitioning to a Hyperledger Fabric Quantum-Resistant Clas- sical Hybrid Public Key Infrastructure

Robert Campbell. “Transitioning to a Hyperledger Fabric Quantum-Resistant Clas- sical Hybrid Public Key Infrastructure”. In: The Journal of the British Blockchain Association 2.2 (Nov. 2019), pp. 1–11. issn: 2516-3957. doi: 10.31585/jbba-2- 2-(4)2019

work page doi:10.31585/jbba-2- 2019

[6] [5]

Cisco SD-W AN outage concerns users, impacts businesses

Emma Chervek. “Cisco SD-W AN outage concerns users, impacts businesses”. In: SDxCentral (May 2023). url: https://www.sdxcentral.com/articles/news/ cisco-sd-wan-outage-concerns-users-impacts-businesses/2023/05/

work page 2023

[7] [6]

Towards a Two-Tier Hierarchical Infrastructure: An Offline Payment System for Central Bank Digital Currencies

Mihai Christodorescu et al. Towards a Two-Tier Hierarchical Infrastructure: An Offline Payment System for Central Bank Digital Currencies . 2020. doi: 10 . 48550/ARXIV.2012.08003

work page Pith review arXiv doi:10.48550/arxiv.2012.08003 2020

[8] [7]

Review of Offline Payment Function of CBDC Considering Security Requirements

Yeonouk Chu et al. “Review of Offline Payment Function of CBDC Considering Security Requirements”. In: Applied Sciences 12.9 (Apr. 2022), p. 4488. issn: 2076-

work page 2022