Public Access
Share a vault with a team, without the server holding a key
M3's teams, sharing and ACLs. Teams with roles, a public-key directory, the append-only key log served for clients to check it against, team-owned vaults, and vault key grants wrapped by a client and stored opaquely by the server. VaultAccessService resolves team membership to PermissionFlags, so a viewer may pull and may not push; the desktop client reads and syncs every vault it holds a key for, and a real TEAMS screen replaces the one that said it did not exist. No migration: team, team_membership, vault.team_id and vault_key_grant have all been there since the first one, which is what carrying two unused tables bought. Membership is authorisation. A grant is access. The obvious model is one concept — "access", with a role attached, handed out by the server — and this architecture cannot implement it: a vault key is sealed to each member's X25519 key, and only a client holding the plaintext can seal it for somebody else. So "give Bob access" decomposes into a database write and a wrap, which happen on different machines. Adding a member makes the server serve them the vault; it cannot make it readable. VaultSummary.WrappedVaultKey is null in the meantime and the vault appears in their list saying it is waiting for a key, because hiding it until a grant existed would have been tidier and would have implied the server was the thing granting access. The screen says the same thing after every add, in the status line. ADR 0009 records the whole decision. Sharing verifies or refuses. A directory lookup is a claim by the server about a third party's public key, and wrapping to an unverified claim hands the vault to whoever made it — no amount of transport security helps, because the server is inside the threat model. KeyLogAudit reads the whole log, recomputes every entry's hash from its own contents, checks the chain from genesis, and refuses unless the offered key appears in it unchanged. There is no override flag: one that exists gets used on the day the log is briefly unreachable, and the resulting grant is indistinguishable from a correct one afterwards. What it still cannot promise is that the key is the right person's, so the fingerprint comes back for an out-of-band comparison and the success message says so every time. A test corrupts the fake server's log by one byte and watches the client refuse rather than warn. The roles are only the ones that are enforceable. There is no ConnectOnly, despite the design asking for one and TeamRole having room: SSH terminates on the client, so a session needs the credential's plaintext on that machine, and "may connect but may not read the key" cannot be enforced here. Shipping it as an option in a dropdown would have been a lie. Connect rides along with Read and is documented as an interface hint. Removal is named for what it does — it revokes grants and flags the vault for rekey, and claims nothing about what is already on somebody's laptop. Three things are deliberately absent, and each is a refusal rather than an omission. The rekey itself, because re-wrapping every item's data key under a new vault key needs a client holding the current one; the server records that a rotation is owed and the interface reports it, which is more honest than a button that only appears to do it. Ownership transfer, because allowing an owner to be removed without one leaves a team nobody can administer. And cross-vault host key trust: a pin in a team vault is listed but not consulted at connect time, because any member with Write could otherwise pre-approve a fingerprint another member's client then trusts silently for a host in their own vault. Scoping trust properly needs a scope on the SSH connect path, which IKnownHostStore has not got; until then the narrow direction is the safe one and the cost is in the README rather than hidden. Reading now spans vaults and writing still does not. Every list on the vault and hosts screens covers each vault the keyring opened, rows carry the vault they came from, and an edit goes back to that vault rather than to the active one — writing it to the active vault would fork the item and only show up when a colleague wondered why their change never arrived. A new item goes wherever a picker says, defaulting to the personal vault and never moving on its own, because an item filed into a team's vault is visible to that team and moving it back means deleting and retyping. The sidebar heading stops naming one vault once there are two, and each row names its own. The server checks what it can and nothing it cannot. It will not record a grant for a key its recipient no longer holds, for a superseded generation, or for somebody who is not in the team — each of those would otherwise surface days later at the far end as a tag failure indistinguishable from corruption. It does not verify the wrap or the signature, and the grant service says so: that would be a convenience and never the boundary, and would put an asymmetric implementation on a machine that is supposed to hold no keys. Two bugs the tests found. TeamsViewModel's busy gate blocked its own reload, so a team created a moment earlier was missing from the list it had just been added to. And syncing every vault turned a failure from an exception into a report, which made a background pass announce an unreachable vault once a minute — the exact behaviour AnAutomaticPassThatFails_LeavesTheStatusAlone exists to prevent. The fact is recorded and the message swallowed, as it was before; pressing Sync still names the vault and the reason. Also fixes a build break this branch started with: QuickConnectTests was never updated when M2 added ISftpSessionFactory to the shell's constructor, so nothing built at all.
This commit is contained in:
@@ -97,6 +97,22 @@ public interface IVaultServer : IDisposable
|
||||
/// <summary>Pull and push.</summary>
|
||||
ISyncApi Sync { get; }
|
||||
|
||||
/// <summary>Teams, their members, and the vaults they own.</summary>
|
||||
ITeamApi Teams { get; }
|
||||
|
||||
/// <summary>
|
||||
/// The public-key directory, and the key log that makes an answer from it checkable.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// Exposed as one member because the two are only ever used together: a directory answer is a claim
|
||||
/// the server makes about somebody else's key, and the log is what turns it into something a client
|
||||
/// can verify. See <c>KeyLogAudit</c>.
|
||||
/// </remarks>
|
||||
IDirectoryApi Directory { get; }
|
||||
|
||||
/// <summary>Vault key grants: who can open a vault, and who let them.</summary>
|
||||
IVaultGrantApi Grants { get; }
|
||||
|
||||
/// <summary>Obtains the identity provider's signature over a key statement.</summary>
|
||||
IKeyBindingAuthorizer KeyBinding { get; }
|
||||
|
||||
@@ -164,6 +180,15 @@ public sealed class ServerConnection : IVaultServer
|
||||
/// <inheritdoc />
|
||||
public ISyncApi Sync => Api;
|
||||
|
||||
/// <inheritdoc />
|
||||
public ITeamApi Teams => Api;
|
||||
|
||||
/// <inheritdoc />
|
||||
public IDirectoryApi Directory => Api;
|
||||
|
||||
/// <inheritdoc />
|
||||
public IVaultGrantApi Grants => Api;
|
||||
|
||||
/// <inheritdoc />
|
||||
public IKeyBindingAuthorizer KeyBinding => Oidc;
|
||||
|
||||
|
||||
@@ -26,6 +26,25 @@ public sealed record ConflictNotice(
|
||||
IReadOnlyList<ConflictDetailEntry> Fields,
|
||||
DateTimeOffset DetectedAt);
|
||||
|
||||
/// <summary>One vault's outcome from a pass over all of them.</summary>
|
||||
/// <param name="VaultId">The vault.</param>
|
||||
/// <param name="Name">Its display name, so a message about it can name it.</param>
|
||||
/// <param name="Report">What the pass did, when it completed.</param>
|
||||
/// <param name="Failure">
|
||||
/// Why it did not, when it failed. Carried rather than thrown so one unreachable team vault cannot
|
||||
/// leave the others unsynced — and reported rather than swallowed, because a vault that silently
|
||||
/// stopped syncing is the worst of the three outcomes.
|
||||
/// </param>
|
||||
public sealed record VaultSyncReport(
|
||||
Guid VaultId,
|
||||
string Name,
|
||||
SyncReport? Report,
|
||||
Exception? Failure)
|
||||
{
|
||||
/// <summary>Whether this vault synced.</summary>
|
||||
public bool Succeeded => Report is not null;
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// An unlocked vault: the keys are in memory, the cache is open, and the hosts are readable.
|
||||
/// </summary>
|
||||
@@ -41,7 +60,7 @@ public sealed record ConflictNotice(
|
||||
/// perfectly usable with no network at all and syncing is the occasional thing that needs one.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed class VaultSession : IAsyncDisposable
|
||||
public sealed partial class VaultSession : IAsyncDisposable
|
||||
{
|
||||
private readonly UserSecretBundle bundle;
|
||||
private readonly LocalCacheProtector protector;
|
||||
@@ -87,11 +106,28 @@ public sealed class VaultSession : IAsyncDisposable
|
||||
public StoredUnlockMaterial Profile { get; }
|
||||
|
||||
/// <summary>Every vault this user can reach, readable or not.</summary>
|
||||
public IReadOnlyList<StoredVault> Vaults { get; }
|
||||
/// <remarks>
|
||||
/// Re-read rather than fixed at unlock: a vault a teammate shares arrives mid-session, and one
|
||||
/// whose grant is withdrawn stops being readable mid-session too. <see cref="RefreshVaultsAsync"/>
|
||||
/// is what moves it, and it is the only thing that does.
|
||||
/// </remarks>
|
||||
public IReadOnlyList<StoredVault> Vaults { get; private set; }
|
||||
|
||||
/// <summary>The vault the interface is showing. The personal one, for now.</summary>
|
||||
/// <summary>
|
||||
/// The vault new items are created in.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// One vault is the write target, not the read set — reading spans every vault the keyring opened.
|
||||
/// It stays the first readable one, which is the personal vault whenever there is one, because an
|
||||
/// application that silently filed a new host into a team's vault because that was the last thing
|
||||
/// selected would be the wrong default in the one direction that is hard to undo.
|
||||
/// </remarks>
|
||||
public Guid ActiveVaultId { get; }
|
||||
|
||||
/// <summary>Every vault this session actually holds a key for.</summary>
|
||||
public IEnumerable<StoredVault> ReadableVaults =>
|
||||
Vaults.Where(vault => keyring.CanRead(vault.VaultId));
|
||||
|
||||
/// <summary>Hosts, decrypted, with unpushed local changes laid over them.</summary>
|
||||
public HostRepository Hosts { get; }
|
||||
|
||||
@@ -133,10 +169,14 @@ public sealed class VaultSession : IAsyncDisposable
|
||||
/// </remarks>
|
||||
internal UnlockStore Unlock { get; }
|
||||
|
||||
/// <summary>Runs one synchronisation pass over the active vault.</summary>
|
||||
/// <summary>Runs one synchronisation pass over one vault.</summary>
|
||||
/// <param name="api">The transport. Supplied per call because a session outlives any one connection.</param>
|
||||
/// <param name="vaultId">The vault to sync.</param>
|
||||
/// <param name="cancellationToken">Cancellation token.</param>
|
||||
public Task<SyncReport> SyncAsync(ISyncApi api, CancellationToken cancellationToken)
|
||||
public Task<SyncReport> SyncAsync(
|
||||
ISyncApi api,
|
||||
Guid vaultId,
|
||||
CancellationToken cancellationToken)
|
||||
{
|
||||
ObjectDisposedException.ThrowIf(disposed, this);
|
||||
ArgumentNullException.ThrowIfNull(api);
|
||||
@@ -144,7 +184,51 @@ public sealed class VaultSession : IAsyncDisposable
|
||||
var engine = new SyncEngine(
|
||||
api, Items, Outbox, SyncState, Conflicts, keyring, clock, options);
|
||||
|
||||
return engine.SyncAsync(ActiveVaultId, cancellationToken);
|
||||
return engine.SyncAsync(vaultId, cancellationToken);
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Runs one synchronisation pass over every vault this session can read.
|
||||
/// </summary>
|
||||
/// <returns>One report per vault, in the order they were synced.</returns>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// Sequential rather than concurrent. Each vault has its own cursor and its own outbox, so nothing
|
||||
/// forces the order — but a client that opened one connection per vault would multiply its request
|
||||
/// rate by the number of teams somebody is in, against a server the same person is also using
|
||||
/// interactively. Vaults are few and passes are cheap.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// A vault that throws does not stop the rest. One team's vault being unreachable — a revoked grant
|
||||
/// noticed mid-pass, a server-side fault — is not a reason to leave the personal vault unsynced,
|
||||
/// and the failure is reported per vault rather than as one exception naming none of them.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public async Task<IReadOnlyList<VaultSyncReport>> SyncAllAsync(
|
||||
ISyncApi api,
|
||||
CancellationToken cancellationToken)
|
||||
{
|
||||
ObjectDisposedException.ThrowIf(disposed, this);
|
||||
ArgumentNullException.ThrowIfNull(api);
|
||||
|
||||
var reports = new List<VaultSyncReport>();
|
||||
|
||||
foreach (var vault in ReadableVaults.ToList())
|
||||
{
|
||||
try
|
||||
{
|
||||
var report = await SyncAsync(api, vault.VaultId, cancellationToken)
|
||||
.ConfigureAwait(false);
|
||||
|
||||
reports.Add(new VaultSyncReport(vault.VaultId, vault.Name, report, null));
|
||||
}
|
||||
catch (Exception exception) when (exception is not OperationCanceledException)
|
||||
{
|
||||
reports.Add(new VaultSyncReport(vault.VaultId, vault.Name, null, exception));
|
||||
}
|
||||
}
|
||||
|
||||
return reports;
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
|
||||
@@ -0,0 +1,293 @@
|
||||
using System.Security.Cryptography;
|
||||
using DodoSSH.Client.Api;
|
||||
using DodoSSH.Client.Storage;
|
||||
using DodoSSH.Client.Sync;
|
||||
using DodoSSH.Contracts;
|
||||
using DodoSSH.Crypto;
|
||||
|
||||
namespace DodoSSH.Client.Session;
|
||||
|
||||
/// <summary>What a share attempt did.</summary>
|
||||
/// <param name="Shared">Whether a grant was recorded.</param>
|
||||
/// <param name="Verification">
|
||||
/// How the recipient's key was checked. Present whether or not the share went ahead, because a refusal
|
||||
/// is the interesting outcome and the reason for it is the whole of what a user needs to see.
|
||||
/// </param>
|
||||
/// <param name="Message">One line for a person. Never contains key material.</param>
|
||||
public sealed record ShareOutcome(
|
||||
bool Shared,
|
||||
RecipientVerification Verification,
|
||||
string Message);
|
||||
|
||||
/// <summary>
|
||||
/// Sharing, from the side that holds the keys.
|
||||
/// </summary>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// These live on <see cref="VaultSession"/> rather than in a service above it for the reason
|
||||
/// registering a device does: wrapping a vault key is the one step only an unlocked session can
|
||||
/// perform, and this type is the keyring's custodian. Everything else — the calls, the directory —
|
||||
/// arrives as a parameter, so the session still knows nothing about how either is implemented.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// <b>Nothing here trusts the server's answer about somebody else's key.</b> Every share reads the
|
||||
/// whole key log, verifies its hash chain, and refuses unless the directory's answer appears in it
|
||||
/// unchanged. That check is the difference between end-to-end encryption and a server that can read
|
||||
/// everything by handing out a key of its own; see <see cref="KeyLogAudit"/> and ADR 0001.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public sealed partial class VaultSession
|
||||
{
|
||||
/// <summary>
|
||||
/// Creates a vault owned by a team, generating its key here.
|
||||
/// </summary>
|
||||
/// <param name="api">The team calls.</param>
|
||||
/// <param name="teamId">The owning team.</param>
|
||||
/// <param name="name">Display name. Plaintext, as all vault names are.</param>
|
||||
/// <param name="cancellationToken">Cancellation token.</param>
|
||||
/// <returns>The new vault, already readable by this session.</returns>
|
||||
/// <remarks>
|
||||
/// The key never leaves this process in the clear: it is generated here, sealed to this user's own
|
||||
/// encryption key, and the seal is what the server stores. The creator's grant carries no key log
|
||||
/// head, exactly as a personal vault's does not — there is no third party whose key could have been
|
||||
/// substituted when you wrap something to yourself.
|
||||
/// </remarks>
|
||||
public async Task<StoredVault> CreateTeamVaultAsync(
|
||||
ITeamApi api,
|
||||
Guid teamId,
|
||||
string name,
|
||||
CancellationToken cancellationToken)
|
||||
{
|
||||
ObjectDisposedException.ThrowIf(disposed, this);
|
||||
ArgumentNullException.ThrowIfNull(api);
|
||||
ArgumentException.ThrowIfNullOrWhiteSpace(name);
|
||||
|
||||
var vaultId = Guid.CreateVersion7();
|
||||
var vaultKey = VaultKeys.Create();
|
||||
var now = clock.GetUtcNow();
|
||||
|
||||
try
|
||||
{
|
||||
var request = BuildCreateRequest(vaultId, vaultKey, name, now);
|
||||
|
||||
var summary = await api.CreateTeamVaultAsync(teamId, request, cancellationToken)
|
||||
.ConfigureAwait(false);
|
||||
|
||||
var stored = ToStored(summary);
|
||||
|
||||
await Vault.UpsertAsync(stored, cancellationToken).ConfigureAwait(false);
|
||||
|
||||
// Adopted rather than unwrapped from the response: this process generated the key, so
|
||||
// unwrapping the server's copy of our own seal would be a round trip to learn something we
|
||||
// already know. The keyring takes ownership from here.
|
||||
keyring.Adopt(vaultId, vaultKey, summary.KeyGeneration);
|
||||
|
||||
Vaults = await Vault.ListAsync(cancellationToken).ConfigureAwait(false);
|
||||
|
||||
return stored;
|
||||
}
|
||||
catch
|
||||
{
|
||||
// Never reached the keyring, so this is the only thing that can release it.
|
||||
CryptographicOperations.ZeroMemory(vaultKey);
|
||||
throw;
|
||||
}
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Wraps a vault's key to another member, after verifying their published key.
|
||||
/// </summary>
|
||||
/// <param name="grants">The grant calls.</param>
|
||||
/// <param name="directory">The directory and the key log that makes it checkable.</param>
|
||||
/// <param name="vaultId">The vault to share.</param>
|
||||
/// <param name="recipientUserId">Who to share it with.</param>
|
||||
/// <param name="cancellationToken">Cancellation token.</param>
|
||||
/// <remarks>
|
||||
/// <para>
|
||||
/// The verification is not optional and is not a parameter. A caller that could pass
|
||||
/// <c>skipChecks: true</c> is a caller that will, on the day the log is briefly unreachable, and the
|
||||
/// resulting grant is indistinguishable from a correct one afterwards.
|
||||
/// </para>
|
||||
/// <para>
|
||||
/// What this still cannot promise is that the key belongs to the person you meant. Compare
|
||||
/// <see cref="VerifiedRecipient.Fingerprint"/> with them over a channel this server does not carry;
|
||||
/// that is the only step that closes the gap, and the outcome message says so.
|
||||
/// </para>
|
||||
/// </remarks>
|
||||
public async Task<ShareOutcome> ShareVaultAsync(
|
||||
IVaultGrantApi grants,
|
||||
IDirectoryApi directory,
|
||||
Guid vaultId,
|
||||
Guid recipientUserId,
|
||||
CancellationToken cancellationToken)
|
||||
{
|
||||
ObjectDisposedException.ThrowIf(disposed, this);
|
||||
ArgumentNullException.ThrowIfNull(grants);
|
||||
ArgumentNullException.ThrowIfNull(directory);
|
||||
|
||||
if (!keyring.TryGet(vaultId, out var vaultKey, out var keyGeneration))
|
||||
{
|
||||
throw new VaultUnreadableException(vaultId);
|
||||
}
|
||||
|
||||
var entry = await directory.LookupByIdAsync(recipientUserId, cancellationToken)
|
||||
.ConfigureAwait(false);
|
||||
|
||||
var log = await KeyLogAudit.ReadAsync(directory, cancellationToken).ConfigureAwait(false);
|
||||
var verification = KeyLogAudit.Verify(log, entry);
|
||||
|
||||
if (!verification.IsVerified)
|
||||
{
|
||||
return new ShareOutcome(false, verification, verification.Message);
|
||||
}
|
||||
|
||||
var recipient = verification.Recipient!;
|
||||
|
||||
await IssueAsync(grants, vaultId, vaultKey, keyGeneration, recipient, cancellationToken)
|
||||
.ConfigureAwait(false);
|
||||
|
||||
return new ShareOutcome(
|
||||
true,
|
||||
verification,
|
||||
"Shared. Check the fingerprint with them out of band — everything the client can verify on "
|
||||
+ "its own only proves this server has been consistent with itself.");
|
||||
}
|
||||
|
||||
/// <summary>
|
||||
/// Re-reads which vaults the server says are reachable, and opens any that have become readable.
|
||||
/// </summary>
|
||||
/// <returns>How many vaults this call made readable that were not before.</returns>
|
||||
/// <remarks>
|
||||
/// Called after a share and on a periodic pass. A vault somebody shared a minute ago arrives as a
|
||||
/// new entry with a wrapped key attached; one whose grant was revoked arrives without one, and is
|
||||
/// marked unreadable rather than quietly dropped so the interface can say what happened. Items
|
||||
/// already pulled are deliberately left alone — see <see cref="VaultStore.ReplaceAllAsync"/>.
|
||||
/// </remarks>
|
||||
public async Task<int> RefreshVaultsAsync(IAccountApi api, CancellationToken cancellationToken)
|
||||
{
|
||||
ObjectDisposedException.ThrowIf(disposed, this);
|
||||
ArgumentNullException.ThrowIfNull(api);
|
||||
|
||||
var me = await api.GetMeAsync(cancellationToken).ConfigureAwait(false);
|
||||
|
||||
await Vault.ReplaceAllAsync([.. me.Vaults.Select(ToStored)], cancellationToken)
|
||||
.ConfigureAwait(false);
|
||||
|
||||
Vaults = await Vault.ListAsync(cancellationToken).ConfigureAwait(false);
|
||||
|
||||
var admitted = 0;
|
||||
|
||||
foreach (var vault in Vaults)
|
||||
{
|
||||
if (keyring.CanRead(vault.VaultId))
|
||||
{
|
||||
continue;
|
||||
}
|
||||
|
||||
if (keyring.TryAdmit(bundle, vault))
|
||||
{
|
||||
admitted++;
|
||||
}
|
||||
else
|
||||
{
|
||||
keyring.MarkUnreadable(vault.VaultId);
|
||||
}
|
||||
}
|
||||
|
||||
return admitted;
|
||||
}
|
||||
|
||||
/// <summary>Signs and posts one grant.</summary>
|
||||
private async Task IssueAsync(
|
||||
IVaultGrantApi grants,
|
||||
Guid vaultId,
|
||||
ReadOnlyMemory<byte> vaultKey,
|
||||
uint keyGeneration,
|
||||
VerifiedRecipient recipient,
|
||||
CancellationToken cancellationToken)
|
||||
{
|
||||
var now = clock.GetUtcNow();
|
||||
var entry = recipient.Entry;
|
||||
|
||||
var wrapped = VaultKeys.WrapTo(
|
||||
vaultKey.Span, entry.EncryptionPublicKey, vaultId, keyGeneration);
|
||||
|
||||
var ownFingerprint = DshCrypto.ComputeFingerprint(
|
||||
bundle.EncryptionPublicKey, bundle.SigningPublicKey);
|
||||
|
||||
var canonical = GrantStatementCodec.Encode(
|
||||
vaultId,
|
||||
keyGeneration,
|
||||
GrantPurpose.Member,
|
||||
granteeUserId: entry.UserId,
|
||||
granteeKeyFingerprint: recipient.Fingerprint,
|
||||
wrappedKey: wrapped,
|
||||
granterUserId: Profile.UserId,
|
||||
granterKeyFingerprint: ownFingerprint,
|
||||
|
||||
// Present, unlike a self-grant's. This is the third-party case the head exists for: it
|
||||
// records which view of the key log this client held while wrapping, so a server showing
|
||||
// two clients different logs has to keep both stories straight for ever after.
|
||||
keyLogHead: recipient.KeyLogHead,
|
||||
grantedAt: now);
|
||||
|
||||
await grants.IssueVaultGrantAsync(
|
||||
vaultId,
|
||||
new IssueVaultGrantRequest(
|
||||
RecipientUserId: entry.UserId,
|
||||
RecipientKeyFingerprint: recipient.Fingerprint,
|
||||
KeyGeneration: keyGeneration,
|
||||
WrappedVaultKey: wrapped,
|
||||
KeyLogHead: recipient.KeyLogHead,
|
||||
GrantSignature: GrantStatementCodec.Sign(bundle.SigningKey, canonical),
|
||||
GrantedAt: now),
|
||||
cancellationToken)
|
||||
.ConfigureAwait(false);
|
||||
}
|
||||
|
||||
/// <remarks>
|
||||
/// The signature covers the vault id, so the id has to be chosen before anything is wrapped — which
|
||||
/// is also what makes a create whose response was lost safe to send again.
|
||||
/// </remarks>
|
||||
private CreateTeamVaultRequest BuildCreateRequest(
|
||||
Guid vaultId,
|
||||
byte[] vaultKey,
|
||||
string name,
|
||||
DateTimeOffset now)
|
||||
{
|
||||
var wrapped = VaultKeys.WrapTo(vaultKey, bundle.EncryptionPublicKey, vaultId, 1);
|
||||
|
||||
var fingerprint = DshCrypto.ComputeFingerprint(
|
||||
bundle.EncryptionPublicKey, bundle.SigningPublicKey);
|
||||
|
||||
var canonical = GrantStatementCodec.Encode(
|
||||
vaultId,
|
||||
keyGeneration: 1,
|
||||
GrantPurpose.Member,
|
||||
granteeUserId: Profile.UserId,
|
||||
granteeKeyFingerprint: fingerprint,
|
||||
wrappedKey: wrapped,
|
||||
granterUserId: Profile.UserId,
|
||||
granterKeyFingerprint: fingerprint,
|
||||
keyLogHead: default,
|
||||
grantedAt: now);
|
||||
|
||||
return new CreateTeamVaultRequest(
|
||||
VaultId: vaultId,
|
||||
Name: name,
|
||||
WrappedVaultKey: wrapped,
|
||||
GrantSignature: GrantStatementCodec.Sign(bundle.SigningKey, canonical),
|
||||
GrantedAt: now);
|
||||
}
|
||||
|
||||
private static StoredVault ToStored(VaultSummary summary) =>
|
||||
new(
|
||||
summary.VaultId,
|
||||
summary.Name,
|
||||
summary.IsPersonal,
|
||||
summary.TeamId,
|
||||
summary.KeyGeneration,
|
||||
summary.Permissions,
|
||||
summary.WrappedVaultKey,
|
||||
summary.RekeyRequired);
|
||||
}
|
||||
Reference in New Issue
Block a user