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
>
>
>
>
>
