On Jun 9, 2006, at 5:15 PM, John Levine wrote:
If the "g=" tag in the public key is present and is anything other
than *, and the domains in the "i=" and "n=" tags in the signature
are not identical, the verifier MUST ignore the key record and
return PERMFAIL (inapplicable key).
This
>I can see where this might not be desired. The fix for this that I
>would suggest would be to put something in the key record saying that
>the key can't sign for subdomains. Is this worth doing?
Hi, I'm back with another proposal that completely contradicts my
previous message.
I observe that
On Jun 9, 2006, at 1:41 PM, Stephen Farrell wrote:
Pity none of them involved an underscore.
The terminology 'key is "referenced" or "located"' use a '_domainkey'
subdomain.
. <- root
. <-
.. <-
>This gives the holder of the private key the ability to sign messages
>for [EMAIL PROTECTED], which might be a different provider, in
>addition to the intended address.
>
>I can see where this might not be desired. The fix for this that I
>would suggest would be to put something in the key record
On Jun 9, 2006, at 12:33 PM, Hallam-Baker, Phillip wrote:
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman
Domain names are limited to alphabetic characters, digits and
hyphen.
No, *host names* are restricted to alphabetic characters,
digits and hyphen. This has been discussed, ad na
I don't see this as a policy issue. It really has to do with
determining whether a given signature is valid or invalid. If the
signature is valid, and is a first party signature, we might not even
need to consult policy (depending on what direction the SSP discussion
takes, of course...).
-Jim
Jim Fenton wrote:
I can see where this might not be desired. The fix for this that I
would suggest would be to put something in the key record saying that
the key can't sign for subdomains. Is this worth doing?
Oh. Well, at least this isn't trying to make the DNS into something that
it isn
Don't you very quickly run into policy considerations once you
start down that route? In your example, if I want the key to be
ok for foo.example.com during working hours and bar.example.com
for 24 hours.
So another approach would be to punt to ssp if this is a real
concern (and there are those
Let me see if I understand Doug well enough to boil this down to a small
example:
Suppose [EMAIL PROTECTED] is a outsourced benefits provider which
needs to sign messages in order to send them to clients at example.com
without making them look spoofed. So the domain administrator of
benefits.com
Bill,
I'm not sure I understand the question. The g= tag (in the key record)
only has to do with the local-part of the address, and can be
wildcarded. There is no definition of wildcards in the i= address.
The only 'wildcarding' that exists with respect to subdomains is that
implied by the
Damn the cutoff for the -foo drafts was last week !
Actually my idea here was to persuade as many people as I could to plagarize
the idea so maybe I would not need to write it up.
> -Original Message-
> From: Stephen Farrell [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 09, 2006 4:35 P
Hallam-Baker, Phillip wrote:
Damn the cutoff for the -foo drafts was last week !
You're in luck, the actual deadline in June 19 [1].
Isn't that handy:-)
S.
[1] http://www.ietf.org/meetings/cutoff_dates_66.html
___
NOTE WELL: This list operates ac
Stephen Farrell wrote:
>
> Jim,
>
> Jim Fenton wrote:
>> The term 'signing address' is used several places within -base, so it
>> might warrant being defined in section 2. Since the first mention of it
>> is in the introduction, I'd propose that we add a forward reference in
>> the introduction.
Douglas Otis wrote:
On Jun 9, 2006, at 7:34 AM, Stephen Farrell wrote:
Your first paragraph below is impossible for me, and I bet, others, to
understand. If you're not clear you'll be ignored, most likely. Sorry
to call this out on the list, but this is far from being the first time.
I'l
Hi Phil,
That looks like it might be interesting to discuss.
I hope that writing it up as draft-hallam-dkim-foo isn't too much
work, since that's the barrier-to-entry:-)
S.
Hallam-Baker, Phillip wrote:
I am not sure that I want to propose a different architecture, it is
conditional on wheth
Tony Hansen wrote:
Since we're talking about possibly WGLCing base, there's an issue that
needs to be resolved. In section 3.4.4, there's this note:
3.4.4 The "relaxed" Body Canonicalization Algorithm
[[This section may be deleted; see discussion below.]] The "relaxed"
body canonicaliz
On Jun 9, 2006, at 7:34 AM, Stephen Farrell wrote:
Your first paragraph below is impossible for me, and I bet, others,
to understand. If you're not clear you'll be ignored, most likely.
Sorry to call this out on the list, but this is far from being the
first time.
I'll try to explain it
I am not sure that I want to propose a different architecture, it is
conditional on whether we are going to have an incompatible backwards change or
not.
I see two cases of interest here:
Case One: Adopt SSP essentially as is without backwards incompatible change.
This is an entirely ju
This is a totally separate issue. Please discuss that issue in a
separate thread.
Tony Hansen
[EMAIL PROTECTED]
John Levine wrote:
>> Do we have enough data yet to make a decision on this? Do we have data
>> to back things up, one way or the other? Do we have proof of cases where
> [mailto:[EMAIL PROTECTED] On Behalf Of Paul Hoffman
> >Domain names are limited to alphabetic characters, digits and hyphen.
>
> No, *host names* are restricted to alphabetic characters,
> digits and hyphen. This has been discussed, ad nauseum, for decades.
Absolutely right, and there is ple
>About the only thing you can rely on is that most (all?) registries
>enforce those character restrictions in domains registered with them.
I just checked, none of the domain I register via Tucows will accept a
name that starts with an underscore, although of course there are lots
of other TLD
>Do we have enough data yet to make a decision on this? Do we have data
>to back things up, one way or the other? Do we have proof of cases where
>a relaxed body passes verification but a simple body does not?
This sounds like it's related to the milter bug that munges spaces
around the colon in a
Since we're talking about possibly WGLCing base, there's an issue that
needs to be resolved. In section 3.4.4, there's this note:
3.4.4 The "relaxed" Body Canonicalization Algorithm
[[This section may be deleted; see discussion below.]] The "relaxed"
body canonicalization algorithm: ..
On Jun 9, 2006, at 8:25 AM, Eliot Lear wrote:
Steve Atkins wrote:
No, *host names* are scarcely restricted at all. You may wish it were
otherwise, but it's not the case. In particular, underscores are
downright common in hostnames, and most DNS servers don't put any
constraints on them. There
Steve Atkins wrote:
>
> No, *host names* are scarcely restricted at all. You may wish it were
> otherwise, but it's not the case. In particular, underscores are
> downright common in hostnames, and most DNS servers don't put any
> constraints on them. There are RFC requirements on them, sure, but
>
On Jun 9, 2006, at 7:32 AM, Paul Hoffman wrote:
At 8:53 PM -0700 6/8/06, SM wrote:
Hi Jim,
At 16:35 08-06-2006, Jim Fenton wrote:
Let's try to construct the problem case: Suppose someone managed to
register _domainkey.com. They could then publish keys in that
domain,
and sign arbitrary me
Douglas Otis wrote:
>>> J. Otis, i= parameterJabber Status: review on list
>>> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html
>>>
>> Same message same issue.
>>
>
> Sorry, I had copied this link from the agenda. Here is the correction again.
>
> http://mipassoc.org/p
At 8:53 PM -0700 6/8/06, SM wrote:
Hi Jim,
At 16:35 08-06-2006, Jim Fenton wrote:
Let's try to construct the problem case: Suppose someone managed to
register _domainkey.com. They could then publish keys in that domain,
and sign arbitrary messages on behalf of .com. That's obviously a Bad
Thi
Doug,
Your first paragraph below is impossible for me, and I bet, others,
to understand. If you're not clear you'll be ignored, most likely.
Sorry to call this out on the list, but this is far from being the
first time.
So: use fewer words!
Stephen.
Douglas Otis wrote:
The concern about con
Jim,
Jim Fenton wrote:
The term 'signing address' is used several places within -base, so it
might warrant being defined in section 2. Since the first mention of it
is in the introduction, I'd propose that we add a forward reference in
the introduction. So the second paragraph of section 1.2
On Fri, 2006-06-09 at 08:23 -0400, [EMAIL PROTECTED] wrote:
> You want to ensure that wildcards and i,g tags can delimit subdomains,
> is that correct?
The concern about conveying what is a validated email-address has little
to do with MX records using a wildcard. This only relates to why did
th
On Fri, 2006-06-09 at 14:57 +0200, Eliot Lear wrote:
> As a reminder, when you wish to raise a new issue, please indicate "new
> issue" in the subject.
>
> Douglas Otis wrote:
> > Issues not within tracking system:
> >
> > H. Otis, g= templateJabber Status: review on list
> > http://mi
As a reminder, when you wish to raise a new issue, please indicate "new
issue" in the subject.
Douglas Otis wrote:
> Issues not within tracking system:
>
> H. Otis, g= templateJabber Status: review on list
> http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html
Now Issue 1292.
>
Just want to clarify
You want to ensure that wildcards and i,g tags can delimit subdomains,
is that correct?
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Be
John L wrote:
>>> INFORMATIVE NOTE: A message forwarder may remove DKIM-Signature
>>> header fields if it modifies a message in a way that makes it
>>> implausible that a subsequent verifier could verify the
>>> signature, e.g., if it reorders the MIME parts in a message
>>> or flattens an HTML m
On Thu, 2006-06-08 at 18:56 -0700, Dave Crocker wrote:
>
> Paul Hoffman wrote:
> > At 5:57 PM -0700 6/8/06, Douglas Otis wrote:
>
> >> But this is the issue being discussed. These are serious security
> >> concerns. There is zero containment of local-part namespace between
> >> any subdomains.
36 matches
Mail list logo
