X509 certificates edge cases: fixes and improvements

[ashcherbakov]

Current Behavior and Proposed Fixes

Current behavior	Proposed Changes	Comment
1. If multiple certificates share the same Subject + SKID but have different serial number or other fields: If revocation is instructed for the Subject + SKID combination, all of them will be revoked. There is no way of revoking only a "version" of them.	For Root and Non-Root: Add an optional field SerialNumber to Revocation (Soft-delete) requests; For Non-Root: Need to be add a new command to Remove certificate completely by Subject+SKID+SerialNumber (same rules as in Item 3)	Removing of Root certs is not needed right now
2. If a Root certificate is revoked (soft-delete), then all intermediate and leaf certificates signed by it are revoked as well	Change it, so that no child certificates are revoked automatically by default. Add an optional parameter to revoke transaction to enable it (False/disabled by default).	The current behavior is error-prone and may lead to unexpected consequences. On the other hand, if we change that behavior, there can be situations when there are certificates on the ledger without a valid chain (parent is revoked, child is not). So, it makes sense to make it configurable: if it's a complete revoke, then revoke all children. If it's a revoke to add a newer version of the certificate, then children can be untouched.
3. If an Intermediate certificate is revoked (soft-delete), then all leaf certificates signed by it are revoked as well	Change it, so that no child certificates are revoked automatically by default. Add an optional parameter to revoke transaction to enable it (False/disabled by default).	The current behavior is error-prone and may lead to unexpected consequences. On the other hand, id we change that behavior, there can be situations when there are certificates on the ledger without a valid chain (parent is revoked, child is not). So, it makes sense to make it configurable: if it's a complete revoke, then revoke all children. If it's a revoke to add a newer version of the certificate, then children can be untouched.
4. Only original proposer account of a Root cert with the given Subject+SKID can propose another root cert with the same Subject+SKID	Any Trustee can propose any root certificates
5. A Vendor with any VID can add certificates under a Root CA, it doesn't matter if the Root CA has a different VID as long as they have a valid certificate signed by the Root CA.	If added under a VID scoped root CA: intermediate cert must be also VID scoped to the same VID as a root one; only a Vendor associated with this VID can add an intermediate certificate. - If added under a non-VID scoped root CA associated with a VID: intermediate cert must be either VID scoped to the same VID, or non-VID scoped; only a Vendor associated with this VID can add an intermediate certificate. If added under a non-VID scoped root CA not associated with any VID: an error
6. It's not possible to overwrite a certificate.	-	Proposed workflow: Add-new -> Remove/Revoke-old. (Optional/Future): Think if we need a command to replace a certificate (for example, to update the expiration time). The command's effect can be equal to add-new -> remove-old.
7. It's possible to have multiple "versions" of a certificate with Subject + SKID combination but they all must be added by the same owner that issued the first one. Ie, have different validity time and serial number.	If the owner is a Vendor, than any Vendor account with the same VID can add/remove/revoke certificates with the same Subject + SKID combination
8. The serial numbers under a Root CA must be unique.	-
9. If a Root or Leaf certificate is revoked, there is no way of un-revoking it or proposing it back.	For Root and Non-root: Need to be able to re-add after revocation (soft-delete) or remove
10. If multiple certificates share the same Subject + SKID but have different serial number or other fields: There is no way of querying a specific "version" of a certificate.	-	The user can filter on her side. Moreover, in most of the cases the owner will keep only 1 version of Subject + SKID by revoking/removing old/expired ones

Summary of Proposed changes

Must-have for DCL 1.4

1. Changes in REVOKE_X509_CERT / REVOKE_NOC_CERT / REVOKE_ICA_CERT
   • Add an optional parameter Serial Number. If specified - only a particular certificate is revoked. If not specified - all certificates for Subject+SKID are revoked (as of now)
   • Add an optional parameter to revoke all children (chained) certificates on DCL (False be default). If True - revoke all children (as of now). If False - do not revoke child (chained) certificates.
   • Auth checks:
     • If the initial publisher is a Vendor, than any Vendor account with the same VID can revoke it
     • If the initial publisher is not a Vendor - only the same account who published can revoke it
2. Changes in PROPOSE_REVOKE_X509_ROOT_CERT / APPROVE_REVOKE_X509_ROOT_CERT
   • Add an optional parameter Serial Number. If specified - only a particular certificate is revoked. If not specified - all certificates for Subject+SKID are revoked (as of now)
   • Add an optional parameter to revoke all children (chained) certificates on DCL (False be default). If True - revoke all children (as of now). If False - do not revoke child (chained) certificates.
3. A new command REMOVE_X509_CERT / REMOVE_NOC_CERT / REMOVE_ICA_CERT
   • Auth checks:
     • If the initial publisher is a Vendor, than any Vendor account with the same VID can remove it
     • If the initial publisher is not a Vendor - only the same account who published can remove it
   • Only for Non-DA-Root certs
   • Completely removes a certificate from the State
   • Both active and revoked certificates can be removed
   • Doesn't affect child certificates (if an Intermediate certificate is removed, all leaf certs chained back to it are untouched)
4. Changes in ADD_X509_CERT / ADD_ICA_CERT
   • If added under a VID scoped root CA:
     - intermediate cert must be also VID scoped to the same VID as the root one;
     - only a Vendor associated with this VID can add an intermediate certificate.
   • If added under a non-VID scoped root CA associated with a VID:
     - intermediate cert must be either VID scoped to the same VID, or non-VID scoped;
     - only a Vendor associated with this VID can add an intermediate certificate.
   • If added under a non-VID scoped root CA not associated with any VID: an error
   • If there is another certificates with Subject-SKID exists on the ledger (active or revoked) and published by AccountX:
     - If AccountX is a Vendor - the sender can be any Vendor account with the same VID as AccountX.
     - Otherwise - the sender must be AccountX.

Should-have for DCL 1.4

1. Changes in PROPOSE_ADD_X509_ROOT_CERT
   • If there is already a root cert with the same Subject+SKID, then any Trustee account can propose the new cert with the same Subject+SKID, not only the original proposer.
   • If a certificate was revoked or removed - be able to re-propose it.
2. Changes in ADD_X509_CERT
   • If a certificate was revoked or removed - be able to re-add it.

[akarabashov]

• Functionality has been implemented as described in the ticket, with the exception of improvements listed in rows 4 and 9, which have been moved to a follow-up ticket.
• Unit and integration tests are added
• Docs are updated