Repository navigation
security: persist and resolve revocation records - #224
Harsh23Kashyap wants to merge 2 commits into
Conversation
| if current, _ := tc.keychain.Store().Get(data.Name(), false); len(current) > 0 { | ||
| if bytes.Equal(current, wire.Join()) { | ||
| return nil | ||
| } | ||
| return fmt.Errorf("conflicting revocation record already stored: %s", data.Name()) | ||
| } |
There was a problem hiding this comment.
Could there be a use case for one certificate getting revoked multiple times?
There was a problem hiding this comment.
I added this check to make InsertRevoke idempotent under replay. Receiving the same wire again can happen through sync or reconnection, so that case returns nil. A different packet with the same record name is rejected instead of silently overwriting the stored record.
Since the record name is deterministic for the exact certificate, this currently gives us first-write-wins behavior. A second revocation could still be useful to correct the reason or NotBefore, so this check would be too strict if updates are meant to be supported. In that case we should define whether the later record replaces the earlier one or gets a distinct/versioned name. I'll wait for Tianyuan's view before changing the behavior.
This branch has not been deployed
2 participants
Summary
TrustConfigWhy
Consumers need to authorize a revocation target before the target certificate is necessarily cached. The exported name helper provides that exact identity without adding application-specific certificate conventions to ndnd. Durable lookup also removes the need for consumers to maintain a second in-memory revocation map.
InsertRevokeremains storage-oriented. Signature validation and application-specific authorization are caller preconditions.Tests
go test ./...go vet ./...go test -race ./std/security/...git diff --check