diff options
Diffstat (limited to 'zarb-ml/mageia-dev/20110131/002397.html')
| -rw-r--r-- | zarb-ml/mageia-dev/20110131/002397.html | 154 |
1 files changed, 154 insertions, 0 deletions
diff --git a/zarb-ml/mageia-dev/20110131/002397.html b/zarb-ml/mageia-dev/20110131/002397.html new file mode 100644 index 000000000..306031dfc --- /dev/null +++ b/zarb-ml/mageia-dev/20110131/002397.html @@ -0,0 +1,154 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Mageia-dev] PGP keys and package signing + </TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C1296496587.12892.104.camel%40akroma.ephaone.org%3E"> + <META NAME="robots" CONTENT="index,nofollow"> + <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> + <LINK REL="Previous" HREF="002396.html"> + <LINK REL="Next" HREF="002398.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Mageia-dev] PGP keys and package signing</H1> + <B>Michael Scherer</B> + <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C1296496587.12892.104.camel%40akroma.ephaone.org%3E" + TITLE="[Mageia-dev] PGP keys and package signing">misc at zarb.org + </A><BR> + <I>Mon Jan 31 18:56:27 CET 2011</I> + <P><UL> + <LI>Previous message: <A HREF="002396.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002398.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2397">[ date ]</a> + <a href="thread.html#2397">[ thread ]</a> + <a href="subject.html#2397">[ subject ]</a> + <a href="author.html#2397">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit : +><i> On Mon, 31 Jan 2011, Michael Scherer wrote: +</I>><i> +</I>><i> > Le lundi 31 janvier 2011 à 16:03 +0100, nicolas vigier a écrit : +</I>><i> > > On Sun, 30 Jan 2011, Motoko-chan wrote: +</I> +><i> > > >> - In case we think the packages@ key may have been compromised, or is +</I>><i> > > >> too old, or we want to change it for any other reason, we revoke the +</I>><i> > > >> key, and/or revoke the signature from board@ so that it is no +</I>><i> > > >> longer accepted by urpmi. We create a new key, we sign it with +</I>><i> > > >> the board@ key and we can start to use this new key. +</I>><i> > > > Sounds good. I'd almost suggest a new packages signing key for each new +</I>><i> > > > release that is valid for the supported life of the release plus one year. +</I>><i> > > > It's a bit more work, but would reduce the damage a key leak would cause. +</I>><i> > > > Unfortunately, this would bring back the problems of re-signing packages +</I>><i> > > > when they are turned into a release. +</I>><i> > > +</I>><i> > > I think we should avoid keys with expiration date because : +</I>><i> > > - maybe we will want to extend supported life of the release +</I>><i> > > - some people may want to continue using the release after end of life +</I>><i> > +</I>><i> > We can 1) have a long enough expiration date ( but EOL + 1y seems quite +</I>><i> > enough IMHO ) +</I>><i> > 2) push unexpired keys before it is too late if needed ( I routinely +</I>><i> > push my key after extending the expiration date ). +</I>><i> +</I>><i> Pushing new unexpired keys also means we need to resign all old packages +</I>><i> if we want them to be installable. So that's not something we want to do +</I>><i> too often if it's not needed. +</I> +Nope, I didn't say "new unexpired key", but just push the same key, with +the expiration date extended. That should be painless IIRC ( at least, +it is for me ). + +><i> > And people should be able to force a bypass of the system of course, but +</I>><i> > they will be on their own ( ie, that's quite the definition of EOL ). +</I>><i> > And this should be documented, and easy to do ( but warn people without +</I>><i> > harrassing too much can be quite difficult ). +</I>><i> > +</I>><i> > We can also say that we erase the keys once it is not planned to be used +</I>><i> > anymore, so we would no longer care about protecting them ( ie, we say +</I>><i> > the key is expired for good, and that's all ). +</I>><i> +</I>><i> If we decide that a key won't be used anymore, and don't want to care +</I>><i> about protecting it, I think we should revoke it (or its signature) as +</I>><i> soon as possible, instead of waiting for it to expire. +</I> +Well, we can do both. Revoke it, and for those that still use it and +didn't update, let it expires. + +><i> I think the only use of expiration date would be if one day all +</I>><i> known keyservers are down and never come back (I think it's unlikely to +</I>><i> happen, or we will also have other problems) +</I> +Yep, unlikely ( unless in Egypt ) + +Maybe this also mean we should have a SKS server too +( <A HREF="http://minskyprimus.net/sks/">http://minskyprimus.net/sks/</A> ). + +><i> , or we lose all private +</I>><i> keys, so we can't revoke them or their signature. But if we lose all +</I>><i> private keys, we will also have other problems (like not being able to +</I>><i> sign a new key), so we should avoid it. +</I> +Usually, revokation certificates can be prepared in advance. ( in case +you lose the key, simply ). So this should also be done. + +The point about losing all keys also mean we need to take backup in +accounts ( for example, encrypt them, bacula can do it client side ). + +><i> > > - I don't think using expiration date reduce the damage of a leaked +</I>><i> > > key. If the key is leaked, we revoke it (or its signature) immediatly +</I>><i> > > on all key servers, which should be faster than waiting for the key to +</I>><i> > > expire. And replacing an expired key is not more simple than replacing +</I>><i> > > a revoked key. +</I>><i> > +</I>><i> > The problem is not leaking the key, it is about cryptographic attacks +</I>><i> > about older keys. +</I>><i> > +</I>><i> > If in 10 years, there is some technology that allows people to get our +</I>><i> > private key by bruteforce on the public one, if it is expired, attackers +</I>><i> > will not be able to use it even if they have it. Since the plan is to +</I>><i> > say "every key signed is valid", then we are potentially screwed if a +</I>><i> > old key is compromised offline. +</I>><i> +</I>><i> If in 10 years there is some technology to get our private key, then +</I>><i> it's still possible to revoke the key at that time. +</I>><i> +</I>><i> Instead of deciding +</I>><i> now that the key will expire in a few years, I would prefer that we look +</I>><i> at it in a few years to decide if we want to revoke it. +</I> +Wouldn't it be too late ? + +-- +Michael Scherer + +</PRE> + + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI>Previous message: <A HREF="002396.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI>Next message: <A HREF="002398.html">[Mageia-dev] PGP keys and package signing +</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#2397">[ date ]</a> + <a href="thread.html#2397">[ thread ]</a> + <a href="subject.html#2397">[ subject ]</a> + <a href="author.html#2397">[ author ]</a> + </LI> + </UL> + +<hr> +<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev +mailing list</a><br> +</body></html> |