Subject: [dmarc-ietf] Partial Review of: draft-ietf-dmarc-arc-protocol-16

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Jul 2018 16:59:48 -0700

Review of:    draft-ietf-dmarc-arc-protocol-16 (partial)
Date:         17 Jul 18
Reviewed by:  D. Crocker

Summary:

I gave a review for -14 and will skip the pro forma functional summary.

I reviewed the initial portions of the -16 draft and see some basic and 
pervasive language problems that are serious enough to make it likely 
that a reader will misunderstand core ARC concepts.  I've suggested 
alternative language, where I could.

d/

Detail:

> Abstract
> 
>    The Authenticated Received Chain (ARC) protocol allows Internet Mail
>    Handlers to attach assertions of message authentication state to
>    individual messages.  As messages traverse ARC-enabled Internet Mail
>    Handlers, additional ARC assertions can be attached to messages to
>    form ordered sets of ARC assertions that represent authentication
>    state along each step of message handling paths.
> 
>    ARC-enabled Internet Mail Handlers can process sets of ARC assertions
>    to inform message disposition decisions, to identify Internet Mail
>    Handlers that might break existing authentication mechanisms, and to
>    convey original authentication state across trust boundaries.

My review of -14 noted problems with the abstract.  While there have 
been some changes, the Abstract remains too... abstract.  While the 
current text is better it really does not provide simple, direct 
statements about the problem(s) ARC is addressing nor the solution or 
benefit that it enables.

Text like this needs to be written for people who are not trained in 
theoretical computer science and are not already deeply enmeshed in this 
work.

For convenience, here's what I wrote in the -14 review, for a suggested 
change:

>> I suggest adding this existing, excellent sentence from the Intro:
>> 
>>      ARC provides an authenticated "chain of custody" for a message,
>>      allowing each entity that handles the message to see what entities
>>      handled it before, and to see what the authentication status of the
>>      message was at each step in the handling.
>> 
>> (I added 'authenticated'.)

Note also that while typical discussion of ARC refers to it as 
establishing a chain of custody, no language like that is in the 
Abstract.  I think that's a serious omission.

Consider the 'general concepts' section, below and the sub-topics.  Note 
that nothing like 'assertions of message authentication state' shows up 
there.

