I definitely can't imagine any sensible case in which the d= tags should be
different.  I do think the tag should still be specified in both the AS &
AMS though.  While not strictly necessary technically, it does make the
language in the spec & implementation details a bit cleaner.  So I would
suggest simply adding a line/section in the chain validation section of the
draft or somewhere else that says cv=fail(or invalid?) if the d= tags
aren't identical.  I think this is an entirely reasonable restriction.

=Gene

On Thu, May 4, 2017 at 3:44 PM, Brandon Long <[email protected]> wrote:

> When thinking about how to extract information from an arc chain, I was
> wondering at the "owner" of a section of the chain.
>
> Theoretically, that's the ADMD.  A single hop, however, has three separate
> domain ownerships, the srv_id from the AAR, and the d= field from the AS
> and AMS.
>
> Our current implementation uses google.com for the d= field, and we have
> three different srv_id's for different pools that serve different
> purposes.  That said, the srv_id has no "validation" except for by the key
> signature, so d= seems like a stronger "owner".
>
> Except, the AMS and AS can have separate selectors and domains.  I'm not
> sure if that's useful or desirable.  I'm tempted to only consider a chain
> valid if the domains are the same, and I guess not care if the selectors
> are.
>
> Should we require them to be the same?  If we do, should they only be
> specified once?
>
> For changing algorithms, I guess s would be different, along with a,
> though I would think you would need a separate set of headers for the hop
> for each a in transition...
>
> So:
> Should we require d= to be the same?  Should we specify it only once?  If
> not, why not?
>
> Brandon
>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to