Tuesday, 26 July 2011< ^ >
Room Configuration

[13:11:10] Bjoern joins the room
[15:53:24] Bjoern leaves the room
[15:53:40] Bjoern joins the room
[19:14:16] =JeffH joins the room
[19:16:27] kepeng_li\ joins the room
[19:16:46] linyi joins the room
[19:17:04] <linyi> is there meetecho available?
[19:18:10] <=JeffH> dunno
[19:19:17] David Cooper joins the room
[19:19:59] spturner joins the room
[19:21:24] <kepeng_li\> Do we have links for the related drafts?
[19:21:35] stpeter joins the room
[19:21:47] stpeter has set the subject to: WOES BoF
[19:21:48] Karen O'Donoghue joins the room
[19:21:56] linuxwolf joins the room
[19:22:00] barryleiba joins the room
[19:22:02] stpeter has set the subject to: WOES BoF | IETF 81
[19:22:17] yoav.nir joins the room
[19:22:40] <linuxwolf> going over the agenda
[19:22:46] stpeter has set the subject to: WOES BoF | IETF 81 | agenda:
[19:23:21] stpeter has set the subject to: WOES BoF | IETF 81 | agenda: | charter:
[19:23:44] <linuxwolf> reversing direction of charter issues
[19:23:55] <linuxwolf> ("basing on CMS" then "key format")
[19:24:00] <stpeter> linuxwolf: are you the jabber proxy?
[19:24:13] <linyi> yes, linuxwolf is
[19:24:20] resnick joins the room
[19:24:24] <linuxwolf>
[19:24:25] <linyi> the chair approached him and he agrees:)
[19:24:32] <spturner> and we thank you
[19:24:36] hildjj joins the room
[19:24:45] richard.barnes joins the room
[19:24:46] <linyi> it's amazing that linuxwolf speek chinese:)
[19:24:50] <linuxwolf> haha
[19:25:32] yoiwa joins the room
[19:25:46] <linuxwolf> if you haven't already…READ THE CHARTER
[19:25:47] <linuxwolf> (-:
[19:26:07] <kepeng_li\> Does anybody have links for the related drafts? I can't find the drafts from the slides or agenda.
[19:26:38] sftcd joins the room
[19:26:40] <linuxwolf> word from our sponsor: look at CMS, strip out the things that don't work
[19:27:01] mcharlesr joins the room
[19:27:09] <linuxwolf> Richard Barnes: going over history
[19:27:41] <resnick> (Sean didn't even really say CMS. He said to start from existing technology and trim instead of starting new because it will likely take much longer.)
[19:27:47] bkihara.l joins the room
[19:28:02] <linuxwolf> resnick: thanks for the clarification
[19:28:09] <linuxwolf> essentially "don't start from scratch!"
[19:28:43] <resnick> +1
[19:29:08] <linuxwolf> hoffman: any questions about things on the list that did not get summarized in the slides?
[19:29:17] <linuxwolf> none from room...
[19:29:40] <linuxwolf> call for the "basing on CMS" opinionated people to speak
[19:30:07] <linuxwolf> JH: yes, security stuff is hard; yes, CMS has a lot of the things we need
[19:30:40] <linuxwolf> JH: taking the things in there that fit our world view should be kept, the things that don't are not
[19:30:56] <linuxwolf> JH: but make sure we start with the work that's already been done.
[19:31:10] <linuxwolf> (JH == Joe Hildebrand)
[19:31:16] <linuxwolf> (PR == Pete Resnick)
[19:31:28] tlyu joins the room
[19:31:39] <linuxwolf> PR: we are talking about the "semantic meaning" of CMS makes a lot of sense…but maybe not the "syntactic structure"
[19:32:01] <linuxwolf> PR: starting with CMS, and removing things is good…but the adding of things should be done judiciously
[19:32:16] <linuxwolf> EKR: I'm probably the person that wrote "Starting with CMS" (-:
[19:32:41] <linuxwolf> EKR: This means steal things that work, but make sure we're not just a JSON encoding of ASN.1
[19:32:53] <linuxwolf> (DC == Dave CROCKER)
[19:33:22] <linuxwolf> DC: I got involved because of work in DKIM…
[19:33:35] <linuxwolf> DC: A good charter can make a difficult WG easier…
[19:33:50] sftcd leaves the room
[19:33:52] <linuxwolf> DC: .. but the three speakers have all had a different definition of "based on"
[19:34:18] sftcd joins the room
[19:34:59] <linuxwolf> DC: be sure not to use compressed language in the charter, so
[19:35:10] <linuxwolf> real people can understand what it is we're doing
[19:35:20] <kepeng_li\> JH Speaking
[19:35:33] <linuxwolf> JH: I agree that we need clear language
[19:35:50] sftcd leaves the room
[19:35:54] <linuxwolf> JH: about PR's note about being careful about adding things missing..
[19:36:02] <linuxwolf> JH: one is preventing replay
[19:36:03] <richard.barnes> far too detailed question: would we expect that if we encrypted the same octets with CMS and WOES, would we expect the encrypted octets to be the same? (as opposed to the metadata/key packaging/etc)
[19:36:14] <richard.barnes> for a signed object, would we expect the signature octets to be the same?
[19:36:16] <richard.barnes> i think so
[19:36:24] <linuxwolf> richard.barnes: do you want me to ask that?
[19:36:34] <richard.barnes> no, i'm definitely in the room to ask it myself :)
[19:36:37] <richard.barnes> just musing
[19:36:42] <tlyu> richard: i think that it might be too much to expect for the octets to be identical
[19:36:48] <stpeter> he's even got a mic at his disposal :)
[19:37:07] <linuxwolf> DR: basing on is really strong language
[19:37:37] <linuxwolf> PR: "basing on" is probably too strong, and probably need to start with "informed by"
[19:37:55] <linuxwolf> PR: write the charter to say exactly what we mean
[19:38:05] <linuxwolf> (DR ==> DC) (-:
[19:38:31] <linuxwolf> DC: I thought it was to take a strict structure of CMS, and remove as little of possible
[19:38:47] <linuxwolf> PR: not agreeing…think we ought to remove judiciously, not as little as possible
[19:39:06] <=JeffH> Paul Hoffman (PH) agrees
[19:39:07] <hildjj> richard.barnes: absolutely not.
[19:39:20] <linuxwolf> EKR: As someone writing this stuff…doing a translation from CMS was a convenience for me
[19:39:35] LouB joins the room
[19:39:46] <richard.barnes> tlyu, hildjj: wow, not the answer i expected
[19:40:10] <linuxwolf> EKR: if "basing on CMS" shouldn't become a crutch, or an obstable
[19:40:20] <linuxwolf> EKR: this has been done before (e.g. xml-dsig)
[19:40:44] martin.thomson joins the room
[19:40:46] <hildjj> richard.barnes: that was in answer to "do we expect the bits to be the same after signing or encryption", which may or may not be what you were asking.
[19:40:47] <tlyu> you almost always encrypt/sign some of the metadata to get the security properties you want
[19:40:49] <linuxwolf> EKR: we should rip off as much of this stuff as possible, but get rid of the things that's not needed
[19:41:34] <linuxwolf> PH: does EKR have a presence have a preference about "one item" or a list of items to "base on"/"be informed by"/etc/etc
[19:41:50] kepeng_li\ leaves the room
[19:41:58] <linuxwolf> EKR: would like us to look at all the things that came before us, to learn from our previous work/mistakes
[19:42:32] <linuxwolf> PH: is there anything new that was not part of CMS (structural)?
[19:42:56] <linuxwolf> EKR: I don't want a fight six months from now because we want something that wasn't in CMS
[19:43:24] <linuxwolf> DC: I'm getting more confused, not less
[19:43:45] <linuxwolf> DC: EKR's statement makes a lot of sense…but sounds like we're coming up with a new security protocol
[19:43:45] lef_jp joins the room
[19:44:17] <linuxwolf> DC: sounds like we're starting with a blank piece of paper, and look around for a way to do things
[19:44:29] <linuxwolf> PH: doesn't sound like we're starting with a blank sheet
[19:44:56] <linyi> are the requirements clear to make a decision whether CMS can meet them?
[19:44:59] <linuxwolf> MJ: I want to support EKR's statement if we start with the list of prior art
[19:45:44] <linuxwolf> MJ: Also want to say this substantive discussion is not happening in the background, because there's not an ubiquitous spec for signing and encryption for the web
[19:46:17] <linuxwolf> MJ: and come up with a spec that a developer (PH: plural) that will use for real-world implementations
[19:46:40] <linuxwolf> ??: I think you're starting with the use-cases and requirements for CMS and others makes perfect sense to start with
[19:46:48] <martin.thomson> This is PHB
[19:46:52] <linuxwolf> grazie
[19:47:26] <linuxwolf> PHB: But in trying to simplify, you'll get down to the details that CMS had to deal with, and will need some features (e.g. detached signatures), and not have them as barnacles
[19:47:38] <linuxwolf> MJ: or decide the usecases are out of scope
[19:47:50] <linuxwolf> PHB: We should have a document that says what we need and what's out of scope
[19:48:10] <linuxwolf> JH: Echo back — using CMS as an input for the usecase document?
[19:48:28] <linuxwolf> PHB: really using CMS as a substitute to a usecase document
[19:48:46] <linuxwolf> JH: I don't think this particular discussion is getting us to a protocol faster
[19:49:19] <linuxwolf> JH: I think that enough skills to figure out what to use/not use to build something secure
[19:49:34] Jeremy Laurenson joins the room
[19:49:37] <linuxwolf> JH: Being strict constructionist on "We must use CMS as the start" is not helpful
[19:50:06] <linuxwolf> JH: "Basing on CMS" is not used as a helpful guideline, then we should remove it altogether
[19:50:27] martin.thomson leaves the room
[19:50:35] <richard.barnes> who's at the mic?
[19:50:45] <linuxwolf> I don't know...anyone?
[19:50:46] <tlyu> Thomas Hardjono at mic
[19:50:47] <=JeffH> thomas hardjono
[19:50:51] <linuxwolf> grazie
[19:51:10] <linuxwolf> TH: what is it we want? Signing and Encryption, but willing to add more if needed
[19:51:15] <=JeffH> can linuxwolf raise hand to allow meatspace mapping ? 8^)
[19:51:27] <=JeffH> Thot so, thx
[19:51:28] linuxwolf raised hand
[19:51:29] <=JeffH> :)
[19:51:33] linuxwolf is now known as m&m
[19:51:51] <m&m> EKR: started with CMS so as not to explain 50 pages of background
[19:52:16] <m&m> EKR: works as a starting point but not as the end-all be-all
[19:52:27] <=JeffH> <applause>
[19:52:31] <m&m> EKR: recommends we strike the "basing on CMS" altogether
[19:52:40] martin.thomson joins the room
[19:52:40] <m&m> <applause for stpeter>
[19:52:56] <m&m> stp: If we had the cryptography book, we'd want the signing and encrypting pattern
[19:53:01] <=JeffH> oh shiza, meant to write that book last week
[19:53:13] <m&m> stp: but since we don't we, we'll need to put that together
[19:53:14] <hildjj> "using well-known message security primitives"
[19:53:16] <=JeffH> "the crypto pattern book
[19:53:44] <m&m> PH: Paul Hoffman and Richard Barnes are BOF chairs, *NOT* WG chairs (necessarily)
[19:53:57] <m&m> PH: will have more on the list shortly (immediately after this list?)
[19:54:07] <m&m> charter #1 (now #2): key format
[19:54:15] <=JeffH> list --> session
[19:54:17] <m&m> call for key comments
[19:54:25] <stpeter> I thought PH was just typing on Facebook
[19:54:31] <stpeter> er, RB :)
[19:54:34] yone joins the room
[19:54:36] <=JeffH> are "key comments"
an object component ?
[19:54:52] kepeng_li\ joins the room
[19:54:55] <m&m> Mike Jones (MJ): To the extent as part of a larger goal of allowing web devs to have a way of signing and encrypting./..
[19:55:09] <m&m> MJ: and their de facto standard of having JSON encoding
[19:55:48] <martin.thomson> JSON Object Keys, Encryption and Signing: JOKES
[19:55:49] <m&m> MJ: we should have a key format, and have a data structure for the keys, it makes sense for us to have JSON structure
[19:55:54] <m&m> heh
[19:55:59] <m&m> EKR: second MJ's
[19:56:05] <=JeffH> john bradley @ mic
[19:56:23] <m&m> John Badley (JB): Some implementations tried to use "raw keys"
[19:56:34] <m&m> JB: if we don't define something, then devs will go off and do something
[19:56:39] <=JeffH> and it should be included in scope
[19:56:48] <m&m> thanks
[19:56:57] <=JeffH> < here to help :) >
[19:57:07] <m&m> EKR: We are talking about the PCKS#1 key format STOP
[19:57:16] <tlyu> "raw key" is not a very well-defined concept for most public key algorithms
[19:57:24] <=JeffH> agreed
[19:57:28] <m&m> Steve Kent: What algo's does PKCS#1 supports?
[19:57:50] <m&m> EKR: That's my mistake, it's for the algorithms that need support (??) (-:
[19:58:06] <yoav.nir> So we won't say PKCS#1 on the charter? :-)
[19:58:09] <m&m> Sean Turner (ST): any not just use x.509 certs
[19:58:16] <=JeffH> a way to refer to them (what a so-called "raw key" in PK world ) is to point at the SubjectPublicKeyINfo structure from X.509
[19:58:29] sftcd joins the room
[19:58:46] <m&m> EKR: let's assume you're working in an environment where you just want to sign and encrypt…there's a separate format for the keys and the certs
[19:58:46] <=JeffH> what did ekr just say ?
[19:58:49] <=JeffH> k
[19:59:02] m&m will figure out to say his comment (-:
[19:59:21] <m&m> ??: We have been attempting to use certs, and it causes endless problems
[19:59:38] <stpeter> m&m that was RL 'Bob' Morgan
[19:59:46] <m&m> PHB: We have an approach we've been working on that's similar to this
[19:59:49] <m&m> grazie
[20:00:07] <m&m> PHB: we need to have a way to send along the key, because we've already got the trust, but not the keys themselves
[20:00:18] <stpeter> m&m you don't need to capture all words said here -- there is audio, after all
[20:00:33] <m&m> stpeter: thanks…wasn't sure
[20:00:34] <=JeffH> he's taking excellent notes
[20:00:40] <=JeffH> please continue
[20:00:43] <=JeffH> :)
[20:00:48] <stpeter> :P
[20:00:54] <=JeffH> otherwise I'll have to start doing it
[20:01:07] <=JeffH> who's @ mic ?
[20:01:10] stpeter reaches over to punch =JeffH
[20:01:13] <linyi> Bert
[20:01:13] <m&m> ??: If we don't have the cert format, then we don't have a way to determine where this key is coming from…
[20:01:14] florob joins the room
[20:01:24] <Jeremy Laurenson> Bert Greenvenbosch at the mic
[20:01:25] <m&m> JH: How you generate trust in the public keys is "out of scope"
[20:01:26] <=JeffH> stpeter, always a smart***
[20:01:30] <yoav.nir> Do we need a key format just for signing keys or also for D-H "public keys"?
[20:01:47] <m&m> JH: The idea of using a fingerprint doesn't save much…not enough now vs. then
[20:02:10] <m&m> yoav.nir: don't think so
[20:02:13] <=JeffH> Bert speaking
[20:02:28] <m&m> Bert Greevenborsh (BG): so we don't need to generate trust?
[20:02:44] <stpeter> Jim Schaad at the mic
[20:02:45] <=JeffH> jim Schaad
[20:02:47] <m&m> JH: Just having a keying mechanism is useful, and there's other ways of doing trust
[20:02:59] <martin.thomson> JSON octet keys, encryption and signing
[20:03:01] <m&m> JS: Are we talking public only, or public/private?
[20:03:20] <m&m> JS: what pieces of CMS, but are we also looking at symmetric keys also?
[20:03:42] <m&m> PH: based on the mailing list, talk only about public (asymmetric) keys
[20:03:56] <m&m> PH: any need for symmetric keys?
[20:04:28] <stpeter> "Simplicity, simplicity, simplicity." --Thoreau
[20:04:32] <m&m> PHB: we definitely need both…some people start with asym, then need symmetric
[20:04:53] <m&m> PHB: may need a way to exchange symmetric keys using asymmetric keys'
[20:06:04] <=JeffH> PHB example: imagine a control session in JSON, need to be able to convey symmetric key
[20:06:14] <stpeter> JS: wouldn't that key be encrypted in private and the format wouldn't necessarily be JSON -- do we need to encode private keys/info as JSON objects?
[20:06:29] <kepeng_li\> M&M @ Mic
[20:06:53] <stpeter> PHB: need way to reference private key, but don't need to represent it
[20:06:55] <=JeffH> PHB: need means to ref assymetric keys as well as convey symmmetric key(s) (?)
[20:07:10] <=JeffH> ref the assym priv key (?)
[20:07:10] <stpeter> M&M same data structures for public and private simplifies processing
[20:07:28] <tlyu> if you're doing key escrow, you might want to transmit private keys. (assuming you think key escrow is a good thing...)
[20:07:49] <stpeter> Tony Nadalin: existing specs have both
[20:07:58] <m&m> what did i miss? (-:
[20:08:05] <stpeter> TN: do we really need data structure representation for symmetric key
[20:08:25] <m&m> ?? we have a need for symmetric keys...
[20:08:41] <stpeter> TN
[20:08:43] <m&m> TN: don't want to leave known needs to be left behind
[20:08:45] <m&m> grazie
[20:08:50] <stpeter> Michael Richardson at the nic
[20:08:54] <=JeffH> aren't there plenty of examples of data structures for conveying all these diff keys? eg PKCS #foo, XKMS, X.509, CMS, etc
[20:08:56] <=JeffH> ???
[20:09:04] <m&m> Michael Richardson (MR): Just to be clear, we don't need to represent symmentric keys...
[20:09:43] <m&m> MR: While it might not be on the wire, but that people don't want to exclude them
[20:09:55] <stpeter> John Herzog
[20:10:06] <richard.barnes> what did he just say?
[20:10:25] <=JeffH> isn't RFC 6301(?) relevant
[20:10:30] <m&m> John Herzon (JZ): We have many specs for representing keys, do we need to encode all of those?
[20:10:33] <resnick> He said that there is now an RFC for symmetric keys in CMS. Why did they do it?
[20:10:35] <martin.thomson> rfc 6031 i THINK
[20:10:48] <m&m> grazie, that makes more sense
[20:10:52] <martin.thomson> CaPS lOCk fTW
[20:10:57] <richard.barnes> yes:
[20:11:29] <m&m> EKR: to be clear, if I want to send a message, I can take a key, parse in an unambiguous way and go along
[20:11:53] <m&m> EKR: the only thing we need is the public key, but private keys (while über convenient) is not fundamentally required
[20:12:05] <m&m> EXR: my take is that private keys is not immediately needed
[20:12:49] <m&m> ??: On the history of charter, schema for json is out of scope? (yes)
[20:13:00] <linyi> Linyi Tian
[20:13:03] <m&m> grazie
[20:13:11] <linyi> it was me
[20:13:20] lef_jp leaves the room
[20:13:20] LouB leaves the room
[20:13:22] <m&m> Sean Turner (ST): Obviously we have some work...
[20:13:26] lef_jp joins the room
[20:13:30] <m&m> who wants to review (several hands)
[20:13:36] <m&m> the rest…to the list!
[20:13:44] sm joins the room
[20:13:50] <m&m> charter to be finalized on the list
[20:13:56] louberger joins the room
[20:14:06] <m&m> PH: any other issues? (45 minutes)
[20:14:20] yone leaves the room
[20:14:21] yone joins the room
[20:14:26] <m&m> PH: is anything being left out with the new streamlined charter?
[20:14:42] Jeremy Laurenson leaves the room: Replaced by new connection.
[20:14:44] Jeremy Laurenson joins the room
[20:14:55] <m&m> *crickets*
[20:15:11] <m&m> PH: we are done! anyone disagree?
[20:15:18] <m&m> EKR: the name!
[20:15:42] <m&m> EKR: name should be JSON Object Encryption and Signing (JOES)
[20:15:49] barryleiba leaves the room
[20:15:58] yoav.nir leaves the room
[20:15:58] Jeremy Laurenson leaves the room
[20:16:00] <m&m> *ph bangs gavel*
[20:16:02] <martin.thomson> +1 ekr
[20:16:06] tlyu leaves the room
[20:16:12] martin.thomson leaves the room
[20:16:14] <m&m> -1 I have to work for that JH loser!
[20:16:19] Karen O'Donoghue leaves the room
[20:16:36] linyi leaves the room: Computer went to sleep
[20:16:44] yone leaves the room
[20:16:51] m&m leaves the room
[20:16:59] hildjj leaves the room: Replaced by new connection.
[20:17:30] yoiwa leaves the room
[20:17:41] sm leaves the room
[20:18:20] bkihara.l leaves the room
[20:18:20] lef_jp leaves the room
[20:18:24] David Cooper leaves the room
[20:18:50] kepeng_li\ leaves the room
[20:18:50] spturner leaves the room
[20:18:54] resnick leaves the room
[20:21:44] florob leaves the room
[20:21:58] Karen O'Donoghue joins the room
[20:21:59] richard.barnes leaves the room
[20:25:42] sven joins the room
[20:30:22] =JeffH leaves the room
[20:32:51] sftcd leaves the room
[20:34:21] sftcd joins the room
[20:49:37] sftcd leaves the room
[20:51:33] bkihara.l joins the room
[20:51:59] hildjj joins the room
[20:52:12] hildjj leaves the room: Disconnected.
[20:59:43] hildjj joins the room
[21:05:37] bkihara.l leaves the room
[21:09:58] richard.barnes joins the room
[21:12:30] richard.barnes leaves the room
[21:13:42] martin.thomson joins the room
[21:15:29] martin.thomson has set the subject to: JOES BoF | IETF 81 | agenda: | charter:
[21:16:58] martin.thomson leaves the room
[21:19:52] hildjj leaves the room
[21:33:44] mcharlesr leaves the room
[21:39:53] mcharlesr joins the room
[21:59:28] mcharlesr leaves the room
[22:01:05] stpeter leaves the room
[22:04:24] spturner joins the room
[22:09:50] Karen O'Donoghue leaves the room
[22:37:36] spturner leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!