> Table of Contents
> 
>    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
>    2.  General Concepts  . . . . . . . . . . . . . . . . . . . . . .   4
>      2.1.  Evidence  . . . . . . . . . . . . . . . . . . . . . . . .   5
>      2.2.  Custody . . . . . . . . . . . . . . . . . . . . . . . . .   5
>      2.3.  Chain of Custody  . . . . . . . . . . . . . . . . . . . .   5
>      2.4.  Validation of Chain of Custody  . . . . . . . . . . . . .   5
>    3.  Terminology and Definitions . . . . . . . . . . . . . . . . .   5
>      3.1.  ARC Set . . . . . . . . . . . . . . . . . . . . . . . . .   6
>      3.2.  Authenticated Received Chain (ARC)  . . . . . . . . . . .   6
>      3.3.  Sealer  . . . . . . . . . . . . . . . . . . . . . . . . .   7
>      3.4.  Validator . . . . . . . . . . . . . . . . . . . . . . . .   7
>      3.5.  Imported ABNF Tokens  . . . . . . . . . . . . . . . . . .   7
>      3.6.  Common ABNF Tokens  . . . . . . . . . . . . . . . . . . .   7
>    4.  Protocol Elements . . . . . . . . . . . . . . . . . . . . . .   7
>      4.1.  ARC Headers . . . . . . . . . . . . . . . . . . . . . . .   7
>        4.1.1.  ARC-Authentication-Results (AAR)  . . . . . . . . . .   8
>        4.1.2.  ARC-Message-Signature (AMS) . . . . . . . . . . . . .   8
>        4.1.3.  ARC-Seal (AS) . . . . . . . . . . . . . . . . . . . .   9
>      4.2.  ARC Set . . . . . . . . . . . . . . . . . . . . . . . . .  10
>        4.2.1.  Instance Tags . . . . . . . . . . . . . . . . . . . .  10
>      4.3.  Authenticated Received Chain  . . . . . . . . . . . . . .  11
>      4.4.  Chain Validation Status . . . . . . . . . . . . . . . . .  11
>    5.  Protocol Actions  . . . . . . . . . . . . . . . . . . . . . .  12
>      5.1.  Sealer Actions  . . . . . . . . . . . . . . . . . . . . .  12
>        5.1.1.  Header Fields To Include In ARC-Seal Signatures . . .  13
>        5.1.2.  Marking and Sealing "cv=fail" (Invalid) Chains  . . .  13
>        5.1.3.  Only One Authenticated Received Chain Per Message . .  13
>        5.1.4.  Broad Ability to Seal . . . . . . . . . . . . . . . .  14
>        5.1.5.  Sealing is Always Safe  . . . . . . . . . . . . . . .  14
>        5.1.6.  Signing vs Sealing  . . . . . . . . . . . . . . . . .  14
>      5.2.  Validator Actions . . . . . . . . . . . . . . . . . . . .  14
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019                [Page 2]
> 
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>        5.2.1.  All Failures Are Permanent  . . . . . . . . . . . . .  16
>        5.2.2.  Responding to ARC Validation Failures During the SMTP
>                Transaction . . . . . . . . . . . . . . . . . . . . .  16
>      5.3.  Result of Validation  . . . . . . . . . . . . . . . . . .  16
>    6.  Communication of Validation Results . . . . . . . . . . . . .  17
>    7.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  17
>      7.1.  Communicate Authentication Results Across Trust
>            Boundaries  . . . . . . . . . . . . . . . . . . . . . . .  17
>        7.1.1.  Message Scanning Services . . . . . . . . . . . . . .  17
>        7.1.2.  Multi-tier MTA Processing . . . . . . . . . . . . . .  18
>        7.1.3.  Mailing Lists . . . . . . . . . . . . . . . . . . . .  18
>      7.2.  Inform Message Disposition Decisions  . . . . . . . . . .  18
>        7.2.1.  DMARC Local Policy Overrides  . . . . . . . . . . . .  19
>        7.2.2.  DMARC Reporting . . . . . . . . . . . . . . . . . . .  19
>    8.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  20
>    9.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
>      9.1.  Increased Header Size . . . . . . . . . . . . . . . . . .  20
>      9.2.  DNS Operations  . . . . . . . . . . . . . . . . . . . . .  21
>      9.3.  Message Content Suspicion . . . . . . . . . . . . . . . .  21
>      9.4.  Message Sealer Suspicion  . . . . . . . . . . . . . . . .  21
>      9.5.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  22
>    10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
>      10.1.  Email Authentication Results Names Registry Update . . .  22
>      10.2.  Email Authentication Methods Registry Update . . . . . .  22
>      10.3.  Definitions of the ARC header fields . . . . . . . . . .  23
>    11. Experimental Considerations . . . . . . . . . . . . . . . . .  23
>      11.1.  Success Consideration  . . . . . . . . . . . . . . . . .  24
>      11.2.  Failure Considerations . . . . . . . . . . . . . . . . .  24
>      11.3.  Open Questions . . . . . . . . . . . . . . . . . . . . .  24
>        11.3.1.  Value of the ARC-Seal (AS) Header  . . . . . . . . .  24
>        11.3.2.  DNS Overhead . . . . . . . . . . . . . . . . . . . .  24
>        11.3.3.  What Trace Information is Valuable . . . . . . . . .  25
>    12. Implementation Status . . . . . . . . . . . . . . . . . . . .  25
>      12.1.  GMail test reflector and incoming validation . . . . . .  26
>      12.2.  AOL test reflector and internal tagging  . . . . . . . .  26
>      12.3.  dkimpy . . . . . . . . . . . . . . . . . . . . . . . . .  27
>      12.4.  OpenARC  . . . . . . . . . . . . . . . . . . . . . . . .  27
>      12.5.  Mailman 3.x patch  . . . . . . . . . . . . . . . . . . .  27
>      12.6.  Copernica/MailerQ web-based validation . . . . . . . . .  28
>      12.7.  Rspamd . . . . . . . . . . . . . . . . . . . . . . . . .  28
>      12.8.  PERL MAIL::DKIM module . . . . . . . . . . . . . . . . .  29
>      12.9.  PERL Mail::Milter::Authentication module . . . . . . . .  29
>      12.10. Sympa List Manager . . . . . . . . . . . . . . . . . . .  29
>      12.11. Oracle Messaging Server  . . . . . . . . . . . . . . . .  30
>      12.12. MessageSystems Momentum and PowerMTA platforms . . . . .  30
>      12.13. Exim . . . . . . . . . . . . . . . . . . . . . . . . . .  30
>    13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  30
>      13.1.  Normative References . . . . . . . . . . . . . . . . . .  31
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019                [Page 3]
> 
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>      13.2.  Informative References . . . . . . . . . . . . . . . . .  32
>      13.3.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  33
>    Appendix A.  Appendix A - Design Requirements . . . . . . . . . .  33
>      A.1.  Primary Design Criteria . . . . . . . . . . . . . . . . .  34
>      A.2.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . .  34
>    Appendix B.  Appendix B - Example Usage . . . . . . . . . . . . .  34
>    Appendix C.  Acknowledgements . . . . . . . . . . . . . . . . . .  34
>    Appendix D.  Comments and Feedback  . . . . . . . . . . . . . . .  35
>    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35
> 
> 1.  Introduction
> 
>    The utility of widely deployed email authentication technologies such
>    as Sender Policy Framework (SPF) [RFC7208] and DomainKeys Identified
>    Mail (DKIM) [RFC6376] is impacted by the processing of Internet Mail
>    by intermediate handlers.  This impact is thoroughly documented in
>    the defining documents for SPF and DKIM and further discussed in
>    [RFC6377] and [RFC7960].
> 
>    The utility of technologies that build upon SPF and DKIM (such as
>    DMARC [RFC7489]) is similarly impacted by intermediate handlers.  The
>    disruption of authentication mechanisms for legitimate messages by
>    intermediate handlers can impact all aspects of Internet Mail -
>    message authors, message recipients, and even the intermediary
>    handler itself.

