RFC023: X509Credential #283

reinkrul · 2024-12-17T11:07:04Z

No description provided.

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.

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.

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

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.

rolandgroen · 2025-01-07T09:53:48Z

Request to change the structure of the attributes:

Remove the : separator
Use nested properties.

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.

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.

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.

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

gerardsn

accepted alg types should be documented. Or more specifically, PS256 should be used over RS256.

rfc/rfc023-x509credential.md

Co-authored-by: reinkrul <[email protected]>

Ensure that the DID specifies an accepted trust anchor (CA certificate) for the `ca-fingerprint` during credential validation. This strengthens the validation process by confirming the trustworthiness of the issuing CA.

Revised the credential example with updated issuer information, including organization, location, and SAN fields. This ensures the example aligns with current specification changes and provides clearer, more accurate data.

Updated the certificate revocation check to rely solely on CRL instead of both OCSP and CRL. This change aims to streamline the revocation verification process and ensure consistency in validation methods.

Replaced `subject.commonName` with `subject.CN` for clarity and consistency with standard naming conventions. Removed the `san.dNSName` entry as it was redundant or no longer required.

Corrected the alignment of diagram elements in the x509credential RFC for better visual clarity. These adjustments ensure the diagram is more readable and properly formatted.

Updated the RFC to clarify that the `NutsX509Credential` is issued by the subject of an x509 certificate, rather than its holder. This improves the precision of the specification and ensures alignment with the intended semantics.

Corrected the reference from "CIBG register" to "UZI register" to ensure accuracy in the explanation of trust transfer within the NUTS ecosystem. This aligns the documentation with the proper terminology.

Updated the X.509 certificate section to provide a clearer introduction, highlight key features, and explain the trust hierarchy more effectively. Added relevance to the Nuts framework by showcasing its integration with X.509 for decentralized identity.

The x5t field is deprecated and no longer supported, so its description has been removed for clarity. The document now accurately reflects current usage standards.

Revised the introduction to focus on the purpose and functionality of the `did:x509` method, ensuring clarity and alignment with interoperability goals. Removed redundant explanations and outdated statements to enhance readability and precision.

Refined the explanation of credential signing to specify the use of private keys associated with the UZI certificate and improved clarity on verification steps. These updates ensure better accuracy and comprehensibility of the credential lifecycle.

Revised the verification process to improve accuracy and alignment with trust anchors. Included a detailed check for the URA number in the Verifiable Credential against the trusted certificate, ensuring stricter validation.

Reordered and refined the validation process for better clarity and consistency. Removed redundant section duplicating validation instructions and fixed a formatting issue with `ca-fingerprint`.

Enhanced details on trust chain validation, including mandatory signature checks and the requirement for a DID-specified trust anchor in the certificate chain. These changes provide clearer guidance on securing credentials.

Detailed security risks and mitigation steps were added to the document, addressing issues such as broken trust chains, revocation checks, expired certificates, and weak cryptographic practices. This update improves clarity on potential threats and their consequences, enhancing the guidance for secure implementation.

Updated terminology from "holder" to "subject" for accuracy in describing entities linked to UZI certificates. Enhanced diagram explanations and added a detailed step-by-step breakdown of the trust establishment process using X.509 certificates, did:x509, and NutsX509Credential.

Updated links and references to point to the latest version (v1.1) of the Verifiable Credentials Data Model for better accuracy and alignment with current standards. Minor formatting adjustments were also made for consistency.

rolandgroen · 2025-02-05T12:49:31Z

rfc/rfc023-x509credential.md

+* [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
+* [Verifiable Credentials Data Model v1.1](https://www.w3.org/TR/vc-data-model/)


Is this version correct?

Shouldn't it be: https://www.w3.org/TR/vc-data-model-2.0/

we use 1.1, 2.0 is still in draft

reinkrul · 2025-02-07T06:18:20Z

rfc/rfc023-x509credential.md

+
+### 1. Verify Credential Structure
+
+To validate an `NutsX509Credential`, the following steps MUST be performed:


It's just X509Credential (without the Nuts prefix)

RFC023: X509Credential

1181a20

reinkrul requested a review from rolandgroen December 17, 2024 11:07

rolandgroen added 3 commits December 17, 2024 19:04

Update section title to specify UZI server certificate usage

6af5704

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.

rolandgroen assigned reinkrul Dec 19, 2024

rolandgroen requested changes Dec 19, 2024

View reviewed changes

rfc/rfc023-x509credential.md Outdated Show resolved Hide resolved

rolandgroen added 3 commits January 7, 2025 11:35

Refactor credentialSubject structure in RFC023.

6c17ad6

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.

rolandgroen marked this pull request as ready for review January 7, 2025 10:42

rolandgroen requested review from woutslakhorst, stevenvegt and gerardsn January 7, 2025 10:44

Normalize attribute notation in RFC023 document.

6f72f41

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.