summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/20110131/002399.html
blob: 6cacf13c3eb9d228ff38e5018f66c469c77eab8f (plain)
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
<!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=%3C1296502627.12892.132.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="002398.html">
   <LINK REL="Next"  HREF="002401.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=%3C1296502627.12892.132.camel%40akroma.ephaone.org%3E"
       TITLE="[Mageia-dev] PGP keys and package signing">misc at zarb.org
       </A><BR>
    <I>Mon Jan 31 20:37:07 CET 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="002398.html">[Mageia-dev] PGP keys and package signing
</A></li>
        <LI>Next message: <A HREF="002401.html">[Mageia-dev] PGP keys and package signing
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#2399">[ date ]</a>
              <a href="thread.html#2399">[ thread ]</a>
              <a href="subject.html#2399">[ subject ]</a>
              <a href="author.html#2399">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Le lundi 31 janvier 2011 &#224; 20:12 +0100, nicolas vigier a &#233;crit :
&gt;<i> On Mon, 31 Jan 2011, Michael Scherer wrote:
</I>&gt;<i>
</I>&gt;<i> &gt; Nope, I didn't say &quot;new unexpired key&quot;, but just push the same key, with
</I>&gt;<i> &gt; the expiration date extended. That should be painless IIRC ( at least,
</I>&gt;<i> &gt; it is for me ).
</I>&gt;<i> 
</I>&gt;<i> Oh, I misunderstood this as I imagined it was not possible to change
</I>&gt;<i> expiration date on a key as it would be difficult to check if the change
</I>&gt;<i> was done before expiration. But after checking, it is indeed possible,
</I>&gt;<i> and it is even possible to do it after the expiration date.
</I>&gt;<i> 
</I>&gt;<i> So we can do it, but we should remember that it does not protect against
</I>&gt;<i> a key compromised after it has expired (as someone stealing the key
</I>&gt;<i> can change the expiration date even after it has expired).
</I>
But we would notice it, I guess. That could be a good idea to check if
any of our old key do not appear on the keyring with a non expired
date :)

&gt;<i> So the only use of expiration date I see is to check that the key was
</I>&gt;<i> updated from keyserver recently. Maybe we can set a short expiration
</I>&gt;<i> time (15 days ?), and have something in cron to update it a few days
</I>&gt;<i> before it expire ?
</I>
Or maybe we can keep the expiration date to indicate when the key should
not be used anymore ( ie, as a indication, nothing more, as we cannot
guarantee anything ), and once the expiration date occurs ( expiration
date set on our copy of the key ), we upload the revocation certificate
( with we == a cronjob , by checking the date of the key )

We could even use this on client side to indicate that a release is no
longer supported. ( ie, DRY principle ).

&gt;<i> &gt; &gt; Instead of deciding
</I>&gt;<i> &gt; &gt; now that the key will expire in a few years, I would prefer that we look
</I>&gt;<i> &gt; &gt; at it in a few years to decide if we want to revoke it.
</I>&gt;<i> &gt; 
</I>&gt;<i> &gt; Wouldn't it be too late ?
</I>&gt;<i> 
</I>&gt;<i> Considering that it is possible to update expiration date even after it
</I>&gt;<i> has expired, this expiration date doesn't protect against some technology
</I>&gt;<i> that would allow people in the futur to bruteforce the private key.
</I>
It is up to the tool to use or not the expiration. Ie, if we tell to
urpmi &quot;do not trust expired key&quot;, we can as well say &quot;keep a list of key
that have expired and never trust a key, even if it say the contrary&quot;.

But indeed, that doesn't sound very secure per se :/

-- 
Michael Scherer

</PRE>



<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="002398.html">[Mageia-dev] PGP keys and package signing
</A></li>
	<LI>Next message: <A HREF="002401.html">[Mageia-dev] PGP keys and package signing
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#2399">[ date ]</a>
              <a href="thread.html#2399">[ thread ]</a>
              <a href="subject.html#2399">[ subject ]</a>
              <a href="author.html#2399">[ 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>