[Last-Call] Re: [secdir] Secdir last call review of draft-ietf-asdf-sdf-18

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>(Unfortunately, RFC 4949 *uses* provenance once, but does not *define* it, maybe for similar reasons as here.)
Would be nice if it did.

 

> The term provenance is not exactly defined in Section 8 because it really doesn’t have to be:
+1

 

From: Carsten Bormann <cabo@xxxxxxx>
Date: Tuesday, May 28, 2024 at 12:43
To: Smith, Ned <ned.smith@xxxxxxxxx>
Cc: Magnus Nyström <magnusn@xxxxxxxxx>, secdir@xxxxxxxx <secdir@xxxxxxxx>, asdf@xxxxxxxx <asdf@xxxxxxxx>, draft-ietf-asdf-sdf.all@xxxxxxxx <draft-ietf-asdf-sdf.all@xxxxxxxx>, last-call@xxxxxxxx <last-call@xxxxxxxx>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-asdf-sdf-18

Hi Ned,

thanks for providing the citation and the thoughts about using this term.

For a current example of how the term is used in the IETF, please see [0].

[0]: https://www.ietf.org/archive/id/draft-lopez-opsawg-yang-provenance-02.html

(Unfortunately, RFC 4949 *uses* provenance once, but does not *define* it, maybe for similar reasons as here.)

Authentication and integrity protection are methods (or can be abstracted into objectives) that can be used to ascertain provenance.

The term provenance is not exactly defined in Section 8 because it really doesn’t have to be:
The text in question is about security considerations, not about defining a protocol for achieving or communicating provenance (which would be out of scope for this interchange format definition).

What the user of a information/interaction model really cares about is its provenance (and applicability), not how that is reliably communicated by way of authentication, integrity protection, endorsement, appraisal, policy etc.

When I said that provenance is a stronger word, I meant that this is really the objective that we desire to support by addressing those specific objectives.
I thought that mentioning that provenance implies authentication and integrity protection [1] would be enough to address the fact that these objectives/mechanisms are not otherwise mentioned in the security considerations.

[1]: https://github.com/ietf-wg-asdf/SDF/pull/157/files

Grüße, Carsten


> On 28. May 2024, at 20:25, Smith, Ned <ned.smith@xxxxxxxxx> wrote:
>
> The draft uses provenance without defining it. There is a definition in NIST SP800-53r5:
> “The chronology of the origin, development, ownership, location, and changes to a system or system component and associated data”.
>  It isn’t clear if the I-D authors intended this definition or something else. If this is the intended definition, then the NIST definition doesn’t specifically say “authentication”, “integrity”, or (attestation) “appraisal”. But if the authors intended these properties, they could have used those words directly rather than “provenance”. If they intended the NIST definition of provenance, they could site the NIST document.
>  -Ned

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux