Garrett D'Amore wrote: > Bart Smaalders wrote: >> 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.) >>> >>> - Garrett >>> >> >> I don't understand. >> >> What is wrong with simply allowing multiple signature by the simple >> expedient of not including signatures in the hash. This is a very >> natural thing to do, since it simply requires removing all signatures >> from the manifest and then computing the hash. >> >> Doing otherwise means that a hierarchal manifest of arbitrary nesting >> depth is required; this complexity doesn't seem to be justified by >> any real requirements. >> >> There's plenty of track to be laid on this project w/o adding more for >> the use of invisible trains. > > The problem is whether meta data needs to be covered by the hash (and > signature) or not. > > Lets see if I can explain more fully. > > Sun delivers package A, and signs it, [A,sun] > > Sun support only guarantees support for packages that are signed. > > The customers IT organization wants to ensure that only "blessed > packages" are installed. And maybe they want to provide some additional > data, such as the date it was blessed, who blessed it, and perhaps > limitations upon the packages use. So they want to take [A,sun] and > make it [[A,sun],it] > > Now if you only allow multiple signatures in parallel over a common > hash, the problem is that the customer's IT metadata isn't covered by > the signature. (Unless the customer invents some other packing and > distribution format, which I think we want to avoid.) > > An alternative approach might be to have separate signatures, so that > you have: > > let pkg deliverables = A > let SHA[A] = H > let Sun's meta data for A = Msun > let customer IT dept's metadata for A = Mcustomer > let signed copy of x using Sun's key = [x,sun] > let signed copy of x using Customer's key = [x,customer] > > So Sun delivers: > > A + [H + Msun, sun] > > The customer's IT department serves up: > > A + [H + Msun,sun] + [H + Msun + Mcustomer, customer] > > This preserves the cryptographic integrity of both Msun and Mcustomer. > > -- Garrett > >> >> - Bart >> >> >> >> >> >
Since each action can contain arbitrary attributes, the customer's signature action can contain whatever data he wants; the packaging system happily ignores that which it doesn't know about so he can add new attributes to his signature ad nauseam. This would mean that any actions that are signatures are simply ignored when computing the hash for signing purposes. Each signature can carry whatever extra data (within reason, of course) is deemed necessary by the signer. If the customer is worried about retrieving these packages from a repo run by a hostile which is attempting to edit his meta data, we can always include just the signature being generated (minus the hash value) in the hash. Thus, each signature stands alone, but if present cannot be altered w/o detection. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
