Secure Patterns for Internet CrEdentials D. Wang
Internet-Draft F. Liu
Intended status: Standards Track L. Li
Expires: 3 September 2025 Huawei
2 March 2025
A Public Key Service Provider for Verification in Multiple Issuers and
Verifiers
draft-wang-spice-public-key-service-provider-00
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 3 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires 3 September 2025 [Page 1]
Internet-Draft SD-CWT PKSP March 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
4. Functions of Public Key Service . . . . . . . . . . . . . . . 4
4.1. Public Key Registration . . . . . . . . . . . . . . . . . 4
4.2. Token verification . . . . . . . . . . . . . . . . . . . 5
4.3. permissioned distributed ledger . . . . . . . . . . . . . 6
4.4. distributed ledger infrastructure . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Consideration . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative Reference . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
With the development of Web3.0, the future society and network will
become more people-oriented and facilitate more cross-field
collaboration. In this context, there will be a greater need for the
establishment of cross-field trust, which means a credential issued
by one issuer may be verified by multiple verifiers. Or a verifier
may need to verify credentials issued by multiple issuers. As a
result, it requires trust be established between each pair of issuers
and verifiers before the verification. For example, in the express-
telecom integration scenario, a courier with an express company-
issued staff credential makes calls via the telecom operator's
network. To help the recipient confirm the caller's identity and
avoid rejecting it as a nuisance call, the courier submits the
credential to the telecom operator, which then verifies it. Only
after successful verification will the call display show it's a
legitimate courier call. In this scenario, for telecom operators,
they need to be able to verify the credentials of multiple express
delivery companies. Conversely, for express delivery companies,
their credentials need to be verifiable by multiple operators.
Furthermore, as more participants join, such as express goods
Wang, et al. Expires 3 September 2025 [Page 2]
Internet-Draft SD-CWT PKSP March 2025
manufacturers, the verification relationships will become more
complex. Express delivery companies then need to build equally
complex trust relationships with them, and so on.
Therefore, the future trust establishing is no longer a simple one-
to-one or one-to-many relationship. Instead, it forms a complex
network of trust relationships. During the verification, the
verifiers need to obtain the isser's public key to 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]) . But
future complex verification relationship makes the obtaining of
issuer public keys more difficult than ever before. Different
issuers may adopt different public key disclosure mechanisms. This
requires verifiers to have the ability to get the public key one by
one, also deal with the security risks during the transmission and
storage. Otherwise, it may lead to errors in credential verification
and trigger business risks.
Based on the above requirements, this document presents a new entity
called Public-Key-Service-Provider(PSKP) for public key issues in SD-
CWT verification to provide public key registration, and querying.
To ensure its efficient, stable, and secure operation, the PSKP has
these features: distributed deployment to prevent single-point
failure, non-tamperability for data integrity, and consensus-based
data writing for consistency.
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
As shown in Figure 1, PKSP plays a crucial role in the public key
registration and verification process. 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. Besides, with the transformation of
participants' roles, for example, participant A holds a credential
issued by Participant B and also acts as an issuer to issue a
credential to Participant C. In this case, A can also register its
public key on the platform as an issuer.
Wang, et al. Expires 3 September 2025 [Page 3]
Internet-Draft SD-CWT PKSP March 2025
+--------+ +---------+
| | (2)Token issuance | |
| Holder |<-------------------------- | Issuer |
| | | |
+--------+ +---------+
| |
| |
|(3)Token display | (1)Public Key Registration
| |
| +-----------------------------+ |
| | Public-Key-Service-Provider |<--+
| +-----------------------------+
| ^
| |(4)Public key query and token verification
| |
| +----------+
| | |
+---------->| Verifier |
| |
+----------+
Figure 1 System architecture of a Public-Key-Service-Provider
As for the implementation technology of PKSP, distributed ledger
technology strongly enables PKSP to meet these features.
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. Functions of Public Key Service
4.1. Public Key Registration
It enables legitimate issuers to register their public key
information into the public key service. During the registration
process, identity verification is usually carried out to ensure that
only legitimate entities can add public keys. The service conducts
preliminary checks on the format and validity of the public key to
ensure it meets the system requirements. In a distributed ledger,
the function of public key registration can be implemented through
smart contracts. The registration process between the issuer and the
Wang, et al. Expires 3 September 2025 [Page 4]
Internet-Draft SD-CWT PKSP March 2025
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 carefully
examined 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.
4.2. Token verification
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, certificate 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 containing relevant
information to the Verifier.
Wang, et al. Expires 3 September 2025 [Page 5]
Internet-Draft SD-CWT PKSP March 2025
* 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 corresponding to this issuer.
* 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.3. permissioned distributed ledger
As a distributed ledger-based service, the PKSP is well-served by
choosing a permissioned ledger when considering efficiency and
security. The permissioned ledger aligns with PKSP requirements in
multiple ways:
* Efficiency: In contrast to public distributed ledger, the number
of nodes in a permissioned ledger is more manageable, and all
participating nodes are pre-authorized. This streamlines the
consensus process. With fewer nodes to coordinate, the time to
reach consensus is shortened, thereby enhancing PKS's business -
handling speed. For instance, in identity verification, public
key verification can be expedited, minimizing user waiting time.
* Security: The permissioned ledger features a stringent access
mechanism. Only authorized nodes can be part of it, reducing the
vulnerability to external malicious attacks. Moreover, due to
their common origin in a specific cooperation system, nodes in the
Wang, et al. Expires 3 September 2025 [Page 6]
Internet-Draft SD-CWT PKSP March 2025
permissioned ledger have a high level of mutual trust. They share
a common interest in safeguarding data security and platform
stability. This trust bolsters data security and integrity,
preventing illegal data tampering and meeting PKSP's data tamper-
resistance demands.
4.4. distributed ledger infrastructure
In the context of modern digital infrastructure development, the
establishment of a reliable PKSP ledger infrastructure is of utmost
importance. As we delve into the options for constructing this
critical infrastructure, operators stand out as highly suitable
candidates. The distributed ledger of PKSP can be built either by
Issuers with network infrastructure capabilities or based on the
existing 5G communication network infrastructure, mainly due to the
following key factors:
* 1. Network Foundation and User Identity Management Advantages:
The telecommunications network serves as the cornerstone of global
interconnection, shouldering the responsibility of serving
billions of users worldwide. During long - term operations, the
telecommunications network is deeply involved in user identity
management. As an indispensable part of identity attributes, user
tokens can be naturally and tightly bound to user identities.
This natural connection endows the construction of the PKSP ledger
infrastructure based on the telecommunications network with unique
advantages. It can effectively integrate user identity
verification and token management processes, enhancing overall
security and convenience.
* 2. Trustworthiness Assurance: Operators have accumulated
extensive social trust during their long - term operations and are
highly trustworthy organizations. Relying on this advantage,
operators can provide users with verifiable tokens, ensuring the
credibility and reliability of tokens in various business
scenarios. This not only helps to enhance users' trust in their
own digital identities but also provides a solid trust foundation
for the expansion of token - based businesses.
Wang, et al. Expires 3 September 2025 [Page 7]
Internet-Draft SD-CWT PKSP March 2025
* 3. Broad Cooperative Potential: Operators possess strong
cooperation and expansion capabilities and can carry out in -
depth cooperation with non - operator institutions such as OTT
manufacturers, authoritative organizations, and social third -
parties. Through this cross - field cooperation model, a more
abundant and diverse digital identity verification and management
ecosystem can be constructed for the whole society. It gives full
play to the advantages of all parties, realizes resource sharing
and complementarity, and further expands the coverage and
application value of the PKSP ledger infrastructure[GS_PDL_024].
5. IANA Considerations
This document has no IANA considerations.
6. Security Consideration
TODO
7. References
7.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>.
7.2. Informative References
Wang, et al. Expires 3 September 2025 [Page 8]
Internet-Draft SD-CWT PKSP March 2025
[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/>.
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 3 September 2025 [Page 9]