[{"author": "Daniel Gillmor", "text": "

<deleted>

", "time": "2023-11-10T08:32:49Z"}, {"author": "Daniel Gillmor", "text": "

Meetecho Robot the overhead projector in the ballroom is not on, dunno whether that is in your bailiwick

", "time": "2023-11-10T08:33:06Z"}, {"author": "Lorenzo Miniero", "text": "

Ack, heading there

", "time": "2023-11-10T08:33:34Z"}, {"author": "Shivan Sahib", "text": "

lots of FOMO this IETF :(

", "time": "2023-11-10T08:35:05Z"}, {"author": "Daniel Gillmor", "text": "

we wish you were here too, @Shivan Sahib i've got :socks: with your name on them

", "time": "2023-11-10T08:35:29Z"}, {"author": "Shivan Sahib", "text": "

ooh, next time!

", "time": "2023-11-10T08:35:46Z"}, {"author": "Daniel Gillmor", "text": "

Daniel Gillmor said:

\n
\n

Meetecho Robot the overhead projector in the ballroom is not on, dunno whether that is in your bailiwick

\n
\n

all fixed!

", "time": "2023-11-10T08:36:37Z"}, {"author": "Richard Barnes", "text": "

what do i need to do to get DKG socks?

", "time": "2023-11-10T08:39:16Z"}, {"author": "Lorenzo Miniero", "text": "

Note to chair: there's an ethernet cable on the chair desk you can use to avoid relying on the WIFI

", "time": "2023-11-10T08:39:49Z"}, {"author": "Lorenzo Miniero", "text": "

If it's not on the desk, it may have fallen under or behind it

", "time": "2023-11-10T08:40:03Z"}, {"author": "Deb Cooley", "text": "

wait, DKG has socks?

", "time": "2023-11-10T08:41:03Z"}, {"author": "Alison Becker", "text": "

+1 taylor's version lol

", "time": "2023-11-10T08:42:53Z"}, {"author": "Christopher Patton", "text": "

I have like 3 people verified on signal

", "time": "2023-11-10T08:43:45Z"}, {"author": "Orie Steele", "text": "

Thanks Lorenzo!

", "time": "2023-11-10T08:43:55Z"}, {"author": "Shivan Sahib", "text": "

https://notes.ietf.org/notes-ietf-118-keytrans?view

", "time": "2023-11-10T08:44:48Z"}, {"author": "Thibault Meunier", "text": "

still happy to take note, I started doing so on notes.ietf.org

", "time": "2023-11-10T08:44:57Z"}, {"author": "Shivan Sahib", "text": "

thanks to Thibault for helping with notes!

", "time": "2023-11-10T08:45:00Z"}, {"author": "Phillip Hallam-Baker", "text": "

If you are having that problem, it is because you are doing it wrong....
\nKey Transparency should be one mechanism for establishing trust, not the only mechanism.

", "time": "2023-11-10T08:49:06Z"}, {"author": "Simon Friedberger", "text": "

Christopher Patton said:

\n
\n

I have like 3 people verified on signal

\n
\n

I vote for reviving PGP signing parties!

", "time": "2023-11-10T08:51:44Z"}, {"author": "Phillip Hallam-Baker", "text": "

If Alice and Bob meet in person, they can establish direct trust.
\nKT becomes relevant when Alice is deciding whether to accept an assertion signed by Bob saying Carol's public key is X.
\nOr when it is Mallet saying Doug's public key is Y

", "time": "2023-11-10T08:52:42Z"}, {"author": "Phillip Hallam-Baker", "text": "

Knowing that an assertion was signed ten years ago creates a really strong work factor

", "time": "2023-11-10T08:53:12Z"}, {"author": "Simon Friedberger", "text": "

Phillip Hallam-Baker said:

\n
\n

If Alice and Bob meet in person, they can establish direct trust.

\n
\n

But they don't.

", "time": "2023-11-10T08:53:14Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Simon Friedberger Why not? If they exchange QR codes, they can establish direct trust with a 120 bit work factor really easily.

", "time": "2023-11-10T08:54:07Z"}, {"author": "Rohan Mahy", "text": "

To paraphrase dkg, it would be a shame if in attempting to protect the privacy of the user being looked up (by learning their public key), we violate the privacy of user being looked up and the person looking them up by learning part of their social graph.

", "time": "2023-11-10T08:56:40Z"}, {"author": "Jonathan Hoyland", "text": "

Is Formal Analysis a requirement for acceptance of any final spec?

", "time": "2023-11-10T08:59:02Z"}, {"author": "Jonathan Hoyland", "text": "

(Not that I'm biased.)

", "time": "2023-11-10T08:59:17Z"}, {"author": "Benjamin Beurdouche", "text": "

I would say no, though that should be a real criteria in our mind when we ship this

", "time": "2023-11-10T08:59:46Z"}, {"author": "Simon Friedberger", "text": "

It's not afaict. Nothing in the charter or elsewhere.

", "time": "2023-11-10T09:00:57Z"}, {"author": "Shivan Sahib", "text": "

as a doc shepherd, it helps to have had formal analysis while moving the document forward in the process. Not required though

", "time": "2023-11-10T09:01:05Z"}, {"author": "Benjamin Beurdouche", "text": "

More pragmatically, we can't require it, for the simple reason that we don't know if anyone will commit to make an analysis at the level of say MLS

", "time": "2023-11-10T09:01:16Z"}, {"author": "Benjamin Beurdouche", "text": "

I certainly don't have the cycles to do it.

", "time": "2023-11-10T09:01:50Z"}, {"author": "Jonathan Hoyland", "text": "

I would actually have thought you'd prove something just about KT and then have an interface to any relying protocol

", "time": "2023-11-10T09:02:13Z"}, {"author": "Benjamin Beurdouche", "text": "

That's the way we would approach this, yes. It seems highly non trivial though simply because of the unbounded nature of the log.

", "time": "2023-11-10T09:03:04Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland I doubt that anyone has the necessary tooling set up to establish proofs of KT like things at the moment. But the KT work will hopefully clarify the terms sufficiently to allow someone to do that.

", "time": "2023-11-10T09:03:56Z"}, {"author": "Benjamin Beurdouche", "text": "

This is definitely feasible, just non trivial. We have these kind of trees within MLS proofs.

", "time": "2023-11-10T09:04:53Z"}, {"author": "Daniel Huigens", "text": "

FWIW, we are doing a formal analysis of (a simplified model of) our (Proton's) version of KT using Tamarin, that will most likely be published later this year

", "time": "2023-11-10T09:05:22Z"}, {"author": "Jonathan Hoyland", "text": "

@Phillip Hallam-Baker That's exactly why I'm keen on it. I think it'll advance the field.

", "time": "2023-11-10T09:05:23Z"}, {"author": "Thom Wiggers", "text": "

lots of zero knowledge stuff in Parakeet though, right?

", "time": "2023-11-10T09:05:23Z"}, {"author": "Orie Steele", "text": "

(chair hat off) I tried to write some proverif code a while back in the context of DIDs which have some similar structure... I do think formal modeling of some of this is achievable, i'd be interested to see someone attempt it

", "time": "2023-11-10T09:05:34Z"}, {"author": "Rohan Mahy", "text": "

I would like to encourage us to have more discussion of the requirements. We have already the three models described in Brendan's slides. That three messaging services picked two different models is largely because they had different requirements. I think this should be more explicit

", "time": "2023-11-10T09:05:51Z"}, {"author": "Devon O'Brien", "text": "

Rohan Mahy said:

\n
\n

I would like to encourage us to have more discussion of the requirements. We have already the three models described in Brendan's slides. That three messaging services picked two different models is largely because they had different requirements. I think this should be more explicit

\n
\n

I second this. Anecdotally, CT had too little of this up front and ended up specifying more options than were used in practice, with little clarity as to which option should be used when.

", "time": "2023-11-10T09:07:53Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland I might actually have a formalizable treatment! But it might well show why it doesn't fit well in current formal model. The correct frame to evaluate KT like things is by looking at work factor, as in the cost of making an attack.
\nEnrolling an assertion in THE KT log at time T means that the work factor for creating such an assertion at that time goes from 0 to essentially infinity

", "time": "2023-11-10T09:09:55Z"}, {"author": "Shivan Sahib", "text": "

@meetecho getting slight echo for Brendan, at least remotely

", "time": "2023-11-10T09:10:08Z"}, {"author": "Jonathan Hoyland", "text": "

With KT, is there a way to boot someone off without their key remaining visible, e.g. if a terror group had a key in the log is there a way to remove/overwrite it without breaking all the proofs?

", "time": "2023-11-10T09:10:24Z"}, {"author": "Lorenzo Miniero", "text": "

Is it better now?

", "time": "2023-11-10T09:11:06Z"}, {"author": "Shivan Sahib", "text": "

yeah!

", "time": "2023-11-10T09:11:16Z"}, {"author": "Felix Linker", "text": "

@Jonathan: There are ways around this, I will bring it up in the discussion o:)

", "time": "2023-11-10T09:11:56Z"}, {"author": "Felix Linker", "text": "

But I'd also say that moderation in this context is not so critical, because even if there's a key in the tree, you can moderate at the application level.

", "time": "2023-11-10T09:12:37Z"}, {"author": "Rohan Mahy", "text": "

Jonathan Hoyland said:

\n
\n

With KT, is there a way to boot someone off without their key remaining visible, e.g. if a terror group had a key in the log is there a way to remove/overwrite it without breaking all the proofs?

\n
\n

Isn't a message being sent by a terror group also useful for non-repudiation? In other words prosecuting a terror group for illegal activity..

\n

It sounds like you want to moderate in the application protocol and not in the KT infra

", "time": "2023-11-10T09:14:14Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland There is in my system. Encrypted data can be erased by erasing the salt used to encrypt it.

\n

But there is a fundamental limit that if we don't let the log know what is being included, it is impossible for them to reject 'terrorist keys'

", "time": "2023-11-10T09:14:43Z"}, {"author": "Jonathan Hoyland", "text": "

I don't want them to reject the keys, I want it to be possible for the service to make certain keys no longer available after the fact.

", "time": "2023-11-10T09:15:52Z"}, {"author": "Devon O'Brien", "text": "

A relevant question is whether you consider keeping, after the fact, a permanent record of a banned/blocked/moderated user's key around a desirable property. These can be useful in other contexts.

", "time": "2023-11-10T09:15:52Z"}, {"author": "Daniel Gillmor", "text": "

\"terrorist keys\" :rolling_eyes:

\n

the most likely use of some sort of redaction mechanism is to do some sort of copyright enforcement :grimacing:

", "time": "2023-11-10T09:16:36Z"}, {"author": "Stephen Farrell", "text": "

If a KT log goes bad, is dealing with that (for users) somehow in scope? (just wondering)

", "time": "2023-11-10T09:16:39Z"}, {"author": "Jonathan Hoyland", "text": "

@Daniel Gillmor Absolutely, but if you look on Telegram you can very easily find channels explicitly supporting terrorist orgs. It's not a non-existent use case.

", "time": "2023-11-10T09:17:50Z"}, {"author": "Daniel Gillmor", "text": "

i'm pleased to see the discussion about gossip happening as a first-order task here. when a few of us tried to spec out gossip for CT, we failed. it got super complicated and there was no clear way to get it deployed. https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/ :sad:

", "time": "2023-11-10T09:18:58Z"}, {"author": "Jonathan Hoyland", "text": "

Can you ask Rohan to get closer to the mic?

", "time": "2023-11-10T09:19:26Z"}, {"author": "Jonathan Hoyland", "text": "

He's almost inaudible remote

", "time": "2023-11-10T09:19:33Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland i'm just very wary of the \"terrorist\" frame. It's used as a pejorative without any objective measurement. By most defintions, i'd consider any major military force (including the US DoD) a terrorist organization, but i can't imagine we're talking about taking DoD key material off of a transparency log.

", "time": "2023-11-10T09:20:43Z"}, {"author": "Jonathan Hoyland", "text": "

Anyway @Daniel Gillmor I was actually thinking about the failure case. Imagine some chat app is legally obligated to remove access to some copyrighted content. If I understand the current design, we lose all KT because the Merkle Tree breaks.

", "time": "2023-11-10T09:21:35Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland that's a much clearer (and less contentious) question. we know that copyright holders will be upset and they have a fair amount of leverage. can they use it to break things for the rest of us?

", "time": "2023-11-10T09:22:25Z"}, {"author": "Daniel Gillmor", "text": "

I usually frame this as \"what will the logs do about toxic data\"?

", "time": "2023-11-10T09:22:41Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland Why would a notary log have anything more than hash values?

\n

Why would it even know they are keys

", "time": "2023-11-10T09:22:46Z"}, {"author": "Daniel Gillmor", "text": "

that covers anything legally objectionable

", "time": "2023-11-10T09:22:50Z"}, {"author": "Jonathan Hoyland", "text": "

And what about partitioning the view to show different things in different countries?

", "time": "2023-11-10T09:23:32Z"}, {"author": "Felix Linker", "text": "

@Chris: I think the properties (in the core sense) stay the same, but your threat model changes.

", "time": "2023-11-10T09:24:22Z"}, {"author": "Benjamin Beurdouche", "text": "

I am not particularly scared about handling all 3 deployment models ...

", "time": "2023-11-10T09:24:41Z"}, {"author": "Benjamin Beurdouche", "text": "

It is a lot of work though.

", "time": "2023-11-10T09:24:49Z"}, {"author": "Daniel Gillmor", "text": "

@Phillip Hallam-Baker you can still smuggle toxic data into the logs if the logs only ever see the hash values: if i can claim a hash without demonstrating the preimage, i can push 10K \"keys\" whose \"hashes\" happen to be concatenatable into an mp3 of \"Master of Puppets\"

", "time": "2023-11-10T09:24:53Z"}, {"author": "Simon Friedberger", "text": "

@Orie Steele There are a lot of security and privacy discussions. Maybe we should do the next two presentations first.

", "time": "2023-11-10T09:25:10Z"}, {"author": "Jonathan Hoyland", "text": "

@Phillip Hallam-Baker If it doesn't have the actual key, but simply e.g. a commitment, then how do I as a user learn the actual public key?

", "time": "2023-11-10T09:25:34Z"}, {"author": "Jonathan Hoyland", "text": "

Did anyone else just lose audio?

", "time": "2023-11-10T09:26:27Z"}, {"author": "Thom Wiggers", "text": "

no

", "time": "2023-11-10T09:26:31Z"}, {"author": "Daniel Gillmor", "text": "

Jonathan Hoyland said:

\n
\n

Phillip Hallam-Baker If it doesn't have the actual key, but simply e.g. a commitment, then how do I as a user learn the actual public key?

\n
\n

good question. We need to clarify whether this is a key distribution system or a key verification system.

", "time": "2023-11-10T09:27:43Z"}, {"author": "Simon Friedberger", "text": "

It is doing distribution according to the charter.

", "time": "2023-11-10T09:28:08Z"}, {"author": "Jonathan Hoyland", "text": "

Maybe lock the queue at some point, so we don't block here forever?

", "time": "2023-11-10T09:29:26Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Daniel Gillmor That is my point. Once there is a notary log, you can use it to fix the time of any assertion you like proving it was made after the date of a particular apex and before the date of a set of apexes with dependency chains.

", "time": "2023-11-10T09:29:58Z"}, {"author": "Daniel Gillmor", "text": "

@Kevin Lewi doesn't whatsapp already sync all sorts of other state between devices?

", "time": "2023-11-10T09:30:31Z"}, {"author": "Bumblefudge", "text": "

(and the cloud backups :grimacing: )

", "time": "2023-11-10T09:30:53Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland The way it works in the Mesh is
\nAlice sends Bob a contact request with her contact assertion signed by Alice with a set of proofs which are each a notarized signature with a proof chain to some well known peering point.

", "time": "2023-11-10T09:31:59Z"}, {"author": "Kevin Lewi", "text": "

@Daniel Gillmor: yes, but doing this kind of sync for key transparency is pretty complicated. plus we also have to consider the scenario where a user loses all of their devices and starts from scratch.

", "time": "2023-11-10T09:32:03Z"}, {"author": "Daniel Gillmor", "text": "

@Kevin Lewi starting from scratch is pretty easy -- just grab a new tree head and start fresh.

", "time": "2023-11-10T09:32:40Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland So the KT stuff for me is simply EVIDENCE, it is not the DATA. The evidence is merely hashes of data so as to preserve privacy, it is not data.

", "time": "2023-11-10T09:33:06Z"}, {"author": "Kevin Lewi", "text": "

@Daniel Gillmor: right I agree. But if the KT deployment requires, for security, that you remember some information about the last thing you checked, otherwise you might never check it again, then I think that's an example where we are relying too much on the client storing state

", "time": "2023-11-10T09:33:45Z"}, {"author": "Daniel Gillmor", "text": "

@Kevin Lewi and why not treat the different clients of a single as gossiping peers -- without needing to do explicit sync of their tree heads? i'm not understanding the concern for WhatsApp around gossiping

", "time": "2023-11-10T09:33:55Z"}, {"author": "Phillip Hallam-Baker", "text": "

In forensics terms, the KT logs are giving you the information you find written on the OUTSIDE of the evidence bag, the serial number etc. It is not the evidence inside the bag

", "time": "2023-11-10T09:34:06Z"}, {"author": "Stephen Farrell", "text": "

wrt \"what happens if a log goes bad\" question, does this wg have a modus operandi for remembering to address such things, or is it still too soon? (issue tracker etc)

", "time": "2023-11-10T09:34:45Z"}, {"author": "Jonathan Hoyland", "text": "

@Phillip Hallam-Baker So KT is a key distribution service, not a key verification service.

", "time": "2023-11-10T09:34:57Z"}, {"author": "Daniel Gillmor", "text": "

@Kevin Lewi my understanding is that gossiping is something that collectively defends the system, and if everyone is doing it, occasional individual failures to keep up with gossip aren't going to break the global safety impact.

", "time": "2023-11-10T09:35:03Z"}, {"author": "Simon Friedberger", "text": "

Stephen Farrell said:

\n
\n

wrt \"what happens if a log goes bad\" question, does this wg have a modus operandi for remembering to address such things, or is it still too soon? (issue tracker etc)

\n
\n

I would say put it here: https://github.com/Bren2010/draft-kt-arch as an issue. Those should get migrated if this gets adopted.

", "time": "2023-11-10T09:35:52Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland Not Key verification nor distribution.

", "time": "2023-11-10T09:36:05Z"}, {"author": "Kevin Lewi", "text": "

@Daniel Gillmor: regarding gossiping of tree heads -- yes that could work! Actually I was surprised to see that Apple was doing that. I was always under the impression that relying on gossip for tree heads wouldn't be reliable enough, and it's better to just rely on some third-party to disseminate them. But tbh we could explore that option more

\n

I think what I was originally discussing though was not about gossiping of the tree heads. The linearizable view, in my mind, is about storing even more state other than just tree heads. It's about storing some intermediate calculations that you get from your most recent query about some set of your contact's keys

", "time": "2023-11-10T09:36:08Z"}, {"author": "Stephen Farrell", "text": "

@Simon Friedberger will do, ta

", "time": "2023-11-10T09:36:12Z"}, {"author": "Daniel Gillmor", "text": "

+1 for not having SCT-equivalents. keep it simple as long as we can.

", "time": "2023-11-10T09:36:12Z"}, {"author": "Shivan Sahib", "text": "

@Stephen Farrell issue tracker for this individual draft (for now): https://github.com/Bren2010/draft-kt-arch/issues

", "time": "2023-11-10T09:36:14Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland It is a mechanism that fixes the time of an assertion in a time series represented by a dense lattice.

", "time": "2023-11-10T09:36:52Z"}, {"author": "Devon O'Brien", "text": "

SCTs are a nightmare of design compromises to handle in practice. +1 to avoid using similar models at all cost.

", "time": "2023-11-10T09:37:39Z"}, {"author": "Daniel Gillmor", "text": "

@Phillip Hallam-Baker i don't think this WG is talking about (or designing) a generic timestamping service, nor should that be a goal here.

", "time": "2023-11-10T09:37:39Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Daniel Gillmor Gossip has two separate effects
\n1) It creates redundancy, instead of a single chain, you have a lattice and any path through that lattice can be used to establish a proof.
\n2) It creates accountability if each notary can only enroll a single apex value with a given partner.

", "time": "2023-11-10T09:39:34Z"}, {"author": "Devon O'Brien", "text": "

Though, I will admit that besides accommodating server-side reliability, SCTs do paper over a lot of client-side difficulty of staying very up-to-date with fresh tree heads and let you ignore the privacy problems around inclusion proof verification (or if you punt it one layer down, consistency proof fetching)

", "time": "2023-11-10T09:39:35Z"}, {"author": "Thibault Meunier", "text": "

side comment from the notetaker: everything in chat is out of the notes. I'm not able to track chat+live discussion at the same time as taking notes

", "time": "2023-11-10T09:40:13Z"}, {"author": "Jonathan Hoyland", "text": "

@Thibault Meunier the chat is permanent anyway.

", "time": "2023-11-10T09:40:38Z"}, {"author": "Jonathan Hoyland", "text": "

So self documenting.

", "time": "2023-11-10T09:40:45Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Daniel Gillmor The WG might not want to make a generic timestamp service but if you want to analyze the properties of the system you will not simplify them by introducing consideration of applying it to keys.

", "time": "2023-11-10T09:40:48Z"}, {"author": "Stephen Farrell", "text": "

I scanned the draft - seems fine to adopt

", "time": "2023-11-10T09:41:01Z"}, {"author": "Felix Linker", "text": "

I support adoption

", "time": "2023-11-10T09:41:20Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland Well chat would be really permanent if enrolled in a transparency log...

", "time": "2023-11-10T09:41:43Z"}, {"author": "Daniel Gillmor", "text": "

@Thibault Meunier that's reasonable. thanks for the note-taking!

", "time": "2023-11-10T09:41:55Z"}, {"author": "Jonathan Hoyland", "text": "

Phillip Hallam-Baker said:

\n
\n

Jonathan Hoyland Well chat would be really permanent if enrolled in a transparency log...

\n
\n

Not if it only contained commitments to what was said :stuck_out_tongue_wink:

", "time": "2023-11-10T09:42:41Z"}, {"author": "Phillip Hallam-Baker", "text": "

SCT?

", "time": "2023-11-10T09:42:54Z"}, {"author": "Jonathan Hoyland", "text": "

Adoption does not mean done

", "time": "2023-11-10T09:43:31Z"}, {"author": "Devon O'Brien", "text": "

Phillip Hallam-Baker said:

\n
\n

SCT?

\n
\n

Signed Certificate Timestamp, per RFC 6962

", "time": "2023-11-10T09:43:51Z"}, {"author": "Daniel Gillmor", "text": "

SCT: https://www.rfc-editor.org/rfc/rfc9162#name-signed-certificate-timestam

", "time": "2023-11-10T09:44:23Z"}, {"author": "Felix Linker", "text": "

may I comment?

", "time": "2023-11-10T09:44:29Z"}, {"author": "Shivan Sahib", "text": "

+1

", "time": "2023-11-10T09:44:40Z"}, {"author": "Daniel Gillmor", "text": "

@Felix Linker i can relay to the mic if you want (never mind, your audio/video is working :smiling_face:)

", "time": "2023-11-10T09:44:42Z"}, {"author": "Shivan Sahib", "text": "

(that is also my understanding)

", "time": "2023-11-10T09:44:46Z"}, {"author": "Daniel Huigens", "text": "

@Felix the call for adoption is of the document though, afaiu, the charter (presented in the first slide) was already accepted

", "time": "2023-11-10T09:46:21Z"}, {"author": "Felix Linker", "text": "

Yes, my point. I wonder why we should clarify requirements if they are in the charter. (And in my eyes, they're sufficiently clear in the charter.)

", "time": "2023-11-10T09:47:02Z"}, {"author": "Daniel Huigens", "text": "

Ah ok

", "time": "2023-11-10T09:47:14Z"}, {"author": "Phillip Hallam-Baker", "text": "

OK so a SCT is a promise to enroll an assertion in a log at a later date. It is actually something that you end up having to use in any system.

\n

At the time Alice signs her contact assertion, she only knows the LAST notary chain apex, she cannot know the next apex until after she has submitted the signature for notarization.

\n

We are going to need them.

", "time": "2023-11-10T09:48:41Z"}, {"author": "Daniel Gillmor", "text": "

that depends on the latency requirements.

", "time": "2023-11-10T09:50:07Z"}, {"author": "Felix Linker", "text": "

I got the echo as well when I was remote speaker

", "time": "2023-11-10T09:50:20Z"}, {"author": "Shivan Sahib", "text": "

@meetecho there is quite a bit of echo

", "time": "2023-11-10T09:50:41Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Daniel Gillmor We are going to need them in the construction of the signature regardless. We might not need to expose them to the end user.

", "time": "2023-11-10T09:51:03Z"}, {"author": "Jonathan Hoyland", "text": "

I think Esha has put her headset near her mic.

", "time": "2023-11-10T09:51:04Z"}, {"author": "Daniel Gillmor", "text": "

@Meetecho Robot remote speakers are reporting echo

", "time": "2023-11-10T09:51:05Z"}, {"author": "Felix Linker", "text": "

Now we're getting echo, right? :grinning_face_with_smiling_eyes:

", "time": "2023-11-10T09:51:26Z"}, {"author": "Richard Barnes", "text": "

i am hearing a little bit of echo.

", "time": "2023-11-10T09:51:44Z"}, {"author": "Phillip Hallam-Baker", "text": "

If Alice tries to exchange contacts with Bob and her assertion was signed 30 seconds ago, the notarization has zero value in any case.

", "time": "2023-11-10T09:51:52Z"}, {"author": "Daniel Gillmor", "text": "

they don't call it meetecho for nothing!

", "time": "2023-11-10T09:52:01Z"}, {"author": "Jonathan Hoyland", "text": "

I guess it's consistent to return 451 for everyone if you have to remove a key.

", "time": "2023-11-10T09:53:39Z"}, {"author": "Daniel Gillmor", "text": "

(i tease because i care -- i use a lot of remote A/V systems, and the failure modes in meetecho are actually fewer and less bad than the failure modes of nearly every other public A/V system i've tried)

", "time": "2023-11-10T09:54:17Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland if you do that, how can the auditor (or any user, for that matter) prove the consistency of the Merkle Tree?

", "time": "2023-11-10T09:55:10Z"}, {"author": "Phillip Hallam-Baker", "text": "

The way I see KT being used is in filtering inbound contact assertions.

\n", "time": "2023-11-10T09:55:13Z"}, {"author": "Jonathan Hoyland", "text": "

Daniel Gillmor said:

\n
\n

Jonathan Hoyland if you do that, how can you prove the consistency of the Merkle Tree?

\n
\n

I was simply referring to \"you must show every user the same thing for a given request\". If you remove key X, and return 451 for everything then it's still consistent for every user.

", "time": "2023-11-10T09:57:53Z"}, {"author": "Jonathan Hoyland", "text": "

You'd need to return the hash of the parent to check the rest of the tree

", "time": "2023-11-10T09:58:19Z"}, {"author": "Daniel Gillmor", "text": "

but if there is a mystery thing at the node returning 451, then it could be a binding between my identity and a different key

", "time": "2023-11-10T09:58:53Z"}, {"author": "Daniel Gillmor", "text": "

so now i can't trust the transparency log, because while i'm getting a 451 at some node, i don't know whether the log is returning something else at that node when someone else queries it.

", "time": "2023-11-10T09:59:33Z"}, {"author": "Richard Barnes", "text": "

@Daniel Gillmor i think the usual tree structure here puts each identity at exactly one leaf, so you can always know the full set of keys for that identity

", "time": "2023-11-10T09:59:43Z"}, {"author": "Benjamin Beurdouche", "text": "

Thanks @Esha Ghosh !

", "time": "2023-11-10T09:59:50Z"}, {"author": "Jonathan Hoyland", "text": "

Not that I'd ever design a cryptosystem whilst standing on one foot, but maybe you could have every leaf be a singleton node and leaf.

", "time": "2023-11-10T09:59:57Z"}, {"author": "Kevin Lewi", "text": "

Right exactly, @Daniel Gillmor there is an important property here that needs to be emphasized which is that clients can be ensured that there is a unique leaf location for an entry

", "time": "2023-11-10T10:00:21Z"}, {"author": "Daniel Gillmor", "text": "

@Esha Ghosh thanks for working to document these properties! i think this is the right kind of frame for the group to consider.

", "time": "2023-11-10T10:00:48Z"}, {"author": "Jonathan Hoyland", "text": "

Daniel Gillmor said:

\n
\n

so now i can't trust the transparency log, because while i'm getting a 451 at some node, i don't know whether the log is returning something else at that node when someone else queries it.

\n
\n

I think that might end up being the behaviour we go for, so that different jurisdictions can remove something from the tree for their country without removing it for everyone.

", "time": "2023-11-10T10:01:54Z"}, {"author": "Jonathan Hoyland", "text": "

It's better than the people who can speak being only the people approved of by every country.

", "time": "2023-11-10T10:02:56Z"}, {"author": "Daniel Gillmor", "text": "

i'm not keen on that outcome -- smells like a censorship mechanism

", "time": "2023-11-10T10:03:13Z"}, {"author": "Jonathan Hoyland", "text": "

I'm not keen either, but I think it's better than the alternative of \"country X can silence a person in every country in the world\"

", "time": "2023-11-10T10:04:03Z"}, {"author": "Daniel Gillmor", "text": "

this is a classic tension

", "time": "2023-11-10T10:04:21Z"}, {"author": "Richard Barnes", "text": "

i don't think we have any evidence of countries seeking this capability, so let's not be proactively here?

", "time": "2023-11-10T10:04:44Z"}, {"author": "Daniel Gillmor", "text": "

esp. if we agree that the transparency log should be accessible via an anonymity network

", "time": "2023-11-10T10:04:45Z"}, {"author": "Jonathan Hoyland", "text": "

That's why I said \"I think that might end up being the behaviour we go for\" :joy:

", "time": "2023-11-10T10:04:51Z"}, {"author": "Simon Friedberger", "text": "

Daniel Gillmor said:

\n
\n

esp. if we agree that the transparency log should be accessible via an anonymity network

\n
\n

I want this approach but given that the charter says the \"The authentication service used by the service provider only reveals information about specific users, such as what keys are associated with an identity, or even whether or not a specific identity is registered by the service provider, to clients authorized to ask about that user\" it seems like people had something else in mind.

", "time": "2023-11-10T10:05:59Z"}, {"author": "Daniel Gillmor", "text": "

yeah, CT addressed that by deciding that privacy for the logged identities was not in scope. this is a substantially harder problem.

", "time": "2023-11-10T10:07:04Z"}, {"author": "Jonathan Hoyland", "text": "

Richard Barnes said:

\n
\n

i don't think we have any evidence of countries seeking this capability, so let's not be proactively here?

\n
\n

I think there's a reason why the owner of Telegram lives in Dubai.

", "time": "2023-11-10T10:07:11Z"}, {"author": "Daniel Gillmor", "text": "

<sarcasm>you mean because UAE has no history of civil rights violations?</sarcasm> (tags added for clarification)

", "time": "2023-11-10T10:07:47Z"}, {"author": "Jonathan Hoyland", "text": "

I mean because he fell out with the government of his home country.

", "time": "2023-11-10T10:08:14Z"}, {"author": "Cory Myers", "text": "

Do we need to define transparency as explicitly global transparency?

", "time": "2023-11-10T10:08:52Z"}, {"author": "Richard Barnes", "text": "

@Cory Myers a certain level of global consistency is the whole point of the protocol

", "time": "2023-11-10T10:09:28Z"}, {"author": "Cory Myers", "text": "

Yes, but we also seem to be trying to hedge that. :-)

", "time": "2023-11-10T10:09:48Z"}, {"author": "Daniel Gillmor", "text": "

if it's not global, then we need to explicitly contemplate the jurisdictional boundaries. i don't think we're well-prepared to do that. the problem posed in the charter is hard enough without that additional wrinkle.

", "time": "2023-11-10T10:10:19Z"}, {"author": "Jonathan Hoyland", "text": "

Cory Myers said:

\n
\n

Yes, but we also seem to be trying to hedge that. :-)

\n
\n

I'm just trying to anticipate issues that will need to be dealt with in the future so we can resolve them in the best possible way.

", "time": "2023-11-10T10:10:57Z"}, {"author": "Phillip Hallam-Baker", "text": "

One of the architectural issues here is whether the tree is over the data itself or over the updates to the data

", "time": "2023-11-10T10:11:34Z"}, {"author": "Phillip Hallam-Baker", "text": "

I was thinking it is about updates, this presentation is looking at going over the tree.

", "time": "2023-11-10T10:11:56Z"}, {"author": "Jonathan Hoyland", "text": "

If the end protocol gets blocked in every country or if the entire tree has to be rebuilt every time DKG shares master of puppets then we might as well not bother.

", "time": "2023-11-10T10:12:09Z"}, {"author": "Orie Steele", "text": "

(hat off), in SCITT we often see domains (web origins) as the primary identifier, and then can be bought and sold, or changed by mergers.

", "time": "2023-11-10T10:12:26Z"}, {"author": "Jonathan Hoyland", "text": "

Yeah, I thought Signal was working on moving off reliance on phone numbers?

", "time": "2023-11-10T10:14:44Z"}, {"author": "Phillip Hallam-Baker", "text": "

@Jonathan Hoyland They keep talking about that but have yet to see it happen

", "time": "2023-11-10T10:16:00Z"}, {"author": "Jonathan Hoyland", "text": "

But zk-SNARKs are a lot of fun. Who cares about practicality :stuck_out_tongue_closed_eyes:

", "time": "2023-11-10T10:21:07Z"}, {"author": "Devon O'Brien", "text": "

@Daniel Gillmor CT Logs originally did have infinite lifetime, and it was extremely problematic, which is why we moved it to temporally-partitioned model. The big difference here is that certificate notAfter was an extremely natural fit for this sharding

", "time": "2023-11-10T10:24:59Z"}, {"author": "Devon O'Brien", "text": "

Being able to stop caring about expired certificates was possible due to an existing temporal boundary in use. That doesn't translate naturally to KT use cases

", "time": "2023-11-10T10:25:35Z"}, {"author": "Daniel Gillmor", "text": "

@Devon O'Brien when a new tree is created, it can be initially populated with the current leaves of the retiring tree

", "time": "2023-11-10T10:26:15Z"}, {"author": "Shivan Sahib", "text": "

we'll be closing the queue v soon, please join now or forever hold your peace

", "time": "2023-11-10T10:26:37Z"}, {"author": "Stephen Farrell", "text": "

btw this privacy slide deck does a nice job of identifying interesting issues

", "time": "2023-11-10T10:26:46Z"}, {"author": "Daniel Gillmor", "text": "

standardized rotation also provides an answer to the \"how do we handle someone inheriting an identifier\" case -- just ensure a quiescence period after an identifier goes out of use that is longer than the tree rotation period.

", "time": "2023-11-10T10:27:22Z"}, {"author": "Daniel Gillmor", "text": "

Stephen Farrell said:

\n
\n

btw this privacy slide deck does a nice job of identifying interesting issues

\n
\n

it is missing the queries-reveal-the-social-graph-to-the-transparency-log concern

", "time": "2023-11-10T10:28:28Z"}, {"author": "Stephen Farrell", "text": "

true

", "time": "2023-11-10T10:29:14Z"}, {"author": "Simon Friedberger", "text": "

Imho, it also misses metadata like key age that PHB just mentioned, maybe some key properties that leak which tool or hardware was used to generate it, etc.

", "time": "2023-11-10T10:29:53Z"}, {"author": "Daniel Gillmor", "text": "

Thanks @Kevin Lewi for formulating these questions and leading the discussion

", "time": "2023-11-10T10:29:59Z"}, {"author": "Stephen Farrell", "text": "

'case it's not clear imo we should for \"more private\"

", "time": "2023-11-10T10:30:08Z"}, {"author": "Devon O'Brien", "text": "

Daniel Gillmor said:

\n
\n

Stephen Farrell said:

\n
\n

btw this privacy slide deck does a nice job of identifying interesting issues

\n
\n

it is missing the queries-reveal-the-social-graph-to-the-transparency-log concern

\n
\n

Several ways of achieving property can be layered on top of KT queries without being built in.

", "time": "2023-11-10T10:30:21Z"}, {"author": "Daniel Gillmor", "text": "

:tada:

", "time": "2023-11-10T10:30:25Z"}, {"author": "Felix Linker", "text": "

:clap:

", "time": "2023-11-10T10:30:35Z"}]