[{"author": "Richard Barnes", "text": "

fwiw, i think \"distribute\" is terrible terminology here. what we care about is the fidelity of the (key, id) binding, however it physically gets distributed

", "time": "2023-03-29T04:07:56Z"}, {"author": "Melinda Shore", "text": "

Well, it's unconventional but it may be the case (I haven't read the drafts) that the distribution problem is in scope.

", "time": "2023-03-29T04:09:44Z"}, {"author": "Melinda Shore", "text": "

Oops, maybe not.

", "time": "2023-03-29T04:09:47Z"}, {"author": "Melinda Shore", "text": "

The other problem is authenticating the keys to start with - with CT, certificates are accepted based on whether or not they chain back to a known, trusted root

", "time": "2023-03-29T04:10:29Z"}, {"author": "Eric Rescorla", "text": "

Uh, this is not in fact correct.

", "time": "2023-03-29T04:10:35Z"}, {"author": "Melinda Shore", "text": "

Which?

", "time": "2023-03-29T04:10:46Z"}, {"author": "Eric Rescorla", "text": "

TIGRESS does not in any way rely on transparency

", "time": "2023-03-29T04:10:51Z"}, {"author": "Richard Barnes", "text": "

seems like a side point

", "time": "2023-03-29T04:11:07Z"}, {"author": "Richard Barnes", "text": "

clearly CT is the widely-deployed predecessor

", "time": "2023-03-29T04:11:30Z"}, {"author": "Eric Rescorla", "text": "

Sure.

", "time": "2023-03-29T04:12:05Z"}, {"author": "Deb Cooley", "text": "

Isn't the server just an authority?

", "time": "2023-03-29T04:12:28Z"}, {"author": "Melinda Shore", "text": "

It needs to see the proof, which is a partial tree

", "time": "2023-03-29T04:12:43Z"}, {"author": "Deb Cooley", "text": "

Like searching a CA database?

", "time": "2023-03-29T04:12:44Z"}, {"author": "Melinda Shore", "text": "

They may be interested in something more like the certwatch database

", "time": "2023-03-29T04:13:17Z"}, {"author": "Melinda Shore", "text": "

which, granted, is pulled out of CT logs.

", "time": "2023-03-29T04:13:45Z"}, {"author": "Melinda Shore", "text": "

But doesn't include the proofs

", "time": "2023-03-29T04:13:54Z"}, {"author": "Alexey Melnikov", "text": "

I will ask people to reserve discussion points to the end of this presentation, only clarifying questions during the presentation please.

", "time": "2023-03-29T04:16:06Z"}, {"author": "Amir Omidi", "text": "

As a non-typical user, I would prefer to use a service that does use KT over one that doesn't. I can even see this eventually becoming a requirement to call something E2EE.

", "time": "2023-03-29T04:18:21Z"}, {"author": "Richard Barnes", "text": "

to DKG's point -- i think there's robust enough competition in the E2EE space that i'm actually less worried about incentives.

", "time": "2023-03-29T04:18:46Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes that would be great, i hope you're right.

", "time": "2023-03-29T04:19:09Z"}, {"author": "Richard Barnes", "text": "

like i think if it were straightforward to deploy KT, one of the several vendors here would want to be the first to deploy it

", "time": "2023-03-29T04:19:15Z"}, {"author": "Richard Barnes", "text": "

i talk to a lot of enterprise customers, and the notion of identity that the comms provider can't tamper with is salient

", "time": "2023-03-29T04:20:19Z"}, {"author": "Daniel Gillmor", "text": "

i'm just wondering what happens the first time some celebrity says \"ZOMG my WhatsApp (or whatever) account was hacked!\" and they wouldn't have noticed it if it weren't for KT

", "time": "2023-03-29T04:20:22Z"}, {"author": "Daniel Gillmor", "text": "

confusing, because the key of the key value store is not a key, but the value is a key :confounded:

", "time": "2023-03-29T04:26:05Z"}, {"author": "Daniel Gillmor", "text": "

did i hear \"the google effort for KT is ongoing\"? is that right?

", "time": "2023-03-29T04:30:13Z"}, {"author": "Antonio Marcedone", "text": "

No I am from Zoom

", "time": "2023-03-29T04:30:21Z"}, {"author": "Amir Omidi", "text": "

Feel strongly re: problem statement

", "time": "2023-03-29T04:30:35Z"}, {"author": "Daniel Gillmor", "text": "

@Antonio Marcedone sorry for misunderstanding. so the Zoom effort for KT is ongoing? can you say a bit more about what that means?

", "time": "2023-03-29T04:31:13Z"}, {"author": "Richard Barnes", "text": "

As long as we get rid of the \"distribution\" language, i'm a :thumbsup: :)

", "time": "2023-03-29T04:31:19Z"}, {"author": "Richard Barnes", "text": "

@dkg there's a preso in a few minutes

", "time": "2023-03-29T04:31:29Z"}, {"author": "Aron Wussler", "text": "

Also, about commitments, you don't want to put an arbitrarily sized data structure in the public tree, therefore you need some sorta hashing step (whether that's a commitment or a fingerprint)

