[Openid Federation and X.509 PKI] division of responsabilities, x5c ops moved to annex#1095
Open
peppelinux wants to merge 2 commits into
Open
[Openid Federation and X.509 PKI] division of responsabilities, x5c ops moved to annex#1095peppelinux wants to merge 2 commits into
peppelinux wants to merge 2 commits into
Conversation
…ps moved to annex
peppelinux
requested review from
fmarino-ipzs,
giadas,
m-basili and
pcerqua-ipzs
Contributor
There was a problem hiding this comment.
Pull request overview
This PR restructures the documentation around X.509/PKIX by moving day-to-day x5c/certificate evaluation operations into an annex, and by clarifying the separation between OpenID Federation onboarding flows and PKIX-native certificate lifecycle/validation responsibilities.
Changes:
- Moved the “x5c evaluation / X.509 operations” content from the main document into a new annex page (IT/EN) and updated the Table of Contents accordingly.
- Updated Trust Infrastructure chapters (IT/EN) to emphasize that PKIX validation must be performed with standard PKIX tooling and is not replaced by federation protocol responses.
- Updated onboarding chapters (IT/EN) to reference the new annex location and to reduce coupling between federation metadata and PKIX operations.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 8 comments.
Show a summary per file
| File | Description |
|---|---|
| docs/it/x5c-evaluation.rst | Removed old main-section X.509 operations page (moved to annex). |
| docs/en/x5c-evaluation.rst | Removed old main-section X.509 operations page (moved to annex). |
| docs/it/annex/x5c-evaluation.rst | Added annex page for PKIX operational procedures (IT). |
| docs/en/annex/x5c-evaluation.rst | Added annex page for PKIX operational procedures (EN). |
| docs/it/trust-infrastructure.rst | Revised federation-vs-PKIX responsibility split; updated PKIX issuance/validation text. |
| docs/en/trust-infrastructure.rst | Revised federation-vs-PKIX responsibility split; updated PKIX issuance/validation text. |
| docs/it/entity-onboarding.rst | Updated onboarding narrative and references to point to annex PKIX operations. |
| docs/en/entity-onboarding.rst | Updated onboarding narrative and references to point to annex PKIX operations. |
| docs/it/index.rst | Removed old x5c-evaluation page from main toctree. |
| docs/en/index.rst | Removed old x5c-evaluation page from main toctree. |
| docs/it/appendix.rst | Added annex/x5c-evaluation into the appendix toctree. |
| docs/en/appendix.rst | Added annex/x5c-evaluation into the appendix toctree. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+1
to
+7
| Operazioni di Gestione dei Certificati X.509 | ||
| ============================================= | ||
|
|
||
| Questa sezione descrive il lavoro PKIX che gli operatori svolgono quando il materiale certificato è già presente nel dispiegamento. Le attività tipiche includono la costruzione delle catene, la verifica di firme ed estensioni, il controllo della revoca, la pianificazione del rinnovo prima della scadenza e la dismissione delle credenziali non più autorizzate. | ||
|
|
||
| Il rapporto tra enrolment OpenID Federation e PKIX, nonché le regole per richiedere i bundle certificati, sono chiariti in :ref:`trust-infrastructure:L'Infrastruttura di Trust` e in :ref:`trust-infrastructure:X.509 PKI`. Questa sezione resta sul piano PKIX. Le valutazioni DEVONO basarsi su librerie PKIX consolidate o su strumenti da riga di comando per X.509, anziché dedurre la fiducia solo dai metadati di federazione. | ||
|
|
Comment on lines
+1
to
+7
| X.509 Certificate Management Operations | ||
| ========================================= | ||
|
|
||
| This section describes PKIX work that operators perform once certificate material exists in the deployment. Typical tasks include building certificate chains, validating signatures and extensions, checking revocation status, planning renewal before expiry, and retiring credentials that are no longer authorised. | ||
|
|
||
| The relationship between OpenID Federation enrolment and PKIX, together with the rules for requesting certificate bundles, is explained in :ref:`trust-infrastructure:The Infrastructure of Trust` and in :ref:`trust-infrastructure:X.509 PKI`. Those chapters describe how participants obtain material during onboarding. The present section stays strictly on the PKIX side. Assessments MUST rely on conventional X.509 or PKIX libraries and command-line tools rather than on inference from federation metadata alone. | ||
|
|
| - Un JSON Web Key Set (JWKS) :rfc:`7517` che rappresenta la parte pubblica delle chiavi di firma dell'Entità in questione. Ogni JWK nel set JWK DEVE avere un ID chiave (claim kid) e PUÒ avere un parametro `x5c`, come definito in :rfc:`7517`. Contiene le Chiavi dell'Entità di Federazione richieste per le operazioni di Trust Evaluation. | ||
|
|
||
| **x5c**: Il parametro `x5c` incluso nel parametro `jwks` dell'Entity Configuration DEVE contenere solo il Certificato X.509 auto-emesso relativo al corrispondente `jwk`. | ||
| - Un JSON Web Key Set (JWKS) :rfc:`7517` che rappresenta la parte pubblica delle chiavi di firma dell'Entità in questione. Ogni JWK nel set JWK DEVE avere un ID chiave (claim kid). Contiene le Chiavi dell'Entità di Federazione richieste per le operazioni di Trust Evaluation. |
| - A JSON Web Key Set (JWKS) :rfc:`7517` that represents the public part of the signing keys of the Entity at issue. Each JWK in the JWK set MUST have a key ID (claim kid) and MAY have a `x5c` parameter, as defined in :rfc:`7517`. It contains the Federation Entity Keys required for the operations of Trust Evaluation. | ||
|
|
||
| **x5c**: The `x5c` parameter included in Entity Configuration's `jwks` parameter MUST only contain the self-issued X.509 Certificate about the corresponding `jwk`. | ||
| - A JSON Web Key Set (JWKS) :rfc:`7517` that represents the public part of the signing keys of the Entity at issue. Each JWK in the JWK set MUST have a key ID (claim kid). It contains the Federation Entity Keys required for the operations of Trust Evaluation. |
| 5. **Basic Constraints**: Il Certificato X.509 DEVE includere un'estensione ``Basic Constraints`` con ``CA:TRUE`` e una lunghezza massima del path di 1 se l'emittente del certificato è un Intermediario di Federazione. Se è una Foglia, la lunghezza massima del path DEVE essere impostata a 0. Questo indica che il Subordinato a cui il certificato si riferisce, può emettere Certificati X.509 solo su se stesso. L'estensione ``BasicConstraints`` DEVE essere impostata ``critical``. | ||
| 6. **Key Usage**: ``Digital Signature``, ``Key Encipherment``, ``Certificate Sign``, ``CRL Sign`` DEVONO essere inclusi. L'estensione ``KeyUsage`` DEVE essere impostata ``critical``. | ||
| 5. **Basic Constraints**: i certificati di **emissione dell'entità** degli Intermediari di Federazione DEVONO includere ``Basic Constraints`` con ``CA:TRUE`` e ``pathLen`` impostato dal Superiore (tipicamente ``0`` quando l'Intermediario emette solo certificati end-entity verso le Foglie). I certificati di **protocollo** end-entity rilasciati **alle** Foglie di Federazione DEVONO impostare ``CA:FALSE``. ``BasicConstraints`` DEVE essere ``critical`` ove PKIX lo richieda per questi ruoli. | ||
| 6. **Key Usage**: i certificati di emissione dell'entità degli Intermediari di Federazione DEVONO includere ``Digital Signature``, ``Key Encipherment``, ``Certificate Sign`` e ``CRL Sign`` come richiesto dal ruolo PKIX di una Certificate Authority, e DEVONO impostare ``KeyUsage`` ``critical``. I certificati di protocollo end-entity rilasciati **alle** Foglie NON DEVONO includere ``Certificate Sign`` né ``CRL Sign``; DEVONO includere ``Digital Signature`` e POSSONO includere ``Key Encipherment`` secondo il profilo applicativo. |
| 5. **Basic Constraints**: The X.509 Certificate MUST include a ``Basic Constraints`` extension with ``CA:TRUE`` and a maximum path length of 1 if the certificate issuer is a Federation Intermediate. If it is a Leaf, the maximum path length MUST be set to 0. This indicates that the Subordinate to which certificate is about, can only issue X.509 Certificates about itself. ``BasicConstraints`` extension MUST be set ``critical``. | ||
| 6. **Key Usage**: ``Digital Signature``, ``Key Encipherment``, ``Certificate Sign``, ``CRL Sign`` MUST be included. ``KeyUsage`` extension MUST be set ``critical``. | ||
| 5. **Basic Constraints**: Federation Intermediate **entity issuance** certificates MUST include ``Basic Constraints`` with ``CA:TRUE`` and a ``pathLen`` set by the Superior (typically ``0`` when the Intermediate only issues end-entity certificates to Leaves). End-entity **protocol** certificates issued **to** Federation Leaves MUST set ``CA:FALSE``. ``BasicConstraints`` MUST be ``critical`` where PKIX requires it for these roles. | ||
| 6. **Key Usage**: Federation Intermediate entity issuance certificates MUST include ``Digital Signature``, ``Key Encipherment``, ``Certificate Sign``, and ``CRL Sign`` as required for the PKIX CA role, and MUST set ``KeyUsage`` ``critical``. End-entity protocol certificates issued **to** Leaves MUST NOT include ``Certificate Sign`` or ``CRL Sign``; they MUST include ``Digital Signature`` and MAY include ``Key Encipherment`` as required by the application profile. |
| 4. **Ritiro delle pubblicazioni.** Interrompere la pubblicazione del materiale di fiducia del partecipante quando la governance lo richiede. | ||
| 5. **Conferma operativa.** Quando il deployment espone canali di registro o di stato, gli operatori DOVREBBERO verificare che i consumatori a valle abbiano recepito l'esito della revoca. | ||
|
|
||
| Esempio non normativo di richiesta di revoca del Certificato X.509 seguendo il formato :rfc:`3280`: |
| 4. **Publication withdrawal.** Stop publishing participant trust material when governance requires it. | ||
| 5. **Operational confirmation.** When the deployment provides registry or status channels, operators SHOULD confirm that downstream consumers have picked up the revocation outcome. | ||
|
|
||
| Non-normative example of X.509 Certificate revocation request following :rfc:`3280` format: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR moves x5c operations and examples to an annex
it also simplify and reduce the mixtures between openid federation 1.0 and X.509 PKI, making the latter dependant to the first only for the onboarding processes and certificates provisioning, while the entire x.509 certificate lives on their own using native PKIX tools.
It also, from an editorial perspecive, aim to reduce the text and the overall verbosity of the contents, to prepare the road for the inclusion of Trusted Lists and ETSI references.
It doesn't really introduce breaking change, since all the previous approaches are compatible with the current one proposed within this PR. The evidence is that this PR also relaxes the normative burden to the implementations.