IETF
openpgp
openpgp@jabber.ietf.org
Monday, March 21, 2022< ^ >
Meetecho has set the subject to: OpenPGP @ IETF 112
Room Configuration
Room Occupants

GMT+0
[00:44:37] xcrypt1210 leaves the room
[06:24:26] Werner joins the room
[08:14:18] xcrypt1210 joins the room
[08:39:04] gniibe joins the room
[08:42:10] sftcd-x joins the room
[08:43:12] Meetecho joins the room
[08:44:27] dkg joins the room
[08:45:03] Daniel Gillmor_web_368 joins the room
[08:45:03] Stephen Farrell_web_791 joins the room
[08:45:03] Werner Koch_web_290 joins the room
[08:45:03] Evangelos Karatsiolis_web_957 joins the room
[08:45:03] Yoshiro Yoneya_web_413 joins the room
[08:45:03] Stephan Ehlen_web_601 joins the room
[08:45:03] Alessandro Toppi_web_225 joins the room
[08:46:19] <sftcd-x> is the chair mic going to remote folks?
[08:47:21] <Werner> Morning
[08:50:16] Alyssa Thompson_web_198 joins the room
[08:52:46] Shigeya Suzuki_web_121 joins the room
[08:53:33] Shigeya Suzuki_web_121 leaves the room
[08:54:44] Benjamin Schwartz_web_288 joins the room
[08:55:30] Shigeya Suzuki_web_117 joins the room
[08:55:50] Thom Wiggers_web_316 joins the room
[08:56:31] Aron Wussler_web_686 joins the room
[08:56:43] Daniel Huigens_web_325 joins the room
[08:57:19] Johannes Roth_web_409 joins the room
[08:57:19] Jan-Frederik Rieckers_web_358 joins the room
[08:57:26] xcrypt1210 leaves the room
[08:58:22] Aron Wussler_web_686 leaves the room
[08:58:26] Stavros Kousidis_web_725 joins the room
[08:58:26] Aron Wussler_web_609 joins the room
[08:58:31] Jonathan Hammell_web_658 joins the room
[08:58:39] Randy Bush_web_202 joins the room
[08:58:42] justus joins the room
[08:58:56] Korry Luke_web_215 joins the room
[08:58:57] Michael Hollyman_web_977 joins the room
[08:59:02] <justus> Moin
[08:59:04] Aron Wussler_web_609 leaves the room
[08:59:17] Florence D_web_850 joins the room
[08:59:45] <sftcd-x> @justus - you joining in meetecho too? probably needed for slide stuff (thought Daniel H is here as backup)
[08:59:52] Tadahiko Ito_web_512 joins the room
[08:59:58] Alison Becker_web_508 joins the room
[09:00:00] Melinda Shore_web_302 joins the room
[09:00:15] Andreas Huelsing_web_547 joins the room
[09:00:17] Falko Strenzke_web_264 joins the room
[09:00:24] <justus> I cannot reach the conferencing tool
[09:00:45] muelli joins the room
[09:00:46] <justus> it pongs, but http requests time out
[09:00:57] <muelli> 'morning o/
[09:02:02] <justus> I don't think there is anything I can do from my end, you'll have to make due without me, sorry
[09:02:02] Michael B_web_807 joins the room
[09:02:24] g新部 裕_web_566 joins the room
[09:02:33] Daniel Huigens_web_325 leaves the room
[09:02:37] Daniel Huigens_web_143 joins the room
[09:03:16] <muelli> am I seeing it correctly that the video stream requires credentials?
[09:03:30] Roman Danyliw_web_994 joins the room
[09:04:01] Kesara Rathnayake_web_406 joins the room
[09:04:04] Benson Muite_web_340 joins the room
[09:04:12] Lara Bruseghini_web_550 joins the room
[09:04:20] Justus Winter_web_113 joins the room
[09:04:46] Quynh Dang_web_619 joins the room
[09:04:49] <dkg> muelli: i think that's correct.
[09:05:17] <dkg> if you have a datatracker login registered for the meeting, you can find the stream at https://wws.conf.meetecho.com/conference/?group=openpgp
[09:06:14] Mallory Knodel_web_924 joins the room
[09:06:44] <muelli> dkg: thanks.  I've tried to register, but their email is probably greylisted for the moment :-\
[09:07:00] <muelli> I've found audio, but it doesn't seem to be working: https://icecast-ietf.conf.meetecho.com:8443/
[09:09:13] Werner Koch_web_290 leaves the room
[09:09:15] Marek Blachut_web_874 joins the room
[09:09:17] Werner Koch_web_834 joins the room
[09:10:03] Hernâni Marques_web_643 joins the room
[09:10:35] <Roman Danyliw_web_994> I'm seeing 8 people have read it.  52 in Meetecho.
[09:11:00] <Mallory Knodel_web_924> There is a slight echo from the room
[09:11:19] <Roman Danyliw_web_994> @Meetecho -- anything you can do to help?
[09:11:20] <Randy Bush_web_202> soudns fine on meetecho
[09:11:24] <muelli> https://icecast-ietf.conf.meetecho.com:8443/parksuite9.mp3
actually works.
[09:11:32] <Benjamin Schwartz_web_288> I hear the echo via meetecho
[09:11:42] <dkg> i alos hear the echo via meetecho
[09:11:43] <Roman Danyliw_web_994> I also hear the echo
[09:11:48] <sftcd-x> @remote (or onsite) folks: please jump in the queue for clarifying questions or other comments
[09:11:55] <Andreas Huelsing_web_547> also echo here
[09:12:34] paulwouters joins the room
[09:12:43] <sftcd-x> @dkg do you need to end the poll? it's still on screen in the room
[09:12:59] <Meetecho> We'll send someone to check
[09:13:17] <paulwouters> dkg: can you kill / close the  hand raising thing. it is overlaying the presentation slides :(
[09:13:22] Jesus Martin_web_388 joins the room
[09:13:50] <Roman Danyliw_web_994> @Meetecho -- thank you
[09:14:26] <paulwouters> dkg: good. it is fixed now
[09:14:50] <sftcd-x> I figured it out:-)
[09:16:20] Robert Carolina_web_595 joins the room
[09:16:36] Ryan Cross_web_910 joins the room
[09:17:29] <Werner> Sorry, there is no such implementaion for GnUPG.  What Gniibe did are experimets to understand that new thing.
[09:17:57] <sftcd-x> @werner: did you want that on the mic? (and hence recorded?)
[09:18:42] <Werner> Its fro the records.  The slide is factual wrong here.
[09:19:15] Hernâni Marques_web_643 leaves the room
[09:19:30] Ryan Cross_web_910 leaves the room
[09:20:24] <sftcd-x> if anyone who can't send audio wants me to replay something to the room/recording, just preface your comment here with "mic:"
[09:21:29] <paulwouters> i guess if there is an interoperable implementation, there have to be at least two ? :)
[09:22:56] <Werner> Please recall that AEAD has been defined in January 2018 and since then deployed.
[09:23:30] <Daniel Huigens_web_143> @paul: we have two (OpenPGP.js and patched gopenpgp, though the latter is more of a hack than a branch)
[09:23:42] <Werner> With several 100k Users usuing it daily.
[09:23:58] <Daniel Huigens_web_143> And of course it's possible that I implemented it wrong twice, so certainly it would be better to have another implementation to check :)
[09:24:48] <sftcd-x> @werner: are you able to send audio? sounds like it'd be good to raise your last above wrt AEAD at the end of Justus' slides?
[09:24:52] <Werner> Sure
[09:24:57] <sftcd-x> great
[09:25:03] <paulwouters> no one claimed the interoperable implementations were independent :)
[09:25:12] <Daniel Huigens_web_143> Hmhm :)
[09:25:13] <Werner> Also video ;-)
[09:25:16] Jesus Martin_web_388 leaves the room
[09:25:20] Jesus Martin_web_969 joins the room
[09:25:36] <sftcd-x> video's great, but audio wins:-)
[09:25:52] <Werner> Need to save some bandwidth
[09:26:31] Jesus Martin_web_969 leaves the room
[09:26:35] Jesus Martin_web_475 joins the room
[09:26:52] Jesus Martin_web_475 leaves the room
[09:26:56] Jesus Martin_web_107 joins the room
[09:27:09] Aron Wussler_web_725 joins the room
[09:27:26] kesara joins the room
[09:29:42] Yoshiro Yoneya_web_413 leaves the room
[09:29:46] Yoshiro Yoneya_web_983 joins the room
[09:30:36] <Werner> OCB as MUST is great.  Having a FIPS mode is something I would have proposed anyway due to the current state of the FIPS algo discussions
[09:30:49] <sftcd-x> good!
[09:30:53] <Andreas Huelsing_web_547> is there a reason that the secret key algorithm is limited to AES-128 (in contrast to AES-256)?
[09:31:05] Robin Wilton_web_153 joins the room
[09:31:29] xcrypt1210 joins the room
[09:31:31] <Daniel Huigens_web_143> AES-256 is there, but not mandatory to implement
[09:31:34] <dkg> Andreas Huelsing_web_547: AES-128 is just MTI - AES-256 is still supported :)
[09:31:37] <g新部 裕_web_566> My understanding: AEADv1 is orthogonal to SEIPDv2.  GnuPG and rnp can work with AEADv1 packet.  AEADv1 is not defined in crypto-refresh-05.
[09:31:46] <Andreas Huelsing_web_547> Great, thanks
[09:34:12] Lorenzo Miniero_web_254 joins the room
[09:35:17] <muelli> Audio has just gotten much better. Thanks to whoever made this.
[09:35:23] <Mallory Knodel_web_924> +1
[09:35:39] <Roman Danyliw_web_994> he's very quiet
[09:35:40] <Andreas Huelsing_web_547> yes
[09:35:40] <dkg> we can hear you, but it's quiet
[09:35:42] <muelli> quiet
[09:35:43] <Benson Muite_web_340> yes
[09:35:44] <Roman Danyliw_web_994> that's much butter
[09:36:30] <sftcd-x> lesson is: wearing mask => speak close to mic
[09:37:09] <Werner> The lesson is: Never use GCM ;-)
[09:37:17] <Werner> Its just FIPS which likes it.
[09:37:36] <sftcd-x> reality though is that lotsa people (are forced to) like FIPS
[09:37:50] <Werner> :-( - I known
[09:37:50] <dkg> This is also a potential concern for any other AEAD mode -- having a robust key separation method avoids the problem in general.
[09:38:20] <sftcd-x> @werner please feel free to respond (or whomever)
[09:38:50] Lorenzo Miniero_web_254 leaves the room
[09:39:19] Stephen Farrell_web_791 leaves the room
[09:39:23] Stephen Farrell_web_519 joins the room
[09:39:30] <paulwouters> how would dropping aes_gcm not endanger the backwards compatiblity of gnupg's AEAD that uses aes_gcm ??
[09:41:08] <Werner> ic: No. It would just be dropping EAX
[09:42:05] <paulwouters> afaik, the backup cipher for AES-128 with NIST is AES-256
[09:43:49] <dkg> we can hear you Paul
[09:44:32] <Werner> mic: okay
[09:45:02] Benjamin Schwartz_web_288 leaves the room
[09:45:04] Florence D_web_850 leaves the room
[09:45:08] Florence D_web_359 joins the room
[09:45:37] <dkg> we can hear you
[09:46:06] Andrew Campling_web_208 joins the room
[09:47:12] Stephen Farrell_web_519 leaves the room
[09:47:16] Stephen Farrell_web_285 joins the room
[09:48:33] <Werner> Best practise is anyway to put just the mail address into the user id.
[09:48:59] <Werner> Technical required data so no GDPR concerns
[09:50:59] <muelli> you could loosen the requirement, though.
[09:51:09] <sftcd-x> @werner: I guess part of this question is whether, for v5 keys, we do consider including mail address as best practise or not
[09:51:21] <Werner> The whole idea of PGG 2 to OpenPGP was to require a self-signed user-id.  It was a backward compatible thing that we had no such requirement in the RFC.  That can and should of course be dropped.
[09:51:51] Valery Smyslov_web_762 joins the room
[09:52:44] <paulwouters> Werner: should the "no requirement" requirement be dropped? eg you are saying it should become mandatory ?
[09:52:46] <dkg> if anyone is interested in signing e-mail headers, please join LAMPS on Friday
[09:53:05] Thom Wiggers_web_316 leaves the room
[09:53:09] Thom Wiggers_web_983 joins the room
[09:53:24] <dkg> we'll be discussing draft-ietf-lamps-header-protection there, which explicitly contemplates S/MIME but should be applicable to PGP/MIME as well.
[09:53:42] Andrew Campling_web_208 leaves the room
[09:53:46] Andrew Campling_web_754 joins the room
[09:54:04] Thom Wiggers_web_983 leaves the room
[09:54:08] <Werner> At least it should be a SHOULD.  I would like a MUST but Derek once explained that for some minor implemntations there is no space for it.
[09:54:47] <sftcd-x> the "no space" question wasn't one the DT considered in this context
[09:55:16] <Werner> Thus the self-signature should be a MUST
[09:55:57] <dkg> daniel huigens: is this proposal about all OpenPGP certificates, or just those certificates with a v5 primary key?
[09:55:59] <sftcd-x> @werner: I'd be interested in your argument for why inclusion of user-id (likely containing an email addr) isn't less privacy friendly than not including (not in GDPR terms just general privacy)
[09:56:25] kesara leaves the room
[09:57:17] Valery Smyslov_web_762 leaves the room
[09:57:32] <Werner> For mail a user-id is required anyway (containing the mail address)
For other data some ther identifier is often used.
[09:58:02] <dkg> if the certificate is gathered by WKD, why would the recipient need to see a User ID?
[09:58:03] Satoru Kanno_web_187 joins the room
[09:58:12] <dkg> (if it's verified by the WKD fetch itself)
[09:58:17] <sftcd-x> @werner: you mean necessary for searching for public keys based on email addr?
[10:00:56] Thom Wiggers_web_145 joins the room
[10:01:38] Valery Smyslov_web_373 joins the room
[10:02:18] Valery Smyslov_web_373 leaves the room
[10:02:21] <Werner> and comparing the mail sender to the key.  Requirement in many policies
[10:02:37] <sftcd-x> ack
[10:03:09] Jan-Frederik Rieckers_web_358 leaves the room
[10:03:10] <Roman Danyliw_web_994> Not a comment on the technical part of the proposal.  I'm the new responsible AD and still getting up to speed.  I will need to chat offline with the chairs on the charter assessment.
[10:03:13] Jan-Frederik Rieckers_web_281 joins the room
[10:04:01] <dkg> Roman Danyliw_web_994: thanks, that would be great
[10:04:11] Marek Blachut_web_874 leaves the room
[10:04:37] <sftcd-x> @roman: sure
[10:04:42] xcrypt1210 leaves the room
[10:05:24] <dkg> RFC 4880 didn't say anything about the user ID packet having any particular length (it also didn't prohibit a zero-length User ID)
[10:05:32] <Werner> pgp 2.6.3ia I think started to require self-signatures.
[10:07:58] <Werner> keep human presentation of the fingerprint to the implementations.
[10:08:05] <Florence D_web_359> Werner, would you be able to summarise your comment from the issue before in the notes?  We didn't catch it (sorry)
[10:08:40] Robin Wilton_web_153 leaves the room
[10:08:40] <Florence D_web_359> It's ok, Daniel is on it
[10:08:42] <Werner> self-signature?
[10:08:44] Robin Wilton_web_303 joins the room
[10:08:48] Andrew Campling_web_754 leaves the room
[10:09:10] <sftcd-x> @florence: action on chairs to start thread on list with options: a) the "tentative proposal" or b) the status quo (possiblly better documented)
[10:10:32] <Florence D_web_359> Done
[10:10:55] <Werner> Formatting the fingerprint depends on the UI - maybe suggest an option to show the fingerprint as hex digits.
[10:11:00] <Mallory Knodel_web_924> I'm here
[10:11:14] <sftcd-x> oh sorry, didn't see ya in the list
[10:11:21] <Mallory Knodel_web_924> But you should work this out before you come to me
[10:11:22] <Andreas Huelsing_web_547> Comparing fingerprints is also not a PGP specific issue. Is there any proposal that may be worth considering?
[10:11:26] <muelli> +1 to Daniel
[10:11:36] <Werner> You can't read a QR code over the phone.
[10:11:45] <sftcd-x> @mallory: we won't figure this one out today;-(
[10:11:56] <Mallory Knodel_web_924> In the queue on this issue, not my pres
[10:12:02] <sftcd-x> ack
[10:13:29] <Mallory Knodel_web_924> It woudl be good to do a check
[10:13:32] <dkg> signal's "security code" is also pairwise, not per-participant
[10:14:07] <Mallory Knodel_web_924> Correct
[10:14:07] <dkg> my experience talking to users of secure messaging apps is that no one is actually verifying fingerprints at all 😛
[10:14:11] <muelli> I'd say the OpenPGP spec sholdn't concern itself with the verification of key material but rather describe how it's serialised on the wire.
[10:14:24] <sftcd-x> @dkg: thats what I do (or don't do)
[10:14:24] <Thom Wiggers_web_145> Interestingly WhatsApp went with base 10 (for ux reasons ?)
[10:14:45] <Thom Wiggers_web_145> Ah signal does the same
[10:14:49] <dkg> Thom Wiggers_web_145: yes, i think that more people know (and can distinguish) the arabic numerals than all of the hex digits.
[10:15:12] Florence D_web_359 leaves the room
[10:15:16] Florence D_web_238 joins the room
[10:15:28] <Thom Wiggers_web_145> might also match the language used better (‘security numbers’)
[10:15:37] <Mallory Knodel_web_924> My point is not that messaging apps are doing it better, but that this effort should align with (perhaps) imperfect UX implementations elsewhere.
[10:15:45] <Thom Wiggers_web_145> ++
[10:16:56] <Daniel Huigens_web_143> Fwiw, I would be in favor for rechartering for this work and other work
[10:19:25] Andrew Campling_web_218 joins the room
[10:22:51] Daniel Huigens_web_143 leaves the room
[10:22:55] Daniel Huigens_web_977 joins the room
[10:23:18] Randy Bush_web_202 leaves the room
[10:23:28] <paulwouters> i would even think think of rechartering only after we pass WGLC  since lots of people will wake up only at WGLC
[10:24:06] Daniel Huigens_web_977 leaves the room
[10:24:10] Daniel Huigens_web_625 joins the room
[10:24:20] <dkg> there they are!
[10:24:37] Marek Blachut_web_737 joins the room
[10:25:18] <dkg> note that https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/101 covers this topic generally
[10:25:21] Daniel Huigens_web_625 leaves the room
[10:25:25] Daniel Huigens_web_740 joins the room
[10:25:28] Shigeya Suzuki_web_117 leaves the room
[10:25:32] Shigeya Suzuki_web_460 joins the room
[10:25:55] Shigeya Suzuki_web_460 leaves the room
[10:25:59] Shigeya Suzuki_web_302 joins the room
[10:26:19] Daniel Huigens_web_740 leaves the room
[10:26:20] <sftcd-x> sure let's all just use rainbow, what could possibly go wrong? :-)
[10:26:23] Daniel Huigens_web_300 joins the room
[10:26:44] <dkg> it's worth noting that some of the changes to the v5 keys in the current crypto-refresh draft were designed to accomodate larger cryptographic objects, in expectation that PQ algorithms might require larger keys
[10:26:58] xcrypt1210 joins the room
[10:27:59] <justus> did we?
[10:28:07] sftcd-x wonders if anyone's looked at applications for hash based sigs with pgp?
[10:28:19] <justus> we changed the signature subpacket area sizes
[10:28:26] <justus> don't think we did that for keys
[10:28:35] <Roman Danyliw_web_994> Per LAMPS, yes it has a number of PQC charter items
[10:28:41] <dkg> justus: sorry, you're right that it's v5 signatures, not v5 keys
[10:28:53] <Thom Wiggers_web_145> stateful hashes are extremely scary in this application imo
[10:28:54] <justus> notably, we didn't lift the size restrictions that the MPI representation brings
[10:29:20] <dkg> not all pubkeys expect MPI in all places
[10:29:26] <justus> true
[10:29:27] Daniel Huigens_web_300 leaves the room
[10:29:31] Daniel Huigens_web_611 joins the room
[10:29:35] <dkg> (ecdsa and ecdh expect a non-MPI OID)
[10:29:49] <Werner> That one of the reasons why we proposed the SOS but in any case there is no need to use MPIs.
[10:30:36] <Stavros Kousidis_web_725> We will focus on stateless signatures for OpenPGP (in the project), but Linux Distributions might have use cases für stateful hash-based signatues. Actually this is a ppoint that we would like input on from the openpgp wg.
[10:30:40] <dkg> i lean twoard new pubkey algorithms should probably use "raw" (or "native") formats for pubkey material where possible
[10:30:47] <sftcd-x> @thom: yeah that's what I'd have thought too (about stateful sigs)
[10:31:24] <Andreas Huelsing_web_547> @sftcd-x There are companies that implemented the stateful hash-based signatures for software updates. This wouldtypically be an application that would be happy about PGP support. Given the missing standards, these are right now only proprietary
[10:31:43] <sftcd-x> personal (biased) opinion: mid-2024 is way too early to know we're standardising the right stuff in PQC-space
[10:32:29] <sftcd-x> @andreas: yep, I just wondered if any package mgr type things using pgp had look at stateful sigs
[10:32:41] <Thom Wiggers_web_145> NISTs call for new submissions to the signature schemes will probably only just be getting started by then I think
[10:32:56] <Andreas Huelsing_web_547> --> that is why we propose to do multi-algorithm schemes (i.e., combining lattice with ECDH)
[10:33:02] <dkg> Thanks, Falko!
[10:33:30] <Werner> What about Applebaum/DJBs work on PQC for OpenPGP?  Any news?
[10:34:13] Benjamin Schwartz_web_660 joins the room
[10:36:19] <dkg> Werner: do you have a link for that work?
[10:36:39] <Werner> No,  personal communication quite some time ago.
[10:36:48] <Werner> I was just curious
[10:36:51] <justus> Falko Strenzke_web_264: your mic is still hot
[10:39:59] Valery Smyslov_web_361 joins the room
[10:42:41] <sftcd-x> section 1.a could be dozens of pages;-)
[10:44:12] Valery Smyslov_web_361 leaves the room
[10:44:16] Valery Smyslov_web_550 joins the room
[10:44:41] Werner Koch_web_834 leaves the room
[10:44:45] Werner Koch_web_148 joins the room
[10:45:34] Florence D_web_238 leaves the room
[10:45:38] Florence D_web_688 joins the room
[10:46:47] <Mallory Knodel_web_924> e2ee@ietf.org
[10:47:40] <Thom Wiggers_web_145> Nice and important work!
[10:47:56] <Mallory Knodel_web_924> Thank you! We need more engagement if we are to move the work forward.
[10:48:14] <sftcd-x> thanks for presenting
[10:48:17] <dkg> Mallory Knodel_web_924: thanks for working on this, and raising it to the group
[10:48:29] <Mallory Knodel_web_924> Appreciate the time on the agenda, Stephen and Daniel.
[10:49:09] <paulwouters> mumbles openpgpkey DNSSEC records as third party check on WKD :)
[10:50:05] Korry Luke_web_215 leaves the room
[10:50:09] Korry Luke_web_818 joins the room
[10:50:29] Valery Smyslov_web_550 leaves the room
[10:50:33] Valery Smyslov_web_241 joins the room
[10:51:16] <dkg> "everyone" meaning every domain owner?
[10:51:35] <dkg> ok, so could be cross-domain
[10:51:44] <Daniel Huigens_web_611> @dkg potentially, it's still open for debate
[10:51:45] Andrew Campling_web_218 leaves the room
[10:51:49] Andrew Campling_web_504 joins the room
[10:51:51] <sftcd-x> sounded more like the things like CT-logs
[10:52:06] <sftcd-x> availability is a bit of a deal for those
[10:52:11] <Werner> paulwouters: Get the browser vendors on board and the ISPs to allow adding keys to the zone.  That is the major hassle - thus the idea to get back to the easier deployable web key direcory
[10:52:14] <Daniel Huigens_web_611> @sftcd-x yeah, it's quite similar
[10:52:57] Andrew Campling_web_504 leaves the room
[10:53:29] <Werner> Adding stuff to a web server is an easy thing for everyone with a website.  Change the zone is not.
[10:53:55] <Daniel Huigens_web_611> For clarity, we (ProtonMail) are not proposing a specific implementation for standardization here, it's more an idea at this point that might warrant discussion & potential standardization
[10:54:49] <Daniel Huigens_web_611> (Even though we do have a specific implementation, it's somewhat specific to ProtonMail and a general implementation / standard would probably look a bit different)
[10:55:08] <Werner> SCNR to post this note on PQC as well as some other ideas:
  In the meantime, while everyone's fixated on patching the theoretical
  mousehole in the corner, they're conveniently avoiding addressing the
  fact that entire walls of the barn are missing elsewhere.
                                                            -pgut001
[10:55:23] <justus> I'd like to see ProtonMail simply certifying userid bindings
[10:55:42] <justus> i understand that the goals are slightly different, but at least this would be immediately useful for existing implementations
[10:57:37] <Daniel Huigens_web_611> @dkg I think simply putting a certificate in there could also work
[10:58:16] Roman Danyliw_web_994 leaves the room
[10:58:20] Roman Danyliw_web_631 joins the room
[11:00:46] Thom Wiggers_web_145 leaves the room
[11:00:56] Roman Danyliw_web_631 leaves the room
[11:01:04] <dkg> thanks all!
[11:01:05] <Daniel Huigens_web_611> @justus we could certify User IDs, but indeed the goal here is for the user to detect if ProtonMail (or any keyserver) serves a malicious key for their email address
[11:01:06] paulwouters leaves the room
[11:01:09] <Quynh Dang_web_619> Thank you all.
[11:01:12] Robin Wilton_web_303 leaves the room
[11:01:13] Jonathan Hammell_web_658 leaves the room
[11:01:14] Valery Smyslov_web_241 leaves the room
[11:01:16] <Daniel Huigens_web_611> Thanks all!
[11:01:16] <Benson Muite_web_340> Thanks, useful discussion
[11:01:20] <Werner> cu
[11:01:22] <Aron Wussler_web_725> Thanks, bye!
[11:01:25] Werner leaves the room
[11:01:26] Benjamin Schwartz_web_660 leaves the room
[11:01:27] Falko Strenzke_web_264 leaves the room
[11:01:27] <Florence D_web_688> Can people check they're correctly paraphrased in the notes please?  Thanks
[11:01:30] Shigeya Suzuki_web_302 leaves the room
[11:01:37] Lara Bruseghini_web_550 leaves the room
[11:01:40] <justus> Daniel Huigens_web_611: please start with that ;)
[11:01:40] Florence D_web_688 leaves the room
[11:01:41] Lara Bruseghini_web_181 joins the room
[11:01:46] Robert Carolina_web_595 leaves the room
[11:01:48] Andreas Huelsing_web_547 leaves the room
[11:01:51] Mallory Knodel_web_924 leaves the room
[11:01:52] Stavros Kousidis_web_725 leaves the room
[11:01:54] Melinda Shore_web_302 leaves the room
[11:01:57] Alyssa Thompson_web_198 leaves the room
[11:01:58] Quynh Dang_web_619 leaves the room
[11:01:58] <justus> Thanks :)
[11:02:04] Jan-Frederik Rieckers_web_281 leaves the room
[11:02:05] Alison Becker_web_508 leaves the room
[11:02:05] Aron Wussler_web_725 leaves the room
[11:02:07] g新部 裕_web_566 leaves the room
[11:02:07] Meetecho leaves the room
[11:02:08] Werner Koch_web_148 leaves the room
[11:02:15] Alessandro Toppi_web_225 leaves the room
[11:02:15] Daniel Gillmor_web_368 leaves the room
[11:02:15] Johannes Roth_web_409 leaves the room
[11:02:15] Stephan Ehlen_web_601 leaves the room
[11:02:15] Tadahiko Ito_web_512 leaves the room
[11:02:15] Michael B_web_807 leaves the room
[11:02:15] Benson Muite_web_340 leaves the room
[11:02:15] Justus Winter_web_113 leaves the room
[11:02:15] Michael Hollyman_web_977 leaves the room
[11:02:15] Evangelos Karatsiolis_web_957 leaves the room
[11:02:15] Yoshiro Yoneya_web_983 leaves the room
[11:02:15] Stephen Farrell_web_285 leaves the room
[11:02:15] Satoru Kanno_web_187 leaves the room
[11:02:15] Kesara Rathnayake_web_406 leaves the room
[11:02:15] Daniel Huigens_web_611 leaves the room
[11:02:15] Marek Blachut_web_737 leaves the room
[11:02:15] Korry Luke_web_818 leaves the room
[11:02:15] Lara Bruseghini_web_181 leaves the room
[11:02:15] Jesus Martin_web_107 leaves the room
[11:04:28] sftcd-x leaves the room
[11:20:32] gniibe leaves the room
[12:03:30] paulwouters joins the room
[12:29:21] paulwouters leaves the room
[13:14:39] justus leaves the room
[18:18:38] dkg leaves the room: leaving
[19:52:44] sftcd leaves the room
[19:52:48] sftcd joins the room
[20:50:11] muelli leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!