", "time": "2023-03-29T04:31:40Z"}, {"author": "Antonio Marcedone", "text": "

I am presenting later in this meeting

", "time": "2023-03-29T04:31:41Z"}, {"author": "Antonio Marcedone", "text": "

So I will say more, yes :)

", "time": "2023-03-29T04:32:05Z"}, {"author": "Daniel Gillmor", "text": "

can the chairs give the folks in the minority a chance to explain?

", "time": "2023-03-29T04:32:21Z"}, {"author": "Melinda Shore", "text": "

I think I was the only one in the minority. I'm not clear on whether they want proofs of inclusion or an actual distribution mechanism

", "time": "2023-03-29T04:33:03Z"}, {"author": "Harjasleen Malvai", "text": "

Only proofs of inclusion and correct state evolution

", "time": "2023-03-29T04:33:24Z"}, {"author": "Richard Barnes", "text": "

yet more reason to get rid of \"distribution\"!

", "time": "2023-03-29T04:33:40Z"}, {"author": "Melinda Shore", "text": "

:+1:\ud83c\udffc

", "time": "2023-03-29T04:33:57Z"}, {"author": "Richard Barnes", "text": "

in general, this model of roles seems insufficient. it seems like the Bobs in conversation with Alice also have actions here

", "time": "2023-03-29T04:40:02Z"}, {"author": "Rohan Mahy", "text": "

i.e the 1st-party verifiers

", "time": "2023-03-29T04:40:40Z"}, {"author": "Daniel Gillmor", "text": "

right, Bob has a different capability than the auditors somehow (he can see stuff about Alice specifically)

", "time": "2023-03-29T04:41:00Z"}, {"author": "Richard Barnes", "text": "

yep, and Bob wants specific assurance that the keys he sees for Alice are the same as everyone else sees, presumably via some short proof

", "time": "2023-03-29T04:42:11Z"}, {"author": "Daniel Gillmor", "text": "

the same as every other \"Bob\" sees, i guess

", "time": "2023-03-29T04:45:00Z"}, {"author": "Richard Barnes", "text": "

good 'ol Bob

", "time": "2023-03-29T04:45:58Z"}, {"author": "Richard Barnes", "text": "

actually, i think Bob wants to know that he sees the same set that Alice sees, since Alice knows ground truth

", "time": "2023-03-29T04:46:55Z"}, {"author": "Daniel Gillmor", "text": "

right, i think that's stronger

", "time": "2023-03-29T04:48:18Z"}, {"author": "Richard Barnes", "text": "

Keybase proofs on Twitter now cost $8.99/month

", "time": "2023-03-29T04:53:31Z"}, {"author": "Richard Barnes", "text": "

so it seems like this signature stuff goes for a stronger property than non-equivocation

