security: add certificate revocation record

[Harsh23Kashyap]

Summary

• Add low-level Revoke and IsRevoked certificate revocation APIs in std/security.
• Store revocation entries as process-local, mutex-protected records derived from UCLA-IRL/ndnrevoke's revocation record shape.
• Derive REVOKE-style record names from certificate names and keep record metadata including the certificate name, public key hash, reason, and timestamp.
• Add tests for nil handling, unrelated certificates, repeated revocation checks, and concurrent access.

Test plan

• go test ./std/security -run 'TestCertificateRevocationRecord' -count=20
• go test -race ./std/security
• go test ./std/security
• make test

[tianyuan129]

https://github.com/UCLA-IRL/ndnrevoke.

Please use this as reference for Revocation Record.

[Harsh23Kashyap]

Thanks for the pointer. I looked through UCLA-IRL/ndnrevoke, especially the record/revoker/checker flow, and updated this PR to make the local revocation record closer to that model.

The public API is still limited to the requested low-level surface:

Revoke(cert ndn.Data)
IsRevoked(cert ndn.Data) bool

Internally, Revoke now builds and stores a revocation record instead of just a bare certificate-name set entry. The record derives a REVOKE-style name from the certificate name, stores the original cert name, public key hash, reason, and timestamp, and IsRevoked checks using that derived record name. I kept ledger/checker integration out of this PR since this still looks like the low-level API step before the app-facing flow.

I reran:

go test ./std/security -run 'TestCertificateRevocationRecord' -count=20
go test -race ./std/security
go test ./std/security
make test

All passed.

[tianyuan129]

Thanks for the initial work! I saw that you currently have a struct storing revocation records and make the code checks against that. That's exactly the next step we want to work on.

The library has a module trust_config that automates the data authentication and authorization workflow, and actually the downstream applications who uses ndnd mainly rely on the high-level APIs that are binded to this module to get rid of the crypto details.

At high level, it executes the NDN trust schema and recursively climb the certification chain for a received data until reaching a bootstrapped (or otherwise externally authenticated) trust anchor. We need corporate the revocation here -- so obviously we need to store received revocation records here....but first lets think about design space.

[Harsh23Kashyap]

Thanks for the context. I’ll pause on further implementation for now and read through trust_config and the papers first, so I understand where revocation should fit in the existing validation flow before making the next change.

[Harsh23Kashyap]

I went through the trust_config validation path and the two papers at a high level.

My understanding is that trust_config is the right place to think about the next step, because it already handles the high-level data validation flow: checking the trust schema, fetching certificates, using the certificate cache, and recursively climbing the certificate chain until a trust anchor.

I also see why the Envelope-related code can look like it jumps between trust anchors. I’ll avoid touching that part for now unless needed, and focus only on where revocation records should be stored and checked inside the current validation workflow.