[10:22:42] --- sftcd has joined
[10:23:00] * sftcd has set the topic to: DKIM meeting in about 30 minutes
[10:23:00] --- mike thomas has left: Lost connection
[10:32:56] --- Paul Hoffman has joined
[10:33:28] <Paul Hoffman> And the agenda will be... ?
[10:34:10] <sftcd> Hi Paul
[10:34:18] <sftcd> Continuation from last week
[10:34:20] <Paul Hoffman> Hi Stephen.
[10:34:47] <Paul Hoffman> A pointer to the page, and starting number, would be helpful.
[10:35:05] <sftcd> Sure will post that when we start, but look back to last week's jabber log either
[10:36:50] <Paul Hoffman> Are we going off of Eric's issues list or the WG issues list?
[10:37:08] <sftcd> Eric's - don't think Eliot had a chance to update the official one yet
[10:37:17] <sftcd> (Maybe someone might help him out:-)
[10:37:33] <Paul Hoffman> For the benefit of the group, that's at <http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html>
[10:38:00] <Paul Hoffman> You want to start at #1264?
[10:38:15] <sftcd> Thanks Paul but we have to say that again after the start since not all clients
[10:38:22] <sftcd> display the earlier messages
[10:38:25] --- Peter Koch has joined
[10:38:30] <sftcd> Hi Peter
[10:38:34] <Paul Hoffman> I'll let you say that because you're chairing this.
[10:38:38] <Peter Koch> Hi Stephen
[10:38:56] <sftcd> Actually, Barry's gonna chair today
[10:39:00] <Paul Hoffman> I just want to be ready. Given that the next set of issues have no pointers to mailing list messages, I thought it would be useful to be ready ahead of time.
[10:39:52] --- leiba has joined
[10:39:57] <sftcd> Hi Barry
[10:40:29] <leiba> 'lo
[10:40:50] --- leiba is now known as Barry Leiba
[10:41:26] <Paul Hoffman> The other reason I wanted to see mail to the list is that I have lost my link to Eliot's list.
[10:43:32] <Paul Hoffman> Could someone post a copy of that link?
[10:44:45] <Barry Leiba> https://rt.psg.com/
[10:45:13] <sftcd> And the DKIM queue
[10:45:13] --- thomasm has joined
[10:46:21] <Paul Hoffman> Ah. <https://rt.psg.com/Search/Results.html?Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50>. Maybe that's why I forgot the URL. :-)
[10:48:27] * sftcd has set the topic to: DKIM meeting in about 12 minutes (Barry chairing:-)
[10:51:11] <sftcd> Last week's log: http://www.ietf.org/meetings/ietf-logs/dkim/2006-05-18.html
[10:51:42] <sftcd> We got as far as issue 1258 (which we finished), working fro Eric's list which is:
[10:51:50] <sftcd> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html
[10:52:31] <Paul Hoffman> FWIW, the Internet Drafts editor put the -02 document in the IETF directory about a half hour ago.
[10:52:43] <sftcd> Ah, good.
[10:55:35] * Barry Leiba has changed the subject to: DKIM meeting in about 5 minutes (Barry chairing)
[10:56:40] <thomasm> boy, I guess everybody's still working their coffee machines
[10:57:27] <sftcd> Lots of just-in-time or else we beat up the others who wanted weekly chats:-)
[10:57:34] --- doug_trendmicro@jabber.org has joined
[10:58:26] <Barry Leiba> I hope we at least get Eric.
[10:58:39] <thomasm> he said he'd be here
[10:59:36] <doug_trendmicro@jabber.org> It is early in the work day on the left coast.
[10:59:51] --- eric has joined
[10:59:59] <Barry Leiba> And there he be.
[11:00:06] <eric> speak of the devil....
[11:00:22] * Barry Leiba has changed the subject to: DKIM meeting in progress (Barry chairing)
[11:00:31] <Barry Leiba> OK, let's call this to order.
[11:00:51] <Barry Leiba> Hi all, and thanks for joining. We're going to hit Eric's issues list, here:
[11:00:58] <Barry Leiba> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003640.html
[11:01:30] <Barry Leiba> And I see we got thru 1258 last week. So...
[11:01:39] <Barry Leiba> 1263 (get rid of x=): I /think/ this has been resolved.
[11:01:47] <Barry Leiba> Is that, indeed, resolved?
[11:02:02] <Paul Hoffman> +1 on resolved
[11:02:05] <doug_trendmicro@jabber.org> Unless someone is willing to drop x.
[11:02:09] <thomasm> that was my understanding
[11:02:12] <sftcd> Confession time: I think I took an action to summarise from the 1st jabber chat
[11:02:18] <sftcd> (and haven't done it)
[11:02:32] <Barry Leiba> OK, 1263 done. "1264 (proposed fingerprint tag description)."
[11:02:52] <sftcd> Eric - wanna say what's in -02 since people may not have read it?
[11:02:56] <Barry Leiba> Jim's online... I guess he's coming.
[11:03:16] <eric> i'm trying to remember what that was.
[11:03:23] --- fenton has joined
[11:03:29] <doug_trendmicro@jabber.org> 02 is looking much better than 01.
[11:03:34] <fenton> sorry I'm late
[11:03:34] <thomasm> you mean 1264?
[11:03:37] <Barry Leiba> f= Signature fingerprint (plain-text; OPTIONAL) The fingerprint of the signature. This is a short string which is used to distinguish between two different signatures of the same message, which may have been added at the same time by the same signer, so that the receiver can decide which of two or more conflicting results makes a more desirable assertion. The fingerprint SHOULD be fairly short but MUST be unique among signature headers added by the same signer. Thus, the concatenation of the values of "f=" and "i=" will uniquely distinguish this signature from any others that might be added between the originator and the receiver.
[11:03:40] <eric> hold on, i'll need to get to the expanded list
[11:03:42] <eric> ok, thanks
[11:03:57] <thomasm> I guess what I'
[11:04:06] <thomasm> i"m not clear on is what it's use case is
[11:04:11] <Barry Leiba> (I think it's Murray's.)
[11:04:17] <thomasm> yes
[11:04:19] <eric> there's nothing about that in -02.
[11:04:44] <eric> i think we're about at the spot on the list that I didn't get to for -02.
[11:04:57] --- dcrocker has joined
[11:04:59] <Paul Hoffman> The use case is for clients who get a "this was validated" header. Thus, it's in Murray's realm
[11:05:12] <eric> lemme see if murray is online.
[11:05:13] <Barry Leiba> Right... we're past the -02 stuff, and trying to work thru the rest.
[11:05:30] <Barry Leiba> OK, let's move on for now and come back to this one.
[11:05:38] <eric> alas no, idle fro 3:38. i'm guessing he's not going to be up soon.
[11:05:40] <Barry Leiba> "1265 (signing by parent domains)."
[11:05:55] <eric> anyone have the URL for the tracker site?
[11:06:03] <fenton> I think I brought that issue to the list (1265)
[11:06:03] <Barry Leiba> That's Jim's
[11:06:05] <doug_trendmicro@jabber.org> This should be deleted to avoid future problems.
[11:06:10] <Peter Koch> https://rt.psg.com/Ticket/Display.html?id=1265
[11:06:21] <eric> merci
[11:06:39] <fenton> It had seemed like the consensus was against getting rid of the parent signing.
[11:06:46] <fenton> Peter, any more thoughts?
[11:06:56] <thomasm> I haven't see any such consensus
[11:07:00] <doug_trendmicro@jabber.org> I would be in favor of getting rid of parent signing.
[11:07:00] <Peter Koch> Well, I can try to explain my concern ...
[11:07:16] <thomasm> this will cause a *HUGE* problem for domains
[11:07:53] <fenton> Mike: Which 'this'? Parent signing or getting rid of it?
[11:08:01] <thomasm> getting rid of it
[11:08:14] <Peter Koch> the problem I see is less that the "parent domain" (and still I have difficulties to see domains as acting entities) would "attack" their children, but more that it would lead to defaulting up the tree.
[11:08:33] --- tonyhansen has joined
[11:08:39] <doug_trendmicro@jabber.org> Why would getting rid of parent signing pose a problem?
[11:08:51] <Peter Koch> E.g. if there's no MX RR for foo.example.com, noone is supposed to look up example.com (I know that some MTAs do anyway)
[11:08:55] <Paul Hoffman> Possible issue: Verisign starts sending out mail signing "com".
[11:08:56] --- boxley has joined
[11:09:26] <thomasm> getting rid of it would require population of dkim keys in _every_ subdomain. yuck!
[11:09:47] <Barry Leiba> IBM, for instance, does not send out mail @ibm.com. ....
[11:09:48] <dcrocker> Why would "defaulting up the tree" be a problem? (There is an issue with limiting the amount of searching needed, in order to avoid a DOS attack, but that seems to be reasonably well understood.)
[11:09:48] <eric> my argument for parent signing is a company such as sun that uses "<dept>.sun.com" but it all goes through a centralized mail server.
[11:09:51] <thomasm> many of those subdomains are likely to be delegated. double yuck
[11:09:54] <doug_trendmicro@jabber.org> But this population of every zone also allows proper delegation.
[11:10:03] <eric> they would have to maintain separate selectors for each departement
[11:10:09] <eric> on the other hand that doesn't seem so bad.
[11:10:10] <thomasm> or not
[11:10:10] <Paul Hoffman> But, getting rid of it requires many more keys. It is likely that domains would make copies of keys (example.com would just duplicate its key for mail.example.com and marketing.example.com)
[11:10:17] <Barry Leiba> But we might want to publish keys there, and sign as "us.ibm.com" and "ca.ibm.com" and "uk.ibm.com" and so on.
[11:10:41] <sftcd> Are there reasons to punt this, or some of this, to SSP (or not)?
[11:10:48] <Peter Koch> Also, as a side issue, as far as I understand the current state of proposals this 'parent signing' could limit what the maintainer of the parent zone could enter into their zone since it could affect a part of the namespace that was actually delegated out and in the hands of the child zone maintainer
[11:10:56] <dcrocker> paul: if the 'owner' of a parent domain wants to attack the owner of a sub-domain, there are lots of ways they can do it. so, having them inappropriately declare a default does not create a new, basic exposure.
[11:10:57] <fenton> This is a different issue from SSP parents
[11:11:13] <thomasm> +1 crocker
[11:11:20] <eric> thought: a domain could use a CNAME for _domainkey.<dept>.example.com that would point up the tree.
[11:11:36] <eric> that way you could reduce the management problem and get rid of parent signing.
[11:11:54] <eric> next question: the @foo part is redundant with d= if you do that.
[11:11:54] <thomasm> part of the issue being ignored here is that many of these subdomains aren't in the same administrative realm
[11:11:54] <Peter Koch> dave: this is not about an "attack" as in: revoking the delegation or similar.
[11:11:56] <Paul Hoffman> Right. I'm talking about a way that a parent can ease the burden if we get rid of parent signing: simply copy the same key throughout.
[11:12:02] <fenton> Peter: there shouldn't be a concern about a parent unintentionally affecting a child domain, because they needn't sign messages from them.
[11:12:05] <doug_trendmicro@jabber.org> It would be more a matter of what is considered having been validated. A .com should not be able to validate all emails for all of .com.
[11:12:07] <thomasm> though part of the same domain
[11:12:29] <Barry Leiba> We could certainly require at least two levels in the d=
[11:12:40] <eric> Barry: .co.uk
[11:12:41] <Barry Leiba> If the ".com" is what we're worried about
[11:12:46] <Barry Leiba> Flrg.
[11:12:52] <Barry Leiba> I forgot about that
[11:13:31] <Peter Koch> barry: there's no reliable way to predict what is a 'registry like domain' and what isn't
[11:13:37] <Paul Hoffman> This seems like a problem that needs more list discussion.
[11:13:44] <sftcd> That's why this seems partly to be a "policy" ish thing to me - foo.example.org says that example.org can sign for it
[11:13:52] <eric> it still has to be in base.
[11:13:55] <tonyhansen> (what's the usename/passwd for rt.psg.com?)
[11:13:56] <dcrocker> barry, requiring 2 levels is an attempt to specify something simply that is actually quite a bit more complex. hence it winds up providing little protection but adds another bit to the spec. The real issue is that anyone registering signature data needs to have authority to do so... for the entire subtree. Period.
[11:14:01] <thomasm> note that receiver isn't completely without clue here.
[11:14:02] <Paul Hoffman> +1 to Peter. These kinds of guesses should not be in DKIM base.
[11:14:04] <sftcd> (ietf/ietf I think)
[11:14:05] <Barry Leiba> Tony: use ietf/ietf
[11:14:18] <tonyhansen> (thanks)
[11:14:34] <sftcd> eric: what has to be in base do you think?
[11:14:36] <fenton> paul: what do you mean by a 'guess'
[11:14:37] <eric> any comment on the CNAME hack? If that will work then I think I'm comfortable with dropping superdomains.
[11:14:51] <Paul Hoffman> Guessing how many levels are required, and where.
[11:15:08] <eric> we need to say in -base which key records are legal and which aren't.
[11:15:11] <eric> it's not a policy thing.
[11:15:19] <fenton> eric: won't cname have side effects beyond the publication of keys? What if there is also an NS record for the subdomain?
[11:15:19] <Paul Hoffman> Eric: I want to think about it more. CNAMEs keep biting me on the butt when I forget about leaves.
[11:15:23] <thomasm> I don't understand what you mean by cname hack
[11:15:24] <Barry Leiba> I agree with Eric that this needs to be in the base.
[11:15:25] <doug_trendmicro@jabber.org> The _domainkey label at the parent restricts what is being validated when subdomains are not allowed.
[11:15:27] <eric> also, if the domain on i= must equal d=, then i= should probably just become the localpart.
[11:15:44] <eric> jim: the CNAME would be for _domainkey only.
[11:15:50] <doug_trendmicro@jabber.org> Yes. I= localpart only.
[11:16:03] <Barry Leiba> I don't see consensus coming here. Shall we take this issue back to the list? Who will post it?
[11:16:06] <fenton> eric: so you don't mean publish an actual cname RR then?
[11:16:11] <Peter Koch> eric: if from the canonical entry point there's an explicit pointer elsewhere in the tree (I don't see that would necessarily have to be limited to the parent), I do not see a problem. But that CNAME could be there without that possibility being explicitly being mentioned, or just as an informational operational hint
[11:16:28] <Paul Hoffman> Make Jim post it: he brought it up the first time. :-)
[11:16:30] <eric> peter: sorry, i don't understand. let's take this to the list.
[11:16:38] <fenton> I'll take the action to post it.
[11:16:43] <Barry Leiba> :-) OK, Jim, thanks.
[11:16:45] <eric> yeah jim!
[11:16:57] <Barry Leiba> "1266 (sec 5.2 move recommendations for key retention to a BCP)."
[11:17:27] <Barry Leiba> This is Doug's.
[11:17:33] <doug_trendmicro@jabber.org> In favor of that of course.
[11:18:12] <eric> i guess i'll ask a loaded question: why move this to a BCP, when SMTP minimum timeouts are in the standard?
[11:18:17] <sftcd> Suggested text needs to distinguish public from private keys - saying "key" ain't ok here
[11:18:26] <doug_trendmicro@jabber.org> Otherwise this will affect the use of DKIM at the MUA for example. Let the signing domain decide when to expire based upon where they want the verification to take place.
[11:18:44] <eric> signers don't know how the verifier will be implemented.
[11:19:04] <boxley> which is why we need to clarify explicitly
[11:19:10] <doug_trendmicro@jabber.org> Exactly, which is why the current recommendation is likely wrong.
[11:19:33] <dcrocker> Doug's proposed text nicely describes the goal and who should attend to it, without specifying arbitrary detail.
[11:19:45] <Barry Leiba> I'll go back to my thought that having the sender try to "expire" the signature in any way other than not publishing the key... is bogus.
[11:20:02] <Paul Hoffman> The question is: does the signer define the desired transit period, or does the recipient? If the former, Doug's proposal is right; if the latter, we should stick with the seven days. I have no opinion which way to go here.
[11:20:04] <Barry Leiba> And trying to tell the signer that it can't stop publishing the key... is bogus.
[11:20:09] <dcrocker> the signer's admin does have to worry about transitions. exactly what they should decide is up to them.
[11:20:09] <Barry Leiba> I like Doug's text.
[11:20:25] <boxley> go with dougs text
[11:20:29] <eric> as an implementer, doug's text tells me nothing useful.
[11:20:41] <sftcd> text has to distibguish public/private keys folks
[11:20:43] <eric> i think the "transit time" is probably less than an hour.
[11:20:47] <eric> smtp is fast.
[11:20:51] <dcrocker> eric -- it tells you to pay attention to transition times. we can't specify more detail than that.
[11:21:16] <boxley> transit time can be up to 4 days depending on the system
[11:21:22] <dcrocker> eric - "smtp is fast" attends to one component in the overal transit activity. overall transit often is slow.
[11:21:26] <Barry Leiba> Ad to Stephen's comment, I think we do need to tweak any text...
[11:21:40] <Barry Leiba> It's not the case that the signing key (private) is "expiring", but...
[11:21:40] <eric> dave, i agree, my point was just to express what an implementer might think.
[11:21:59] <Barry Leiba> ...rather that the verification key (public) will no longer be published.
[11:22:12] <eric> to me this is kind of like the message retry timeout.
[11:22:33] <eric> the spec says that you SHOULD try for at least 4 (or is it 5?) days.
[11:22:38] <eric> but of course you can try more.
[11:22:41] <doug_trendmicro@jabber.org> The transports being protected by dkim is not limited to SMTP however.
[11:22:47] <Barry Leiba> Maybe we should refer to the "key" as a "key pair"?
[11:22:48] <eric> that tells me clearly not to think in terms of hours.
[11:22:53] <Paul Hoffman> Eric, Doug's text says " a transit period where protection is desired". That's clearly not "one hour"
[11:22:58] <doug_trendmicro@jabber.org> What is good for SMTP may not be good for other transports.
[11:23:21] <eric> ok, ok. i think it's a mistake, but consensus is clearly against me.
[11:23:38] <Barry Leiba> I think trying to put specific time periods in this document (1) will get us into a rathole and (2) limits the shelf life of the document.
[11:23:55] <dcrocker> small wording tweak suggestion: commence with the new key *but* the old key SHOULD be retained *until messages that were signed by it are expected to have been delivered*.
[11:24:05] <Paul Hoffman> No opinion on "key" vs. "key pair". It's obvious from the context.
[11:24:20] <Barry Leiba> Paul: I thought that at first, but then see my other comment.
[11:24:21] <sftcd> Not entirely - you can ditch the old private key immediately
[11:24:23] <eric> keypair is fine with me.
[11:24:32] <Barry Leiba> It's NOT that the "signing key" is "expiring".
[11:24:39] <dcrocker> saying "public key" rather than "key" probably is a useful improvement in precision.
[11:24:45] <fenton> I think the new text could clarify what is meant by the 'transit period'
[11:24:54] <doug_trendmicro@jabber.org> Why talk about the private key?
[11:25:16] <sftcd> cause keeping private keys around is a bad idea
[11:25:18] <fenton> not in terms of days, but that we're talking about the maximum expected transit period, not the typical one
[11:25:20] <Barry Leiba> Doug: you ARE talking about the private key, when you say "sign with a key".
[11:25:22] <doug_trendmicro@jabber.org> Transit period for all related transports...
[11:25:28] <Paul Hoffman> Stephen: so? After the sender ditches the private key, the recipient can still verify.
[11:25:50] <doug_trendmicro@jabber.org> But this was about how long to publish the public key.
[11:25:50] <eric> i'll take care of the key wording. it's obvious i think what we want to say.
[11:26:01] <Barry Leiba> OK...
[11:26:08] <sftcd> fine
[11:26:09] <Barry Leiba> Eric will reword and post to the list.
[11:26:23] <Barry Leiba> Any more comments on this one for right now?
[11:26:25] <tonyhansen> (barry: technically you can sign with a public key. It doesn't do much good though. :-) )
[11:26:48] <Barry Leiba> OK, now for a real rathole: "1267 (expiry based on received time rather than current time)."
[11:27:02] <dcrocker> tony -- that was not a nice post; you forget that some of us are still on our first cup of coffee.
[11:27:07] <doug_trendmicro@jabber.org> The 02 draft has good language already.
[11:27:26] <Barry Leiba> OK, good. Then 1267 is resolved?
[11:27:34] <sftcd> well people need a chance to read -02
[11:28:06] <Barry Leiba> All right, but we don't need to talk about 1267 now. Next...
[11:28:07] <Barry Leiba> "1268 (format of t=)."
[11:28:10] <dcrocker> if the proposer of something has declared themselves satisfied -- ie, they effectively remove their proposal -- we probably do not need to consider the topic further.
[11:28:19] --- boxley has left
[11:28:52] <Barry Leiba> 1268: From a prior conversation, I think the concern was whether to use seconds from 1970 or the RFC2822 date time format. Standardizing on a consistent format with that of the other headers being examined would also permit a recipient to understand what the time stamp value represents. The conversion routines are already be available. The draft could recommend encompassing an evaluated Date header within the signature, or providing for a human readable t= time stamp when the Date header differs significantly.
[11:29:02] <Barry Leiba> (That's Doug's text.)
[11:29:15] <Paul Hoffman> No opinion. Seems fine now, and would seem fine with the change.
[11:29:17] <fenton> is this just for t= or for x= as well?
[11:29:24] <tonyhansen> the description on rt.psg.com is missing the suggestion of using the standard time format used in later RFCs
[11:29:29] <eric> actually i proposed this a long time ago (pre-ietf work)
[11:29:42] <eric> and it was shouted down, so there is some desire to keep it as-is.
[11:29:58] <doug_trendmicro@jabber.org> A human readable form is safer.
[11:30:06] <eric> personally i think i proposed the fairly compact ISO format.
[11:30:10] <dcrocker> this might expand the scope of 1268 too far, however: If I am understanding the gist of the concern about signing the Date field, I see the underlying issue as how to canonicalized structured header fields that are included in the signature.
[11:30:10] <thomasm> unless there's something that actually broken, why bother?
[11:30:39] <doug_trendmicro@jabber.org> When there is a problem it can also be understood more quickly as related to other dates found within the message.
[11:30:48] <tonyhansen> rfc 3339 Date and Time on the Internet: Timestamps.
[11:30:51] <Barry Leiba> I'm with Mike on this -- we all know how to convert dates.
[11:31:10] <doug_trendmicro@jabber.org> This could be specified to always use the Z zone.
[11:31:17] <Paul Hoffman> Doug: "understood more quickly" is only for people analyzing the headers. They will have conversion tools.
[11:31:31] <thomasm> and textual representations are always at risk of being inprecise
[11:31:40] <Barry Leiba> What's there is maximally compact, and well defined.
[11:31:56] <doug_trendmicro@jabber.org> The text can still indicate the second however.
[11:32:00] <Barry Leiba> Here's where I think I'll invoke the "really good reason to change it" clause.
[11:32:14] <tonyhansen> barry: +1
[11:32:19] <thomasm> barry+1
[11:32:22] <Paul Hoffman> Barry: +1
[11:32:23] <sftcd> barry: +1
[11:32:24] <fenton> barry: I don't see a really good reason
[11:32:31] <Barry Leiba> I see consensus.
[11:32:47] <Barry Leiba> "1269/1270 (body length mechanism rejections)."
[11:32:50] <fenton> do we really need t= at all?
[11:32:57] <fenton> sorry too late
[11:33:10] <Barry Leiba> Well, we've had lots of discussions of t= before.
[11:33:26] <Barry Leiba> Pre-IETF as well. Enough people liked it, and enough who didn't thought it harmless.
[11:33:34] <fenton> ok
[11:33:42] <Barry Leiba> Body...
[11:34:05] <eric> already done in -02:
[11:34:14] <Barry Leiba> Both 1269 and 1270?
[11:34:14] <doug_trendmicro@jabber.org> The rejection of the message is the problem, or this mechanism should be removed.
[11:34:15] <eric> Note that verifiers MAY choose to truncate messages that have body content beyond that specified by the body length count. Alternatively, verifiers MAY ignore signatures that do not cover the entire message body.
[11:34:23] <eric> (that's a quote)
[11:34:30] <fenton> looks good to me
[11:34:34] <Barry Leiba> OK, what about 1270?
[11:34:46] <Paul Hoffman> Verifiers MAY do whatever the @#$% they want.
[11:34:57] <tonyhansen> I don't like ignoring the signature possibility
[11:35:01] <doug_trendmicro@jabber.org> If a body length is specified in the "l=" tag of the signature, verifiers MUST only verify the number of bytes indicated in the body length. Verifiers MAY decide to treat a message containing bytes beyond the indicated body length with suspicion. Verifiers MAY truncate the message at the indicated body length, reject the signature outright, or convey the partial verification to the policy module using DKIM_STAT_PARTIALSIG.
[11:35:10] <Paul Hoffman> We shouldn't be telling them, much less limiting them, in that.
[11:35:22] <doug_trendmicro@jabber.org> Sorry, the reject is for the signature.'
[11:35:40] <Barry Leiba> Paul: I agree that verifiers MAY do anything, but it's valid to give guidance, and to use RFC 2119 wording in that guidance.
[11:35:41] <eric> are we on 1270?
[11:35:46] <sftcd> 1269 and 1270 seem quite different to me
[11:35:47] <eric> it seems to have nothing to do with this.
[11:35:55] <Barry Leiba> I think we're still hanging on 1269.
[11:36:07] <eric> ah, sorry, i thought it was resolved.
[11:36:10] <Barry Leiba> (And I think the title of 1270 is wrong)
[11:36:35] <Barry Leiba> Anyway, on 1269...
[11:36:41] <thomasm> so is there a problem here or no?
[11:36:43] <Barry Leiba> Tony isn't happy with "ignore sig".
[11:36:51] <Barry Leiba> And Paul doesn't like telling the verifier what to do at all.
[11:36:58] <Barry Leiba> Further comments on either of those?
[11:37:03] <eric> i can easily see sites being unwilling to truncate the message.
[11:37:04] <sftcd> thought eric's quote seems ok
[11:37:14] <doug_trendmicro@jabber.org> I have not reviewed 02 well enough on this topic.
[11:37:28] <Barry Leiba> Doug: Eric pasted the text above.
[11:37:29] <Paul Hoffman> I'm OK with the current wording. I don't want to change it and pretend that the verifier won't reject.
[11:37:53] <eric> paul: current as in -02 (quoted above) or -01?
[11:37:56] <doug_trendmicro@jabber.org> That text looks okay.
[11:38:02] <fenton> Tony, I don't understand your issue with 'ignore sig'.
[11:38:04] <Barry Leiba> Tony, do you want to pursue your comment further?
[11:38:18] <Paul Hoffman> Any text. Telling the verifier what they MAY do is silly.
[11:38:40] <dcrocker> "Reject the message outright": The base should not talk about accepting or rejecting messages. It should talk about validating a signature or not. Rejection is a matter of policy.
[11:38:51] <Barry Leiba> Dave: +1
[11:39:00] <fenton> dave +1
[11:39:06] <thomasm> +1
[11:39:12] <doug_trendmicro@jabber.org> +1
[11:39:23] <eric> -02 does not say "reject the message outright" ---
[11:39:24] <Barry Leiba> It sounds like current text (-02) is OK by most of us.
[11:39:31] <Barry Leiba> Moving on, then.
[11:39:32] <eric> so is this a vote in favor of no further change?
[11:39:38] <Barry Leiba> Eric: I think so
[11:39:40] <dcrocker> On the matter of truncation: I think the issue is normative vs. informative. Normative is validating up to the l= limit. Informative is suggesting interesting choices in how to deal with the remainder.
[11:40:02] <tonyhansen> if something has tacked on something to the end of the message, and l= is specified, the signature is still valid. so I don't see where "ignore the signature" comes into play dave: +1
[11:40:02] <dcrocker> barry - WAIT
[11:40:07] <Barry Leiba> Waiting.
[11:40:33] <dcrocker> The current wording has at least 2 problems. It says 'truncate' and it specifies something normatively that should be informative.
[11:40:36] <eric> tony: what if the stuff tacked on the end is malicous HTML that overwrites the true text on the screen?
[11:40:46] <eric> dave: i can change that paragraph to label it informative.
[11:41:03] <thomasm> that sounds right
[11:41:10] <Barry Leiba> Dave, you wanna work with Eric on a tweak to the text?
[11:41:17] <dcrocker> barry - yeah.
[11:41:35] <eric> how about tony's issue?
[11:41:36] <Barry Leiba> Tony: I interpret "ignore the signature" as "treat the message as unsigned".
[11:41:56] <eric> barry: technically it means "go ahead and try other signatures"
[11:42:00] <Barry Leiba> Ah
[11:42:02] <fenton> Barry: Almost, but there could be other signatures that are valid, so you only want to ignore this one.
[11:42:06] <doug_trendmicro@jabber.org> Consider the signature invalid.
[11:42:20] <Barry Leiba> Doug better explains what I meant to say
[11:42:38] <thomasm> it's not invalid, it just isn't the best in all possible worlds
[11:42:50] <tonyhansen> how to deal with potential evilness of extra stuff is policy. I don't know, my head hurts on this one. :-(
[11:42:58] <doug_trendmicro@jabber.org> A verifier may consider some algorithms invalid.
[11:43:05] <thomasm> this really belongs in the bcp
[11:43:06] <Barry Leiba> I think here we go back to Paul's statement -- about not telling the verifier what it MAY do.
[11:43:07] <dcrocker> tony, yes on both points (policy and pain)
[11:43:11] <fenton> Maybe the question really is, how strongly do we want to make the point that invalid signature == signature isn't there.
[11:43:26] <doug_trendmicro@jabber.org> Yes.
[11:43:31] <dcrocker> jim, pls clarify
[11:43:51] <Barry Leiba> Maybe what we're REALLY advising here is that the verifier should look at all sigs and find a "best" one.
[11:44:09] <thomasm> rathole, IMO
[11:44:15] <fenton> There are good reasons that messages with invalid signatures shouldn't be considered either more or less favorable than unsigned messages
[11:44:18] <thomasm> best assumes there is a best
[11:44:28] <doug_trendmicro@jabber.org> A verifier should be able to decide what is acceptable from their prespective.
[11:44:38] <fenton> I think that leaves "ignore all invalid signatures"
[11:44:40] <eric> the actual verifier actions are described in more detail in section 6.
[11:44:44] <Barry Leiba> Mike: That's why I said "a", and put "best" in quotes. No, I wouldn't want to doc to say it that way.
[11:45:19] <Barry Leiba> I meant that we're advising that if you get one of these "l=" issues, you probably want to see if there's another sig that validates and DOESN'T have that issue.
[11:45:50] <thomasm> I still think this would be best deferred to the bcp
[11:46:19] <Barry Leiba> Anyway, I think Dave and Eric have lots of input here, so they'll go off and tweak the text again. Keeping in mind whether or not the BCP is a better place for some of it.
[11:46:27] <thomasm> the fact of the matter is that we don't have a whole lot of experince yet
[11:46:36] <Barry Leiba> More to say here, or shall we go on to the next?
[11:46:44] <thomasm> next
[11:46:59] <Barry Leiba> OK, 1270, which seems to have a bad title.
[11:47:04] <eric> should be Binary algorithms and algorithm spoofing during a transition.
[11:47:18] <eric> for some reason eliot changed the title, probably a thumb-fumble.
[11:47:25] <doug_trendmicro@jabber.org> I posted some additional text last night.
[11:47:32] <thomasm> I frankly don't get why we have a problem given h= in the selector
[11:47:40] <Paul Hoffman> Blech. -1
[11:47:48] <thomasm> does anybody else think we have a problem?
[11:47:51] <sftcd> not i
[11:47:54] <eric> nope
[11:47:54] <fenton> not i
[11:48:17] <Barry Leiba> A lot of "no", and I saw the same on the mailing list (albeit from probably the same people :-) ).
[11:48:24] <Barry Leiba> I think we move to the next.
[11:48:43] <sftcd> so 1270 is close/reject for Eliot then?
[11:48:44] <eric> ah, 1271 appears to be == 1270
[11:48:58] <Barry Leiba> Stephen: yes
[11:49:11] <Barry Leiba> "1272 (when i= domain != d= domain)."
[11:49:25] <thomasm> we're on 1272>
[11:49:29] <thomasm> ?
[11:49:48] <Barry Leiba> Yes; 1270 == 1271, and that's a "no".
[11:49:53] <Barry Leiba> So it's 1272 now.
[11:50:21] <Barry Leiba> Doug wants to change the text about i= and d= disagreeing.
[11:50:25] <fenton> the need for domains on both i= and d= depends on the parent signing issue
[11:50:28] <Paul Hoffman> +1 on 1272. Say how to interpret, not what they have to do.
[11:50:39] <dcrocker> +1
[11:50:42] <eric> +1 for consistency
[11:50:43] <Peter Koch> jim +1
[11:50:46] <sftcd> seems like we should be consistent on this all right
[11:51:20] <fenton> agree on removing the language about rejecting the message
[11:51:42] <doug_trendmicro@jabber.org> Again have not reviewed the 02 draft...
[11:51:56] <Barry Leiba> OK, it looks like we should accept Doug's change for now, but understand that the whole thing may change if we change on the "parent signing" issue.
[11:52:16] <eric> ah, turns out it seems to be done.
[11:52:33] <Barry Leiba> One more issue on the list: "1274 (r= for instilling good domain-name practices)."
[11:52:36] <eric> ``This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below). When presented with a signature that does not meet this requirement, verifiers MUST consider the signature invalid.''
[11:53:11] <Barry Leiba> OK, good on 1272, then.
[11:53:28] <Barry Leiba> Let's try to finish 1274 quickly, and wrap up the meeting on the hour, yes?
[11:53:38] <thomasm> kewl
[11:53:46] <thomasm> thumbs down on 1274
[11:53:54] <sftcd> I didn't see support on the list for this
[11:54:10] <doug_trendmicro@jabber.org> It can be added later, but would be best done in base.
[11:54:20] <eric> i don't like the way it's proposed, but i can see the point.
[11:54:40] <Paul Hoffman> Disagree about "would be best done in base" (much less the idea iteself)
[11:54:49] <Barry Leiba> I do see this as easy to add later.
[11:54:52] <eric> example: an ISP that has both free- and paid-mail accounts would "trust" the folks from whom they have a credit card more than the others.
[11:55:01] <doug_trendmicro@jabber.org> This has to do with poor vetting at ISPs.
[11:55:04] <fenton> I would like the semantics of signatures defined by -base to be much cleaner, just a "valid" or nothing.
[11:55:09] <sftcd> not in base IMO (agree with Paul)
[11:55:34] <Barry Leiba> We talked with one ISP that simply doesn't sign "free" accounts at all.
[11:55:40] <doug_trendmicro@jabber.org> There needs to be a way to safely communicate messages as being fully backed by the isp as safe...
[11:55:45] <dcrocker> "i can see the point": I am missing it.
[11:55:51] <thomasm> as was also pointed out, this sort of grouping can be down in the selector space, so there's no need at all
[11:55:51] <Barry Leiba> For that case, it WOULD be nice to have a "we're signing it, but..." option.
[11:55:53] <eric> barry: 1 != all.
[11:56:11] <doug_trendmicro@jabber.org> Add this plug-in to your browser, or go to this website, for example.
[11:56:26] <eric> tying it to the selector makes sense to me.
[11:56:27] <sftcd> semantics too fuzzy by far
[11:56:48] <eric> well, 0-9 sucks without some objective measure.
[11:56:50] <doug_trendmicro@jabber.org> Conventions on the selector would be another choice.
[11:57:03] <Barry Leiba> I'm not sure we need conventions on the selector.....
[11:57:03] <dcrocker> "we're signing it, but..." really opens the door on the meaning of the signature. we've been careful to use a rather generic term for the semantics of the signature, but not go into detail about it. i view this as a strength of dkim.
[11:57:10] <doug_trendmicro@jabber.org> The r= draft changes this to -1 0 and +1.
[11:57:20] <doug_trendmicro@jabber.org> 0 = normal
[11:57:25] <Barry Leiba> I think verifiers can learn that selector X from domain Z are spammier than selector Y from domain Z.
[11:57:43] <dcrocker> at a minimim, "we're signing it, but..." is a policy issue.
[11:57:44] <Barry Leiba> And I think it's better for the verifiers to sort that out.
[11:57:53] <eric> barry: should probably note somewhere (overview?) that reputation should be tied to a selector then.
[11:57:57] <Barry Leiba> And I agree with Dave that more than that is a policy thing.
[11:58:09] <thomasm> It seemed to me that if there were any support for this at all, it could easy be added later and that we should just concentrate on -base
[11:58:09] <doug_trendmicro@jabber.org> The annotation software in the MUA needs something a bit more defined than these seem spammer.
[11:58:17] <Barry Leiba> Mike +1
[11:58:31] <fenton> mike +1
[11:58:41] <sftcd> mike + barry + jim +1
[11:58:49] <doug_trendmicro@jabber.org> The MUA annotation will not work based upon selector reputations that change with each key change.
[11:59:08] <fenton> I'm not entirely comfortable with suggesting reputation goes with selectors, there are other situations where you want to tie reputations together
[11:59:18] <fenton> as when different selectors are just different MTAs
[11:59:23] <dcrocker> eric: where to tie the reputation is not at all that clear, or at least resolving it isn't all that clear. for example (and not to pursue this particular) I could easily argue that a selector MUST NOT have any special semantics concerning the reputation. The reputation MUST be tied strictly to the domain name (minus the selector.)
[11:59:29] <eric> +1 for leaving it for later. it' s not fundamental to the protocol.
[11:59:35] <Barry Leiba> I think the reputation issue is a big one that needs a lot of work outside the scope of this WG.
[12:00:05] <Barry Leiba> In any case, I see agreement here that this isn't an issue for base.
[12:00:09] <fenton> We also don't want to make it too easy for spammers to fragment their bad reputations!
[12:00:13] <doug_trendmicro@jabber.org> There needs to be a way for the domain to specifically endorse a message as safe.
[12:00:19] <Barry Leiba> I'm happy to leave it open as "defer to extension" or something like that.
[12:00:21] <Paul Hoffman> My clock say 9:00....
[12:00:33] <thomasm> close it..
[12:00:34] <doug_trendmicro@jabber.org> There are critical communications that need protection.
[12:00:53] <sftcd> doug - I think that that one is close/reject for base
[12:00:55] <Paul Hoffman> Doug: "There needs to be a way for the domain to specifically endorse a message as safe." Ummm, it's called DKIM.
[12:01:07] <Barry Leiba> OK. Stephen or I will post a summary to the mailing list, and we will continue the discussions back there again.
[12:01:18] <Barry Leiba> We did skip the fingerprint tag issue that Murray raised.
[12:01:23] <thomasm> we're done right? last call? :)
[12:01:27] <doug_trendmicro@jabber.org> Not when all messages are being signed. Some messages will be from less vetted sources.
[12:01:31] <eric> let's try to get murray on next week.
[12:01:31] <Barry Leiba> So Eric, can you get Murray to bring that back up on the list?
[12:01:40] <eric> roger that.
[12:01:57] <Paul Hoffman> If there are no open issues now, do we need a "next week"?
[12:01:58] <Barry Leiba> OK. Meeting closed, room remains open for a bar fight. And I'm off.
[12:01:59] <fenton> Next week is Inbox. Who else will be there? Want to group-jabber?
[12:02:00] <sftcd> and we should raise issues with -02 if we have 'em - use the "New issue: "contention if you remember (for Eliot's sake)
[12:02:15] <fenton> thanks Barry
[12:02:15] * Barry Leiba has changed the subject to: DKIM meeting ended. Bar brawl begins....
[12:02:36] <dcrocker> Post-meeting rathole invitation: Paul -- "There needs to be a way for the domain to specifically endorse a message as safe." Ummm, it's called DKIM" is wrong. DKIM merely says that the administrator of a domain is responsible for the message; not that they have declared it "safe".
[12:02:52] <fenton> I have a little problem with the "safe" part too
[12:03:02] <sftcd> Yes. Sounds like dinner time for me!
[12:03:04] <sftcd> Bye
[12:03:06] <eric> i think it's more "confidence"
[12:03:07] --- sftcd has left
[12:03:10] <thomasm> right, that's my receiver's call to make
[12:03:24] <eric> the sender can give the receiver hints.
[12:03:26] <thomasm> after he's disconnected the "safe" bomb
[12:03:29] <fenton> I liked the word 'endorse' though
[12:03:34] <doug_trendmicro@jabber.org> When a domain issues a message, they should be able to clarify the message is different than those from just any account.
[12:03:44] <dcrocker> eric, i think that any language that refers to the nature of the content is a mistake for dkim. it all hangs on issues outside the scope of dkim proper.
[12:04:03] <thomasm> +1
[12:04:07] <Paul Hoffman> To me, "safe" == "vouched for". "Vouched for and given two gold stars" == "vouched for"
[12:04:13] <eric> dkim is about identity. and some sites have more certainty about the identity of some users than others.
[12:04:23] <doug_trendmicro@jabber.org> Update your account information, run this process at this website, add this browser plugin would be examples of highly critical and yet dangerous messages.
[12:04:33] <eric> consider poor yahoo, who is going to have a mixed rep.
[12:04:36] <thomasm> which leads you into the reputation rathole
[12:04:43] <doug_trendmicro@jabber.org> There should be added assurances before a recipient acts on these messages.
[12:05:05] <eric> as a verifier, i would like to know which yahoo signatures are on behalf of freemail accounts versus (say) employees.
[12:05:15] <eric> that would give me a LOT of useful info.
[12:05:22] <thomasm> then add a "X-I'M-TRUSTWORTHY: !!!" header and sign it
[12:05:38] <Paul Hoffman> Eric: that's what selectors are for.
[12:05:41] <Paul Hoffman> Thomas: +1
[12:05:48] <doug_trendmicro@jabber.org> The r= of -1, 0, 1 added some valuable information for the recipient.
[12:05:50] <dcrocker> "dkim is about identity" -- maybe not. it is about someone declaring themselves on the hook for the message. it uses identity technology to make that assertion, but it's not really "about" identity.
[12:05:51] <eric> hmm.... mike, yes, that would work.
[12:06:08] <thomasm> or better yet, don't turn on the evil bit in the IP header
[12:06:12] <eric> paul: i don't think that is what selectors are for.
[12:06:16] <Paul Hoffman> A selector says "which part of or kind of mail I know this is"
[12:06:30] <dcrocker> selectors are for differential keys, not differential reputation.
[12:06:32] <eric> it can be used for that, yes, but that's not the semantics.
[12:06:38] <eric> in fact, semantics are not defined.
[12:06:43] <eric> they are just different keys.
[12:06:47] <fenton> we don't want to encourage people to do stupid things with private keys just so they can use the same selector
[12:06:52] <eric> how the signer uses those is up the signer.
[12:06:53] <Paul Hoffman> The current definition of selectors covers "which group of my users are sending this", yes?
[12:06:54] <thomasm> right, bcp land may do that eventually
[12:07:05] <thomasm> no it doesn't paul
[12:07:08] <doug_trendmicro@jabber.org> The signing domain can limit r=1 to those messages they generate from transactional messages or administrators for example.
[12:07:10] <thomasm> at least there's no requirement
[12:07:28] <eric> ``To support multiple concurrent public keys per signing domain, the key namespace is subdivided using "selectors". For example, selectors might indicate the names of office locations (e.g., "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date (e.g., "january2005", "february2005", etc.), or even the individual user. Selectors are needed to support some important use cases. For example: * Domains which want to delegate signing capability for a specific address for a given duration to a partner, such as an advertising provider or other outsourced function. * Domains which want to allow frequent travelers to send messages locally without the need to connect with a particular MSA. * "Affinity" domains (e.g., college alumni associations) which provide forwarding of incoming mail but which do not operate a mail submission agent for outgoing mail. ''
[12:07:44] <Paul Hoffman> Thomas: correct. But that's what it could be used for.
[12:08:13] --- Peter Koch has left
[12:08:17] <Paul Hoffman> The second bullet sounds like it could cover groups of users.
[12:08:17] <thomasm> yep... JD Falk@Y! said they were investigating that... it would be interesting to get more info
[12:08:17] <eric> to tie reputation to selectors, the standard would have to say that they should be used that way.
[12:08:24] <Paul Hoffman> So does the third
[12:08:29] <eric> right now the standard says "use it however you want"
[12:08:34] <dcrocker> selectors are one of those constructs that provide important flexibility that we will come to understand only as they are used more (creatively).
[12:08:43] <eric> agreed
[12:08:46] <Paul Hoffman> Dave: yep
[12:09:04] <thomasm> which says that we ought to leave it for expirimentation until we know better
[12:09:08] <Paul Hoffman> But the idea of adding a reputation header and signing it sounds a lot more useful that r=.
[12:09:15] <doug_trendmicro@jabber.org> Partitioning the domain is still an important security concern.
[12:09:42] <doug_trendmicro@jabber.org> The r= was not about reputation, it was about setting up partitions.
[12:09:43] <eric> i do agree that a header is the right way to go.
[12:09:57] <tonyhansen> I'd much rather use something outside of the DKIM header like Mike's I'm-Trustworthy header, which is then included in the h= list of the dkim signature
[12:10:04] <dcrocker> we are finally seeing enough different reputation efforts to see significant variation. i think we are a long way from knowing what set of reptuation semantics are going to be sufficient for the market.
[12:10:06] <doug_trendmicro@jabber.org> Email must be annotated as the recipient can not see the signature.
[12:10:29] <doug_trendmicro@jabber.org> When annotated, the level of support behind the message can be communicated at the same time.
[12:10:48] <doug_trendmicro@jabber.org> The r=1 says the domain stands behind this message.
[12:11:08] <doug_trendmicro@jabber.org> This would assure customers this is safer than just any message from the domain.
[12:11:08] <tonyhansen> having dkim-signature says the domain stands behind this message
[12:11:18] <doug_trendmicro@jabber.org> No.
[12:11:22] <tonyhansen> yes
[12:11:30] <tonyhansen> :-)
[12:11:39] <dcrocker> maybe
[12:11:43] <doug_trendmicro@jabber.org> The dkim signature says we will need to take care of abuse after the fact.
[12:11:58] <doug_trendmicro@jabber.org> The r=1 is a proactive assertion.
[12:12:17] <tonyhansen> I differentiate between "standing behind the message" and "standing behind the purported sender of the message"
[12:12:20] <dcrocker> tony, are you sure it doesn't mean they stand ... in front of ... the message?
[12:12:40] <dcrocker> but seriously
[12:12:42] <tonyhansen> ready aim fire
[12:12:59] <fenton> dave: what is this, a car commercial?
[12:13:05] <dcrocker> the per-message vs. per-originator distinction is pretty important and I am not sure dkim's sig distinguishes
[12:13:24] <dcrocker> between them.
[12:13:45] <tonyhansen> we've said all along that dkim is for the domain signing, not for individual signing
[12:13:46] <dcrocker> oh. and I'm not sure it should.
[12:14:12] <tonyhansen> r= starts blurring that line considerably
[12:14:18] <dcrocker> domain signing -- yes. i was glibbly using common labels and should have
[12:14:57] <dcrocker> tailored the language: the difference between "all messages associated with this domain" vs. "this particular message" is not really distinguished by dkim itself.
[12:15:36] <doug_trendmicro@jabber.org> A bank will be between a rock and a hard place without a means to partition their domain. Either all messages are signed, but this may include temp workers, or there are some messages that are marked safer than others.
[12:15:40] <fenton> Dave: Association between messages is reputation and out of scope
[12:15:47] <doug_trendmicro@jabber.org> No.
[12:15:53] <dcrocker> r=??? what is that
[12:15:55] <doug_trendmicro@jabber.org> This is not about reputation.
[12:16:14] <dcrocker> jim -- oh i completely agree.
[12:16:37] <fenton> doug: I wasn't talking about r= being about reputation, I was responding to Dave's earlier comment.
[12:16:47] <dcrocker> hmmm. i guess that because a dkim sig is on an individual message, a dkim sig is by definition about a particular message.
[12:16:55] <fenton> yup
[12:17:06] <dcrocker> whether there is anything to say across multiple messages is therefore something "above" dkim.
[12:17:19] <fenton> again yup
[12:17:32] <Paul Hoffman> Doug: are 0-9 partitions, or an ordered ranking? You have indicated "both"
[12:17:43] <dcrocker> hell, if we are going to keep agreeing, there's no point in continuing.
[12:17:45] <doug_trendmicro@jabber.org> The choice should not be limited to just using sub-domains to make distinctions.
[12:18:06] <fenton> i gotta run anyway. bye...
[12:18:13] <dcrocker> ditto
[12:18:13] --- fenton has left
[12:18:17] <doug_trendmicro@jabber.org> This will increase the success of phishing for example.
[12:18:44] <Paul Hoffman> Doug: a straight answer would be more useful.
[12:18:53] --- thomasm has left
[12:19:51] <doug_trendmicro@jabber.org> http://www.ietf.org/internet-drafts/draft-otis-dkim-reliance-level-00.txt
[12:20:24] <doug_trendmicro@jabber.org> This was changed to simplify the number of partitions and to reduce the complexity that seemed to be a cause for concern.
[12:20:25] <tonyhansen> I really dislike using numbers for parameters. The use of numbers implies ranking to me, and the suggested values for r=0-9 did not seem to be in a ranking sort order I would have chosen
[12:20:52] <doug_trendmicro@jabber.org> This was changed to -1 warning, 0 normal, and 1 for assurance.
[12:21:12] <Paul Hoffman> OK, so it's still "both".
[12:21:32] <doug_trendmicro@jabber.org> By using numbers, a key impose a restriction in the upward direction conveyed by a number.
[12:22:01] <doug_trendmicro@jabber.org> This would be easier to administer.
[12:22:30] <doug_trendmicro@jabber.org> Normal still allows warning on guest accounts for example.
[12:23:08] <doug_trendmicro@jabber.org> An r=1 should be reserved for those messages where assurance is vital.
[12:27:08] --- Paul Hoffman has left
[12:27:19] <tonyhansen> bye all
[12:27:22] --- tonyhansen has left
[12:27:38] <doug_trendmicro@jabber.org> Bye
[12:27:41] --- doug_trendmicro@jabber.org has left
[12:27:58] --- eric has left
[12:46:33] --- wildcat has joined
[12:49:40] --- wildcat has left