", "time": "2023-03-29T04:54:24Z"}, {"author": "Richard Barnes", "text": "

there are assumptions on this bulletin board, i assume. like it seems like that's the role Stellar is playing in what @Antonio desribed

", "time": "2023-03-29T05:07:43Z"}, {"author": "Richard Barnes", "text": "

gah please no gossi

", "time": "2023-03-29T05:09:12Z"}, {"author": "Richard Barnes", "text": "

*gossip

", "time": "2023-03-29T05:09:18Z"}, {"author": "Rohan Mahy", "text": "

My understanding is that the bulletin board is running on one of their servers but a signed digest of the bulletin board is published to Stellar periodically

", "time": "2023-03-29T05:12:00Z"}, {"author": "Richard Barnes", "text": "

either way, the presumption is roughly that the bulletin board is an immutable record

", "time": "2023-03-29T05:12:39Z"}, {"author": "Richard Barnes", "text": "

(or at least not mutable by the log)

", "time": "2023-03-29T05:12:46Z"}, {"author": "Antonio Marcedone", "text": "

yeah. Only the root is posted on the blockchain

", "time": "2023-03-29T05:13:06Z"}, {"author": "Antonio Marcedone", "text": "

the root digest, to be precide

", "time": "2023-03-29T05:13:18Z"}, {"author": "Rohan Mahy", "text": "

(in the keybase case). in the parakeet case they can compress the log

", "time": "2023-03-29T05:13:24Z"}, {"author": "Richard Barnes", "text": "

this PCS property seems like a stretch goal

", "time": "2023-03-29T05:15:57Z"}, {"author": "Daniel Gillmor", "text": "

i'm a bit confused about the interaction between the VRF and the user identity -- how can the user know that the only key published associated with their identity is their actual key?

", "time": "2023-03-29T05:19:27Z"}, {"author": "Daniel Gillmor", "text": "

thanks for doing this work, and for bringing it here!

", "time": "2023-03-29T05:21:12Z"}, {"author": "Aron Wussler", "text": "

+1, agree, very interesting presentations

", "time": "2023-03-29T05:22:00Z"}, {"author": "Richard Barnes", "text": "

i raised my hand, with the caveat that i stated, that we'll need to figure out what the cut point is between standard and extensions

", "time": "2023-03-29T05:22:51Z"}, {"author": "Richard Barnes", "text": "

because i don't think we will want to do anything as complex as Parakeet / Keybase / Zoom

", "time": "2023-03-29T05:23:13Z"}, {"author": "Daniel Gillmor", "text": "

agree with @Richard Barnes that there will probably be some haggling at the edges

", "time": "2023-03-29T05:23:22Z"}, {"author": "Amir Omidi", "text": "

Whats the alternative?

", "time": "2023-03-29T05:23:51Z"}, {"author": "Daniel Gillmor", "text": "

anywhere non-IETF ? or not done at all?

", "time": "2023-03-29T05:24:07Z"}, {"author": "Daniel Gillmor", "text": "

so many options

", "time": "2023-03-29T05:24:10Z"}, {"author": "\u67f3\u7530 \u6dbc", "text": "

Are these key-identity etc. Web issue?

", "time": "2023-03-29T05:24:50Z"}, {"author": "Richard Barnes", "text": "

you could argue that because we don't have a cross-vendor problem here, we don't need an interop spec

", "time": "2023-03-29T05:24:53Z"}, {"author": "Richard Barnes", "text": "

so like, each vendor can figure it out on their own

", "time": "2023-03-29T05:25:05Z"}, {"author": "Pieter Kasselman", "text": "

....but, will we need it if systems need to be interoperable?

", "time": "2023-03-29T05:26:00Z"}, {"author": "Amir Omidi", "text": "

Although with the new EU chat rules, that might be changing.

", "time": "2023-03-29T05:26:06Z"}, {"author": "Daniel Gillmor", "text": "

i'd like for an auditor to be able to audit multiple systems

