Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>> Dave Crocker wrote:
>>> At best, the benefit of having s= defined now depends on whether
>>> people are setting s=email now. Are they? Should they? How will
>>> they know?
>>
>> Are they: I haven't seen a key with s=email yet, although I'll have
Ahh. Indeed.
Yes, having those in the DNS record always struck me as oddly unnecessary.
d/
Jim Fenton wrote:
> Dave Crocker wrote:
>>
>> Jim Fenton wrote:
>>> Dave Crocker wrote:
Jim Fenton wrote:
> Dave Crocker wrote: The current utility is that, while extensions
> can be added
Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>> Dave Crocker wrote:
>>> Jim Fenton wrote:
Dave Crocker wrote: The current utility is that, while extensions
can be added any time, constraints need to be added up front. So
if another service besides email wanted to use DKIM and its k
Jim Fenton wrote:
> Dave Crocker wrote:
I don't understand. What is there in the DKIM signing protocol that
requires the author adress to "follow suit"?
>>> Not in the signing protocol, but in ADSP. If an email with a From
>>> address of, say, [EMAIL PROTECTED] is signed with
Dave Crocker wrote:
>
>
> Jim Fenton wrote:
The last paragraph also suggests the use of different sub-domains
for d=, but does not point out that the author address must also
follow suit, otherwise the message may not be seen to be in
compliance with Signing Policy.
>>> I don
Jim Fenton wrote:
> Dave Crocker wrote:
>> Jim Fenton wrote:
>>> Dave Crocker wrote: The current utility is that, while extensions can be
>>> added any time, constraints need to be added up front. So if another
>>> service besides email wanted to use DKIM and its key infrastructure, it
>>> wo
Jim Fenton wrote:
> Dave Crocker wrote:
>> At best, the benefit of having s= defined now depends on whether
>> people are setting s=email now. Are they? Should they? How will
>> they know?
>
> Are they: I haven't seen a key with s=email yet, although I'll have to
> admit that I don't look
Jim Fenton wrote:
>>> The last paragraph also suggests the use of different sub-domains for
>>> d=, but does not point out that the author address must also follow
>>> suit, otherwise the message may not be seen to be in compliance with
>>> Signing Policy.
>> I don't understand. What is there
Jim noticed:
> Are you perhaps confusing s= in the signature (selector name) with s=
> in the key record (service type)? It's the latter that we're
discussing.
Yep, I must be confusing those.
Is it too late to change the letter?
___
NOTE WELL: This
J D Falk wrote:
> Jim Fenton wrote:
>
>
>>> At best, the benefit of having s= defined now depends on whether
>>> people are setting s=email now. Are they? Should they? How will
>>> they know?
>>>
>> Are they: I haven't seen a key with s=email yet, although I'll have
>> to admit that I
At 07:08 21-03-2008, [EMAIL PROTECTED] wrote:
> In particular, great care MUST be taken when
>releasing memory pages to the operating system to ensure that private
>key information is not disclosed to other processes.
>Should be changed to
>If one does not clearly understand how computers
> [X] ADSP - Administrative Domain Signing Practices (**)
> [X] ADSP - Author Domain Signing Practices
> [X] ASP - Author Signing Practices\
But mostly, I want to see this issue closed so I can start telling
people what A(D)SP is /for/ rather than what it's likely to be called.
Bill Oxley wrote:
> In particular, great care MUST be taken when
>releasing memory pages to the operating system to ensure that
private
>key information is not disclosed to other processes.
> Should be changed to
> If one does not clearly understand how computers work you MUST NOT try
> to
Jim Fenton wrote:
>> At best, the benefit of having s= defined now depends on whether
>> people are setting s=email now. Are they? Should they? How will
>> they know?
>
> Are they: I haven't seen a key with s=email yet, although I'll have
> to admit that I don't look at a lot of selectors.
I
On Mar 24, 2008, at 10:00 PM, Jim Fenton wrote:
> Section 4.3, "The Selector Construct", talks quite a bit about
> identities for doing assessments. Other than the point that it
> makes in the section beginning NOTE:, none of this has anything to
> do with selectors. Furthermore, I consid
4.4. Verification
|After a message has been signed, any agent in the message transit
|path can verify the signature to determine that the signing identity
|took responsibility for the message.
This is a grossly inaccurate statement! Verification of a signature
_only_ indicates the domain IS re
3.1.4. Distinguish the core authentication mechanism from its
derivative uses
|An authenticated identity can be subject to a variety of processing
|policies, either ad hoc or standardized. The only semantics inherent
|to a DKIM signature is that the signer is asserting (some)
|responsibili
> It also limits the ability of an external party that has been
> delegated a key for a particular service to (mis)use that key for
> other, unauthorized services.
>
That's probably the best reason for it. In any event, this is surely
moot at this stage. Most protocols end up with unused or
On Mar 25, 2008, at 9:00 AM, Jim Fenton wrote:
> Dave Crocker wrote:
>>
>>
>> Jim Fenton wrote:
>>> Dave Crocker wrote:
>>>
You further seem to indicate that s= is not currently useful but
would be
if it listed other services. (I well might be misunderstanding
this
part
Mark Delany wrote:
> On Mar 24, 2008, at 10:30 PM, Jim Fenton wrote:
>
>> The current utility is that, while extensions can be added any time,
>> constraints need to be added up front.
>
>
> Okay, I'll bite. Why is this a good idea? By way of contrast, when an
> A RR is added to a DNS zone saying
Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>> Dave Crocker wrote:
>>
>>> You further seem to indicate that s= is not currently useful but
>>> would be
>>> if it listed other services. (I well might be misunderstanding this
>>> part
>>> of your text.) In any event, either the capability has cur
Dave Crocker wrote:
>
>
> Jim Fenton wrote:
>> Section 4.3, "The Selector Construct", talks quite a bit about
>> identities for doing assessments.
>
> Let's take care of the "quite a bit", just to make sure we are in sync
> about the relevant text.
>
> The first paragraph merely says that d=/i=
22 matches
Mail list logo
