From 1181a209dd9c77de0b282214b93603e9b2067197 Mon Sep 17 00:00:00 2001 From: Rein Krul Date: Tue, 17 Dec 2024 12:06:39 +0100 Subject: [PATCH 01/13] RFC023: X509Credential --- rfc/rfc023-x509credential.md | 174 +++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 rfc/rfc023-x509credential.md diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md new file mode 100644 index 0000000..61347f7 --- /dev/null +++ b/rfc/rfc023-x509credential.md @@ -0,0 +1,174 @@ +# RFC023: X509Credential + +| | | +|:--------------------------|:--------------| +| Nuts foundation | R.G. Krul | +| Request for Comments: 023 | Zorg bij jou | +| | R. Groen | +| | Zorg bij jou | +| | December 2024 | + +## Abstract + +This RFC specifies the requirements and validation process for the `X509Credential`, a W3C Verifiable Credential (VC) +type issued by a `did:x509` DID. The `X509Credential` ensures strong alignment with the properties of the associated +X.509 certificate and defines mechanisms to validate the credential and verify its association with a `did:x509` DID. + +## Status of this document + +This document is a proposal for discussion and implementation. Feedback is welcome to improve the interoperability +and robustness of the specification. + +## Introduction + +The `X509Credential` is a W3C Verifiable Credential type designed for use cases where trust anchors are based on X.509 +certificates. It leverages the `did:x509` method, as specified in +the [Trust Over IP DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/). +By aligning credential subject validation with the fields of the associated `did:x509` DID and enforcing +certificate revocation checks, the `X509Credential` ensures integrity and adherence to the PKI trust model. + +Its intended use is to bridge the gap in ecosystems where issuers don't support issuance of Verifiable Credentials yet, +but do issue X.509 certificates containing relevant information about the credential subject. + +## Definitions + +- **X509Credential**: A Verifiable Credential whose issuer is a `did:x509` DID and whose structure adheres to the + requirements in this document. +- **did:x509**: A Decentralized Identifier (DID) method specified by the Trust Over IP Foundation, where the DID is + derived from an X.509 certificate. +- **Issuer Certificate**: The X.509 certificate associated with the `did:x509` DID that issued the credential. +- **Credential Subject**: The entity described by the credential. +- **Revocation Check**: The process of verifying the revocation status of the issuer certificate using mechanisms like + OCSP or CRL. + +## Credential Structure + +An `X509Credential` must conform to the general structure of a W3C Verifiable Credential and conform to the following +rules: + +- The credential MUST be in JWT format. +- `type`: MUST include `VerifiableCredential` and `X509Credential`. +- `issuer`: MUST be a valid `did:x509` identifier. +- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies. + +The credential subject can be identified by any DID method (e.g. `did:web`) accepted by the credential verifier. + +### Example `X509Credential` + +Below is an example of an `X509Credential` issued by a `did:x509` DID. The credential subject is identified by a +`did:web`. +The first snippet is the JWT header, and the second snippet is the credential payload. + +(TODO: check this example) + +```json +{ + "alg": "PS256", + "typ": "JWT", + "x5c": [ + "", + "", + "" + ], + "x5t": "", + "kid": "did:x509:0:sha256:::subject:O:Library%20The%20Bookworm::subject:L:Bookland::san:otherName:123#1" +} +``` + +(TODO: Add right JSON-LD context) +Payload: + +```json +{ + "vc": { + "@context": [ + "https://www.w3.org/2018/credentials/v1" + ], + "type": [ + "VerifiableCredential", + "X509Credential" + ], + "issuer": "did:x509:0:sha256:::subject:O:Library%20The%20Bookworm::subject:L:Bookland::san:otherName:123", + "issuanceDate": "2024-12-01T00:00:00Z", + "credentialSubject": { + "id": "did:web:example.com", + "subject:O": "Library The Bookworm", + "subject:L": "Bookland", + "san:otherName": "123" + } + } +} +``` + +## Validation + +To validate an `X509Credential`, the following steps MUST be performed: + +- Verify that the credential is in JWT format. +- Verify that the issuer's DID is a `did:x509` DID. +- Resolve the `did:x509` DID document according to the did:x509 specification and check the certificate chain for + revocation. +- Validate that the `credentialSubject` fields match the policies in the `did:x509` DID. + +### 1. Verify Credential Structure + +Ensure that the credential: + +- Includes the `X509Credential` type. +- Contains a valid `did:x509` issuer. +- Includes a `credentialSubject` whose fields match the `did:x509` DID Document. + +### 2. Validate the Issuer Certificate + +The certificate associated with the `did:x509` issuer MUST be validated as follows: + +- **Certificate Chain Validation**: The certificate must have a valid trust chain to a known root CA. +- **Revocation Check**: Verify the revocation status of the certificate using OCSP or CRL. + +Failure to validate the issuer certificate invalidates the credential. + +### 3. Validate the Credential Subject + +The `credentialSubject` MUST be verified against the `did:x509` DID Document. Specifically: + +- Every field in the `credentialSubject` MUST be present in the `did:x509` DID Document. +- Fields not present in the `did:x509` DID Document invalidate the credential. + +### 4. Verify the Proof + +The cryptographic proof of the credential MUST be verified using the public key associated with the `did:x509` DID. +This involves: + +- Resolving the public key from the DID Document. +- Verifying the signature on the credential's `proof`. + +### 5. Check Credential Expiry + +If the `issuanceDate` or any other relevant date constraints (e.g., `expirationDate`) are present, they MUST be +validated to ensure the credential is within its valid timeframe. + +## Security Considerations + +TODO: Trust, which ca-fingerprint to use, ... + +### Certificate Revocation + +The revocation status of the issuer's certificate is a critical component of `X509Credential` validation. Implementers +MUST use reliable revocation checking mechanisms (e.g., OCSP or CRL) and handle failures (e.g., network issues) +appropriately to avoid false-positive validations. + +### Field Alignment + +Restricting the `credentialSubject` fields to those present in the `did:x509` DID Document ensures alignment with the +X.509 certificate, reducing the risk of unauthorized data inclusion. + +### Proof Verification + +The cryptographic proof verification ensures that the credential has not been tampered with and was issued by the +entity controlling the `did:x509` DID. + +## References + +- [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) +- [DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/) +- [X.509 Certificate Revocation (OCSP/CRL)](https://datatracker.ietf.org/doc/html/rfc5280) From 2574caf61152d1f4b8e3e781ccc8290117a35aca Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Tue, 17 Dec 2024 19:04:19 +0100 Subject: [PATCH 02/13] Add detailed explanation of x509 certificates in RFC Expand the RFC with an in-depth introduction to x509 certificates, their structure, and their application in the Nuts network. Include details on the `did:x509` DID method and its attributes, usage of x509 for signing JWEs, and expanded specification of the Subject Other Name attribute. --- rfc/rfc023-x509credential.md | 144 +++++++++++++++++++++++++++++++++-- 1 file changed, 139 insertions(+), 5 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 61347f7..bf886f9 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -10,20 +10,45 @@ ## Abstract +Trust is a key element in the Nuts network. This RFC describes how x509 certificates can be used to source trust from +outside the Nuts network. The x509 certification process has been around for a long time and is widely used in the +internet. This RFC describes how x509 certificates can be used in the Nuts network to establish trust between parties by +being able to link the x509 certificate to a Nuts identity by as a Verifiable Credential that is issued by the holder of +the x509 identity. + This RFC specifies the requirements and validation process for the `X509Credential`, a W3C Verifiable Credential (VC) -type issued by a `did:x509` DID. The `X509Credential` ensures strong alignment with the properties of the associated -X.509 certificate and defines mechanisms to validate the credential and verify its association with a `did:x509` DID. +type issued by the holder of a x509 certificate, represented by a `did:x509` DID. The `X509Credential` ensures strong +alignment with the properties of the associated X.509 certificate and defines mechanisms to validate the credential and +verify its association with a `did:x509` DID. ## Status of this document -This document is a proposal for discussion and implementation. Feedback is welcome to improve the interoperability -and robustness of the specification. +This document is currently in draft. Feedback is welcome to improve the interoperability and robustness of the +specification. + +### Copyright Notice + +![](../.gitbook/assets/license.png) ## Introduction +The Nuts network is a network of trust. The trust is established by the use of Verifiable Credentials. These credentials +are issued by a trusted party and can be used to establish trust between parties. The Nuts network is a decentralised +network and the trust is established between parties that are not necessarily known to each other. The trust is +established by the use of Verifiable Credentials that are issued by trusted sources. Members of the Nuts network can +then trust their peers by verifying the Verifiable Credentials that are presented to them. + +At this time of writing, there are not many sources of trust available that act as trusted source of identity AND that +are capable of providing such trust in the form of Verifiable Credentials. Even tough work is being done in this area. +Most trusted sources in The Netherlands make use of systems like the x509 certificates to establish trust. This RFC +describes how x509 certificates can be used to establish trust in the Nuts network by bridging the gap between the x509 +certificates and the Nuts network. This is done by issuing a Verifiable Credential that is based on the x509 certificate +that makes use of the did:x509 method. + The `X509Credential` is a W3C Verifiable Credential type designed for use cases where trust anchors are based on X.509 certificates. It leverages the `did:x509` method, as specified in the [Trust Over IP DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/). + By aligning credential subject validation with the fields of the associated `did:x509` DID and enforcing certificate revocation checks, the `X509Credential` ensures integrity and adherence to the PKI trust model. @@ -41,7 +66,112 @@ but do issue X.509 certificates containing relevant information about the creden - **Revocation Check**: The process of verifying the revocation status of the issuer certificate using mechanisms like OCSP or CRL. -## Credential Structure +## Used standards and technologies + +This RFC builds on the following standards and technologies: + +* [X.509 Certificate Standard](https://datatracker.ietf.org/doc/html/rfc5280) +* [JSON Web Signature (JWS)](https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.6) +* [did:x509 method specification](https://trustoverip.github.io/tswg-did-x509-method-specification/), with modifications +* W3C Verifiable Credentials Data Model + +### x509 certificates, a brief introduction + +The structure of an x509 certificate is defined by the X.509 standard. An x509 certificate contains information about +the holder and is signed by a Certificate Authority (CA). The CA is a trusted party that is capable of verifying the +identity of the holder of the certificate. The CA signs the certificate with its own private key. The holder of the +certificate can then use the public key of the CA to verify the signature of the certificate. This way the holder of the +certificate can prove that the certificate is valid and that the information in the certificate is correct. + +The verifier of a x509 certificate can then trust the information in the certificate by verifying the signature of the +certificate chain of the certificate. The verifier can then trust the information in the certificate by trusting the CA +that signed the certificate. + +The chain of certificates can be viewed as a hierarchy, where the root certificate is the certificate is trusted, and +signing is delegated to intermediate certificates. The root certificate is the certificate that is trusted by the +holder. The holder maintains a list of trusted CAs that the holder trusts. The holder can then +verify the signature of the certificate chain by verifying the signature of the CA that signed the intermediate +certificate and the intermediate certificates that lead to the signing certificate. + +
+┌────────────────────┐
+│        CA          │
+└─────────┬──────────┘
+          │           
+┌─────────▼──────────┐
+│    Intermediate    │
+└─────────┬──────────┘
+          │           
+┌─────────▼──────────┐
+│    Intermediate    │
+└─────────┬──────────┘
+          │           
+┌─────────▼──────────┐
+│Signing Certificate │
+└────────────────────┘
+
+ +### Using x509 for signing JWEs + +The JWE is a standard that is used to sign and encrypt JSON objects. Thus standard allows for the signing and encryption +of JSON objects with certificates part of the a certificate chain. This allows for the signing of JSON objects with the +private key of the certificate and the verification of the signature with the public key of the certificate, and the +verification of the certificate chain with the public key of the CA. This is done by using the following headers fields: + +* x5c, the certificate chain as a list of base64 encoded certificates in the DER format, with the signing certificate + first and the root certificate last. +* x5t, the thumbprint of the signing certificate. +* x5t#S256, the thumbprint of the signing certificate as a SHA256 hash. + +### The `did:x509` DID Method + +The `did:x509` DID method is a method that can be used to create a Decentralized Identifier (DID) based on an x509 +certificate chain. This is done by creating a DID that is based on the root CA of the certificate chain. The did:x509 +method is used to specify specific attributes of the signing certificate to specify the holder of the signing +certificate. By doing this, a did:x509 DID can be used to identify the holder of the signing certificate by specifica +attributes that are assigned to the signing certificate. So, for example following did:x509: + +``` +did:x509:0:sha256:WE4P5dd8DnLHSkyHaIjhp4udlkF9LqoKwCvu9gl38jk::subject:C:US:ST:California:O:My%20Organisation +``` + +ties down the holder of the signing certificate by, first having a digitally signed certificate by the root CA with the +thumbprint `WE4P5dd8DnLHSkyHaIjhp4udlkF9LqoKwCvu9gl38jk` and then having the following attributes in the certificate: + +* Subjects: + * C: US + * ST: California + * O: My Organisation + +The did:x509 defines various attribute types that can be used as attributes, such as: + +* Subject + * C: Country + * CN: Common Name + * L: Locality + * ST: State + * O: Organisation + * OU: Organisation Unit + * STREET: Street Address +* Subject Other Name (san) + * email + * dns + * uri +* Extended Key Usage (eku) + * Any OID +* A Free-to-Use CA For Code Signing (fulcio-issuer) + * Any issuer hostname + +### Expanding the x509 specification + +This RFC extends the Subject Other Name (san) attribute with the following attribute: + +* otherName: A free-form attribute that can be used to specify any attribute that is not covered by the other + attributes. + +The otherName attribute can be used to specify extra attributes in a x509 certificate. This attribute is added to the specification of this RFC to cater for the use case where the san:otherName attribute is used in the x509 certificate and plays a role in the identification of the holder of the certificate. + +## The X509Credential Structure An `X509Credential` must conform to the general structure of a W3C Verifiable Credential and conform to the following rules: @@ -172,3 +302,7 @@ entity controlling the `did:x509` DID. - [W3C Verifiable Credentials Data Model](https://www.w3.org/TR/vc-data-model/) - [DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/) - [X.509 Certificate Revocation (OCSP/CRL)](https://datatracker.ietf.org/doc/html/rfc5280) + +## PKI overheid & UZI certificates + +## The use of x509 Verifiable Credential in the Nuts network From 12859aa336bcfb794ead7162147fabc60dc642b2 Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Thu, 19 Dec 2024 15:43:03 +0100 Subject: [PATCH 03/13] Update RFC023 to extend x509 specification and clarify usage Extend the x509 specification with additional SAN attributes and updated formatting details. Provide structured guidance on UZI certificates and their integration into the Dutch healthcare ecosystem. Elaborate on the use of x509 Verifiable Credentials within the Nuts network to establish trust. --- rfc/rfc023-x509credential.md | 112 +++++++++++++++++++++++++++++++---- 1 file changed, 102 insertions(+), 10 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index bf886f9..7b82c05 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -93,7 +93,7 @@ holder. The holder maintains a list of trusted CAs that the holder trusts. The h verify the signature of the certificate chain by verifying the signature of the CA that signed the intermediate certificate and the intermediate certificates that lead to the signing certificate. -
+```asciidoc
 ┌────────────────────┐
 │        CA          │
 └─────────┬──────────┘
@@ -109,7 +109,7 @@ certificate and the intermediate certificates that lead to the signing certifica
 ┌─────────▼──────────┐
 │Signing Certificate │
 └────────────────────┘
-
+``` ### Using x509 for signing JWEs @@ -162,12 +162,13 @@ The did:x509 defines various attribute types that can be used as attributes, suc * A Free-to-Use CA For Code Signing (fulcio-issuer) * Any issuer hostname -### Expanding the x509 specification +### Extending the x509 specification This RFC extends the Subject Other Name (san) attribute with the following attribute: -* otherName: A free-form attribute that can be used to specify any attribute that is not covered by the other - attributes. +* Subject Other Name (san) + * otherName: A free-form attribute that can be used to specify any attribute that is not covered by the other + attributes. The otherName attribute can be used to specify extra attributes in a x509 certificate. This attribute is added to the specification of this RFC to cater for the use case where the san:otherName attribute is used in the x509 certificate and plays a role in the identification of the holder of the certificate. @@ -179,7 +180,8 @@ rules: - The credential MUST be in JWT format. - `type`: MUST include `VerifiableCredential` and `X509Credential`. - `issuer`: MUST be a valid `did:x509` identifier. -- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies. +- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies with the format < + policy_type>:, for example `subject:O` or `san:otherName`. The credential subject can be identified by any DID method (e.g. `did:web`) accepted by the credential verifier. @@ -196,9 +198,9 @@ The first snippet is the JWT header, and the second snippet is the credential pa "alg": "PS256", "typ": "JWT", "x5c": [ - "", - "", - "" + "", + "", + "" ], "x5t": "", "kid": "did:x509:0:sha256:::subject:O:Library%20The%20Bookworm::subject:L:Bookland::san:otherName:123#1" @@ -236,7 +238,9 @@ To validate an `X509Credential`, the following steps MUST be performed: - Verify that the credential is in JWT format. - Verify that the issuer's DID is a `did:x509` DID. -- Resolve the `did:x509` DID document according to the did:x509 specification and check the certificate chain for +- Resolve the `did:x509` DID document according to + the [did:x509 specification](https://trustoverip.github.io/tswg-did-x509-method-specification/) and check the + certificate chain for revocation. - Validate that the `credentialSubject` fields match the policies in the `did:x509` DID. @@ -305,4 +309,92 @@ entity controlling the `did:x509` DID. ## PKI overheid & UZI certificates +The Dutch government has a Public Key Infrastructure (PKI) that is used to establish trust between parties. The PKI +framework is currently in place and makes use of PKI Overheid Certificates issued by the root CAs of the Dutch +government. In healthcare a specific instance of PKI overheid certificates are issued: the UZI certificates. These +certificates are used to establish trust between parties in the healthcare sector. The UZI certificates are issued by +the UZI register, which is a trusted party that is capable of verifying the identity of the holder of the certificate. +The UZI register signs the certificate with its own private key. The holder of the certificate can then use the public +key of the UZI register to verify the signature of the certificate. This way the holder of the certificate can prove +that the certificate is valid and that the information in the certificate is correct. The UZI certificates are issued +to: + +* Individuals that work in healthcare, such as doctors, nurses, etc. They hold this certificate on a UZI card. +* Organisations that work in healthcare, such as hospitals, pharmacies, etc. They hold this certificate as server + certificates. + +#### UZI certificate structure for organisations + +The UZI certificate is used to identify the holder of the certificate. The UZI certificate contains information about +the holder of the certificate. This information is used to identify the holder of the certificate. The UZI certificate +contains the following information (of intrest): + +* The `subject.CN` The full FQN. +* The `subject:O` the name of the holder of the certificate. +* The `subject.serialNumber ` The URI number +* The `subject.C` The subject country +* The `subject.ST` The subject state +* The `subject.L` The subject locality (city) +* The `subject.commonName` the full FQN. +* The `san:dNSName` the DNS name of the holder of the certificate. +* The `san:otherName` a string containing `------`, + where: + * `` is the OID of the CA that issued the certificate, `2.16.528.1.1007.99.2110` for CIBG. + * `` is the version number of the certificate. + * `` is the UZI number of the holder of the certificate, same as `subject.serialNumber`. + * `` is the type of the holder of the certificate, always `S`. + * `` is the subscriber URA of the holder of the certificate. + * `` is the role of the holder of the certificate, always "0.00" + * `` is the AGB code of the holder of the certificate. + ## The use of x509 Verifiable Credential in the Nuts network + +The focus on trust in the NUTS network for organizations lies primarily on the URA number identified as the +`` on the UZI certificate. This number is used to identify the holder of the certificate within the Dutch +healthcare ecosystem . The holder of the certificate can use the UZI certificate in combination with the private +key to proof the ownership of the URA number. The diagram below shows how the UZI certificate can be used to transfer +the trust from the CIBG register into the NUTS ecosystem using the `did:x509` method and the `X509Credential` Verifiable +Credential. + +```asciidoc + ┌─────────┐ ┌──────────┐ + │ Keypair ┼───────┤ did:x509 │ + └────┬────┘ └────┬─────┘ + │ │ + │ │ +┌───────────┐ ┌───────┴───────┐ │ +│ ROOT CA │ │ UZI │ ┌───────┴────────┐ ┌────┐ +└─────┬─────┘ │ Certificate │ │ X509Credential ┼───────────────► VP │ + │ └───────────────┘ └───────┬──┬─────┘ └─┬──┘ + │ │ │ │ ┌────────────┐ │ ┌────────────┐ +┌─────┴─────┐ Request ┌───────┴───────┐ │ │ │ │ │ │ │ +│ Source of ◄────────────┼ Holder of ┼─────────┴──┼────► Wallet ┼─────┴─────► Verifier │ +│ Trust ┌────────────► Trust │ Issue│ │ │ Present │ │ +└───────────┘ Issue └───────────────┘ │ └──────┬─────┘ └────────────┘ + │ │ + │ │ + ┌───────┴─┐ ┌────┴────┐ + │ did:web ├────┤ Keypair │ + └─────────┘ └─────────┘ +``` + +The main steps in the diagram are: + +* The holder generates a keypair and requests a UZI certificate from the UZI register with a Certificate Signing + Request (CSR). +* The UZI register issues the certificate to the holder of the UZI certificate and signs the request with the + intermediate CA, linked to the root CA. +* The holder of the UZI creates a `X509Credential` Verifiable Credential: + * The holder set the `did:x509` of the UZI certificate as issuer to the `X509Credential` Verifiable Credential. + * The holder includes the complete chain in the `X509Credential` Verifiable Credential. + * The holder issues the `X509Credential` Verifiable Credential to its own NUTS identity as `did:web` . + * The holder signs the `X509Credential` Verifiable Credential with the keypair associated with the UZI certificate. +* The holder places the `X509Credential` Verifiable Credential in the wallet. +* The holder presents the `X509Credential` Verifiable Credential to the verifier, and signs the presentation with the + keypair associated with the `did:web` of the holder. +* The verifier now can verify that: + * The `X509Credential` Verifiable Credential is issued by a `did:x509` issued by the the UZI register. + * The `X509Credential` Verifiable Credential is signed by the holder of the UZI certificate. + * The attributes of the `X509Credential` Verifiable Credential match the attributes of the UZI certificate. + * The URA number of the holder of the UZI certificate is present in the `X509Credential` Verifiable Credential. + From 6af5704c055035e61cd4ec8eddd4f887038d28b1 Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Thu, 19 Dec 2024 15:45:09 +0100 Subject: [PATCH 04/13] Update section title to specify UZI server certificate usage Clarified the section title to specifically refer to the UZI server certificate instead of the more generic x509 Verifiable Credential. This improves specificity and aligns the document with its intended focus. --- rfc/rfc023-x509credential.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 7b82c05..d8ffc3b 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -347,7 +347,7 @@ contains the following information (of intrest): * `` is the role of the holder of the certificate, always "0.00" * `` is the AGB code of the holder of the certificate. -## The use of x509 Verifiable Credential in the Nuts network +## The use of UZI server certificate in the Nuts network The focus on trust in the NUTS network for organizations lies primarily on the URA number identified as the `` on the UZI certificate. This number is used to identify the holder of the certificate within the Dutch From ccdbf88a97ae69fd9b350747bae9275a141bb096 Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Mon, 6 Jan 2025 19:42:18 +0100 Subject: [PATCH 05/13] Refine X509Credential validation and add UZI mapping guide. Clarified certificate chain validation rules and revocation checks. Added a section to map UZI certificates to X509Credentials, including field mappings and hierarchical structure of the UZI certificate register. This improves compatibility and compliance with the `did:x509` specification. --- rfc/rfc023-x509credential.md | 41 +++++++++++++++++++++++++++++++++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index d8ffc3b..133e9e1 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -240,8 +240,7 @@ To validate an `X509Credential`, the following steps MUST be performed: - Verify that the issuer's DID is a `did:x509` DID. - Resolve the `did:x509` DID document according to the [did:x509 specification](https://trustoverip.github.io/tswg-did-x509-method-specification/) and check the - certificate chain for - revocation. + certificate chain for revocation. - Validate that the `credentialSubject` fields match the policies in the `did:x509` DID. ### 1. Verify Credential Structure @@ -256,7 +255,8 @@ Ensure that the credential: The certificate associated with the `did:x509` issuer MUST be validated as follows: -- **Certificate Chain Validation**: The certificate must have a valid trust chain to a known root CA. +- **Certificate Chain Validation**: The certificate must have a valid trust chain. The use case determines if the CA is + trusted. - **Revocation Check**: Verify the revocation status of the certificate using OCSP or CRL. Failure to validate the issuer certificate invalidates the credential. @@ -347,6 +347,41 @@ contains the following information (of intrest): * `` is the role of the holder of the certificate, always "0.00" * `` is the AGB code of the holder of the certificate. +## Mapping UZI certificate to X509Credential + +### The ROOT Ca + +The `did:x509` specification dictates that the fingerprint of the Root CA is part of the did:x509. For mapping an UZI +certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI register hierarchy. + +```asciidoc + ┌────────────────────────────────────┐ + │ Staat der Nederlanden Root CA - G3 │ + └────────────────┬───────────────────┘ + │ +┌────────────────────────▼───────────────────────────┐ +│ Staat der Nederlanden Organisatie Services CA - G3 │ +└────────────────────────┬───────────────────────────┘ + │ + ┌────────────────────▼───────────────────────┐ + │ UZI-register Medewerker niet op naam CA G3 │ + └────────────────────────────────────────────┘ +``` + +### Field mapping +The following fields are commonly used for mapping UZI cetificates to X509Credentials +* The `subject:O` the name of the holder of the certificate. +* The `subject.L` The subject locality (city) +* The `san:otherName` a string containing `------`, + where: + * `` is the OID of the CA that issued the certificate, `2.16.528.1.1007.99.2110` for CIBG. + * `` is the version number of the certificate. + * `` is the UZI number of the holder of the certificate, same as `subject.serialNumber`. + * `` is the type of the holder of the certificate, always `S`. + * `` is the subscriber URA of the holder of the certificate. + * `` is the role of the holder of the certificate, always "0.00" + * `` is the AGB code of the holder of the certificate. + ## The use of UZI server certificate in the Nuts network The focus on trust in the NUTS network for organizations lies primarily on the URA number identified as the From 95a2f5167446d27b84f580f1e2811ed93250801c Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Tue, 7 Jan 2025 11:35:58 +0100 Subject: [PATCH 06/13] Add detailed security considerations for x509credential Expanded the Security Considerations section to include checks against the root CA structure for specific use cases. Highlighted the importance of matching the ROOT CA chain, such as for UZI certificates. This ensures clearer guidance on trust and certificate validation. --- rfc/rfc023-x509credential.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 133e9e1..1c0656c 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -283,7 +283,10 @@ validated to ensure the credential is within its valid timeframe. ## Security Considerations -TODO: Trust, which ca-fingerprint to use, ... +The following security considerations are to be considered: + +- The Root CA of the did:x509 needs to be checked against the root CA structure of the use case. For instance, in case + of UZI certificates the ROOT CA must match the associated root CA chain. ### Certificate Revocation From 9bdff453e87763faa52edcc0ab2661fca331596c Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Tue, 7 Jan 2025 11:36:23 +0100 Subject: [PATCH 07/13] Add example UZI certificate mapping in RFC023 documentation Updated the RFC023 to enhance clarity around mapping UZI certificates to X509Credentials. Added details on the ROOT G3 CA hierarchy, refined field mapping descriptions, and adjusted sections to improve readability and consistency. --- rfc/rfc023-x509credential.md | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 1c0656c..38b3482 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -310,7 +310,9 @@ entity controlling the `did:x509` DID. - [DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/) - [X.509 Certificate Revocation (OCSP/CRL)](https://datatracker.ietf.org/doc/html/rfc5280) -## PKI overheid & UZI certificates +# An application of the RFC023: UZI server certificates + +## PKI overheid & UZI server certificates The Dutch government has a Public Key Infrastructure (PKI) that is used to establish trust between parties. The PKI framework is currently in place and makes use of PKI Overheid Certificates issued by the root CAs of the Dutch @@ -352,10 +354,13 @@ contains the following information (of intrest): ## Mapping UZI certificate to X509Credential -### The ROOT Ca +The mapping of certificates to x509 is depending + +### The ROOT G3 The `did:x509` specification dictates that the fingerprint of the Root CA is part of the did:x509. For mapping an UZI -certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI register hierarchy. +certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI ROOT CA register hierarchy. +For G3 this is: ```asciidoc ┌────────────────────────────────────┐ @@ -371,9 +376,10 @@ certificate to an X509Credential the ROOT CA MUST match one of the certificates └────────────────────────────────────────────┘ ``` -### Field mapping -The following fields are commonly used for mapping UZI cetificates to X509Credentials -* The `subject:O` the name of the holder of the certificate. +### Field mapping of the UZI credential + +The following fields are commonly used for mapping UZI certificates to X509Credentials +* The `subject:O` the name of the holder of the certificate. Maps to `subject.O` in the X509Credential. * The `subject.L` The subject locality (city) * The `san:otherName` a string containing `------`, where: @@ -385,7 +391,7 @@ The following fields are commonly used for mapping UZI cetificates to X509Creden * `` is the role of the holder of the certificate, always "0.00" * `` is the AGB code of the holder of the certificate. -## The use of UZI server certificate in the Nuts network +## The use of UZI server certificate in the Nuts network or identifying organizations The focus on trust in the NUTS network for organizations lies primarily on the URA number identified as the `` on the UZI certificate. This number is used to identify the holder of the certificate within the Dutch From 6c17ad65019fab6c27e35d7f21ae08b7432f2ef3 Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Tue, 7 Jan 2025 11:41:22 +0100 Subject: [PATCH 08/13] Refactor credentialSubject structure in RFC023. Updated the `credentialSubject` definition to use a structured mapping for each type as separate maps, enhancing clarity and consistency in representation. Provided an example to illustrate the new format. --- rfc/rfc023-x509credential.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 38b3482..9988523 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -180,8 +180,17 @@ rules: - The credential MUST be in JWT format. - `type`: MUST include `VerifiableCredential` and `X509Credential`. - `issuer`: MUST be a valid `did:x509` identifier. -- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies with the format < - policy_type>:, for example `subject:O` or `san:otherName`. +- `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies with the fields mapped by each type as a separate map. An example: +``` +{ + "subject": { + "O" : "My Organisation" + }, + "san" : { + "email" : "info@example.com," + } +} +``` The credential subject can be identified by any DID method (e.g. `did:web`) accepted by the credential verifier. From 6f72f41c8f62fd4ddf59ead7544c9370021cf7e7 Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Tue, 7 Jan 2025 11:46:10 +0100 Subject: [PATCH 09/13] Normalize attribute notation in RFC023 document. Updated attribute references to use consistent dot notation (e.g., `san.otherName` and `subject.O`) instead of colon-based notation. This improves standardization and readability across the document. --- rfc/rfc023-x509credential.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 9988523..6f5a491 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -170,7 +170,7 @@ This RFC extends the Subject Other Name (san) attribute with the following attri * otherName: A free-form attribute that can be used to specify any attribute that is not covered by the other attributes. -The otherName attribute can be used to specify extra attributes in a x509 certificate. This attribute is added to the specification of this RFC to cater for the use case where the san:otherName attribute is used in the x509 certificate and plays a role in the identification of the holder of the certificate. +The otherName attribute can be used to specify extra attributes in a x509 certificate. This attribute is added to the specification of this RFC to cater for the use case where the san.otherName attribute is used in the x509 certificate and plays a role in the identification of the holder of the certificate. ## The X509Credential Structure @@ -344,14 +344,14 @@ the holder of the certificate. This information is used to identify the holder o contains the following information (of intrest): * The `subject.CN` The full FQN. -* The `subject:O` the name of the holder of the certificate. +* The `subject.O` the name of the holder of the certificate. * The `subject.serialNumber ` The URI number * The `subject.C` The subject country * The `subject.ST` The subject state * The `subject.L` The subject locality (city) * The `subject.commonName` the full FQN. -* The `san:dNSName` the DNS name of the holder of the certificate. -* The `san:otherName` a string containing `------`, +* The `san.dNSName` the DNS name of the holder of the certificate. +* The `san.otherName` a string containing `------`, where: * `` is the OID of the CA that issued the certificate, `2.16.528.1.1007.99.2110` for CIBG. * `` is the version number of the certificate. @@ -388,9 +388,9 @@ For G3 this is: ### Field mapping of the UZI credential The following fields are commonly used for mapping UZI certificates to X509Credentials -* The `subject:O` the name of the holder of the certificate. Maps to `subject.O` in the X509Credential. +* The `subject.O` the name of the holder of the certificate. Maps to `subject.O` in the X509Credential. * The `subject.L` The subject locality (city) -* The `san:otherName` a string containing `------`, +* The `san.otherName` a string containing `------`, where: * `` is the OID of the CA that issued the certificate, `2.16.528.1.1007.99.2110` for CIBG. * `` is the version number of the certificate. From b59d760dc88382ef9ea9bfee3dc64a32f8efa1dd Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Tue, 7 Jan 2025 13:20:16 +0100 Subject: [PATCH 10/13] Update rfc/rfc023-x509credential.md Co-authored-by: reinkrul --- rfc/rfc023-x509credential.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 6f5a491..37549fc 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -187,7 +187,7 @@ rules: "O" : "My Organisation" }, "san" : { - "email" : "info@example.com," + "email" : "info@example.com" } } ``` From 755055d339b0237572dd2d08d8f6df431fc82bdc Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Fri, 10 Jan 2025 11:19:02 +0100 Subject: [PATCH 11/13] Update rfc/rfc023-x509credential.md Co-authored-by: reinkrul --- rfc/rfc023-x509credential.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 37549fc..569ddac 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -162,7 +162,7 @@ The did:x509 defines various attribute types that can be used as attributes, suc * A Free-to-Use CA For Code Signing (fulcio-issuer) * Any issuer hostname -### Extending the x509 specification +### Extending the `did:x509` specification This RFC extends the Subject Other Name (san) attribute with the following attribute: From 925757484f307d16f460481183d9bb26221843d8 Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Fri, 10 Jan 2025 11:19:14 +0100 Subject: [PATCH 12/13] Rename `X509Credential` to `NutsX509Credential` in RFC023. Updated all mentions and descriptions of `X509Credential` to `NutsX509Credential` for consistency and alignment with the naming convention. This clarifies the credential's association with the Nuts ecosystem and its specific context. --- rfc/rfc023-x509credential.md | 64 ++++++++++++++++++------------------ 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index 569ddac..d995fe8 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -1,4 +1,4 @@ -# RFC023: X509Credential +# RFC023: NutsX509Credential | | | |:--------------------------|:--------------| @@ -16,8 +16,8 @@ internet. This RFC describes how x509 certificates can be used in the Nuts netwo being able to link the x509 certificate to a Nuts identity by as a Verifiable Credential that is issued by the holder of the x509 identity. -This RFC specifies the requirements and validation process for the `X509Credential`, a W3C Verifiable Credential (VC) -type issued by the holder of a x509 certificate, represented by a `did:x509` DID. The `X509Credential` ensures strong +This RFC specifies the requirements and validation process for the `NutsX509Credential`, a W3C Verifiable Credential (VC) +type issued by the holder of a x509 certificate, represented by a `did:x509` DID. The `NutsX509Credential` ensures strong alignment with the properties of the associated X.509 certificate and defines mechanisms to validate the credential and verify its association with a `did:x509` DID. @@ -45,19 +45,19 @@ describes how x509 certificates can be used to establish trust in the Nuts netwo certificates and the Nuts network. This is done by issuing a Verifiable Credential that is based on the x509 certificate that makes use of the did:x509 method. -The `X509Credential` is a W3C Verifiable Credential type designed for use cases where trust anchors are based on X.509 +The `NutsX509Credential` is a W3C Verifiable Credential type designed for use cases where trust anchors are based on X.509 certificates. It leverages the `did:x509` method, as specified in the [Trust Over IP DID:X509 Method Specification](https://trustoverip.github.io/tswg-did-x509-method-specification/). By aligning credential subject validation with the fields of the associated `did:x509` DID and enforcing -certificate revocation checks, the `X509Credential` ensures integrity and adherence to the PKI trust model. +certificate revocation checks, the `NutsX509Credential` ensures integrity and adherence to the PKI trust model. Its intended use is to bridge the gap in ecosystems where issuers don't support issuance of Verifiable Credentials yet, but do issue X.509 certificates containing relevant information about the credential subject. ## Definitions -- **X509Credential**: A Verifiable Credential whose issuer is a `did:x509` DID and whose structure adheres to the +- **NutsX509Credential**: A Verifiable Credential whose issuer is a `did:x509` DID and whose structure adheres to the requirements in this document. - **did:x509**: A Decentralized Identifier (DID) method specified by the Trust Over IP Foundation, where the DID is derived from an X.509 certificate. @@ -172,13 +172,13 @@ This RFC extends the Subject Other Name (san) attribute with the following attri The otherName attribute can be used to specify extra attributes in a x509 certificate. This attribute is added to the specification of this RFC to cater for the use case where the san.otherName attribute is used in the x509 certificate and plays a role in the identification of the holder of the certificate. -## The X509Credential Structure +## The NutsX509Credential Structure -An `X509Credential` must conform to the general structure of a W3C Verifiable Credential and conform to the following +An `NutsX509Credential` must conform to the general structure of a W3C Verifiable Credential and conform to the following rules: - The credential MUST be in JWT format. -- `type`: MUST include `VerifiableCredential` and `X509Credential`. +- `type`: MUST include `VerifiableCredential` and `NutsX509Credential`. - `issuer`: MUST be a valid `did:x509` identifier. - `credentialSubject`: MUST only contain fields explicitly present in the `did:x509` DID policies with the fields mapped by each type as a separate map. An example: ``` @@ -194,9 +194,9 @@ rules: The credential subject can be identified by any DID method (e.g. `did:web`) accepted by the credential verifier. -### Example `X509Credential` +### Example `NutsX509Credential` -Below is an example of an `X509Credential` issued by a `did:x509` DID. The credential subject is identified by a +Below is an example of an `NutsX509Credential` issued by a `did:x509` DID. The credential subject is identified by a `did:web`. The first snippet is the JWT header, and the second snippet is the credential payload. @@ -227,7 +227,7 @@ Payload: ], "type": [ "VerifiableCredential", - "X509Credential" + "NutsX509Credential" ], "issuer": "did:x509:0:sha256:::subject:O:Library%20The%20Bookworm::subject:L:Bookland::san:otherName:123", "issuanceDate": "2024-12-01T00:00:00Z", @@ -243,7 +243,7 @@ Payload: ## Validation -To validate an `X509Credential`, the following steps MUST be performed: +To validate an `NutsX509Credential`, the following steps MUST be performed: - Verify that the credential is in JWT format. - Verify that the issuer's DID is a `did:x509` DID. @@ -256,7 +256,7 @@ To validate an `X509Credential`, the following steps MUST be performed: Ensure that the credential: -- Includes the `X509Credential` type. +- Includes the `NutsX509Credential` type. - Contains a valid `did:x509` issuer. - Includes a `credentialSubject` whose fields match the `did:x509` DID Document. @@ -299,7 +299,7 @@ The following security considerations are to be considered: ### Certificate Revocation -The revocation status of the issuer's certificate is a critical component of `X509Credential` validation. Implementers +The revocation status of the issuer's certificate is a critical component of `NutsX509Credential` validation. Implementers MUST use reliable revocation checking mechanisms (e.g., OCSP or CRL) and handle failures (e.g., network issues) appropriately to avoid false-positive validations. @@ -361,14 +361,14 @@ contains the following information (of intrest): * `` is the role of the holder of the certificate, always "0.00" * `` is the AGB code of the holder of the certificate. -## Mapping UZI certificate to X509Credential +## Mapping UZI certificate to NutsX509Credential The mapping of certificates to x509 is depending ### The ROOT G3 The `did:x509` specification dictates that the fingerprint of the Root CA is part of the did:x509. For mapping an UZI -certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI ROOT CA register hierarchy. +certificate to an NutsX509Credential the ROOT CA MUST match one of the certificates in the UZI ROOT CA register hierarchy. For G3 this is: ```asciidoc @@ -387,8 +387,8 @@ For G3 this is: ### Field mapping of the UZI credential -The following fields are commonly used for mapping UZI certificates to X509Credentials -* The `subject.O` the name of the holder of the certificate. Maps to `subject.O` in the X509Credential. +The following fields are commonly used for mapping UZI certificates to NutsX509Credentials +* The `subject.O` the name of the holder of the certificate. Maps to `subject.O` in the NutsX509Credential. * The `subject.L` The subject locality (city) * The `san.otherName` a string containing `------`, where: @@ -406,7 +406,7 @@ The focus on trust in the NUTS network for organizations lies primarily on the U `` on the UZI certificate. This number is used to identify the holder of the certificate within the Dutch healthcare ecosystem . The holder of the certificate can use the UZI certificate in combination with the private key to proof the ownership of the URA number. The diagram below shows how the UZI certificate can be used to transfer -the trust from the CIBG register into the NUTS ecosystem using the `did:x509` method and the `X509Credential` Verifiable +the trust from the CIBG register into the NUTS ecosystem using the `did:x509` method and the `NutsX509Credential` Verifiable Credential. ```asciidoc @@ -417,7 +417,7 @@ Credential. │ │ ┌───────────┐ ┌───────┴───────┐ │ │ ROOT CA │ │ UZI │ ┌───────┴────────┐ ┌────┐ -└─────┬─────┘ │ Certificate │ │ X509Credential ┼───────────────► VP │ +└─────┬─────┘ │ Certificate │ │ NutsX509Credential ┼───────────────► VP │ │ └───────────────┘ └───────┬──┬─────┘ └─┬──┘ │ │ │ │ ┌────────────┐ │ ┌────────────┐ ┌─────┴─────┐ Request ┌───────┴───────┐ │ │ │ │ │ │ │ @@ -437,17 +437,17 @@ The main steps in the diagram are: Request (CSR). * The UZI register issues the certificate to the holder of the UZI certificate and signs the request with the intermediate CA, linked to the root CA. -* The holder of the UZI creates a `X509Credential` Verifiable Credential: - * The holder set the `did:x509` of the UZI certificate as issuer to the `X509Credential` Verifiable Credential. - * The holder includes the complete chain in the `X509Credential` Verifiable Credential. - * The holder issues the `X509Credential` Verifiable Credential to its own NUTS identity as `did:web` . - * The holder signs the `X509Credential` Verifiable Credential with the keypair associated with the UZI certificate. -* The holder places the `X509Credential` Verifiable Credential in the wallet. -* The holder presents the `X509Credential` Verifiable Credential to the verifier, and signs the presentation with the +* The holder of the UZI creates a `NutsX509Credential` Verifiable Credential: + * The holder set the `did:x509` of the UZI certificate as issuer to the `NutsX509Credential` Verifiable Credential. + * The holder includes the complete chain in the `NutsX509Credential` Verifiable Credential. + * The holder issues the `NutsX509Credential` Verifiable Credential to its own NUTS identity as `did:web` . + * The holder signs the `NutsX509Credential` Verifiable Credential with the keypair associated with the UZI certificate. +* The holder places the `NutsX509Credential` Verifiable Credential in the wallet. +* The holder presents the `NutsX509Credential` Verifiable Credential to the verifier, and signs the presentation with the keypair associated with the `did:web` of the holder. * The verifier now can verify that: - * The `X509Credential` Verifiable Credential is issued by a `did:x509` issued by the the UZI register. - * The `X509Credential` Verifiable Credential is signed by the holder of the UZI certificate. - * The attributes of the `X509Credential` Verifiable Credential match the attributes of the UZI certificate. - * The URA number of the holder of the UZI certificate is present in the `X509Credential` Verifiable Credential. + * The `NutsX509Credential` Verifiable Credential is issued by a `did:x509` issued by the the UZI register. + * The `NutsX509Credential` Verifiable Credential is signed by the holder of the UZI certificate. + * The attributes of the `NutsX509Credential` Verifiable Credential match the attributes of the UZI certificate. + * The URA number of the holder of the UZI certificate is present in the `NutsX509Credential` Verifiable Credential. From e8949c7d304bd6ff7d91ca05dd5b95a31783928e Mon Sep 17 00:00:00 2001 From: Roland Groen Date: Fri, 10 Jan 2025 11:21:59 +0100 Subject: [PATCH 13/13] Update terminology from JWE to JWT in RFC document Corrected the section to accurately reference JWT instead of JWE when discussing signing and encrypting JSON objects with x509 certificates. This ensures consistency and correctness in the described standard usage. --- rfc/rfc023-x509credential.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfc/rfc023-x509credential.md b/rfc/rfc023-x509credential.md index d995fe8..b7380fa 100644 --- a/rfc/rfc023-x509credential.md +++ b/rfc/rfc023-x509credential.md @@ -111,10 +111,10 @@ certificate and the intermediate certificates that lead to the signing certifica └────────────────────┘ ``` -### Using x509 for signing JWEs +### Using x509 for signing JWTs -The JWE is a standard that is used to sign and encrypt JSON objects. Thus standard allows for the signing and encryption -of JSON objects with certificates part of the a certificate chain. This allows for the signing of JSON objects with the +The JWT is a standard that is used to sign and encrypt JSON objects. Thus standard allows for the signing and encryption +of JSON objects with certificates part of a certificate chain. This allows for the signing of JSON objects with the private key of the certificate and the verification of the signature with the public key of the certificate, and the verification of the certificate chain with the public key of the CA. This is done by using the following headers fields: