Pallet AutoId

[vedhavyas]

This PR introduces pallet-auto-id with following functionality

• Register AutoId using X509 cert
• Revoke certificate
• Deactivate AutoId

This is not the full implementation of the as per spec. Current changes will get us started with above functionality. Once we have a new runtime and domain node, I'm planning to add the remaining spec post that.

I have also left some TODOs regading the revocation and deactivation. Once we have some feedback, based on the feasibility of implementation, they will be handled in the seperate PR

cc: @jfrank-summit

Code contributor checklist:

• I have read, understood and followed contributing guide

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
10089939	Triggered	Generic Private Key	a11c528	domains/pallets/auto-id/res/private.issuer.pem	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

<sup>🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

Our GitHub checks need improvements? Share your feedbacks!</sup>

[jfrank-summit]

I gave an initial pass and and left some comments regarding the general approach.

[jfrank-summit]

I had one nit and I still have some questions on overall design but we can address them later in order to begin testing sooner. @NingLin-P should also review.

[jfrank-summit]

LGTM

[NingLin-P]

Rest LGTM

[NingLin-P]

This seems problematic, since the signing data is always the same the signature is always valid, so the attacker can reuse the signature from previous blocks to construct arbitrary request.

[vedhavyas]

Good catch!
We would need some extra random data for this block for users to sign along with AutoId, we can previous block hash. UX issue with this, whichever data we pick, transaction is valid only for one block. Users need to re-sign if the transaction does not make it into the block.
Thoughts @jfrank-summit

[NingLin-P]

We would need some extra random data for this block for users to sign along with AutoId, we can previous block hash

This may not be enough as the attacker can listen to the tx pool and act something similar to MEV to front run the normal request. Ideally, we should sign the register/revoke/deactivate request itself.

[vedhavyas]

The problem still exists in that case as well since there is no specific request data for these actions.
I would need to think more this

[vedhavyas]

Actually, we can solve this with a nonce and request specific data. So even if the attacker does MEV, this signature will only be valid for specific request and specific nonce. They will end up paying for it instead of user.

Request specific data can be as simple as a enum variant. But this introduces signing nonce for each certificate operation.
cc: @jfrank-summit

[jfrank-summit]

What does the user flow look like for this? Will we iterate nonces or track used random nonces?

[vedhavyas]

every certificate will have a signing nonce like we have a nonce for the account. Along with the nonce, we also will have the request specific pre-defined data. So the final data to be signed would look like this

Action enum {
	RevokeCert
	DeactivateAutoId
	...
}

SigningData struct {
	ID
	Nonce
	Action
}

This ensures, the signature is valid for this (nonce. action) and cannot be re-used.
This does not affect the X509 certificate signing. Just the actions done by the subject of the certificate

[vanhauser-thc]

for PRs that are to be audited, we need context.
What is autoid, what are the specs etc? can you please submit links or a good description?
thank you.

[jfrank-summit]

@vanhauser-thc The needs to audit label on this PR was premature as we are still defining specs, etc.

[vedhavyas]

@vanhauser-thc yes, I tagged the label prematurely. Will reach back once we have more specs in place for your audit