Pierre Habouzit <[EMAIL PROTECTED]> writes:
> Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit :
>> * Lionel Elie Mamane:
>> > Why can't we have a master key that signs the yearly keys? After
>> > all, we have a long-term unique X.509 master key, so what's the
>> > difference with OpenPGP?
>>
>> End users are typically not exposed to the X.509 keys, which makes
>> things a lot easier.
>>
>> By the way, if you've got a master key, you need to plan for key
>> rollover, too. Why not apply that procedure directly to the keys
>> used to sign the release files? A yearly key change just results in
>> unnecessary administrative overhead for our users, without providing
>> any real benefit to them. A key compromise still needs manual
>> intervention.
>>
>> At the very least, if we have to keep that yearly key change for
>> political reasons, please schedule it in a way that it doesn't happen
>> in January.
>
> Proposal 1:
>
> a possible way would be to have two valid keys at any time. like one
> new key per year (or 6 month like you want) with a validity of 2 years
> (resp. one year).
>
> that would obviously mean two signatures per package (but I don't
> think that's that much work) and would require the user to update
> their "keyring package" only once every year (or 6 month), which looks
> like a quite reasonnable trade-off. Even stable updates can use that
> scheme, since it's released more than once a year.
Except that apt-get fails if any of the signatures are unknown or
expired. So you still need both keys and not just one of them as you
intent.
> Proposal 2:
>
> the package that holds the public signature key has to contain every
> single emited key, and be signed with any anterior one. Meaning that
> the upgrade for any user would be smooth.
>
> I don't think that having a kludge in dpkg that forces the upgrade of
> that package ASAP would be hard or dangerous to implement, so that
> even a non aware user could just "apt-get update" without having read
> the release notes.
>
> This is simpler, but less secure than the Proposal 1.
Not applicable to non debian repositories or easily exploitable to
work on any package.
> Proposal ...:
>
> there is a lot of such ideas IMHO, one just has to think 10 minutes to
> imagine a couple of ones.
>
>
> IMHO, changing the key every year at any date is not problematic at all,
> because there is plenty of solution to do smooth replacement of the
> key.
Do you see any drawbacks with my proposal of having Release.key next
to each Releas.gpg or do you have a better idea that will work for
every apt-getable archive?
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