editorial, to simplify and reduce redundancies, replace the above paragraph:

      DMARC [RFC7489] relies on mechanisms such as SPF and DKIM. So 
their failures that are caused by the actions of intermediate handlers 
can in turn cause legitimate mail to be incorrectly rejected or misdirected.

(drop the 'all aspects' sentence.)

> 
>    Authenticated Received Chain (ARC) creates a mechanism for individual
>    Internet Mail Handlers to add their authentication processing results
>    to a message's ordered set of processing results.  ARC encapsulates
>    processing results in a DKIM signature derivative to grant other
>    handlers the ability to verify the authenticity of the individual
>    processing results as well as the aggregate set and sequence of
>    results.
> 
>    Ordered sets of processing results can be used by ARC-enabled
>    Internet Mail Handlers to inform message handling disposition, to
>    identify where alteration of message content might have occurred, and
>    to provide additional trace information for use in understanding
>    message handling paths.
> 
> 2.  General Concepts
> 
>    ARC is loosely based on concepts from evidence collection.  Evidence
>    is usually collected, labeled, stored, and transported in specific
>    ways to preserve the state of evidence and to document all processing
>    steps.

I think this means based on 'legal' concepts of evidence, really.  While 
it theoretically should apply to all handling of anything one might call 
evidence, this really is drawing from the legal world, isn't it?

> Andersen, et al.        Expires January 18, 2019                [Page 4]
> 
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
> 2.1.  Evidence

A term like "authentication state" needs to be defined or at least 
explained, given its importance to the text here.

There's an argument one can make that the term is actually 
inappropriate. I don't think this activity has a concept of an 
authentication state machine.  One might invent such a thing and might 
even be useful, but it hasn't been done, has it?

While it's not as verbally tight, I suspect language more like 
"validation of message authentication information" or "authentication 
assessment" or "authentication validity" are both more intuitive and 
correct.

(BTW, this might be why 'evidence' is a problematic term, since, really, 
assertions about prior validations constitute a kind of hear-say; it's 
second-hand information, not direct, objective 'evidence'.  Though it 
might be a bit facile, an alternative choice could be 'testimony'...)

