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
|
<!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=%3C201101312042.44309.maarten.vanraes%40gmail.com%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="002399.html">
<LINK REL="Next" HREF="002402.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] PGP keys and package signing</H1>
<B>Maarten Vanraes</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20PGP%20keys%20and%20package%20signing&In-Reply-To=%3C201101312042.44309.maarten.vanraes%40gmail.com%3E"
TITLE="[Mageia-dev] PGP keys and package signing">maarten.vanraes at gmail.com
</A><BR>
<I>Mon Jan 31 20:42:44 CET 2011</I>
<P><UL>
<LI>Previous message: <A HREF="002399.html">[Mageia-dev] PGP keys and package signing
</A></li>
<LI>Next message: <A HREF="002402.html">[Mageia-dev] PGP keys and package signing
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#2401">[ date ]</a>
<a href="thread.html#2401">[ thread ]</a>
<a href="subject.html#2401">[ subject ]</a>
<a href="author.html#2401">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Op maandag 31 januari 2011 20:12:24 schreef nicolas vigier:
><i> On Mon, 31 Jan 2011, Michael Scherer wrote:
</I>><i> > Le lundi 31 janvier 2011 à 18:26 +0100, nicolas vigier a écrit :
</I>><i> > > On Mon, 31 Jan 2011, Michael Scherer wrote:
</I>><i> > > > We can 1) have a long enough expiration date ( but EOL + 1y seems
</I>><i> > > > quite 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
</I>><i> > > packages if we want them to be installable. So that's not something we
</I>><i> > > want to do too often if it's not needed.
</I>><i> >
</I>><i> > Nope, I didn't say "new unexpired key", but just push the same key, with
</I>><i> > the expiration date extended. That should be painless IIRC ( at least,
</I>><i> > it is for me ).
</I>><i>
</I>><i> Oh, I misunderstood this as I imagined it was not possible to change
</I>><i> expiration date on a key as it would be difficult to check if the change
</I>><i> was done before expiration. But after checking, it is indeed possible,
</I>><i> and it is even possible to do it after the expiration date.
</I>><i>
</I>><i> So we can do it, but we should remember that it does not protect against
</I>><i> a key compromised after it has expired (as someone stealing the key
</I>><i> can change the expiration date even after it has expired).
</I>><i>
</I>><i> So the only use of expiration date I see is to check that the key was
</I>><i> updated from keyserver recently. Maybe we can set a short expiration
</I>><i> time (15 days ?), and have something in cron to update it a few days
</I>><i> before it expire ?
</I>><i>
</I>><i> > > > > - I don't think using expiration date reduce the damage of a
</I>><i> > > > > leaked
</I>><i> > > > >
</I>><i> > > > > key. If the key is leaked, we revoke it (or its signature)
</I>><i> > > > > immediatly on all key servers, which should be faster than
</I>><i> > > > > waiting for the key to expire. And replacing an expired key is
</I>><i> > > > > not more simple than replacing 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
</I>><i> > > > our private key by bruteforce on the public one, if it is expired,
</I>><i> > > > attackers will not be able to use it even if they have it. Since the
</I>><i> > > > plan is to say "every key signed is valid", then we are potentially
</I>><i> > > > screwed if a 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
</I>><i> > > look at it in a few years to decide if we want to revoke it.
</I>><i> >
</I>><i> > Wouldn't it be too late ?
</I>><i>
</I>><i> Considering that it is possible to update expiration date even after it
</I>><i> has expired, this expiration date doesn't protect against some technology
</I>><i> that would allow people in the futur to bruteforce the private key.
</I>
what if there is no network access? keyservers are nice, but an isolated
install should still be possible...
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="002399.html">[Mageia-dev] PGP keys and package signing
</A></li>
<LI>Next message: <A HREF="002402.html">[Mageia-dev] PGP keys and package signing
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#2401">[ date ]</a>
<a href="thread.html#2401">[ thread ]</a>
<a href="subject.html#2401">[ subject ]</a>
<a href="author.html#2401">[ 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>
|