Internet-Draft SD-CWT PKSP July 2025
Wang, et al. Expires 8 January 2026 [Page]
Workgroup:
Secure Patterns for Internet CrEdentials
Internet-Draft:
draft-wang-spice-public-key-service-provider-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Wang
Huawei
F. Liu
Huawei
L. Li
Huawei

A Public Key Service Provider for Verification in Multiple Issuers and Verifiers

Abstract

SPICE provides a selective disclosure mechanism of credentials from issuer. However, future network services may be built on the trust between multiple entities. Obtaining the public key of multiple issuers for a verifer from potential multiple sources can be complex. In this contribution, an optional public key service is proposed in SPICE architecture for the issue of obtaining the public keys of the issuers from multiple trusted entities. The basic function of public key service is proposed including public key registration, token verification, and a potential implementation such as the distributed ledger. We hope that the proposed contribution can be used as infomative for SPICE regarding to the token validation procedure.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 January 2026.

Table of Contents

1. Introduction

As Web3.0 evolves, future society and networks will enables greater cross-field collaboration. Consequently, establishing trust between different domains is crucial. Consider this scenario: Device manufacturer A produces device a, which is sold to network operator X. During device a's deployment, it must communicate with network operator X's existing device x. Here, device manufacturer A and network operator X are issuers, while device a and device x are holders that also act as verifiers. In the current PKI system, there are three common approaches to achieve trust between a and x:

1. Manual Configuration: Both device a and device x maintain a trusted list. Administrators add the peer issuer's credentials to these lists. For example, device a adds network operator X's credentials, and device x adds device manufacturer A's.

2. Trusted Third Party: A trusted third-party T acts as the issuer to endorse their public keys for both A and X, creating trust chains T->A->a for x and T->X->x for a.

3. Cross-Credentials: A issues a credential for X's public key, and X does the same for A's, forming trust chains A->X->x for a and X->A->a for x.

However, future network is very likely to face a much more dynamic multi-stakeholder environment. Network operator X may want to dynamically engage with multiple device providers, and device provider A may supply devices for multiple network providers. In this situation, the cross-certification approach will be inefficient.

Therefore, this document proposes a method to simplify the complexity of cross-domain trust establishment by introducing a distributed trusted platform, referred to as the Public-Key-Service-Provider (PSKP). This new entity is designed to handle the registration, updating, revocation, and querying of public keys of the issuers in a multi-stakeholder environment.

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Architecture Overview

3.1. Multi-party trust

Figure 1 illustrates the traditional approach where issuers, i.e. CAs, must establish pairwise mutual trust. This process incurs high workload, and maintaining trust will require even more effort when public key updates and revocations occur.

+---------------+              +---------------+
|               |------------> |               |
|   Issuer A    |<------------ |   Issuer B    |
+---------------+              +---------------+
    |      ^                         |     ^
    |      |                         |     |
    |      |                         |     |
    |      |                         |     |
    v                                v     |
+---------------+              +---------------+
|               |------------> |               |
|   Issuer C    |<------------ |   Issuer D    |
+---------------+              +---------------+

  Figure 1 Establish mutual trust between every two issuers.

When we can establish mutual trust among multiple parties based on PKSP, as shown in Figure 2, the issuer only needs to publish registration and revocation messages of public keys/credentials to the public-Key-Service-Provider(PKSP), which can then be accessed by other issuers or verifiers when they are performing verification, then, during the verification, the verifiers may verify the token such as RFC 9207[RFC9207] and RFC 9449 [RFC9449] , or the selective disclosed token such as SD-CWT([draft-ietf-spice-sd-cwt-02])

  +---------------+                         +----------------+
  |   Issuer A    |                         |    Issuer B    |
  |               |                         |                |
  +---------------+                         +----------------+
          |                                        |
          |                                        |
          |                                        |
 +-------------------------------------------------------------+
 |                            PKSP                             |
 +-------------------------------------------------------------+
          |                                        |
          |                                        |
          |                                        |
 +----------------+                        +----------------+
 |    Issuer C    |                        |    Issuer D    |
 |                |                        |                |
 +----------------+                        +----------------+

  Figure 2 Multi-party Trust Based on PKSP

During the registration process, identity verification is usually carried out to ensure that only legitimate entities can add public keys. The service checks on the format and validity of the public key to ensure it meets the system requirements. The registration process between the issuer and the PKSP is as follows:

3.2. PKSP for verification

As a public public key service platform, PKSP accepts public key registration from issuers, stores the registered public keys securely and in a non-tamperable manner. When a verifier queries for a key, it provides the corresponding public key.

  +--------+                            +---------+
  |        |  (2)Token issuance         |         |
  | Holder |<-------------------------- | Issuer  |
  |        |                            |         |
  +--------+                            +---------+
       |                                     |
       |                                     |
       |(3)Token display                     | (1)Public Key Registration
       |                                     |
       |   +-----------------------------+   |
       |   |            PKSP             |<--+
       |   +-----------------------------+
       |                ^
       |                |(4)Public key query and token verification
       |                |
       |           +----------+
       |           |          |
       +---------->| Verifier |
                   |          |
                   +----------+

               Figure 1 System architecture of a PKSP

When a verifier is performing SD-CWT verification, it can query the public key information of relevant issuers through the PKSP. It supports various query methods, such as precise queries based on the identity identifier of the entity, credential number, etc., to quickly obtain the required public key.

The following steps shall be performed between verifiers and PKSP:

4. Enabling Technologies of PKSP

4.1. Permissioned distributed ledger

As for the implementation technology of PKSP, distributed ledger technology strongly enables PKSP to meet the following requirements. Decentralized storage spreads data across multiple nodes to prevent single-point failures. The tamper-proof data structure, formed by complex encryption, makes data modification extremely hard. Besides, the consistency maintenance based on multi - party consensus, such as the Practical Byzantine Fault Tolerance (PBFT) algorithm, ensures that multiple nodes conduct verification for public key operations in the PKSP. Only when most nodes approve are operations recorded, reducing the impact of malicious or wrong actions by individual nodes.

4.2. Operation of distributed ledger

TODO

5. Detailed protocol

TODO

6. IANA Considerations

This document has no IANA considerations.

7. Security Consideration

TODO

8. References

8.1. Normative Reference

[GS_PDL_024]
PDL, E., "Architecture enhancements for PDL service provisioning in telecom networks", , <https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=68066>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC9207]
Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9207, DOI 10.17487/9207, , <https://www.rfc-editor.org/info/rfc9207>.
[RFC9449]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/9449, , <https://www.rfc-editor.org/info/rfc9449>.

8.2. Informative References

[draft-ietf-spice-sd-cwt-02]
Prorock, M., Campbell, O., Steele, H., and R. Mahy, "SPICE SD-CWT", , <https://datatracker.ietf.org/doc/draft-ietf-spice-sd-cwt/>.
[draft-ietf-spice-use-cases-00]
Prorock, M. and B. Zundel, "Use Cases for SPICE", , <https://datatracker.ietf.org/doc/draft-ietf-spice-use-cases/>.

Acknowledgments

TODO

Authors' Addresses

Donghui Wang
Huawei
Faye Liu
Huawei
Lun Li
Huawei