[05:29:27] Warren Kumari joins the room [05:30:59] For those participating remotely: This is where the jabber bits for DANE will be. The time in Prague as of writing this is 07:30 — we start in ~1.5h [05:32:05] Warren Kumari leaves the room [06:18:25] Warren Kumari joins the room [06:22:45] Warren Kumari leaves the room [06:23:20] Warren Kumari joins the room [06:52:09] wouter joins the room [06:54:09] paulwouters joins the room [06:54:58] richard.barnes joins the room [06:55:19] wouter == paulwouters? [06:55:21] naptee joins the room [06:55:30] buckeyeskeeve joins the room [06:55:43] no, paulwouters is Paul Wouter and wouter is Wouter Wijngaards. [06:55:57] sorry, Paul Wouters [06:58:13] jelte@jabber.isc.org joins the room [06:58:21] bogus.nagasaki.com returns 404:Filenotfound for ietf808.mp3 [06:58:25] good morning [06:58:44] damn name space collisions [06:59:01] jelte@jabber.isc.org leaves the room [06:59:12] jelte joins the room [06:59:34] jabley joins the room [07:00:22] scott_rose joins the room [07:01:13] richard.barnes leaves the room [07:02:01] matthijs joins the room [07:02:28] richard.barnes joins the room [07:02:30] sftcd joins the room [07:02:40] warren is making introductions [07:02:43] Simon Josefsson joins the room [07:02:51] I have just volunteered to be jabber scribe [07:03:00] Olafur joins the room [07:03:01] lepinski joins the room [07:03:09] if anybody has anything they want me to channel to the microphone, let me know [07:03:21] =JeffH joins the room [07:03:21] warren: note well, blue sheets [07:03:22] Hugo Salgado joins the room [07:03:32] warren: agenda bashing [07:03:47] happiness with agenda [07:04:31] some difficulty hearing things from the back of the room, local PA problem [07:04:44] ondrej providing introduction to working group [07:05:12] plan to release drafts frequently as issues are resolved [07:05:18] Patrik Halfar joins the room [07:05:30] ietf issue tracker (trac) used to track issues [07:05:41] Paul Hoffman joins the room [07:05:41] yoav.nir joins the room [07:05:42] koji joins the room [07:05:49] Jacky Yao (Health Yao) joins the room [07:06:46] 21 tickets processed in the issue tracker so far [07:06:59] sebastian.castro joins the room [07:07:03] note mailing list name to be dane@, not keyassure@ [07:07:32] transition from one to the other to be made seamless by ondrej [07:07:45] John Dickinson joins the room [07:07:53] sandoche joins the room [07:07:54] paul hoffman to present on TLSA status [07:08:03] jakob is not here [07:08:23] paul and jakob are document authors, but consider themselves editors [07:08:25] Melinda joins the room [07:08:26] pawal joins the room [07:08:39] is paul audible? [07:08:43] Chris Griffiths joins the room [07:08:45] you can't hear him? [07:08:55] the mic works in the room [07:09:02] i can, was asking if he's ok for remote folks [07:09:05] pretty much. What's impairing audio in the back is audience noise, not the speakers [07:09:50] paul does not plan to review the whole document, because he assumes people have read it [07:10:05] currently −06 [07:10:07] Elmar (DENIC) joins the room [07:10:36] Jacky Yao (Health Yao) leaves the room [07:10:40] each rev represents closure on a small number of issues [07:10:45] most of the draft seems stable [07:10:54] spturner joins the room [07:11:12] cdlilj joins the room [07:11:41] Jim Galvin joins the room [07:11:50] matthijs leaves the room [07:12:07] matthijs joins the room [07:12:07] issues seem to come in batches, e.g. because people are new to the topic or because there are several issues opened on the same general point [07:12:20] weiber joins the room [07:12:30] yone joins the room [07:12:54] qname format is _portnum._prototype.hostname [07:13:06] jimsch joins the room [07:13:16] response has cert type, hash type, binary blob [07:13:29] two cert-types defined, end entity and CA [07:13:40] sticking to TLS nomenclature with this [07:14:15] end entity means end entity certificate, CA means CA certificate, in TLS nomenclature [07:14:33] Elmar (DENIC) leaves the room: I'm happy Miranda IM user. Get it at http://miranda-im.org/. [07:14:40] joseph.yee joins the room [07:14:53] three hash types defined, 0 means full certificate, 1 is sha-256, 2 is sha-512 [07:15:00] may get more than one response to a query [07:15:33] e.g. multiple origin servers with individually-unique certs behind a load balancer [07:16:15] cert type 1 is for self-issued certs [07:16:26] cert type 2 specifies a particular CA to chain to [07:17:31] dane tries to associate a certificate with a server [07:18:14] Linus Nordberg joins the room [07:18:23] jeff asks: are we open to wording changes [07:18:26] paul: absolutely [07:18:44] Jacky Yao (Health Yao) joins the room [07:19:27] with dane, clients can get additional information about a server [07:19:37] with dnssec, they can plausibly trust that information [07:19:53] summary of issues [07:20:05] just TLS, or DTLS? clarification in −06 (it's both) [07:20:33] sandoche leaves the room [07:20:56] not other security protocols, though [07:21:11] query/response formats seem stable [07:21:26] mandatory algorithms and formats [07:22:09] section 4 of draft, cert-type 1 and 2, hash-type 0 and 1 are all MUSTs [07:22:18] hash-type 2 (SHA-512) is SHOULD [07:23:52] bhoeneis joins the room [07:24:23] Shane Amante joins the room [07:24:33] both parameters are extensible by way of an IANA registry [07:25:24] some interest in adding support for additional cert-types, e.g. bare keys, openpgp certs [07:25:59] peter koch: clarifying question, I haven't seen language about foreward compatability [07:26:13] koch: what is a client confirming to today's spec to do if in the future it sees an unknown cert type? [07:26:44] paul: true, we will add text for that [07:26:49] warren: it's in section 3 [07:26:57] paul: oh, ok, I guess we did have words for that [07:27:07] paul: perhaps additional words required in section 4 [07:27:19] still open issues [07:27:22] let's not discuss them here [07:27:27] (in this presentation) [07:27:59] question on once you get a certificate, what do you need to know about what's inside it? pull apart the pkix blob, what to do with it. see next presentation. [07:28:13] question on attacks, mitm, compromised intermediate CA [07:28:17] still needs work, maybe in security considerations [07:28:58] you don't want a compromised CA to be able to issue certs for you [07:29:04] milan.sova joins the room [07:29:19] phb: CAA covers that use case, and is designed for that use case [07:29:34] paul: that is a proposal that may get implemented [07:29:38] matthijs leaves the room [07:29:51] matthijs joins the room [07:29:52] phb: the proposal has support of CAs [07:29:54] paul: all of them? [07:29:58] phb: about 60% of them [07:30:29] (phb and paul banter, spec fight, need popcorn) [07:30:39] randy: children, please play nicely [07:31:17] more open issues [07:31:52] there is minimal dnssec protection in practice to end users [07:32:02] due to lack of widespread deployment of validation [07:32:10] Andrew joins the room [07:32:31] without dnssec there is a risk of a mitm insertion of a rogue trust anchor for a session [07:32:55] ekr has a question, paul asks him to wait a second [07:33:28] description of error conditions could be better [07:33:56] Kanno Satoru joins the room [07:34:12] issue of the strongest hash alg that can be used [07:34:38] should TLSA be a self-standing resource record, or should it be returned in conjunction with more general queries? (like RRSIG, maybe) [07:34:51] dane for a whole domain? [07:34:54] next steps [07:34:57] deal with open issues [07:35:21] expect to rev the draft a few more times [07:35:39] also like more feedback from other people who have an interest [07:35:56] e.g. dnssec people, pkix people, tls people [07:36:01] [so many people interested that some of us couldn't get in the room!] [07:36:24] warren asks after blue sheets [07:36:32] if the in-conjunction idea gets traction some of us might have to become more active to oppose that :P [07:36:54] steve kent: in ipsec we put mandatory to implement algorithms in the document, and that was not the right thing to do [07:37:02] steve kent: why not separate them out into other documents? [07:37:40] paul: when you don't expect the mandatory to implement algs to change, putting them in the main document makes sense [07:37:52] paul: some people think that they would be better in a registry [07:38:35] paul: feel free to open an issue on that [07:38:39] russ: separate document please [07:38:44] mic: we haven't actually sent that document out yet, so we don't have any experience with whether it is easier to understand [07:39:01] jim: to the ca cert, not through the ca cert [07:39:04] paul: correct [07:40:01] name ? [07:40:11] Andrew Sullivan. Sorry. [07:40:11] ekr: convention in tls is that there is often ambiguity about what trust anchor to be used [07:40:21] (It shows up on my end!) [07:40:34] i meant speaker at the mic.... [07:40:37] oh [07:40:41] eric rescorla [07:40:44] eburger joins the room [07:40:57] andrew's comment is being channelled to the mic [07:41:00] polk.tim joins the room [07:41:14] narten joins the room [07:41:16] Kanno Satoru leaves the room [07:41:44] matthijs leaves the room [07:41:48] Satoru Kanno joins the room [07:42:08] richard barnes to present on harmonising pkix and dane [07:42:09] [thanks for the channel] [07:42:14] Hugh_Daniel joins the room [07:42:44] richard presents a diagram which shows how TLS works today [07:42:50] matthijs joins the room [07:43:00] Klaas Wierenga joins the room [07:43:03] policies, trust anchors and TLS certification chain feed the PKIX cert/path validation process [07:43:09] outcome is either reject/accept [07:43:39] Hugh_Daniel leaves the room [07:43:55] question of how dane changes that diagram [07:43:57] miek@jabber.sidn.nl joins the room [07:44:20] dane might influence trust anchor and policy inputs to the validation process [07:44:33] but also maybe directly indicate an accept/reject decision [07:44:48] goals: define how dane affects validation [07:44:58] goals: don't change pkix process, but modify pkix inputs [07:45:16] some definitions: ca-issued certificate (issued by someone other than the domain owner) [07:45:32] domain-issued cert, issued by the owner of a TLS server/the domain name [07:46:33] spturner leaves the room [07:46:41] cert-type 2 (CA certificate) PKIX application is straightforward [07:47:42] one subtlety: PKIXTA is defined as (name, key, key params) in 5280. no other checks are required. however, dane could require some additional checks. [07:48:08] martin thompson: when you say add to the TAs, do you mean add or replace existing TAs? [07:48:14] room: "replace!" [07:48:26] leslie joins the room [07:48:48] phb: if you look at the end of section 3 "if no match is found… then the TLS client must abort the handshake..." [07:49:11] phb: so dane is intended to override pkix, and this is not optional [07:49:12] sm joins the room [07:50:05] i think the use case is #commodogate ? :) [07:50:43] phb: concern about incremental deployment, inference that dane's goal is to kill certification authorities, etc [07:51:58] don't know his name: could be a case where the name and key but some key parameters that might usually be inherited from a higher level CA are not retrieved, perhaps some ambiguity [07:52:09] <=JeffH> stephen farrell [07:52:09] richard: that's an interesting point, there is no text to cover that right now [07:52:11] matthijs leaves the room [07:52:13] thanks [07:52:27] richard: what about cert type 1? [07:52:40] intended semantic is that server cert must match the dane cert [07:52:49] is this necessary, or necessary+sufficient? [07:52:58] various options [07:53:00] matthijs joins the room [07:53:19] full pkix validation? [07:53:23] bare keys? [07:53:32] bare keys + some pkix-like checks? [07:53:49] Moral equivalent of bare keys, not actual bare keys [07:53:56] thanks [07:54:10] Not clear from the slide [07:54:26] option a: pkix validation. tls cert must match dane and pass pkix validation [07:54:41] protection against CA re-issuing a certificate [07:54:58] phb: not re-issuing, protects against acceptance of a re-issued cert [07:55:30] for domain-issued certs, also needs a CA to chain to [07:56:15] self-signed certs are CA certs, TLS spec has some ambiguity about this [07:56:39] that's a bit bogus; self signed certs just work [07:56:39] but publish your own cert as a type 2 cert in dane, perhaps removes ambiguitty [07:57:01] ekr: disagrees somewhat that TLS spec is ambiguous, in fact self-signed certs are common practice with TLS [07:57:36] richard: don't think this ambiguity is particularly important for dane, just pointing out we can accommodate either case [07:57:56] (don't know his name): issues with DNS caches, cert expiry need to be managed with DNS TTLs [07:58:02] richard, warren: yeah [07:58:18] option b: bare keys [07:58:31] current document uses certs that are never validated by a relying party [07:58:39] "a cert that is not validated is invalid" [07:58:54] so perhaps just encode what you care about, the public key [07:59:06] matthijs leaves the room [07:59:36] richard compares the two options [07:59:37] not clear to me that bare keys are actually easier to encode than a cert with a key and all bogus fields [07:59:37] Jacky Yao (Health Yao) leaves the room [08:00:03] matthijs joins the room [08:00:49] open question for the working group, how to handle cert type = 1 [08:01:12] three questions posed as thought experiment [08:01:18] should you accept an expired cert? [08:01:24] should you accept a cert with incorrect CA bits? [08:01:42] should you accept a cert type 1 cert whose common name != domain name [08:01:45] sandoche joins the room [08:01:52] miek@jabber.sidn.nl leaves the room [08:02:07] ekr: theme 1: make it difficult for some other CA to issue a cert for your domain [08:02:14] ekr: theme 2: make it easier not to deal with a CA at all [08:02:41] ekr: for theme 1, cert lock, don't need dnssec [08:02:54] ekr: for theme 2: do need dnssec, critically important [08:03:13] ekr: for my money 90% of the value proposition is cert lock, not eliminating need for CAs [08:03:32] phb: +1 ekr, I would like a bit that says whether you want to turn on restriction properties [08:03:46] phb: is what you are trying to do to enable crypto, or to turn on the padlock icon? [08:04:33] phb: re gedankenexperiment, any key is better than no crypto [08:05:02] warren: phb, please send e-mail to list [08:05:26] steve kent: comments reflect lack of requirementsd [08:05:41] steve kent: great progress in design, but nothing to validate against it against [08:06:28] ondrej: clarifying questions on this presentation first please, then open to other questions afterwards [08:06:35] marco joins the room [08:06:42] warren: we are not trying to solve issues right now necessarily, just trying to frame some problems [08:07:40] paul wouters: nervous about implications for pkix validation, and also pkix beats dane or dane beats pkix should be documented [08:08:06] (missed name): worried that this amplifies the phishing problem [08:08:28] stefan santesson [08:08:47] phishing attack with wrong domain name might be harder to notice if dane provides assurance of valid security [08:09:02] warren: how do you figure out from the cert whether you're using the right domain name? [08:09:13] stefan: EV certs [08:09:35] stefan: also images embedded in certs, visual recognition of identity of entity [08:10:33] paul hoffman: most applications that use TLS require domain name from the pkix certificate [08:10:34] cdlilj leaves the room [08:10:35] cdlilj joins the room [08:11:03] matthijs leaves the room [08:11:21] matthijs joins the room [08:11:27] paul hoffman: if you are concerned that the domain name is not sufficient, dane will not hurt you [08:11:51] paul hoffman: dane ties domain name more closely to a cert, but you can still use certs that incorporate other mechanisms [08:12:25] glen zorn: I'd like to agree with dr kent about the need for requirements, problem statement [08:12:43] glen zorn: use cases can be enabling and constraining, and it's useful to have a list of such things [08:12:58] ekr: I also agree with dr kent [08:13:22] ekr: without knowing whether what your goal is cert lock or the other thing [08:13:29] ekr: what is the wg trying to do? [08:13:54] paul hoffman: use cases have been discussed on the list, but they are not in the document [08:14:22] randy: no goals, no use cases, randy is unhappy [08:14:39] what happened to the building-blocks mentality? :P [08:14:40] paul hoffman: even if you had read the mailing list, you would not be happy. [08:15:25] (can't see who is talking) so who is going to write use cases? [08:15:33] paul hoffman: jakob and I are happy to add such things to the document [08:15:50] paul hoffman: don't think we should do it, personally [08:15:58] warren: we will need to figure this out [08:16:03] this is really section 3 as well [08:16:29] ekr: use cases and requirements cases are instruments for defining work to be done [08:16:38] <=JeffH> "so who is going to write use cases?" -- was me -- Jeff Hodges (sorry for not giving my name) [08:16:40] Suggestion: perhaps each person who thinks s/he has a use case could write that up as though it would be included in some document [08:16:44] and send that to the list [08:17:00] ekr: (ekr is talking at ekr speed, and I need coffee, and I am failing to transcribe, sorry) [08:17:04] <=JeffH> andrew: yep [08:17:04] then we could talk about specific trade-offs. [08:17:20] paul hoffman: we don't have wg consensus on the core goals here [08:17:27] John Dickinson leaves the room [08:17:48] We'll never get the consensus on the use cases unless we have concrete text. [08:17:55] matthijs leaves the room [08:18:06] paul hoffman: I would like some requirements to use to validate the defined protocol [08:18:10] ekr: (see above) [08:18:38] matthijs joins the room [08:18:38] warren: asking whether we should hum to get a rough idea about the core goal [08:19:17] ekr: restrictive or permissive. restrictive is cert lock, permissive is CA-avoidance. [08:20:09] paul hoffman: please send to list [08:20:50] phb: +1 steve kent. argued early on that purpose of dane is to assist CAs avoid mis-issue [08:20:59] phb: wring hands, recriminations, finger-pointing [08:21:32] phb: I wrote CAA, etc, etc [08:22:06] randy: spent the last 10 minutes on many use cases for a requirements document [08:22:15] randy: can we agree that requirements will be produced? [08:22:17] warren: yes [08:22:22] polk.tim leaves the room [08:22:45] dougm.home joins the room [08:22:55] dave crocker: requirements docs in the ietf tend to be detailed, take a long time to get to, are frequently ignored. not saying don't do one, but don't make it the immediate task. [08:23:05] dave: instead a list of brief, non-technical statements of what problem you're solving [08:23:09] dave: in terms of real-world need [08:24:03] richard suggests this is a good idea to the chairs [08:24:07] paul suggests ekr write it [08:24:41] matthijs leaves the room [08:24:59] matthijs joins the room [08:25:24] (missed name): I'm not super enthusiastic about having to hunt through mailing list archives months from now to look at, prefer to see a separate document [08:25:34] Glen Zorn [08:25:40] thanks [08:26:48] paul: question to chairs, separate doc, section in this doc? [08:26:52] warren: wait and see what ekr comes up with [08:27:10] mark andrews: use-case draft needs to be permanent, needs to be recorded [08:27:29] Jacky Yao (Health Yao) joins the room [08:27:40] ondrej: separate draft? same draft? [08:27:47] separate [08:27:53] paul hoffman: easier for developers to understand context if it's the same document [08:28:02] can merge later [08:28:11] DNS is also a good example of this :( [08:28:17] bingo [08:28:24] :) [08:28:24] phb: I have most of the text, use cases in my draft [08:29:25] I am running out of battery, and my laptop power supply is in my room [08:29:36] if someone else would like to take over before the machine shuts down, that'd be great [08:29:38] Anyone have a charger for Joe? [08:29:45] except the use case of "I cannot trust any CAs - see repeated failures " :P [08:29:54] what laptop? [08:29:58] macbook air [08:30:09] little magnetic connector thing [08:30:11] ah, thanks warre [08:30:48] normal service has resumed [08:31:17] steve kent: part of the motivation here is to elevate the self-issued cert case out from being an error, so the goal should be not to throw an error [08:31:47] steve kent: observation is that if you issue a self-signed cert, PKIX says it's a CA. [08:32:51] steve kent: I don't see it as being much harder to make two calls to openssl [08:33:42] ekr: (sorry, too many words to type verbatim, and difficult to summarise and type at the same time, others please feel free to contribute) [08:34:22] steve kent: they are doing dane so they're already doing something new [08:34:30] i'm always afraid the mic will catch fire when ekr is talking [08:34:40] steve kent: if someone provides the right interface and script for this it should not be much more work [08:34:52] ekr said that the bogus-CA+cert model is more trouble for admins than current self-signed cert [08:35:25] richard: if you're going to implement dane, regardless of which path you take, you're going to have to provision *something* in the dns. [08:36:13] a lot of discussion seems to imply that the scope is browsers and user-facing TLS, seems like that should be explicit if true [08:36:29] stefan: worried that we're going to engender confusion with additional advice about whether accepting expired certs is ok, etc [08:37:07] richard: could just make up a cert, put it in the dns with the right key [08:37:24] richard: current draft has exact match on cert, could be that cert has expired but you'll still accept it because it has the right key [08:37:31] stefan: who is attesting anything about that key? [08:37:38] stefan: reason to accept it is because you got it from the dns [08:37:47] paul hoffman: sounds like we are agreeing with the current text [08:38:13] stefan: wondering whether anybody is attesting to the key, perhaps the dns infrastructure is providing attestation [08:38:39] stefan: put CERT in the DNS [08:38:50] hoffman: (horrified noises) [08:39:27] randy: you're going to have trouble validating. you're going to head north, but you're supposed to turn left into a different universe. [08:39:56] Rule: if cert OR RRsig is expired do not trust it [08:40:07] paul wouters: what do people think about using a bare public key? [08:40:15] matthijs leaves the room [08:40:22] matthijs joins the room [08:40:40] warren: that will still have to go through TLS [08:40:53] paul wouters: yes, the TLS extension would, but it needs the format of the public key [08:41:13] paul hoffman: no catch-22 necessarily, we could just adopt whatever comes out of tls [08:41:32] paul wouters: client needs to tell the server what public key it is expecting, need to define a format [08:41:39] ekr: what does the client want to express? [08:41:57] paul wouters: client sends an option "I already have pubkey", needs to send cert or hash of key [08:42:08] paul hoffman: I'm sure we would pick for our cert format whatever tls did [08:42:33] ekr: why are you presuming you would put a key rather than a hash in the dns? [08:42:51] paul wouters: client needs to retrieve public key from resource record [08:43:00] ekr: two modes in tls, 1 I have this already, 2 server gices it [08:43:03] gives [08:43:18] ekr: putting the key in the dns and saying "I have it, don't give it to me" is a major hange [08:43:20] change [08:43:41] paul hoffman: once tls has a spec for how this should look, we would match it [08:43:55] paul hoffman: so pick it for the tls side [08:44:17] martin thompson: on bare keys, what about lazy administrators? [08:45:09] Jim Galvin leaves the room [08:45:10] martin: considering end entity certs requiring a CA, as an implementation of a server it's going to be difficult to get the server to generate the CA cert given the APIs we have access to [08:45:19] richard: which APIs lack this capability? [08:45:27] martin: java [08:45:35] narten leaves the room [08:46:06] phb: we've been talking about pkix and cert stuff, don't seem to have talked about the dns cruft [08:46:24] phb: wildcards are going to break [08:46:26] matthijs leaves the room [08:46:34] matthijs joins the room [08:46:35] paul hoffman: this was discussed on the list [08:47:19] ekr: e-mail coming in a minute [08:47:30] ekr: part of the reason cert validation is bad in browsers [08:47:42] ekr: is that lots of existing certs are bogus, either because certs are hard to get [08:47:55] ekr: or because they expire, the names don't match, etc [08:48:06] ekr: browser override cert warnings exist because of this [08:48:24] ekr: tension about false -ve vs. false +ve [08:48:34] eburger leaves the room [08:49:06] ekr: dane provides less incentive to fix certs [08:49:29] ekr: so result may be that there are more warnings for non-dane clients [08:49:58] stephen farrell: +1 ekr [08:50:22] naptee leaves the room [08:50:28] jeff hodges: +1 ekr, +1 stephen [08:50:43] jeff hodges: browser vendors will need to some work. are there some in the room? [08:51:04] naptee joins the room [08:51:27] paul hoffman: not just web browsers, also STARTTLS, etc [08:51:56] paul hoffman: interface for non-web use cases is important [08:52:32] paul hoffman: TLSA is meant for all TLS implementations, not just web and browser [08:52:37] matthijs leaves the room [08:53:14] Chris Griffiths leaves the room [08:53:22] matthijs joins the room [08:53:38] robert c: internet of things area, very different requirements, not browsers, not mail clients [08:54:10] paul hoffman: currently need domain name for dane, what about reverse tree? maybe. [08:55:10] Chris Griffiths joins the room [08:55:15] w3c guy whose name I didn't catch: w3c views making browsers less broken as a strategic priority. [08:55:25] <=JeffH> who is at mic ? [08:55:33] Henry [08:55:41] <=JeffH> harry halpin (sp?) [08:55:44] harry halpern? [08:55:45] thanks [08:56:03] Thompson? [08:56:13] ah [08:56:25] phb: we first starting pushing the browser vendors to hard-fail revocation failure in windows 98 [08:58:23] Per joins the room [08:58:46] scott cantor(sp?): is this about browsers, or about TLS? I think there is more potential for non-browser applications [08:59:23] sandoche leaves the room [08:59:33] scott: I would like to see an alternative to pkix in dane [09:00:04] paul hoffman: agree that semantics are key [09:00:36] jeff hodges: would be great to have people like scott who have server-to-server experience to contribute requirements and such on the list [09:01:10] warren: S/MIME [09:01:16] paul hoffman: slideless one [09:01:26] paul hoffman: just spent two hours talking about TLS [09:01:34] paul hoffman: I submitted an overly-brief draft on doing all this on S/MIME [09:01:43] paul hoffman: think of the same uses for an S/MIME end entity [09:02:01] paul hoffman: draft is out there [09:02:11] jimsch leaves the room [09:02:11] paul hoffman: do not intend to work seriously on it until this work is done [09:03:22] phb: S/MIME is different from TLS because with TLS it makes sense to put end entity certs in the DNS, with S/MIME you really want to have a cert chain and stick the CA cert in the DNS rather than trying to construct a mechanism for looking up individual e-mail certs [09:03:33] paul hoffman: other people have disagreed. once we get to it, it can be discussed. [09:04:24] matthijs leaves the room [09:04:52] phb: various concerns, including IDN scripts in e-mail addresses, etc [09:04:59] matthijs joins the room [09:05:06] paul hoffman: phb has a point [09:05:16] warren: any other business? [09:05:38] warren: thank you everybody [09:05:38] koji leaves the room [09:05:45] meeting ends [09:05:48] dougm.home leaves the room [09:05:48] pawal leaves the room [09:05:50] Andrew leaves the room [09:05:50] jabley leaves the room [09:05:56] Per leaves the room [09:06:01] matthijs leaves the room [09:06:04] bhoeneis leaves the room [09:06:04] Olafur leaves the room [09:06:10] buckeyeskeeve leaves the room [09:06:26] Chris Griffiths leaves the room [09:06:27] Hugo Salgado leaves the room [09:06:34] Satoru Kanno leaves the room [09:06:36] sm leaves the room [09:06:48] naptee leaves the room [09:07:21] jelte leaves the room [09:07:55] =JeffH leaves the room [09:08:16] lepinski leaves the room [09:08:47] scott_rose leaves the room [09:10:27] marco leaves the room: Disconnected [09:11:06] sebastian.castro leaves the room [09:11:51] leslie leaves the room [09:11:58] sandoche joins the room [09:12:52] richard.barnes leaves the room [09:14:16] Warren Kumari leaves the room [09:14:24] Patrik Halfar leaves the room [09:15:07] yoav.nir leaves the room [09:15:34] sandoche leaves the room [09:15:35] sandoche joins the room [09:15:36] Linus Nordberg leaves the room [09:17:40] paulwouters leaves the room [09:18:11] yone leaves the room [09:21:16] leslie joins the room [09:21:40] Simon Josefsson leaves the room [09:21:48] leslie leaves the room [09:22:32] naptee joins the room [09:23:15] Paul Hoffman leaves the room [09:23:38] weiber leaves the room [09:23:59] Klaas Wierenga leaves the room [09:25:34] sftcd leaves the room [09:26:24] Jacky Yao (Health Yao) leaves the room [09:27:41] Shane Amante leaves the room [09:32:15] leslie joins the room [09:35:31] naptee leaves the room [09:36:42] =JeffH joins the room [09:38:18] =JeffH leaves the room [09:39:00] joseph.yee leaves the room [09:40:04] sandoche leaves the room [09:41:34] milan.sova leaves the room [09:42:35] leslie leaves the room [09:42:52] bhoeneis joins the room [09:43:29] narten joins the room [09:44:24] narten leaves the room [09:46:53] paulwouters joins the room [09:47:47] paulwouters leaves the room [09:47:48] paulwouters joins the room [09:47:53] paulwouters leaves the room [09:51:51] jabley joins the room [09:57:55] jabley leaves the room [09:58:11] sftcd joins the room [09:59:05] milan.sova joins the room [10:00:34] Melinda leaves the room [10:08:28] Chris Griffiths joins the room [10:12:40] sftcd leaves the room [10:16:26] Chris Griffiths leaves the room [10:18:58] Warren Kumari joins the room [10:23:36] Warren Kumari leaves the room [10:30:23] Melinda joins the room [10:34:35] milan.sova leaves the room [10:40:30] wouter leaves the room [10:47:58] spturner joins the room [10:48:02] spturner leaves the room [10:49:05] bhoeneis leaves the room [10:49:17] Melinda leaves the room [10:53:14] Simon Josefsson joins the room [10:55:28] Satoru Kanno joins the room [10:55:43] Simon Josefsson leaves the room [10:56:19] ogud joins the room [10:56:28] ogud leaves the room [11:02:51] bhoeneis joins the room [11:03:15] cdlilj leaves the room [11:03:44] pawal joins the room [11:03:46] cdlilj joins the room [11:04:58] Paul Hoffman joins the room [11:05:40] Paul Hoffman leaves the room [11:06:46] pawal leaves the room [11:07:00] paulwouters joins the room [11:07:20] paulwouters leaves the room [11:07:44] paulwouters joins the room [11:08:47] paulwouters leaves the room [11:14:49] cdlilj leaves the room [11:16:29] jabley joins the room [11:20:07] jabley leaves the room [11:31:54] paulwouters joins the room [11:36:55] bhoeneis leaves the room [11:36:55] Satoru Kanno leaves the room [11:38:46] Satoru Kanno joins the room [11:43:04] bhoeneis joins the room [12:13:43] Satoru Kanno leaves the room [12:22:53] bhoeneis leaves the room [12:33:12] Warren Kumari joins the room [12:41:29] Shane Amante joins the room [12:41:44] Shane Amante leaves the room [12:51:55] paulwouters leaves the room [13:06:55] Warren Kumari leaves the room [13:16:08] Warren Kumari joins the room [13:20:48] Warren Kumari leaves the room [13:22:39] Warren Kumari joins the room [13:26:04] paulwouters joins the room [13:34:00] Warren Kumari leaves the room [13:40:40] Warren Kumari joins the room [13:41:01] Warren Kumari leaves the room [13:46:01] paulwouters leaves the room [13:48:48] paulwouters joins the room [13:54:11] Warren Kumari joins the room [13:55:34] Warren Kumari leaves the room [13:56:50] paulwouters leaves the room [14:10:03] paulwouters joins the room [14:16:58] paulwouters leaves the room [14:55:27] Warren Kumari joins the room [15:09:23] paulwouters joins the room [15:27:16] paulwouters leaves the room [15:56:25] paulwouters joins the room [16:04:54] paulwouters leaves the room [16:52:33] Warren Kumari leaves the room [18:03:16] Warren Kumari joins the room [18:06:17] Warren Kumari leaves the room [19:22:18] Warren Kumari joins the room [19:37:48] Warren Kumari leaves the room [20:26:07] paulwouters joins the room [20:59:37] Warren Kumari joins the room [21:02:05] paulwouters leaves the room [23:15:52] Warren Kumari leaves the room