[10:04:25] --- sm-msk has joined
[10:12:27] --- Dennis Dayman has joined
[10:26:27] <sm-msk> hey dude
[10:43:33] <Dennis Dayman> y0
[10:43:41] <Dennis Dayman> sorry was on my other pc
[10:43:46] <sm-msk> s'cool
[10:50:40] --- Barry Leiba has joined
[10:50:57] <Barry Leiba> Hey all
[10:51:00] <Dennis Dayman> hi
[10:51:18] --- eric has joined
[10:51:19] <Dennis Dayman> all here is pretty boring right now :)
[10:51:30] <Dennis Dayman> until Eric the life of the party shows up
[10:51:32] <Barry Leiba> Hm... my roll-call list is effed up.
[10:52:14] <Barry Leiba> Oh, no, never mind... I'm looking at the older messages. Ignore me.
[10:52:30] * Barry Leiba has changed the subject to: Next DKIM meeting 6/22 1500 UTC
[10:52:48] <Barry Leiba> We don't speak PDT 'round these parts......
[10:54:42] <eric> hi all. trying to do three things at once here.
[10:54:51] * Barry Leiba has changed the subject to: Next DKIM meeting 6/22 1500 UTC -- 5 minutes
[10:55:02] --- fenton has joined
[10:55:02] <Barry Leiba> Ah, Jim's on his way.
[10:55:09] <Barry Leiba> There y'are.
[10:55:10] <fenton> 'morning
[10:55:26] <Barry Leiba> I'm not sure whether Stephen'll make it -- he has some kinda funding meeting.
[10:55:27] <eric> hi
[10:55:48] <Barry Leiba> Dave told me he can't make it. Don't know about Doug.
[10:56:25] <eric> this could be a short meeting....
[10:56:36] <Barry Leiba> That'd be fine.
[10:56:49] --- doug_trendmicro@jabber.org has joined
[10:56:53] <Barry Leiba> We're just looking to get status on the open issues, so's you (Eric) can get -04 out.
[10:56:56] <Barry Leiba> Hi Doug.
[10:56:57] <eric> well, except for we should really be getting everything wrapped up.
[10:57:15] * Barry Leiba has changed the subject to: Next DKIM meeting 6/22 1500 UTC -- 3 minutes
[10:57:25] <doug_trendmicro@jabber.org> I will be there
[10:57:43] <Barry Leiba> Where is "there"?
[10:57:54] <doug_trendmicro@jabber.org> There should also be Paul Ferguson.
[10:58:15] <sm-msk> good morning
[10:58:48] <doug_trendmicro@jabber.org> Sorry, I thought the question was about the IETF meeting.
[10:59:09] * Barry Leiba has changed the subject to: Next DKIM meeting 6/22 1500 UTC -- 1 minute
[10:59:55] --- Peter Koch has joined
[10:59:59] * Barry Leiba has changed the subject to: DKIM meeting underway
[11:00:06] <Barry Leiba> OK, here we go.
[11:00:36] <Barry Leiba> The plan for this meeting is to review the open issues, with the idea that Eric can get -base-04 out by Monday and we can to WGLC on that, to end after Montreal.
[11:00:51] <Barry Leiba> Let's run through them by number:
[11:01:09] <Barry Leiba> 1286, draft-ietf-dkim-base-02 //a= algorithm ABNF ... Anything left on this one, or are we set?
[11:01:22] <eric> well, i'm not wild about the change
[11:01:25] <eric> but it was decided last time.
[11:01:29] <sm-msk> URL for issues again please?
[11:01:38] <eric> so i've already made the change
[11:01:57] <Barry Leiba> https://rt.psg.com/Ticket/Display.html?id=1286
[11:02:07] <Barry Leiba> Log in with ietf/ietf.
[11:02:15] <Barry Leiba> Replce "1286" with the appropriate number.
[11:02:34] <Barry Leiba> OK, so: 1286 will be CLOSED, change made for -base-04.
[11:02:53] <sm-msk> yeah i agree with eric: feh, but ok
[11:02:54] <Barry Leiba> 1287: base: signature removal ... What's the status of this?
[11:03:14] <eric> i've made no changes yet, since i didn't see any list discussion
[11:03:26] <doug_trendmicro@jabber.org> I think John said he would propose some text.
[11:03:50] <eric> which john?
[11:03:51] <doug_trendmicro@jabber.org> It should be clarified when this applies at least.
[11:03:55] <doug_trendmicro@jabber.org> John Levine
[11:04:07] <Barry Leiba> OK. Eric, can you remind John Levine? If no text, it stays as is for -base-04.
[11:04:14] <fenton> I don't think the text that is there is harmful
[11:04:26] <doug_trendmicro@jabber.org> It could be.
[11:04:58] <Barry Leiba> I think we agreed that it could use some clarification, but Eric needs text from John. So...
[11:05:09] <eric> i'm just looking to see if he sent something which i missed, but i don't see anything
[11:05:16] <Barry Leiba> 1287: REMAINS OPEN, John Levine to propose text to Eric.
[11:05:32] <Barry Leiba> 1288: base: signing address ...
[11:05:52] <Barry Leiba> I remember lots of discussion, but don't remember where we left it.
[11:06:05] <doug_trendmicro@jabber.org> Jim had made a proposal to change the text.
[11:06:11] <sm-msk> i think it's too wordy
[11:06:13] <sm-msk> the revised version
[11:06:21] <sm-msk> we don't need to define i= and its default in two places
[11:06:25] <sm-msk> or there are just two places to change it later
[11:06:34] <sm-msk> just say it's the i= value
[11:06:43] <doug_trendmicro@jabber.org> That would be fine.
[11:06:49] <fenton> I had proposed that we add it to 'definitions' and refer to it elsewhere
[11:06:54] <sm-msk> yeah, or that
[11:07:01] <Barry Leiba> Yes, what Jim says is what I remember.
[11:07:04] <fenton> but of course that means that the reader has to chase a reference
[11:07:12] <eric> there's a note that "jim to fix default text above"
[11:07:14] <eric> which meant nothing to me.
[11:07:20] <doug_trendmicro@jabber.org> Better than nothing.
[11:07:30] <Barry Leiba> OK, Eric and Jim to sort this one out.
[11:07:33] <sm-msk> i don't think chasing references is something somebody reading a technical document would find unusual
[11:07:38] <sm-msk> and it's a reference within the same document
[11:08:01] <Barry Leiba> 1288: REMAINS OPEN, Jim to work with Eric on defining default in one place & referring to it later.
[11:08:07] <fenton> works for me
[11:08:20] <Barry Leiba> 1289: Base-02 signature process clarification requested
[11:08:37] <Barry Leiba> Again, I think we agreed that clarification here would be useful.
[11:09:02] <eric> I couldn't understand what the problem was from Doug's text.
[11:09:15] <Barry Leiba> I can understand it, and I can propose text. Is that OK with everyone?
[11:09:16] <eric> in chasing the thread, i *think* it has something to do with signed signatures
[11:09:22] <sm-msk> me either
[11:09:24] <sm-msk> sure
[11:09:43] <eric> ok with me
[11:09:43] <doug_trendmicro@jabber.org> Okay.
[11:09:44] <Barry Leiba> 1289: REMAINS OPEN, Barry to propose text.
[11:09:46] <fenton> I think I understand it, and can work it with eric when we work on the previous one
[11:10:02] <Barry Leiba> 1291: Use of "sender" in -base
[11:10:24] <Barry Leiba> Dave sent stuff to Jim and Eric on this. Is that all sorted now?
[11:10:27] <eric> I've resolved these
[11:10:34] <eric> but someone objected to one point
[11:10:44] <Barry Leiba> OK. 1291: CLOSE, fixed in -base-04
[11:10:44] <eric> just came in yesterday
[11:10:53] <Barry Leiba> Oops...
[11:10:54] <eric> well, with the one resolution.
[11:11:03] <Barry Leiba> Are you OK on resolving the objection?
[11:11:43] <eric> i think so. i can't find it in my mailbox right now.
[11:11:57] <eric> let's tentatively close it, and i'll re-open it if necessary.
[11:12:09] <Barry Leiba> OK. 1291: CLOSE stands.
[11:12:11] <Barry Leiba> 1292: draft-ietf-dkim-base-02 //g= template
[11:13:15] <eric> i was left scratching my head over this one.
[11:13:21] <doug_trendmicro@jabber.org> The ideal solution would be to remove the virtual domains from the i= parameter... but barring that outcome, this was a stop-gap.
[11:13:38] <eric> what's a virtual domain?
[11:13:59] <fenton> one that isn't physical :-)
[11:14:09] <eric> gosh, thanks jim.
[11:14:13] <doug_trendmicro@jabber.org> The sub-domains defined within the i= parameter that may have no basis in reality.
[11:14:36] <Peter Koch> 'no basis' as in?
[11:14:47] <doug_trendmicro@jabber.org> No means to confirm the existence.
[11:14:49] <eric> um... this doesn't match my understanding of i=
[11:14:53] <fenton> So this changes g= from just being a user-part thing to something that is both user-part and domain, as I understand it.
[11:14:57] <eric> the domains in i= are real.
[11:15:21] <doug_trendmicro@jabber.org> No they can be imaginary.
[11:15:28] <sm-msk> example?
[11:15:44] <doug_trendmicro@jabber.org> The text in the review suggested changes to make the I= real.
[11:16:17] <doug_trendmicro@jabber.org> i=jon@imaginary-sub-domain.domain.com d=domain.com
[11:16:34] --- thomasm has joined
[11:17:01] <Peter Koch> so, what does the DNS say or not say about 'imaginary-sub-domain.domain.com', then?
[11:17:06] <eric> why all the talk about g= then? all we have to do is say that the RHS of i= has to resolve.
[11:17:15] <fenton> As I understand it, the idea is to constrain the "subdomain rule" on d= by requiring that i= match g= || d=
[11:17:33] <doug_trendmicro@jabber.org> This of course means that a domain can be affected by other delegations.
[11:17:35] <eric> is this a rehash of the issue that (i thought) we had already resolved?
[11:18:02] <doug_trendmicro@jabber.org> No this is nailing down a issue that results in the selection made.
[11:18:11] <doug_trendmicro@jabber.org> It is ugly.
[11:18:21] <fenton> I think this is a new idea, I'm a bit concerned about (1) compatibility and (2) whether the multiple wildcards present a loophole
[11:18:44] <eric> multiple wildcards certainly complicate the algorithm.
[11:18:54] <eric> but it looks like it does change the syntax of g=.
[11:18:58] <doug_trendmicro@jabber.org> This is not about wildcards, but about restricting an MUA private eky.
[11:19:08] <eric> bad news is obvious. good news is that one wildcard on each side of "@" isn't so hard to process.
[11:19:44] <fenton> So, instead of saying that any example.com key can sign for *.example.com, it can only do so if g= is, e.g., *@*
[11:19:49] <fenton> Is this it, Doug?
[11:20:17] <doug_trendmicro@jabber.org> This was to allow agreements where any MUA key would be restricted.
[11:20:32] <doug_trendmicro@jabber.org> A super-domain would need to be able to make assurances.
[11:20:33] <eric> what's an MUA key? never heard of it before.
[11:20:48] <doug_trendmicro@jabber.org> That would be a private key used to sign at the MUA.
[11:21:04] <thomasm> the spec makes no such distinction
[11:21:19] <doug_trendmicro@jabber.org> That would be extremely risky without some additional restrictions.
[11:21:34] <fenton> The concern is that a key delegated to 'user@example.com' could also sign a message from 'user@foo.example.com'
[11:21:51] <thomasm> what does that have to do with mua's?
[11:21:57] <eric> nothing
[11:22:14] <eric> but with jim's example i think i'm starting to understand now.
[11:22:22] <doug_trendmicro@jabber.org> Currently, only the local-part is restricted which means any number of email-addresses can result which means an email-address block would not function to repair this problem.
[11:22:27] <eric> geez, i spent about 20 minutes trying to understand this thing yesterday.
[11:22:29] <Barry Leiba> I think the MUA point is just that it's possible for the sig to be put on in a place that's under very little control of the domain.
[11:22:53] <eric> except that the domain still has to export the public key
[11:22:54] <fenton> By 'MUA key' I think Doug means 'key delegated to a user'
[11:23:05] <sm-msk> rather than tinkering with g= and making it nasty, what about a flag on the key/SSP that restricts signing by superdomains?
[11:23:18] <doug_trendmicro@jabber.org> At the MUA, there would be no isolation between sub-domains.
[11:23:28] <thomasm> murray - that's what I remember from last time too.
[11:23:30] <doug_trendmicro@jabber.org> Please, not more overhead.
[11:23:30] <Barry Leiba> The domain controls the KEY, but can't always control how the sig is created by someone who HAS the (private) key.
[11:23:39] <sm-msk> having that as a flag is way easier than having multiple wildcards/tokens to parse
[11:23:41] <fenton> Murray: Let's not involve SSP, please.
[11:23:48] <sm-msk> ok, they key can have a flag
[11:24:13] <eric> i like that a lot better. it's simple and easy to explain.
[11:24:19] <doug_trendmicro@jabber.org> A flag that disables i= virtual domains?
[11:24:37] <sm-msk> why do you need a flag to do that?
[11:24:40] <sm-msk> the domain is different
[11:24:50] <eric> a flag that says that the RHS of i= must be identical to the d= domain.
[11:24:58] <thomasm> I fear to ask, but what is a virtual domain?
[11:24:59] <doug_trendmicro@jabber.org> Exactly
[11:24:59] <eric> i.e., no subdomaining allowed
[11:25:01] <sm-msk> right
[11:25:13] <eric> virtual domain is doug's private word for subdomain.
[11:25:18] <thomasm> that seems by far the easiest
[11:25:36] <doug_trendmicro@jabber.org> Where is this flag placed?
[11:25:41] <thomasm> t=
[11:25:44] <eric> in the key record
[11:25:48] <Barry Leiba> Looks like we're getting to agreement.
[11:25:55] <fenton> Are there instances where the key would want to be published at the higher level rather than the subdomain? I can't think of any, but that's the main difference.
[11:26:10] <Barry Leiba> Key record will have a new flag that says that i= must be the same as d= in order to use this key.
[11:26:13] <sm-msk> the key has to be at the d=
[11:26:22] <Barry Leiba> Is that right?
[11:26:23] <eric> msk: yes
[11:26:31] <doug_trendmicro@jabber.org> Can that be made the default?
[11:26:35] <sm-msk> if you want to publish it upwards as well, just use a CNAME
[11:26:35] <thomasm> no
[11:26:38] <eric> because that's what gets looked up.
[11:26:43] <sm-msk> right
[11:27:24] <Barry Leiba> Is my summary correct? If so, Eric, are you OK with this for -base-04?
[11:27:43] <eric> yes
[11:28:01] <sm-msk> not "t=" please
[11:28:02] <doug_trendmicro@jabber.org> It seems that this setting can be restrictive in most deployments, so having the restrictive setting the default could save space.
[11:28:05] <sm-msk> that is used as "test" already
[11:28:10] <eric> t= is for flags
[11:28:15] <doug_trendmicro@jabber.org> w=
[11:28:16] <eric> the reason is historic
[11:28:20] <sm-msk> gross, but ok :)
[11:28:20] <thomasm> right -- y is just one of the flags
[11:28:25] <Barry Leiba> Doug, I think changing the default risks breaking existing key records.
[11:28:34] <Barry Leiba> We REALLY do not want to do that unless we have to.
[11:28:41] <fenton> Barry +1
[11:28:42] <doug_trendmicro@jabber.org> Okay,
[11:28:47] <sm-msk> +1
[11:28:54] <eric> +1
[11:28:59] <Barry Leiba> OK. 1292: CLOSE, fix will be made in -base-04.
[11:29:13] <Barry Leiba> 1293: base-02 // worst-case scenario/duration of exploit/use of deprecated
[11:29:31] <eric> i spent another 20 minutes trying to understand this one.
[11:29:41] <eric> can someone other than doug explain it to me?
[11:29:50] <doug_trendmicro@jabber.org> I have published a revision to this
[11:29:58] <doug_trendmicro@jabber.org> I think it is much cleaner.
[11:30:10] <doug_trendmicro@jabber.org> It also covers the case where the service changes.
[11:30:28] <doug_trendmicro@jabber.org> It was posted to the mailing list today and is part of the review.
[11:31:18] <doug_trendmicro@jabber.org> In essence, there is a newlist added to the deprecated key that indicates what is acceptable in an unknown key that must accompany a deprecated key.
[11:31:39] <thomasm> haven't we been over this before?
[11:31:48] <doug_trendmicro@jabber.org> Sorry, unknown signature.
[11:31:48] <sm-msk> a newlist?
[11:32:07] <doug_trendmicro@jabber.org> Yes, to ensure this is not a spoofed signature.
[11:32:15] <sm-msk> what's a "newlist"?
[11:32:17] * sm-msk googles
[11:32:42] <doug_trendmicro@jabber.org> It is the Version Algorithm and Query method VAQ
[11:33:04] <doug_trendmicro@jabber.org> This was added within the n= parameter with '|' separators.
[11:33:16] <doug_trendmicro@jabber.org> This would only be done in the deprecated key.
[11:33:23] <eric> what addition to n=? that's the notes!
[11:33:41] <doug_trendmicro@jabber.org> This would be prepended to notes.
[11:33:54] <fenton> Does anyone but Doug understand this proposal, or do we need to go off and stufy?
[11:34:01] <fenton> stufy -> study
[11:34:15] <eric> i sure don't. and i vigorously object to adding additional semantics to n=
[11:34:19] <sm-msk> no more studying for me, i have stuff coming out my ears already
[11:34:19] <doug_trendmicro@jabber.org> It is covered in the review draft .
[11:34:22] <Barry Leiba> Study, it is.
[11:34:31] <sm-msk> yeah n= shouldn't be augmented
[11:34:37] <Barry Leiba> 1293: REMAINS OPEN, study and discuss on mailing list.
[11:34:45] <sm-msk> there shouldn't be a transition from "meaningless" to "meaningful"
[11:34:51] <doug_trendmicro@jabber.org> Well an new parameter in the key would be okay as well.
[11:34:51] <eric> if anyone other than doug figures it out, please send a summary to the list.
[11:35:03] <sm-msk> next
[11:35:12] <Barry Leiba> 1294: draft-ietf-dkim-base-02 //i= parameter conflict
[11:35:53] <eric> disagree.
[11:36:03] <eric> this could apply to the domain as well as the individual part.
[11:36:05] <doug_trendmicro@jabber.org> It would be better to ensure an email-address validation is explicit rather than assumed.
[11:36:35] <sm-msk> i don't know that this is necessary. i inferred the latter from the former, for example.
[11:36:46] <doug_trendmicro@jabber.org> It does say specific email-address..
[11:37:01] <eric> yes, but this should apply even when i= does NOT contain a specific email address.
[11:37:04] <eric> it is just wrong.
[11:37:11] <fenton> I disagree with this, it makes the signature less meaningful when there is no local-part in i=
[11:37:22] <sm-msk> +1
[11:37:27] <fenton> I don't want two different signature semantics
[11:37:35] <sm-msk> the signer should be prepared to take responsible for the message (end-of-sentence)
[11:37:40] <sm-msk> er, responsibility
[11:37:41] <doug_trendmicro@jabber.org> It makes the validation of an email address more meaningful when it must be explicit.
[11:37:48] <Barry Leiba> It seems that no one here agrees with Doug on this. Was there any support on the mailing list?
[11:38:13] <eric> i don't think so. i would have to check to be sure.
[11:38:17] <doug_trendmicro@jabber.org> There are few providers that would want to be held accountable for email addresses they do not validate.
[11:38:34] <sm-msk> you mean "wouldn't", right?
[11:38:37] <doug_trendmicro@jabber.org> John Levine at least.
[11:38:44] <doug_trendmicro@jabber.org> agreed that is.
[11:38:50] <fenton> doug: that's true regardless if there's a local part in i=
[11:38:56] <sm-msk> yeah
[11:38:57] <eric> on my home server i am willing to act as an outgoing relay for some other domains.
[11:39:04] <eric> but i am not willing to sign them with my DKIM key.
[11:39:09] <eric> even if they don't use i=
[11:39:12] <doug_trendmicro@jabber.org> You want the mechanism to be explicit if there are any annotations involved.
[11:39:25] <sm-msk> eric: what about a key they provide?
[11:39:35] <sm-msk> what annotations?
[11:39:44] <doug_trendmicro@jabber.org> The trust would be established by the signature alone.
[11:39:50] <Barry Leiba> Also keep in mind...
[11:40:04] <sm-msk> the trust would be associated with the key, not the signer
[11:40:07] <eric> what the hell are annotations? you keep talking about them without defining them.
[11:40:11] <sm-msk> and hence the d=
[11:40:12] <doug_trendmicro@jabber.org> The annotation would be based upon the signature unless there was an explicit assertion made by the signing domain.
[11:40:16] <eric> and i think you are using the word at least two ways.
[11:40:19] <Barry Leiba> The text that's there now works nicely with whatever might happen with SSP. With the change, it's tying it specifically to i=. I'm not sure we want that.
[11:40:42] <doug_trendmicro@jabber.org> The threat draft already indicates that recognition of the email-address is not practical.
[11:40:43] <eric> is there *anyone* who wants to support doug on this?
[11:40:46] <fenton> (gotta change location, may drop; back in a couple min)
[11:41:14] <Barry Leiba> Doug says that JohnL supports this; we'll check that on the list. Otherwise.....
[11:41:26] <sm-msk> if recognition of the address by the signer isn't practical, what's left?
[11:41:39] <doug_trendmicro@jabber.org> What is the problem making this explicit?
[11:41:40] <eric> ok, if there's at least one i'm willing to hold it open for now.
[11:41:41] <Barry Leiba> 1294: CLOSE with no change... pending confirmation on mailing list (as with all this).
[11:41:51] <doug_trendmicro@jabber.org> There is always annotations based upon trusted lists.
[11:41:51] <eric> and i will still argue against it.
[11:41:59] <eric> the change that doug proposes makes it semantically incorrect.
[11:42:29] <doug_trendmicro@jabber.org> What is incorrect?
[11:42:35] <Barry Leiba> 1295: issue with relaxed body canonicalization?
[11:42:51] <Barry Leiba> I think we decided that Sendmail will fix this, and we won't change DKIM for it. Right?
[11:43:04] <thomasm> I don't think so
[11:43:07] <eric> i feel strongly about keeping relaxed header, but i'm neutral on relaxed body.
[11:43:09] <Barry Leiba> Oops, wrong one.
[11:43:15] <Barry Leiba> I was thinking about header.
[11:43:16] <eric> there's no sendmail issue with relaxed body.
[11:43:19] <Barry Leiba> For body.....
[11:43:39] <eric> the main reason i can see to keep it is symmetry with the header.
[11:43:42] <thomasm> I'm sort of weakly in favor of keeping it
[11:43:51] <sm-msk> what he said
[11:43:58] <sm-msk> what both said actually
[11:43:59] <eric> deleting it would simplify the code, but not by much.
[11:44:07] <thomasm> I'd sort of like to keep options open, though with no good empirical reason
[11:44:10] <Barry Leiba> As I see it, we can keep relaxed body for now, and toss it in revision (like when we move to Draft Std) if it's not used.
[11:44:12] <sm-msk> and maybe some rewriter we haven't anticipated yet
[11:44:13] <eric> so I'm +0.1 for keeping it.
[11:44:28] <thomasm> +1 Barry
[11:44:35] <Barry Leiba> Does anyone REALLY want to toss it now?
[11:44:38] <sm-msk> i'm a little stronger for that, let's say +(2/3)
[11:45:02] <Barry Leiba> 1295: CLOSE, no change.
[11:45:08] <thomasm> I got the feeling that would have been Paul's preference
[11:45:16] <Barry Leiba> 1296: user@sub.example.com vs. user@example.com
[11:46:22] <sm-msk> someone remind me: what's n= in a signature?
[11:46:28] <Barry Leiba> I think this is related to 1292, a bit.
[11:46:31] <eric> i didn't understand the part about n=
[11:46:52] <Barry Leiba> I thought n= was just human-readable, no?
[11:46:59] <eric> that's the key.
[11:47:04] <Barry Leiba> Glrb
[11:47:08] <sm-msk> and it's not in a signatre
[11:47:12] <sm-msk> only in a key
[11:47:18] <sm-msk> (far as i recall)
[11:47:30] <Barry Leiba> Maybe he meant "d=".
[11:47:33] <fenton> * back paying attention
[11:47:48] <Barry Leiba> Bein' as the "d" and the "n" are so close on the keyboard.... ;-/
[11:48:06] <sm-msk> heh
[11:48:15] <doug_trendmicro@jabber.org> i= d=
[11:48:18] <sm-msk> "domain" ends with "n" ?
[11:48:25] <eric> assuming he means d=, then this is an alternative to the flag we proposed.
[11:48:26] <sm-msk> john works in mysterious ways
[11:48:46] <sm-msk> oh, so it is
[11:48:49] <eric> frankly, i would accept john's suggestion as an alternative to the flag.
[11:48:55] <Barry Leiba> Anyway, I think this relates to 1292, as I said.
[11:49:23] <eric> the flag is slightly more flexible.
[11:49:30] * sm-msk re-reads
[11:49:48] <sm-msk> yeah the flag is marginally better
[11:50:11] <thomasm> it is there for this kind of thing
[11:50:14] <Barry Leiba> Shall we take 1292 and 1296 back to the list briefly, and see if John wants to accept the flag from 1292 instead of this?
[11:50:23] <sm-msk> sounds good to me
[11:50:44] <Barry Leiba> 1296: CLOSE, see resolution for 1292 -- subject to confirmation with JohnL.
[11:50:50] <thomasm> phrase it as "speak now, or we'll close"
[11:50:56] <Barry Leiba> 1297: Clarification on z=
[11:50:56] <thomasm> since it's just a syntax thing
[11:50:57] <eric> who will post it?
[11:50:57] <doug_trendmicro@jabber.org> There should also be a neutral meaning that just adds the restriction without requiring per user keys.
[11:51:15] <eric> doug: that's why we prefer the flag.
[11:51:16] <Barry Leiba> I will post a summary of this chat, and we can go from there. Expect it this aft.
[11:51:40] <sm-msk> i thought z= encoded with QP already, which answers this question
[11:51:43] <Barry Leiba> What did we decide for 1297: Clarification on z=?
[11:51:46] <sm-msk> is that not correct?
[11:51:57] <thomasm> it's not exactly qp
[11:52:00] <Barry Leiba> There was significant discussion of exactly how the encoding should go.
[11:52:07] <thomasm> that's what the problem was
[11:52:09] <Barry Leiba> Different signers were doing it differently.
[11:52:18] <eric> i changed the text
[11:52:19] <Barry Leiba> Where'd the discussion end up?
[11:52:20] <sm-msk> any problem with making it QP formally?
[11:52:21] <eric> posted it to the list
[11:52:26] <eric> i got no response.
[11:52:29] <Barry Leiba> Eric: OK.
[11:52:44] <thomasm> it can't be because it encodes some things that don't have to be encoded with real qp
[11:52:44] <Barry Leiba> Then 1297: CLOSE, accept Eric's text for -base-04.
[11:53:00] <eric> do people accept my text?
[11:53:05] <Barry Leiba> We'll go into WGLC with that, so everyone REVIEW ERIC'S TEXT.
[11:53:11] <sm-msk> thomas: but QP would suffice, no?
[11:53:15] --- fenton has left: Replaced by new connection
[11:53:17] <eric> no
[11:53:20] <thomasm> I don't remember seeing it eric... I'll have to look
[11:53:25] <eric> there are some gotcha's in QP spec
[11:53:30] <thomasm> not exactly murray
[11:53:35] <thomasm> that's the problem
[11:53:42] <sm-msk> hm
[11:53:47] <sm-msk> i thought QP could cover everything
[11:53:49] <eric> the new version just says it is "QP-like" or some such words
[11:54:02] <eric> it's all in the fine print
[11:54:05] --- fenton has joined
[11:54:06] <Barry Leiba> There was also the discussion of "xx:yy" vs "xx:=20yy", right?
[11:54:07] <thomasm> it's just that it's not *exactly* the same...
[11:54:23] <sm-msk> i'll have to read the current stuff again then
[11:54:24] <eric> yes, and the new wording should cover that.
[11:54:33] <sm-msk> and bug eric at work about the hole in QP
[11:54:49] <Barry Leiba> OK. Then we're set -- we have new wording, and we'll confirm that in time for Sunday night.
[11:54:59] <eric> If anyone cares:
[11:55:04] <eric> C<?xml version="1.0"?> <ns:clipboard xmlns:ns="http://www.xmlmind.com/xmleditor/namespace/clipboard" >opied header fields (plain-text, but see description; OPTIONAL, default is null). A vertical-bar-separated list of selected header fields present when the message was signed, including both the field name and value. It is not required to include all header fields present at the time of signing. This field need not contain the same header fields listed in the "h=" tag. The syntax used resembles <xref target="RFC2045" >Quoted-Printable</xref >: any character MAY be encoded as an "=" followed by two hexadecimal digits from the alphabet "0123456789ABCDEF" (no lower case characters permitted) representing the internal value of that character. All control characters (those with values &lt; %x20), eight-bit characters (values &gt; %x7F), and the characters DEL (%x7F), SPACE (%x20), vertical bar ("|", %x7C), colon (":", %x3A), and semicolon (";", %x3B) MUST be encoded in both the header field name and the header field value. Note that all white space, including CR and LF characters, must be encoded. After encoding, SWSP MAY be added at arbitrary locations in order to avoid excessively long lines; such white space is NOT part of the value of the header field, and MUST be removed before decoding.</ns:clipboard >
[11:55:06] <Barry Leiba> That covers all the open issues, and the meeting time's about over.
[11:55:07] <eric> sorry for the XML
[11:56:11] <sm-msk> ok
[11:56:17] <doug_trendmicro@jabber.org> There should be some consideration give the Security Consideration section regarding the affects of the _domainkey subdomain use.
[11:56:21] <Barry Leiba> I'm going to close the meeting, and I'll get a summary out to the mailing list this afternoon.
[11:56:22] <sm-msk> is the description of the issue in the list archives?
[11:56:24] <thomasm> eric -- does this clarify the leading =20 ?
[11:56:35] <eric> msk: yes
[11:56:43] <eric> mike: i hope so
[11:57:11] <eric> essentially i say that /all/ white space in the original header MUST be encoded.
[11:57:19] <eric> all real white space in z= MUST be ignored.
[11:57:23] <Barry Leiba> Doug: I'll ask Eliot to open an issue on that so we can track it, but we've discussed the security considerations issue and I'm not sure we have support for it.
[11:57:29] <eric> so you can add arbitrary line breaks, etc.
[11:57:32] <Barry Leiba> We should definitely track the issue, though.
[11:57:35] <thomasm> Yeah, I think it would be better to be pedantic about the leading space though
[11:57:55] <Barry Leiba> OK... jabber meeting done. Feel free to continue as a "bar BOF".
[11:58:01] <Barry Leiba> T'ta....
[11:58:04] <sm-msk> eric: that's the same as QP, isn't it?
[11:58:07] <sm-msk> cya barry
[11:58:19] <eric> no, it's not the same as QP.
[11:58:23] * Barry Leiba has changed the subject to: DKIM meeting ended at 15:58 UTC
[11:58:33] <sm-msk> QP allows arbitrary insertions of whitespace to break lines, but the decoding ignores them
[11:58:34] <eric> QP says that line breaks MUST be represented as real line breaks
[11:58:34] <thomasm> murray - qp doesn't require semicolon to be encoded, for example
[11:58:46] <sm-msk> eric: except those ending with "="
[11:58:48] <eric> virtual line breaks are encoded as "=" followed by a real line break.
[11:59:14] <eric> but any white space after that virtual line break are part of the QP text.
[11:59:23] <sm-msk> ahhhh
[11:59:27] <eric> so folding a header would add white space to the z= value.
[11:59:31] <sm-msk> maybe i'm mixing base64 and QP in that regard
[11:59:36] --- Dennis Dayman has left
[11:59:39] <eric> yes,, i think you are.
[11:59:51] <eric> you are correct that WSP is ignored in B64
[11:59:51] <sm-msk> base64 is overkill, so that's out
[11:59:56] --- Peter Koch has left
[12:00:30] <thomasm> eric -- did you get my comment on the leading ws for z=?
[12:01:26] <eric> you mean as in the space in "Subject: foo"? yes, and that is covered by my wording, and i did hear that you want it explicitly called out, although i'm not sure why that one is more important than, say, white space at the end.
[12:01:41] <eric> I say that "all white space" must be encoded.
[12:01:48] <eric> i make it clear that SPACE must be encoded.
[12:02:03] <sm-msk> gotta go
[12:02:03] <eric> i'm not at all sure how you can go from there and assume that the space after a colon is omitted.
[12:02:05] --- sm-msk has left
[12:02:08] <thomasm> yes, but I it's a point of confusion, and your milter thing doesn't help the situation
[12:02:26] <doug_trendmicro@jabber.org> bye.
[12:02:28] <thomasm> all I'm saying is to "including the leading white space between header field and value"
[12:02:28] --- doug_trendmicro@jabber.org has left
[12:02:34] <eric> this should have nothing to do with the milter thing.
[12:02:56] <thomasm> the point is that milters strip this, and other things may too, so it might not be obvious
[12:03:15] <eric> i'll add that text. but this has nothing, nil, zero to do with milter.
[12:03:22] <eric> this is encoding /within/ the z= field.
[12:03:44] <thomasm> yes, but milters strip that first space.
[12:03:58] <thomasm> and in fact, with milters I can't actually know that it was a space
[12:03:59] <eric> so?
[12:04:12] <thomasm> which was why I never encoded it in first place
[12:04:41] <thomasm> so if we are going to make it required, it would be good to mention that that particular gotcha is worth noting
[12:05:02] <eric> mike, i've already agreed. stop selling lest you unsell.
[12:05:07] <thomasm> ok
[12:05:25] <fenton> bye all
[12:05:50] <eric> bye. enjoy your conference.
[12:05:57] <eric> time for me to check out too.
[12:06:58] --- eric has left
[12:08:13] --- fenton has left
[12:15:38] --- thomasm has left
[13:06:36] --- Barry Leiba has left
[14:16:23] --- tonyhansen has joined
[14:16:32] --- tonyhansen has left
[17:49:27] --- dcrocker has joined
[22:27:25] --- dcrocker has left: Replaced by new connection
[22:27:26] --- dcrocker has joined
[22:27:26] --- dcrocker has left
[22:58:02] --- dcrocker has joined
[23:52:55] --- dcrocker has left: Replaced by new connection