Re: [Uta] Updated MTA-STS & TLSRPT Drafts

[Daniel Margolis <[e-mail]>]

Thanks. Easy fixes. Done in -19:
https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/.

On Wed, May 23, 2018 at 10:15 AM Viktor Dukhovni <[e-mail]>
wrote:

> [ Accidentally sent to just uta-chairs the other day, fixed, sorry ]
>
> > On May 21, 2018, at 7:38 PM, James Cloos <[e-mail]> wrote:
> >
> > id> Note that in all such cases, the policy endpoint ("https://mta-
> > id> sts.user.example/.well-known/mta-sts.txt" in this example) must still
> > id> present a certificate valid for the Policy Domain ("user.example"),
> > id> and not for that of the provider ("provider.example").
> >
> > Should that be "mta-sts.user.example" vs "mta-sts.provider.example"?
> >
> > As is, it gives the impression that the policy host ought to provide a
> > cert for the policy domain rather than for itself.
>
> Agreed.   A fix might be: s/Policy Domain/Policy Host/
>
> I should have noticed a few other editorial issues earlier:
>
> 1. OLD:
>
>                        If the number of resulting records is not
>   one, senders MUST assume the recipient domain does not have an
>   available MTA-STS policy and skip the remaining steps of policy
>   discovery.  (Note that lack of an available policy does not signal
>   opting out of MTA-STS altogether if the sender has a previously
>   cached policy for the recipient domain, as discussed in Section 5.1,
>   "Policy Application Control Flow".)
>
>   NEW:
>
>
>                        If the number of resulting records is not
>   one, senders MUST assume the recipient domain does not have an
>   available MTA-STS policy and skip the remaining steps of policy
>   discovery.  (Note that absence of a usable TXT record is not
>   by itself sufficient to remove the sender's previously
>   cached policy for the recipient domain, as discussed in Section 5.1,
>   "Policy Application Control Flow".)
>
> 2. OLD:
>
>    Thus for a Policy Domain of "example.com" the path is
>    "https://mta-sts.example.com/.well-known/mta-sts.txt".
>
>   NEW: s/path/full URL/
>
> 3. OLD (possible confusion as to which should not be expired):
>
>   The certificate presented by the receiving MTA MUST chain to a root
>   CA that is trusted by the sending MTA and be non-expired.
>
>   NEW:
>
>   The certificate presented by the receiving MTA MUST not be expired,
>   and must chain to a root CA that is trusted by the sending MTA.
>
> --
>         Viktor.
>
>
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>