In article
you write:
>-=-=-=-=-=-
>
>On Fri, Jul 27, 2018 at 11:15 AM, John R Levine wrote:
>>
>> I'd say that all signatures in a seal SHOULD have the same domain, to make
>> them easier to evaluate.
>>
>
>So the Usage Guide will (does?) say that. Earlier consensus was to keep
>that out of the
On Fri, Jul 27, 2018 at 11:15 AM, John R Levine wrote:
>
> I'd say that all signatures in a seal SHOULD have the same domain, to make
> them easier to evaluate.
>
So the Usage Guide will (does?) say that. Earlier consensus was to keep
that out of the normative document because a) it doesn't affec
On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote:
The ARC draft clearly says that every ARC header can be signed by
whatever domain you want.
Are you saying we should proscribe it, because its semantics are unclear?
I'd say that all signatures in a seal SHOULD have the same domain, to m
On Fri, Jul 27, 2018 at 10:24 AM, John Levine wrote:
> The ARC draft clearly says that every ARC header can be signed by
> whatever domain you want.
>
> I understand what that means technically, but I don't understand the
> semantics of an ARC set where the AMS and AS are signed by different
> do
This was just discussed in a thread with Jim Fenton last week (although
from the DNS angle).
The tl;dr is that we don't believe they'll ever be different, but there's
no technical reason to require d=/s= alignment between AS/AMS for the same
i=.
We can foresee places where separate signing domain
The ARC draft clearly says that every ARC header can be signed by
whatever domain you want.
I understand what that means technically, but I don't understand the
semantics of an ARC set where the AMS and AS are signed by different
domains.
R's,
John
___
