,---
|1.2 Signing Identity
|
| DKIM separates the question of the identity of the signer of the
| message from the purported author of the message. In particular, a
| signature includes the identity of the signer. Verifiers can use the
| signing information to decide how they want to process th
On May 31, 2006, at 2:22 PM, Douglas Otis wrote:
A few more typos noted at the end.
Errors are highlighted using [[error]] notation. This was based
upon the draft located at:
http://ietf.org/internet-drafts/draft-ietf-dkim-base-02.txt
There seems to be a type of corruption introduced and w
..in about 30 minutes I guess.
(...making up an agenda now...)
Stephen.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
As near as I can tell, every single one of these came up at the IETF
end --- I checked the version I sent them and the doubled characters
do not exist.
eric
--On May 31, 2006 2:22:23 PM -0700 Douglas Otis
<[EMAIL PROTECTED]> wrote:
Errors are highlighted using [[error]] notation. This w
There's some place in the draft where it says "these steps must be
performed such that the semantics are identical to processing them in
this order" --- i.e., it makes the sequential nature be to define
semantics, not to implement the code. I think that's probably
appropriate here as well.
e
The point of passing i= is to allow extension in the future to
possible per-user keying. You wouldn't do this in DNS, but another
protocol should be able to handle it easily.
eric
--On May 31, 2006 2:45:30 PM -0700 Jim Fenton <[EMAIL PROTECTED]>
wrote:
Section 3.6 gives an abstract defi
1. agenda bashing
2. open issues (see attached)
3. AOB
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003648.html
talk to ya in about 15
Unresolved from last time, from Barry's notes:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003720.html
Issue 1264: "(proposed fingerprint tag de
...is here [1]. I'll summarise later.
Due to various peoples' schedules it seems like it
might be a good idea to have a meeting next Monday,
June 5th (usual time I guess, 1500 UTC, 1600 Dublin,
1100 New York) instead of (or as well as) the one
planned for this day week.
Is that a problem for an
There should be a security consideration mentioning an unintended
consequence when a different entity controls sub-domains of a high
level domain. This could be viewed as an ICANN, ARIN, APNIC, LACNIC,
AfricNIC, RIPE NCC, and DENIC consideration advice. RFC1591 makes
the following stateme
Thanks Doug,
Douglas Otis wrote:
There should be a security consideration mentioning an unintended
consequence when a different entity controls sub-domains of a high level
domain. This could be viewed as an ICANN, ARIN, APNIC, LACNIC,
AfricNIC, RIPE NCC, and DENIC consideration advice. RFC1
On Thu, 1 Jun 2006, Douglas Otis wrote:
There should be a security consideration mentioning an unintended consequence
when a different entity controls sub-domains of a high level domain. This
could be viewed as an ICANN, ARIN, APNIC, LACNIC, AfricNIC, RIPE NCC,
Could you explain what the ip
On Jun 1, 2006, at 11:33 AM, william(at)elan.net wrote:
On Thu, 1 Jun 2006, Douglas Otis wrote:
There should be a security consideration mentioning an unintended
consequence when a different entity controls sub-domains of a high
level domain. This could be viewed as an ICANN, ARIN, APNIC
Stephen Farrell wrote:
>
> Thanks Doug,
>
> Douglas Otis wrote:
>> There should be a security consideration mentioning an unintended
>> consequence when a different entity controls sub-domains of a high
>> level domain
>> -Doug
>
> Eliot, can you raise this as a new issue as discussed at the
>
Doug,
Just so that I can understand clearly,
TLD offers signing ability to those who don't want to develop or buy
their own.
So bar.com offers to sign for [EMAIL PROTECTED]
However by bringing cetificated messages frm [EMAIL PROTECTED] you are assigning
a reputation to that signature that DKIM p
At 10:19 AM -0700 6/1/06, Douglas Otis wrote:
: Keys published by common higher-level domains
:
: Although TLD managers are trustees for the delegated domain, DKIM
: introduces a security concern unrelated to domain delegation.
: Currently there are no contractual obligations barring gTLD, ccTLD,
Doug,
Thanks for the clarification, so an assertion for subdomains that can
"opt out" of parent signing systems so that [EMAIL PROTECTED] is
authenticated with sig and [EMAIL PROTECTED] is not?
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PR
On Jun 1, 2006, at 11:57 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Just so that I can understand clearly, TLD offers signing ability
to those who don't want to develop or buy their own.
So bar.com offers to sign for [EMAIL PROTECTED]
No.
Imagine a TLD wants to promote use of c
On Jun 1, 2006, at 12:28 PM, Paul Hoffman wrote:
At 10:19 AM -0700 6/1/06, Douglas Otis wrote:
: Keys published by common higher-level domains
:
: Although TLD managers are trustees for the delegated domain, DKIM
: introduces a security concern unrelated to domain delegation.
: Currently there
On Jun 1, 2006, at 12:39 PM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Doug,
Thanks for the clarification, so an assertion for subdomains that can
"opt out" of parent signing systems so that [EMAIL PROTECTED] is
authenticated with sig and [EMAIL PROTECTED] is not?
Partial mitigation o
Douglas Otis wrote:
[]
My suggestion this morning was that if we include this in the security
considerations
at all, that we just lift it from the -threats draft since that has
already been vetted.
Here's what's there now:
4.1.18. Key Publication by Higher Level Domain
In order to support
On Thu, 2006-06-01 at 15:02 -0700, Michael Thomas wrote:
> Higher level domains already have ultimate power over their
> subdomains: they could change the name server delegation for the
> domain or disenfranchise it entirely. So it is unlikely that a higher
> level domain would intentionally com
Douglas Otis wrote:
On Thu, 2006-06-01 at 15:02 -0700, Michael Thomas wrote:
Doug. I didn't write this. It was taken directly from the -threats draft.
Mike
Higher level domains already have ultimate power over their
subdomains: they could change the name server delegation for th
On Thu, 2006-06-01 at 17:39 -0700, Michael Thomas wrote:
> Doug. I didn't write this. It was taken directly from the -threats draft.
My apologies. I trimmed your email to just the critical sections. I
should have included your note that this was from the Threat draft.
-Doug
__
At 5:24 PM -0700 6/1/06, Douglas Otis wrote:
. . .without additional regulatory clarification or
policy changes that might impact existing agreements.
The DKIM WG making DNS policy for ICANN should be considered out of
scope for the WG.
___
NOTE WEL
On Thu, 2006-06-01 at 17:52 -0700, Paul Hoffman wrote:
> At 5:24 PM -0700 6/1/06, Douglas Otis wrote:
> >. . .without additional regulatory clarification or
> >policy changes that might impact existing agreements.
>
> The DKIM WG making DNS policy for ICANN should be considered out of
> scope for
Douglas Otis wrote:
A DKIM implementer might also need to include DKIM related security
terms and conditions with private providers in conjunction with future
or existing services as related to the publishing of DKIM keys and their
use. This is a new security related element independent of norm
26 matches
Mail list logo
