Codex Appendix I

EDGE Toolkit: Normative

APPENDIX I – PKI

(X.509 Public Key Infrastructure – CRL, CSR, and Certificates)

CHAPTER I — GENERAL PROVISIONS

Art. 1º This Appendix establishes the normative framework for the Public Key Infrastructure (PKI) implemented in the EDGE Toolkit (edgetk), based on the X.509 standard, covering digital certificates, Certificate Revocation Lists (CRLs), and Certificate Signing Requests (CSRs).

§ 1º The PKI within edgetk is designed to provide authenticity, integrity, and non-repudiation for operations in distributed and edge computing environments.

§ 2º This Appendix complies with the concepts, classifications, and objectives set forth in the General Codex of edgetk, particularly with respect to asymmetric cryptography.

---

CHAPTER II — X.509 DIGITAL CERTIFICATES

Art. 2º An X.509 digital certificate is a digitally signed data structure that binds a public key to the identity of its holder.

§ 1º The primary objectives of an X.509 certificate are:

1. to establish a trusted association between an entity and its public key;
2. to enable verification of digital signatures;
3. to support authentication in secure communication protocols.

§ 2º Each X.509 certificate shall contain, at a minimum, the following fields:

1. serial number, uniquely assigned by the issuing Certificate Authority (CA);
2. issuer distinguished name;
3. subject distinguished name;
4. subject public key information, including the public key algorithm and parameters;
5. validity period, consisting of a not-before and a not-after date;
6. digital signature of the issuing CA.

§ 3º The edgetk implementation shall support the following X.509 certificate versions:

1. version 1, for basic identity binding;
2. version 3, which adds extensions for key usage, extended key usage, and subject alternative names.

§ 4º Certificate validation in edgetk shall include, at a minimum:

1. signature verification using the issuing CA's public key;
2. validity period checking against the current system time;
3. revocation status verification via CRL.

---

CHAPTER III — CERTIFICATE REVOCATION LISTS (CRL)

Art. 3º The Certificate Revocation List (CRL) is a time-stamped data structure published by a Certificate Authority, listing digital certificates that have been revoked before their scheduled expiration date.

§ 1º The CRL is an irreversible mechanism in the sense that revoked certificates cannot be reinstated through the CRL itself; reinstatement requires issuance of a new certificate.

§ 2º Each CRL entry shall contain, at a minimum:

1. the serial number of the revoked certificate;
2. the revocation date;

§ 3º The CRL itself shall be signed by the issuing CA using its private key, ensuring authenticity and integrity.

§ 4º The edgetk implementation shall support the following CRL features:

1. CRL parsing and validation according to RFC 5280;
2. checking of the nextUpdate field to determine CRL freshness;
3. delta CRLs for incremental updates (optional).

§ 5º During certificate validation, the edgetk shall reject any certificate whose serial number appears in a valid and current CRL.

---

CHAPTER IV — CERTIFICATE SIGNING REQUESTS (CSR)

Art. 4º The Certificate Signing Request (CSR) is a structured message sent by an applicant to a Certificate Authority for the purpose of obtaining an X.509 digital certificate.

§ 1º The CSR contains the applicant's public key and identity information, both of which are authenticated by the applicant's private key signature.

§ 2º A CSR shall contain the following mandatory elements:

1. the subject distinguished name requested for the certificate;
2. the subject public key information;
3. a digital signature generated using the corresponding private key.

§ 3º A CSR may optionally include:

1. challenge password, for later revocation confirmation;
2. extension requests, such as key usage or extended key usage;
3. attributes for additional identity proofing.

§ 4º Upon receiving a CSR, the edgetk implementation shall:

1. verify the integrity of the CSR by checking the applicant's signature;
2. validate the consistency of requested fields with applicable policies;
3. reject CSRs where the signature does not match the enclosed public key.

§ 5º The edgetk may generate CSRs for the following key types, as defined in the General Codex:

1. ECDSA (NIST P-256, P-384);
2. Ed25519.

---

CHAPTER V — PKI OPERATIONAL REQUIREMENTS

Art. 5º The secure operation of PKI within edgetk depends on the following mandatory requirements:

1. protection of CA private keys using hardware security modules or equivalent secure storage;
2. regular publication and distribution of CRLs to all relying parties;
3. immediate revocation of certificates upon compromise of the corresponding private key;
4. rejection of expired or revoked certificates in all cryptographic operations.

§ 1º The validity period of certificates issued in edge environments should be kept short (e.g., days or weeks) to reduce reliance on revocation mechanisms.

§ 2º All CRLs shall be reissued at least once before the expiration of the nextUpdate field.

§ 3º The edgetk shall implement certificate path construction and validation according to the algorithms defined in RFC 5280.

---

CHAPTER VI — FINAL PROVISIONS

Art. 6º This Appendix may be extended to include additional PKI-related mechanisms, including OCSP (Online Certificate Status Protocol), certificate policies, and automated certificate management protocols such as ACME.

§ 1º Future extensions shall maintain compatibility with the X.509 standard and the classification framework established in the General Codex.

§ 2º Any deviation from the normative requirements of this Appendix must be documented and justified as a security exception.

Art. 7º This Appendix enters into force upon its publication as part of the EDGE Toolkit Normative Codex.