A Public Key Service Provider for Verification in Multiple Issuers and Verifiers
draft-wang-spice-public-key-service-provider-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Wangdonghui , Faye Liu , LUN LI | ||
| Last updated | 2025-07-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-wang-spice-public-key-service-provider-01
Secure Patterns for Internet CrEdentials D. Wang
Internet-Draft F. Liu
Intended status: Standards Track L. Li
Expires: 8 January 2026 Huawei
7 July 2025
A Public Key Service Provider for Verification in Multiple Issuers and
Verifiers
draft-wang-spice-public-key-service-provider-01
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.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires 8 January 2026 [Page 1]
Internet-Draft SD-CWT PKSP July 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 3
3.1. Multi-party trust . . . . . . . . . . . . . . . . . . . . 3
3.2. PKSP for verification . . . . . . . . . . . . . . . . . . 5
4. Enabling Technologies of PKSP . . . . . . . . . . . . . . . . 7
4.1. Permissioned distributed ledger . . . . . . . . . . . . . 7
4.2. Operation of distributed ledger . . . . . . . . . . . . . 7
5. Detailed protocol . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Consideration . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
Wang, et al. Expires 8 January 2026 [Page 2]
Internet-Draft SD-CWT PKSP July 2025
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.
Wang, et al. Expires 8 January 2026 [Page 3]
Internet-Draft SD-CWT PKSP July 2025
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:
* 1. Submission by the Issuer. The issuer initiates registration
by sending a request to the PKSP. This request contains the
issuer's public keys. Meanwhile, the issuer declares the purposes
of these keys, such as for token issuance, revocation, and so on.
Along with the public keys, detailed descriptive information about
the issuer is provided. This includes the issuer's name,
identifier, the expiration time of the public keys, as well as a
declaration of the claims of the tokens the issuer can provide.
* 2. Validation by the PKSP. Upon receiving the registration
request, the PKSP first validates issuer's public key. The
descriptive information provided by the issuer is then examined
Wang, et al. Expires 8 January 2026 [Page 4]
Internet-Draft SD-CWT PKSP July 2025
for accuracy and completeness. The PKSP may cross-reference this
information with existing databases or industry-recognized sources
to verify the issuer's legitimacy.
* 3. Response from the PKSP. If all the information is found to be
valid and compliant, the PKSP sends a registration response to the
issuer. This response includes a confirmation of successful
registration. The PKSP may also provide additional information
like the storage location of the issuer's public key within the
PKSP. In case the registration request is not approved, the PKSP
sends a rejection notice to the issuer, stating the reasons for
rejection.
* 4. Completion of Registration. Once the issuer receives a
positive response from the PKSP, the registration process is
considered complete. The issuer can then start using the
registered public key for its intended purposes and issue tokens
according to the specifications provided during registration. The
PKSP updates its records to reflect the newly registered issuer
and is ready to support the verifiers in matters related to public
key querying.
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.
Wang, et al. Expires 8 January 2026 [Page 5]
Internet-Draft SD-CWT PKSP July 2025
+--------+ +---------+
| | (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:
* 1. Token Receipt. The Holder sends the token to the Verifier.
* 2. Request for public key from PKSP. After receiving the token,
the verifier extracts the identification information of the issuer
from the token. For example, the "iss" field in the header or
payload may be found to identify the issuer. The verifier then
uses this identification information to send a request to the
PKSP, asking for the public key of this issuer.
Wang, et al. Expires 8 January 2026 [Page 6]
Internet-Draft SD-CWT PKSP July 2025
* 3. PKSP Processes the Request and Returns the Public Key. When
the PKSP receives the verifier's request, it first authenticates
the verifier's identity. After successful authentication, based
on the issuer identification provided in the request, it searches
for the corresponding public key in its storage system. Then the
PKSP returns this public key to the verifier as a response
message. The response message may also contain some metadata,
such as the expiration date of the public key and the type of the
public key.
* 4. Token Verification. The Verifier uses the public key obtained
from the PKSP to verify the token according to the signature
algorithm specified in the token.
* 5. Processing of Verification Results If the verification passes,
the verifier can perform subsequent business logic processing
based on the information in the token payload, such as allowing
the holder to access specific resources. If the verification
fails, the verifier usually rejects the operations related to this
token and may record relevant log information for subsequent
security audits and problem-troubleshooting.
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
Wang, et al. Expires 8 January 2026 [Page 7]
Internet-Draft SD-CWT PKSP July 2025
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", November 2024,
<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, March 1997,
<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, March 2022,
<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, September
2023, <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", December 2024, <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",
September 2024, <https://datatracker.ietf.org/doc/draft-
ietf-spice-use-cases/>.
Wang, et al. Expires 8 January 2026 [Page 8]
Internet-Draft SD-CWT PKSP July 2025
Acknowledgments
TODO
Authors' Addresses
Donghui Wang
Huawei
Email: wangdonghui124@huawei.com
Faye Liu
Huawei
Email: liufei19@huawei.com
Lun Li
Huawei
Email: lilun20@huawei.com
Wang, et al. Expires 8 January 2026 [Page 9]