Garrett D'Amore wrote: > Bart Smaalders wrote: > >> Stephen Hahn wrote: >> >>> I am having difficulty formulating a use case where nested or >>> multiply >>> signed packages are needed, and in which the consumer makes different >>> decisions when distinct subsets of the signing entities cannot be >>> independently verified. Maybe someone has an example? >> >> >> Multiply signed packages are useful, as others have pointed out, to >> permit systems to require multiple signatures, or permit alternate >> signatures. >> >> The easiest way to do this is to omit all signatures from the >> hash; adding a new signature would then not invalidate previous ones. >> >> - Bart >> > The concern was that the meta data that would be added was also signed. > > Certainly the *contents*, as well as critical portions of meta data > (dependencies and anything else that might impact how the software is > installed or behavior) probably could be covered by a single hash. > > Other meta data (yes, OurBigEnterprise-IT-Dept blesses this package, > on Jun 5, 2020...) may also need a separate signature, covering the > meta data, and the aforementioned hash. > > (So it sounds like we might want to classify meta-data somewhat. > Those that don't change after a package is created, and those that do.)
I agree with Garret here in that the metadata should have a separate signature/hash to that for the actual file data being delivered. This is similar to what we do with PGP and hashes of files. In light of this, is there merit in introducing a schema that defines the metadata and its signature? Darren
