stpeterI really really need to spend some quality time with XEP-0301 again
m&mI think there needs to be a lock-down on 301 updates for a week or two
stpeterheh
ralphmi'm about to set up a filter
stpeter'tis time?
ralphmindeed
KevIt is.
Kev1) Roll call
KevMattJ sends apologies.
ralphmhere
m&mabsent
m&m*presente
ralphmit's getting old quickly now^Uhaha
KevTobias: ?
m&mIt's just getting started
Tobiasyes.here
m&ms/it's just getting started/indeed/
KevRight.
Kev2) Matt's IETF report.
m&mso
m&m2.1) E2E — still progressing, mostly in JOSE not XMPP directly
m&mby the way, if anyone is interested in a solution here, I would recommend joining the jose@ietf.org mailer and commenting on any non-OpenId use cases
m&m2.2) DNA — Stpeter and I wrote up a series of drafts for domain name associations (formerly assertions)
m&mthey are light on examples, and there is desire for more guidelines; which to do first, signaling preferences, etc
m&malso includes prooftypes using DNSSEC/DANE and POSH
stpeterPOSH being "PKIX over Secure HTTP" -- basically parking your certificate at a well-known URI
m&mthank you
m&m2.3) 6122bis — mostly waiting on PRECIS, but there are some changes to processing order, and what to do with certain classes of code points (e.g. full- and half-width)
ralphmto be sure, this is the certificate proving that a host may act for a particular domain, right?
m&mralphm: yes, by virtue of HTTPS 30x redirects
m&mrequest https://mydomain.com/.well-known/posh._xmpp-client._tcp.cer , get redirected to https://thathostingcomany.net/.well-known/posh._xmpp-client._tcp.cer
m&mDNSSEC is our existing SRV lookups, but with the expectation the record(s) are signed (valid)
KevOh, that's a bit icky isn't it?
m&mKev: it's not perfect, but it is deployable
KevRequiring people not just to know how to get to the final resource, but also to keep track of how HTTP panned out getting there, I mean.
KevWell-known-URIs are themselves icky, but I can hold my nose for that.
m&mmost HTTP libraries will let you know when a redirect is followed, and how
KevDoes this allow more than one jump?
m&mthat right now is not specified … it could, and we'll probably need to put some limits around it
KevI've got a feeling of general unease about redirects and proofs, because you need to keep track of cert trust at each hop and blah.
ralphmindeed. There have been issues with this in other protocols
m&mKev: alternate suggestions welcome
KevNot that this is a deal-breaker, I just enter it with trepidation.
m&mso do most of us
m&mbut
m&mit's at least something that could get implemented and deployed before universal IPv6
stpeterwell, universal DNSSEC
stpeter(and DANE)
Kevxmpp:jabber.org has IPv6.
m&mI assert that universal DNSSEC will happen just after universal IPv6
KevAnyone using HE can't route to it...
m&mKev: that's not universal
m&md-:
m&mPOSH is one possible approach, DNSSEC/DANE is another
m&mboth have the potential to make dialback even more relevant than before
KevOK. I need to use my time machine to create some more time to look at this better.
m&mKev: I know exactly what you mean (-:
KevWas that the IETF report done with?
ralphmKev: go back further and tell those IPv4 people to do it right
Kevralphm: I think the IPv4 people /did/ do it right.
KevIPv6 is much more contentious.
m&mre IETF report — there's probably some things happening in PRECIS that are relevant to us also
XMPP Council - 2012-08-15