>    In ARC's situation, the "evidence" is a message's authentication
>    state at any point along the delivery path between origination and
>    final delivery.  Authentication state can change when intermediate
>    handlers modify message content (headers and/or body content), route
>    messages through unforeseen paths, or change envelope information.
> 
>    The authentication state of a message is determined upon receipt of a
>    message and documented in the Authentication-Results header field(s).
>    ARC extends this mechanism to survive transit through intermediary
>    ADMDs.
> 
> 2.2.  Custody
> 
>    "Custody" refers to when an ARC-enabled Internet Mail Handler
>    processes a message.  When a handler takes custody of a message, the
>    handler becomes a Custodian and attaches their own evidence
>    (authentication state upon receipt) to the message.  Evidence is
>    added in such a way so that future handlers can verify the
>    authenticity of both evidence and custody.

Custody refers to when any Internet Mail handler processes a message.

(Applicability of the term does not depend on ARC, or at least it 
shouldn't.)

ARC provides a means of /authenticating/ custody.

*** MAJOR ***

ARC does /not/ allow verifying the authenticity of earlier 'evidence', 
other than the evidence of handling signatures.  That is, assertions 
about prior validations are not really 'evidence'.

This is a persistent point of confusion about ARC and I consider it 
serious.

Using ARC requires developing trust in the handlers that make these ARC 
assertions of earlier validity.  This is quite different from a later 
handler 'verifying' that validity, since it can't.

***   ***

> 2.3.  Chain of Custody
> 
>    The "chain of custody" of ARC is the entire set of evidence and
>    custody that travels with a message.
> 
> 2.4.  Validation of Chain of Custody
> 
>    Any ARC-enabled Internet Mail Handler can validate the entire set of
>    evidence and custody to yield a valid Chain of Custody.  If the

No, it can validate who made what assertions -- and in what order -- not 
that the assertions were valid.

>    evidence-supplying Custodians can be trusted, then the validated
>    Chain of Custody describes the (possibly changing) authentication
>    state as the message traveled through various Custodians.

It can validate statements about authentication, not the actual 
state/correctness of those statements.

>    Even though a message's authentication state might have changed, the
>    validated chain of custody can be used to determine if the changes
>    (and the Custodians responsible for the changes) can be tolerated.
> 
> 3.  Terminology and Definitions
> 
>    This section defines terms used in the rest of the document.
> 
>    Readers should to be familiar with the contents, core concepts, and
>    definitions found in [RFC5598].  The potential roles of
>    intermediaries in the delivery of email are directly relevant.

The term 'intermediaries' does not appear in 5598.  Nor does a term like 
'intermediate handler'.  Worse, the document here probably needs a term 
that covers both regular MTAs AND delivery/re-posting agents such as 
mailing lists, which is what RFC 5598 calls 'mediators'.

I was going to suggest just saying 'handler' or the like but RFC 5598 
uses the word differently.

So the best I can suggest from RFC 5598 is 'transit service' which ought 
to cover both regular MTA service and upper-level services like mailing 
lists.

> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019                [Page 5]
> 
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    Language, syntax (including some ABNF constructs), and concepts are
>    imported from DKIM [RFC6376].  Specific references to DKIM are made
>    throughout this document.  The following terms are imported from
>    [RFC5598]:
> 
>    o  ADministrative Management Domain (ADMD), Section 2.3
> 
>    o  Message Transfer Agents (MTA), Section 4.3.2
> 
>    o  Message Submission Agent (MSA), Section 4.3.1
> 
>    o  Message Delivery Agent (MDA), Section 4.3.3
> 
>    Internet Mail Handlers process and deliver messages across the
>    Internet and include MSAs, MTAs, MDAs, gateways, and mailing lists.
> 
>    Syntax descriptions use Augmented BNF (ABNF) [RFC5234] and [RFC7405].
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.  These words may also appear in this
>    document in lower case as plain English words, absent their normative
>    meanings.
> 
> 3.1.  ARC Set
> 
>    Section 4.1 introduces three (3) ARC header fields.  Together, the 3

    fields
    ->
    fields that are added to a message by an ARC transit system.

(That is, an arc set is a specific instance, not the abstraction that 
defines those 3 fields.)

>    header fields compose a single "ARC Set".  An ARC Set provides the
>    means for an Internet Mail Handler to attach authentication state to
>    a message in a manner that can be verified by future handlers.  A
>    single message can contain multiple ARC Sets.
> 
>    In General Concept terms, an ARC Set represents Evidence and Custody.
> 
> 3.2.  Authenticated Received Chain (ARC)
> 
>    The complete sequence of ARC Sets attached to a message is called the
>    Authenticated Received Chain.  An Authenticated Received Chain is a
>    recording of individual authentication states as a message traverses
>    through ARC-participating ADMDs.

   "The complete sequence"

Hmmm...  /What/ complete sequence?  Do you mean the complete sequence 
attached to a message at any one point during transit?  Or do you mean 
the complete sequence attached to the message after final delivery?  Or...?

(On reflection, I suggest calling a sequence under development -- that 
is, one being built during transit -- a 'partial sequence' and save 
'complete sequence' to refer to what exists after final delivery.)

> 
>    The first attachment of an ARC Set to a message causes an
>    Authenticated Received Chain to be created.  Additional attachments
>    of ARC Sets cause the Authenticated Received Chain to be extended.
> 
> 
> 
> 
> 
> Andersen, et al.        Expires January 18, 2019                [Page 6]
> 
> Internet-Draft                ARC-Protocol                     July 2018
> 
> 
>    In General Concept terms, an Authenticated Received Chain represents
>    Chain of Custody.
> 
> 3.3.  Sealer
> 
>    A Sealer is an Internet Mail Handler that attaches a complete and
>    valid ARC Set to a message.
> 
>    In General Concept terms, a Sealer adds Evidence and proof of Custody
>    to the Chain of Custody.

Might be worth explaining why the term 'signer' isn't sufficient for 
this, since a reader will likely think it the more natural choice.

> 
> 3.4.  Validator
> 
>    A Validator is an ARC-enabled Internet Mail Handler that evaluates an
>    Authenticated Received Chain for validity and content.  The process
>    of evaluation of the individual ARC Sets that compose an
>    Authenticated Received Chain is described in Section 5.2.
> 
>    In General Concept terms, a Validator inspects the Chain of Custody
>    to determine the content and validity of individual Evidence supplied
>    by Custodians.
> 
> 3.5.  Imported ABNF Tokens
> 
>    The following ABNF tokens are imported:
> 
>    o  tag-list ([RFC6376] section 3.2)
> 
>    o  authres-payload ([I-D-7601bis] section 2.2)
> 
>    o  cfws ([RFC5322] section 3.2.2)
> 
> 3.6.  Common ABNF Tokens
> 
>    The following ABNF tokens are used elsewhere in this document:
> 
>    position = 1*2DIGIT ; 1 - 50
>    instance = [CFWS] %s"i" [CFWS] "=" [CFWS] position [CFWS] ";"
>    chain-status = ("none" / "fail" / "pass")
>    seal-cv-tag = %s"cv" [CFWS] "=" [CFWS] chain-status

Over the years, I've come to believe that good ABNF formatting aids 
readers quite a bit.   So I suggest something like:

     position      =  1*2DIGIT                             ; 1 - 50
     instance      =  [CFWS] %s"i" [CFWS] "="
                      [CFWS] position [CFWS] ";"
     chain-status  =  ("none" / "fail" / "pass")
     seal-cv-tag   =  %s"cv" [CFWS] "="
                      [CFWS] chain-status

<< stopped here. /d >>

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Seth Blank <[email-masked]>
Date: Wed, 18 Jul 2018 10:37:25 -0700

On Tue, Jul 17, 2018 at 4:59 PM, Dave Crocker <[email-masked]> wrote:

> pervasive language problems that are serious enough to make it likely that
> a reader will misunderstand core ARC concepts.  I've suggested alternative
> language, where I could.
>
> d/
>

Thanks for this, and keep them coming.

Your review of -14 was heavily folded into the rewrite of -15, but I don't
believe anyone ever said this on list. That was an oversight.

> My review of -14 noted problems with the abstract.  While there have been
> some changes, the Abstract remains too... abstract.  While the current text
> is better it really does not provide simple, direct statements about the
> problem(s) ARC is addressing nor the solution or benefit that it enables.
>

The abstract's been rewritten numerous times, including with the help of
the Chairs and AD. I do like your suggestion, but would appreciate hearing
if other members of the working group concur with your guidance.

> establishing a chain of custody, no language like that is in the Abstract.
> I think that's a serious omission.
>

This is a fair point, but I think discussing custody in the abstract has
led us down less clear paths previously. Raising these issues in a General
Concepts section seems to have clarified and simplified the document.

editorial, to simplify and reduce redundancies, replace the above paragraph:
>
>      DMARC [RFC7489] relies on mechanisms such as SPF and DKIM. So their
> failures that are caused by the actions of intermediate handlers can in
> turn cause legitimate mail to be incorrectly rejected or misdirected.
>

That works.

>> evidence, this really is drawing from the legal world, isn't it?
The original text here referenced legal concepts, but it didn't add
anything valuable and was stricken for the sake of simplicity and clarity.

> explained, given its importance to the text here.

Agreed.

> There's an argument one can make that the term is actually inappropriate.
> I don't think this activity has a concept of an authentication state
> machine.  One might invent such a thing and might even be useful, but it
> hasn't been done, has it?
>
> While it's not as verbally tight, I suspect language more like "validation
> of message authentication information" or "authentication assessment" or
> "authentication validity" are both more intuitive and correct.
>
> second-hand information, not direct, objective 'evidence'.  Though it might
> be a bit facile, an alternative choice could be 'testimony'...)
>