", "time": "2023-03-29T05:26:08Z"}, {"author": "Richard Barnes", "text": "

i didn't say i actually thought that, i just said \"you could argue\" :)

", "time": "2023-03-29T05:26:44Z"}, {"author": "Daniel Gillmor", "text": "

b/c the social/technical cost of setting up and maintaining an auditor is high, and if each form of auditing is both technically and semantically different it increases the cost a lot.

", "time": "2023-03-29T05:26:47Z"}, {"author": "Daniel Gillmor", "text": "

this is the IETF, \"you could argue\" about just about anything :stuck_out_tongue:

", "time": "2023-03-29T05:27:10Z"}, {"author": "Aron Wussler", "text": "

While this can be implemented independently from vendors, I can see the advantage of giving guidance and of allowing \"protocol-specific\" interoperability within various groups of vendors.I don't imagine having a one-size-fits all solution, but maybe a single protocol can develop interoperability based on this draft

", "time": "2023-03-29T05:27:26Z"}, {"author": "Amir Omidi", "text": "

https://www.ietf.org/id/draft-davidben-tls-merkle-tree-certs-00.html Also this is an interesting draft somewhat related to this - more use for Transparency services.

", "time": "2023-03-29T05:27:37Z"}, {"author": "Alexey Melnikov", "text": "

It was clear to me that there are things that KT system need that would be extensions. We will figure out the boundary between core and extensions during chartering.

", "time": "2023-03-29T05:27:46Z"}, {"author": "Julia Len", "text": "

yeah with the DMA specifying that e2ee will need to be interoperable basically a year from now, a standard for KT would be helpful

", "time": "2023-03-29T05:28:23Z"}, {"author": "Richard Barnes", "text": "

fwiw, i think the argument here is similar to what we did for MLS a few years ago -- it's single-vendor today, but (a) it's complicated to do securely, so doing it one way builds assurance, (b) maybe library reuse, (c) maybe interop later on

", "time": "2023-03-29T05:28:28Z"}, {"author": "Richard Barnes", "text": "

\"secure without 3rd-party auditing\" is \"interesting\" in the sense of \"impossible\"

", "time": "2023-03-29T05:29:48Z"}, {"author": "Daniel Gillmor", "text": "

oof, what falls under \"metadata privacy\"? does this include \"list of user identifiers\"?

", "time": "2023-03-29T05:30:03Z"}, {"author": "Richard Barnes", "text": "

please ask that @dkg

", "time": "2023-03-29T05:30:18Z"}, {"author": "Aron Wussler", "text": "

Could also be when a key update is performed

", "time": "2023-03-29T05:30:25Z"}, {"author": "Esha Ghosh", "text": "

Yes, I think both would be covered under Metadata privacy

", "time": "2023-03-29T05:31:10Z"}, {"author": "Richard Barnes", "text": "

that statement about auditors is not really accurate, e.g., about CT audiotrs

", "time": "2023-03-29T05:31:22Z"}, {"author": "Daniel Gillmor", "text": "

this slide says \"Metadata privacy (not addressed)\"

", "time": "2023-03-29T05:31:26Z"}, {"author": "Aron Wussler", "text": "

Via VRFs I would honestly say that \"not leaking the lists of users\" should be put in the non-controversial

", "time": "2023-03-29T05:31:45Z"}, {"author": "Alexey Melnikov", "text": "

I read this as \u201cnot yet addressed by the proposal\u201d

", "time": "2023-03-29T05:32:06Z"}, {"author": "Alexey Melnikov", "text": "

But do ask

", "time": "2023-03-29T05:32:18Z"}, {"author": "Aron Wussler", "text": "

AFAIK the draft uses VRFs

", "time": "2023-03-29T05:32:40Z"}, {"author": "Rohan Mahy", "text": "

is there a practical, referencible post-quantum formulation of VRF?

", "time": "2023-03-29T05:32:43Z"}, {"author": "Pieter Kasselman", "text": "

