Re: [ietf-dkim] New Issue: review of threats-01

Eric Rescorla wrote: > S 1.1: > Please expand the term "AU" before use in this figure. > Will do. > S 2.3.2: > >Bad actors in the form of rogue or unauthorized users or malware- >infected computers can exist within the administrative unit >corresponding to a message's origin address.

Re: [ietf-dkim] Re: Concerns about DKIM and mailiing lists, etc.

I think it will eventually be worth having such a document. Tony Hansen [EMAIL PROTECTED] Hector Santos wrote: > > PS: I am willing to write a DRAFT I-D For "List Server DKIM Support > Recommendations." Is that still desirable? ___ N

Re: [ietf-dkim] Re: Concerns about DKIM and mailiing lists, etc.

Dave, I disagree. We are defining how to verify a message. If we agree that the mechanism below is a reasonable step to perform, it's still just one more step in the verification process. Tony Hansen [EMAIL PROTECTED] Dave Crocker wrote: > In particular: > >> The verifier then si

Re: [ietf-dkim] New Issue: z= field and EAI wg

There are a number of ways that the EAI work may affect DKIM. Among them is the use of the yet-to-be-determined downgrading algorithms. Tony Hansen [EMAIL PROTECTED] Michael Thomas wrote: > Stephen Farrell wrote: >> >> Even if it doesn't hit anywhere else, presumably the EAI work

Re: [ietf-dkim] Review of draft-ietf-dkim-base-00 (1)

S 1.1. o there is no dependency on public and private key pairs being issued by well-known, trusted certificate authorities, This claims seems somewhat disingenuous. It shouldn't. The statement is simply and directly accurate, as given. The problem with the analysis you provided is

Re: [ietf-dkim] Review of draft-ietf-dkim-base-00 (1)

S 1.1. o there is no dependency on public and private key pairs being issued by well-known, trusted certificate authorities, This claims seems somewhat disingenuous. It shouldn't. The statement is simply and directly accurate, as given. The problem with the analysis you provided is

[ietf-dkim] DKIM-related events on dkim.org home page

Folks, I've started listing events concerning DKIM on the dkim.org home page. Please let me know of any that you think should be included. d/ -- Dave Crocker Brandenburg InternetWorking ___ NOTE WELL: This list operates according to

Re: [ietf-dkim] New Issue: 512 too short?

On Sun, 2006-03-19 at 11:37 -0600, Paul Hoffman wrote: > At 8:27 AM -0800 3/19/06, Douglas Otis wrote: > >Of those bytes, 8 bytes are used to the version of the TXT record, > >leaving 131 bytes. The "_domainkeys" label consumes another 14 bytes > >(assuming pointer compression in the answer sectio

[ietf-dkim] New Issue: review of threats-01

S 1.1: Please expand the term "AU" before use in this figure. S 2.3.2: Bad actors in the form of rogue or unauthorized users or malware- infected computers can exist within the administrative unit corresponding to a message's origin address. Since the submission of messages in this a

[ietf-dkim] Review of draft-ietf-dkim-base-00 (1)

This message contains editorial comments on draft-ietf-dkim-base-00. In a separate message I'll explore a larger scale issue: whether it's a good idea to invent a totally new protocol rather than reusing something existing (e.g., S/MIME). S 1.1. o there is no dependency on public and private

Re: [ietf-dkim] New Issue: 512 too short?

At 8:27 AM -0800 3/19/06, Douglas Otis wrote: Of those bytes, 8 bytes are used to the version of the TXT record, leaving 131 bytes. The "_domainkeys" label consumes another 14 bytes (assuming pointer compression in the answer section) and that leaves 117 bytes for name space. From this space, o

Re: [ietf-dkim] New Issue: 512 too short?

On Sat, 2006-03-18 at 21:29 -0600, Paul Hoffman wrote: > At 4:20 PM -0800 3/17/06, Douglas Otis wrote: > >With respect to 2048 bit keys, there is already a placeholder in the > >base draft for developing a much needed binary DKIM key. > > Why is a binary representation "much needed"? A 2048-bit k

Re: [ietf-dkim] New Issue: Include new "known message replay" threat?

In preparing for the WG meeting I realized that there had been no response to this. Read on for my attempt to collect a free beer :-) . Stephen Farrell wrote: > > I think I mentioned this before but maybe didn't explain well. (And > I didn't see it when combing the current issues, so I feel free