lint fixed

neps/nep-0529.md

@@ -11,40 +11,52 @@ LastUpdated: 2024-06-21
 ---
 
 ## Summary
+
 Properly designed custom non-fungible-tokens (RODiT) can complement or replace digital certificates for most purposes. The design presented in this NEP can be easily extended for any number of use cases that use digital certificates. among them, mutual authentication, electronic mail, digital signing, code signing and time stamping.
 
 ## Motivation
+
 Public Key Infrastructure is a prevalent way to use public key encryption. The original motivation of this NEP proposal are the many flaws in Public Key Infrastructure. It is beyond the scope of this NEP to explain these flaws in detail, please refer to the sources \[1\]\[2\]\[3\]\[4\].
 
 Using blockchain issued tokens equivalent to digital certificates can provide better functionality than traditional digital certificates without compromising security.
 
 Currently there are no other NEP specifications covering this specific use case.
 
 Problems solved
+
 ---------------
+
 In this document we call the custom non-fungible-tokens used Rich Online Digital Tokens (RODiT for short). The problems solved are the following:
+
 1.  When implementing mutual authentication with X.509 digital certificates, the workflow has several steps, one of them requires transferring a file (CSR) between the endpoint and the CA. When using SSH digital certificates, the workflow has several steps, one of them requires registering the trusted public key in a registry of authorized keys. With RODiT we use a workflow with fewer steps, without file transfer, that is completed when the RODiT is sent (not installed), to a blockchain address. The impact of using a simpler process becomes highly significant as the number of participant endpoints grows.
 2.  With X.509 digital certificates, key rotation requires coordinated issuing and installing of new digital certificates when the key is due to be rotated, regardless of the expiration date of the service being secured with the digital certificate. SSH digital certificates expiration also require coordination across endpoints. With RODiT, key rotation is decoupled from service expiration, as it does not require issuing a new RODiT. Key rotation using RODiT can be performed independently for every endpoint, without any coordination between the parties, greatly simplifying the management of key rotation.
 3.  Rogue Certificate Authorities (Issuers in X.509 terminology) can generate digital certificates to any identifier, despite of Certificate Transparency and CAA records, making key pinning necessary in high security scenarios. Any X.509 Issuer can create a digital certificate for any domain name, while the legitimate owner of the domain name may not be aware it has been issued. While RODiT are based on smart contracts controlled by Issuers, it is the Service Providers that issue and revoke RODiT for the identifiers they control, and the Service Provider has the exclusive prerogative to authorize the smart contract. This prevents Unexpected Certificates as described in \[5\], making key pinning or Certificate Transparency unnecessary. This NEP describes a mechanism for domain names use by service providers to declare what Issuers are trusted to issue valid digital certificates for them, removing this threat.
 
 Potential use cases
