1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
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>
|