I keep wondering why this is not something that is solved by decentralised identity....

", "time": "2023-03-29T05:32:43Z"}, {"author": "Aron Wussler", "text": "

Yes, there are some PQ-VRF

", "time": "2023-03-29T05:33:37Z"}, {"author": "Orie Steele", "text": "

Pieter Kasselman said:

\n
\n

I keep wondering why this is not something that is solved by decentralised identity....

\n
\n

Yes, in SCITT we have been considering did resolution transparency

", "time": "2023-03-29T05:33:41Z"}, {"author": "Daniel Gillmor", "text": "

@Pieter Kasselman decentralized identity avoids having a central server entirely, but depending on the system, might not have a guaranteed single global view of any given identity.

", "time": "2023-03-29T05:34:32Z"}, {"author": "Pieter Kasselman", "text": "

@daniel the did method you choose can publish and manage the key in a place that meets the transparency requirements...

", "time": "2023-03-29T05:35:27Z"}, {"author": "Orie Steele", "text": "

Decoy entries, noise protocols, etc...

", "time": "2023-03-29T05:36:23Z"}, {"author": "Orie Steele", "text": "

Tree size can be obscured, to some degree

", "time": "2023-03-29T05:37:00Z"}, {"author": "Richard Barnes", "text": "

doing gossip via MLS seems like a circular dependency

", "time": "2023-03-29T05:37:04Z"}, {"author": "Richard Barnes", "text": "

strong negative reaction to gossip because it is so hard to characterize what assurance you get from it

", "time": "2023-03-29T05:37:40Z"}, {"author": "Richard Barnes", "text": "

@Pieter @dkg is anything actually solved by DID? my impression was that it just created more problems :)

", "time": "2023-03-29T05:40:09Z"}, {"author": "Brandon Weeks", "text": "

If you assume a product like Slack, could a customer be/run their own auditor?

", "time": "2023-03-29T05:40:25Z"}, {"author": "Rohan Mahy", "text": "

yes

", "time": "2023-03-29T05:40:47Z"}, {"author": "Richard Barnes", "text": "

@Brandon - I would assume something like that could be accommodated

", "time": "2023-03-29T05:40:50Z"}, {"author": "Daniel Gillmor", "text": "

@Richard Barnes are you asking about a specific DID protocol, or about the general concept of distributed identity?

", "time": "2023-03-29T05:40:54Z"}, {"author": "Antonio Marcedone", "text": "

There are two issues that I think it makes sense to separate:
\n1 - how to get consensus on the tree
\n2 - auditing that the digests are well formed and updated

\n

I think (1) requires some external mechanism like gossip or a blockchain or a third party trusted for this purpose....
\nFor (2), anybody could audit, or you can hand pick an auditing partner

", "time": "2023-03-29T05:41:00Z"}, {"author": "Antonio Marcedone", "text": "

which clients trust to perform these checks

", "time": "2023-03-29T05:41:25Z"}, {"author": "Richard Barnes", "text": "

@dkg this is more a convo for over beers, but my impression is that most DID methods are a net negative

", "time": "2023-03-29T05:41:29Z"}, {"author": "Aron Wussler", "text": "

Agree with Konrad about the distributed, per-provider deployments

", "time": "2023-03-29T05:41:44Z"}, {"author": "Richard Barnes", "text": "

in line with my complaints about \"distribution\" earlier, i think this model where relying parties are fetching keys from a central server is wrong

", "time": "2023-03-29T05:43:59Z"}, {"author": "Brandon Weeks", "text": "

@Richard Barnes In Trusted Computing, the customer being the auditor has became a common pattern. A cloud infrastructure provider offers attestations, the customer runs a verifier elsewhere that consumes the attestations. Basically in an auditor role.

", "time": "2023-03-29T05:44:27Z"}, {"author": "Pieter Kasselman", "text": "

@richard - defiantely a beers discussion. I am just reflecting on similarities in problems folks are trying to being solved with DIDs