Also agreed. We'll review and suggest language; I'm leaning towards
"authentication assessment."

> ARC provides a means of /authenticating/ custody.

The General Concept Terms exist to provide a framework for those unfamiliar
with ARC to understand it. While you are correct that any handler has
Custody irrespective of ARC, while setting up the framework for those new
to ARC we're only specifically talking about the ARC representation of
custody. Removing the reference to ARC makes this less clear to a new
reader.

You are correct that ARC provides a means of authenticating custody of a
message; we will look at folding this language into section 2.4, I believe
it is more clear than the current text.

> other than the evidence of handling signatures.  That is, assertions about
> prior validations are not really 'evidence'.
>

I concur with your final thought, but am unaware of this being a point of
confusion. This is explicitly called out in Security Considerations 9.4.

> that the assertions were valid.

Yes. That was the intent of this language, we'll clarify.

> state/correctness of those statements.

Correct. I believe this clarifies itself when we change "authentication
state" to "authentication assessment" and have that properly defined
earlier in the document.

> mailing lists, which is what RFC 5598 calls 'mediators'.

This is why "Internet Mail Handler" was defined in section 3. However, its
prominence appears lost due to formatting. We'll fix that.

> fields -> fields that are added to a message by an ARC transit system.
>
>

Fixed.

> attached to a message at any one point during transit?  Or do you mean the
> complete sequence attached to the message after final delivery?  Or...?
>
> (On reflection, I suggest calling a sequence under development -- that is,
> one being built during transit -- a 'partial sequence' and save 'complete
> sequence' to refer to what exists after final delivery.)
>

I think this is clarified by simply stating "the complete sequence of ARC
Sets attached to the message at any given time"

> Might be worth explaining why the term 'signer' isn't sufficient for this,
> since a reader will likely think it the more natural choice.
>

This is why 5.1.6 exists; in general concepts this nuance is confusing.

Over the years, I've come to believe that good ABNF formatting aids readers
> quite a bit.   So I suggest something like:
>

Yes, there are several formatting issues that need to be fixed in the final
XML.

Thanks,

Seth

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2018 14:10:28 -0400

> if other members of the working group concur with your guidance.

Dave, do you have sample text to suggest?

> Concepts section seems to have clarified and simplified the document.

I haven't ever felt comfortable with the references to terminology like
"chain of custody".  In particular, that term typically references
something that is handled by one party at a time and critically insulated
against tampering, but (a) it's not clear to me that the chain is complete
(non-participants do technically handle the thing of interest) and (b) the
custody of what, exactly?

If we want to keep that language or general concept, I think we need to be
clear what the payload we're discussing actually is.  It's not simply "the
body" or "the message"; there's more to it than that.  Is it "everything
the latest ARC-Seal covers", for example?

-MSK