Bart Smaalders wrote:
> 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.
I think you want the hash value in the signed portion. Otherwise, how
do you keep someone from reattaching a different signed meta data from a
"bad" package to a "good" package?
Possibly all you need is just the hash signature.
I still don't really understand whether meta data can alter the behavior
of the software (either the installed software or the installation
software itself) -- can it?
- Garrett
>
> - Bart
>
>
>