", "time": "2023-03-29T05:44:36Z"}, {"author": "Orie Steele", "text": "

Richard Barnes said:

\n
\n

@dkg this is more a convo for over beers, but my impression is that most DID methods are a net negative

\n
\n

As one of the did method registry maintainers. I agree with this. I could say similar things about many popular things... I do think KT could help make DIDs better / more usable and more offline friendly.

", "time": "2023-03-29T05:44:42Z"}, {"author": "Richard Barnes", "text": "

tl;dr DIDs are just public keys with less discipline. you would do better by just having public keys and something like KT

", "time": "2023-03-29T05:45:19Z"}, {"author": "Richard Barnes", "text": "

did:key is the one reasonable DID method :)

", "time": "2023-03-29T05:46:04Z"}, {"author": "Richard Barnes", "text": "

(ok maybe did:jwk)

", "time": "2023-03-29T05:46:09Z"}, {"author": "Orie Steele", "text": "

Richard Barnes said:

\n
\n

tl;dr DIDs are just public keys with less discipline. you would do better by just having public keys and something like KT

\n
\n

I don't completely disagree... In some sense, IETF KT is a version of DID.

", "time": "2023-03-29T05:46:36Z"}, {"author": "Pieter Kasselman", "text": "

So we ditch DIDs for KT?

", "time": "2023-03-29T05:46:38Z"}, {"author": "Richard Barnes", "text": "

i think we're a little far afield of the BoF topic :)

", "time": "2023-03-29T05:47:09Z"}, {"author": "Pieter Kasselman", "text": "

I wonder if we just run into the same problems... but perhaps we can do something around scoping that simplifies adoption.

", "time": "2023-03-29T05:47:26Z"}, {"author": "Pieter Kasselman", "text": "

perhaps more discipline is the answer ;)

", "time": "2023-03-29T05:48:02Z"}, {"author": "Orie Steele", "text": "

Yes apologies, I suspect key formats, will be a big discussion though... JWK, COSE Key, PGP, etc...

", "time": "2023-03-29T05:48:09Z"}, {"author": "Daniel Gillmor", "text": "

there's definitely a similar smell to the problem. I wonder whether the https://keys.openpgp.org/ folks would be interested in deploying some flavor of KT.

", "time": "2023-03-29T05:48:17Z"}, {"author": "Richard Barnes", "text": "

if you look at Antonio's presentation, it's basically a description of a DID method for did:keybase:username

", "time": "2023-03-29T05:48:48Z"}, {"author": "Lixia Zhang", "text": "

sorry. I audio didnt work -- it seems to me the critical dependency on this third party auditing, which remains open, is a concern.

", "time": "2023-03-29T05:54:38Z"}, {"author": "Esha Ghosh", "text": "

agreed

", "time": "2023-03-29T05:55:56Z"}, {"author": "Richard Barnes", "text": "

i am concerned that the agreement here might be a little superficial, and that it might fall apart once we have to make some hard decisions about what to build

", "time": "2023-03-29T05:57:17Z"}, {"author": "Rohan Mahy", "text": "

Yes. there is a clear message that we need to discuss 3rd part auditors and metadata privacy

", "time": "2023-03-29T05:57:29Z"}, {"author": "Alexey Melnikov", "text": "

Thank you for all your participation. And a special thank you to the presenters.

", "time": "2023-03-29T05:57:35Z"}, {"author": "Antonio Marcedone", "text": "

Thanks everyone!

", "time": "2023-03-29T05:57:45Z"}, {"author": "Esha Ghosh", "text": "

Thanks, everyone!

", "time": "2023-03-29T05:57:55Z"}, {"author": "Antonio Marcedone", "text": "

Eat some extra cookies for me :)

", "time": "2023-03-29T05:57:58Z"}, {"author": "Lixia Zhang", "text": "

no cookie at 3PM; wait till 5

", "time": "2023-03-29T05:58:23Z"}]