--------------------
-Rich Online Digital Tokens can be used as a complement or replacement of digital certificates for VPN authentication (reference implementation at [https://github.com/cableguard]), SSH authentication and API authentication, among others.
+
+-------------------;
+
+Rich Online Digital Tokens can be used as a complement or replacement of digital certificates for VPN authentication (reference implementation at [https://github.com/cableguard]), SSH authentication and API authentication, among others.NEPs
 
 ## Scope
+
 This NEP includes RODiT structure with mandatory and optional fields. It does not include:
+
 *   Governance of RODiT, who can create RODiT issuing smart contracts and how is their reputation determined.
 *   How RODiT field values are validated to be accurate, particularly when a field is an identifier or an address.
 *   How wallets interact via IPC or other mechanisms with applications using RODiT.
 
 ## Terminology
+
 Some terms are used with a specific meaning, as follows:
+
 *   **Rich Online Digital Token**: Abbreviated as RODiT, is a non fungible token which lifecycle and structure is conformant with this document.
 *   **Service Provider**: Organization that signs its RODiT digitally and provides a service to users where RODiT are used for mutual authentication.
 *   **Issuer**: The organization that creates a smart contract that is used by the Service Providers to mint their RODiT.
 *   **Holder**: A person or system that controls a RODiT via a key pair in a cryptographic wallet.
 
 ## Specification
+
 An implementing contract MUST include the following fields on-chain:
 
 | **Field Name** | **Description** | **X.509 Equivalent** | **Type and Format** | **Default value and Valid Range** |
@@ -57,6 +69,7 @@ An implementing contract MUST include the following fields on-chain:
 For sample implementation see: [https://github.com/cableguard/cgforge/blob/mainnet/contract/src/metadata.ts]
 
 Note:
+
 *   MODIFIEDBASE\_URI is base\_uri, replacing the dot separating the TLD with the rest of the domain name with a dash “-”.
 *   SMARTCONTRACTID follows the following format: MMNNrr-MODIFIEDBASE\_URI.org
 
@@ -89,6 +102,7 @@ The following X.509 fields are not implemented as part of RODiT by default, but
 For sample implementation of custom fields see (examples with the fields cidrblock, listenport, dns, allowedips): For sample implementation see: [https://github.com/cableguard/cgforge/blob/mainnet/contract/src/metadata.ts]
 
 ## Interface
+
 Metadata applies at both the contract level (`RoditContractMetadata`) and the token level (`TokenMetadata`). The relevant metadata for each:
 
 ```java
@@ -111,7 +125,8 @@ export class TokenMetadata {
 ```
 
 Service Provider root RODiT format
----------------------------
+
+---------------------------;
 
 | **Field Name** | **Default value and Valid Range** |
 | --- | --- |
@@ -125,7 +140,8 @@ Service Provider root RODiT format
 | **serviceprovider\_signature** | SHA384WITHECDSA signature of the token\_id with private key of the blockchain address where the Service Provider root RODiT (this RODiT) is sent upon creation |
 
 Service Provider server and client RODiT format
-----------------------------------------
+
+----------------------------------------;
 
 | **Field Name** | **Default value and Valid Range** |
 | --- | --- |
@@ -140,11 +156,13 @@ Service Provider server and client RODiT format
 
 
 Handling of RODiT
------------------
+
+-----------------;
 
 The reference implementation of RODiT uses implicit accounts ([https://docs.near.org/integrator/implicit-accounts](https://docs.near.org/integrator/implicit-accounts) ). Upon creation, RODiT can be sent to final addresses or to an address from where RODiT can be distributed to final endpoint addresses. Practitioners can use NEAR CLI or NEAR CLI RS to view the content of a RODiT or send it to an address. The reference implementation uses a bash script to make handling the RODiT sets more user friendly. It can be found here: [https://github.com/cableguard/cgroditvpn](https://github.com/cableguard/cgroditvpn)
 
 The script has the following options:
+
 *   cgroditwallet.sh: List of available accounts
 *   cgroditwallet.sh _accountID_: Lists the RODiT Ids in the account and its balance
 *   cgroditwallet.sh _accountID_ keys: Displays the accountID and the Private Key of the account
@@ -156,7 +174,9 @@ The script has the following options:
 The key pair used for encryption can be rotated by sending the RODiT to a new address.
 
 Authentication with RODiT
--------------------------
+
+-------------------------;
+
 RODiT authentication is always mutual. The order for the checks and exchange protocol in the reference implementation uses the NOISE protocol (See [https://noiseprotocol.org/](https://noiseprotocol.org/)), as implemented in Wireguard ([https://www.wireguard.com/papers/wireguard.pdf](https://www.wireguard.com/papers/wireguard.pdf)), with the following steps: Initiation, Response and Confirmation.
 
 Both endpoints check that the peer can pass the following checks:
@@ -169,7 +189,9 @@ Both endpoints check that the peer can pass the following checks:
 6.  Valid: The endpoint may check optional properties of the RODiT, like location, number of transactions per minute, among other use cases.
 
 Reference Implementation - Minimum Viable Interface
----------------------------------------------------
+
+---------------------------------------------------;
+
 https://github.com/cableguard/cgtun/blob/49d01c29c656e2f34c6dc2bca67e375f9bbf8f09/cableguard/src/noise/mod.rs#L1166
 
 pub fn verify_hasrodit_getit(
@@ -193,22 +215,30 @@ pub fn verify_rodit_smartcontract_istrusted(
     own_subjectuniqueidentifierurl: String,
 
 Security Implications
----------------------
+
+---------------------;
+
 RODiT offer robust security features, including:
+
 *   Mutual authentication by default.
 *   Explicit authorization of Issuers preventing man in the middle attacks.
 *   Easy detection and recovery from key compromise. As the RODiT is associated with a blockchain address, the only way the attacker can keep exclusive control of the RODiT is moving it to a new address. This can be observed publicly as soon as it happens. Besides, as RODiT can only be verified online, so all parties will react immediately to the RODiT being revoked an will not accept it. Man in the middle attacks are far more challenging using RODiT than X.509 certificates, as we can verify validity against multiple RPC providers or even have our own local NEAR node.
 
 Alternatives
-------------
+
+------------;
+
 RODiT have been developed as an alternative to X.509 and SSH digital certificates.
 
 Future possibilities
---------------------
+
+--------------------;
+
 * RODiT could be used for SSH authentication and API authentication.
 * Using RODiT can lead to new commercialization practices by Service Providers as they can delegate sales and distribution to third parties and resellers easily, by providing stocks of RODiT.
 
 RODiT could be used as personal user accounts not connected to any directory, with fields like:
+
 *   **locationofbirth**: Place of birth in plus code format
 *   **dateandtimeofbirth**: Date and time of birth in GeneralizedTime format or RFC3339
 *   **namesshared**: Part of the full name shared with family (this is known as surname in some countries)
@@ -219,30 +249,40 @@ RODiT could be used as personal user accounts not connected to any directory, wi
 *   **postaddress**: Contact address in plus code format
 
 Consequences
-------------
+
+------------;
+
 ### Positive
+
 *   Reducing complexity and costs by consolidating authentication, configuration, and licensing of online services into a single token
 *   Preventing rogue credential issuers through a verifiable trust model
 *   Enabling seamless issuing and secure delivery of credentials to endpoints
 *   Allowing independent key rotation decoupled from license expiration
 *   Robust mutual authentication and protection against man-in-the-middle attacks
 
 ### Negative
+
 *   The current implementation does not include mechanism to encrypt the information stored in the RODiT, so it can only store information that can be made public without consequence.
 
 ### Backwards Compatibility
+
 There is no need to backwards compatibility as RODiT have a use case fundamentally different from Non-fungible tokens.
 
 Unresolved Issues (Optional)
-----------------------------
+
+----------------------------;
+
 RODiT use implicit accounts at the moment due to cryptographic wallets missing any kind of interface with other software, for example browsers. The utility of RODiT will be limited to use cases that are compatible with implicit accounts until an interface is developed.
 
 Changelog
----------
+
+---------;
+
 Version 1.0.0 Submitted for approval
 
 References
-----------
+
+----------;
 
 1.  [https://www.schneier.com/wp-content/uploads/2016/02/paper-pki.pdf](https://www.schneier.com/wp-content/uploads/2016/02/paper-pki.pdf)
 
@@ -256,10 +296,13 @@ References
 
 
 ### 1.0.0 - Initial Version
+
 > Placeholder for the context about when and who approved this NEP version.
 
 #### Benefits
+
 > List of benefits filled by the Subject Matter Experts while reviewing this version:
+
 *   Benefit 1
 *   Benefit 2
 
@@ -273,5 +316,7 @@ References
 | 2 |  |  |  |
 
 Copyright
----------
+
+---------;
+
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).