{"id":"2b119469-ea49-4477-8a9d-fe3da9f335d5","arxiv_id":"2412.04051","paper_version":2,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"A design for a central bank digital currency certificate hierarchy with a rollover schedule that includes offline hardware wallets.","lead":"This paper proposes a certificate hierarchy and rollover schedule for the public key infrastructure behind a central bank digital currency. It is a design blueprint that central banks could use to prevent payment outages when cryptographic certificates expire.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Rollover design omits cross-verification: new cards are never required to carry the previous Root CA, so offline P2P with legacy cards fails during the u-long overlap after each rollover.","rationale":"I read the paper in good faith and traced the rollover arithmetic. The ramp-up length u elegantly ensures that no in-circulation card at activation lacks the new Root: cards made before the ramp-up expire at or before activation, and cards made during the ramp-up are born with both roots. Hence the reader's specific worry about updating already-issued offline cards is not the decisive gap. However, the mirror-image gap is decisive: old-chain cards do not disappear at activation; they persist for up to u more. The paper's §5.2.1 lists a single pinned Root, and §5.2.2's 'installed alongside' is tied to the ramp-up period. No requirement covers cards made after activation. Without the previous Root, a new card cannot validate a legacy card's chain, so offline P2P fails during the overlap. This directly attacks the central claim. The fix is small—add a transition rule—but the paper does not make it, so the verdict should remain CONDITIONAL.","tokens_in":10347,"tokens_out":21977,"duration_ms":205887,"concrete_test":"Implement the rollover timeline of Figure 5 with u=1: issue a legacy card at T-0.5 (ramp-up) with an old-Root chain, and a new card at T+0.5 with only the new Root pinned as §5.2.1 suggests. Attempt mutual offline authentication using the paper's certificate hierarchy; show the new card's path validation fails against the legacy card's old-Root chain. Then check whether any sentence in §5.2.2 or §5.7 requires new cards to carry the old Root; if none does, the central claim is unsupported for the overlap period.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The paper's ramp-up timing (§5.2.2, §5.7) ensures that at activation all cards in circulation know the new Root, because any card manufactured before the ramp-up expires before activation (card lifetime = u, ramp-up ≥ u). Thus the reader's concern about updating existing offline cards is actually met by the design without a delivery mechanism. However, a different propagation gap breaks the central claim. Cards manufactured during the ramp-up have certificate chains signed under the old Root and remain valid for up to u after activation. New cards manufactured after activation, as specified in §5.2.1, pin only a single Root CA certificate. Nothing in §5.2.2 or §5.7 requires new-generation cards to also carry the old Root. Therefore, when a new card attempts offline P2P with a legacy card during the overlap window (from activation until the last old-chain card expires), it cannot build a trust path to the old Root, so verification fails. This contradicts the 'ensuring continuous operation' claim. The design implicitly needs a transition rule: cards manufactured during the active phase of Root n must also pin Root n-1 until all Root n-1 chains expire. The paper neither states nor derives this rule.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":10545,"tokens_out":4449,"duration_ms":44760,"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":[{"comment":"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.","section":"§5.7, §5.2.1, Figure 5"},{"comment":"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.","section":"§4.3"}],"minor_comments":[{"comment":"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.","section":"Throughout"},{"comment":"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.","section":"§5.2.1, §5.2.2"},{"comment":"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.","section":"Figure 5"},{"comment":"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.","section":"§5.3"}],"recommendation":"major_revision","confidential_remarks":"The cross-verification gap is fixable within the paper's scope by adding a transition rule, so I do not see this as a reject. The self-citation [14] is background context and does not create circularity. If the authors add the missing transition rule and address the offline revocation gap, the paper could be acceptable for publication."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nWhat'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.\n\nThe 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.\n\nMinor 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.\n\nWho 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.\n\nRecommendation: send it to peer review, but with an explicit request that the authors address the cross-generation verification gap. It deserves referee time.","headline":"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.","tokens_in":11057,"tokens_out":2700,"would_cite":true,"duration_ms":27179,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A staged rollover scheme lets a central bank replace its root certificate without ever interrupting offline CBDC payments.","keywords":["central bank digital currency","public key infrastructure","certificate rollover","smartcard","offline payments","card verifiable certificates","certificate hierarchy","root CA"],"falsifier":"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.","tokens_in":10114,"feed_emoji":"🔐","tokens_out":3754,"duration_ms":32838,"temperature":0.7,"pith_summary":"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.","feed_headline":"Ramp-up phase lets CBDC root certificates roll over without downtime","feed_subtitle":"Preloading the next root into smartcards before it activates keeps offline P2P payments valid across generations.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the certificate policy and Certification Practice Statement framework that the paper relies on for structuring CA processes.","marker":"[10]"},{"why":"Defines Card Verifiable certificates, the stripped-down X.509 format chosen for smartcard payment performance.","marker":"[15]"},{"why":"Provides the base X.509 certificate profile that the paper adapts and trims for the CBDC context.","marker":"[3]"},{"why":"Documents the Eastern Caribbean Central Bank outage caused by expired certificates, the motivating real-world failure for the rollover concept.","marker":"[8]"},{"why":"Establishes the offline-payment trust model in which certificates allow safe transactions without an online certificate authority.","marker":"[7]"},{"why":"Earlier work by the same authors identifying PKI as instrumental for CBDC and assessing cryptographic key migration, providing the foundation for this design.","marker":"[14]"}],"fun_headline_variants":["Designing CBDC PKI with zero-downtime certificate rollover","Three-tier CA hierarchy keeps CBDC trust alive across generations","Ramp-up phase ensures offline wallets never lose trust","CBDC PKI: preloaded roots guarantee seamless certificate transitions","Hardware, Operational, Financial CAs: blueprint for CBDC security"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Designing CBDC PKI with zero-downtime certificate rollover","Three-tier CA hierarchy keeps CBDC trust alive across generations","Ramp-up phase ensures offline wallets never lose trust","CBDC PKI: preloaded roots guarantee seamless certificate transitions","Hardware, Operational, Financial CAs: blueprint for CBDC security"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000219,"raw_usage":{"total_tokens":1366,"prompt_tokens":794,"completion_tokens":572,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":410,"completion_tokens_details":{"reasoning_tokens":484}},"tokens_in":410,"tokens_out":572,"duration_ms":5618,"temperature":1.0,"reasoning_tokens":484,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T21:48:50.979627+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Ford et al","cited_arxiv_id":null,"evidence_quote":"Supplies the certificate policy and Certification Practice Statement framework that the paper relies on for structuring CA processes."},{"cited_title":"ISO/IEC 7816-8:2021 Identifica- tion cards — Integrated circuit cards, Part 8: Commands and mechanisms for se- curity operations","cited_arxiv_id":null,"evidence_quote":"Defines Card Verifiable certificates, the stripped-down X.509 format chosen for smartcard payment performance."},{"cited_title":"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile","cited_arxiv_id":null,"evidence_quote":"Provides the base X.509 certificate profile that the paper adapts and trims for the CBDC context."},{"cited_title":"Digital Currency Hit by Expired Certificate — Root Cause for Prolonged Outage","cited_arxiv_id":null,"evidence_quote":"Documents the Eastern Caribbean Central Bank outage caused by expired certificates, the motivating real-world failure for the rollover concept."},{"cited_title":"Review of Offline Payment Function of CBDC Considering Security Requirements","cited_arxiv_id":null,"evidence_quote":"Establishes the offline-payment trust model in which certificates allow safe transactions without an online certificate authority."}],"review_version":1}