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
From:
Carsten Bormann <cabo@xxxxxxx>
Date: Monday, May 27, 2024 at 22:58
To: Magnus Nyström <magnusn@xxxxxxxxx>
Cc: 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: [secdir] Re: [Last-Call] Secdir last call review of draft-ietf-asdf-sdf-18
Hi Magnus,
thank you for this review.
A couple of quick comments to your specific items:
> - The Security Considerations section mentions the possible need for
> confidentiality of an SDF model ("There may be confidentiality requirements on
> SDF models, both on their content and on the fact that a specific model is used
> in a particular Thing or environment"). Couldn't there also be a need for
> integrity/authenticity of a given SDF model? The document is silent on this.
Actually, we use (twice) a much stronger word: provenance.
This combines integrity and authentication with some appraisal (or at least policy) of how the data from the authenticated source can be used.
We are not pointing to a specific mechanism here, as that is likely to be ecosystem specific.
We could, however, explicitly remind the reader that provenance has integrity and authenticity as a prerequisite.
A minimal change in:
https://github.com/ietf-wg-asdf/SDF/pull/157
> -
> Related to the previous point, was it ever discussed to allow for an integrity
> or authenticity value accompanying or being part of an SDFThing instance?
Given the role of SDF as a hub format, SDF needs to be agnostic to the kinds of integrity protection and authenticity that is used with it. Embedding a model into an SDFThing instance is certainly one way to provide this information in a way that could make
use of protection already available for the Thing in general. It is more likely, though, that a Thing will provide a reference to its model that is stored somewhere else. That would be described in a model using an extension such as that proposed in [1]
(if it is offered as an affordance from an instance) or possibly [2]. (These are likely to become WG documents after the current rechartering.)
[1]:
https://datatracker.ietf.org/doc/draft-bormann-asdf-sdftype-link/
[2]: https://datatracker.ietf.org/doc/draft-laari-asdf-relations/
Grüße, Carsten
_______________________________________________
secdir mailing list -- secdir@xxxxxxxx
To unsubscribe send an email to secdir-leave@xxxxxxxx
wiki: https://wiki.ietf.org/group/secdir/SecDirReview
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
