Re: Reminder: Removing 2048 bit keys from the Debian keyrings
Il giorno sab, 08/11/2014 alle 21.15 +0100, Marco d'Itri ha scritto: On Nov 08, Jonathan McDowell nood...@earth.li wrote: Back in August I sent notification[0] about the fact that we will be removing all keys less than 2048 from our keyrings at the end of the year (31st December 2014). Sadly the response to this has been slower than expected, and we still have about 439 keys that require replacement. Vedo parecchi italiani nella lista, io sono sempre disponibile per firmare chiavi a Milano. Ciao a tutti, io sono nella lista e ho bisogno ancora di 1 firma sulla nuova chiave. Se qualcuno passa nei dintorni di Bologna si faccia sentire. Saluti -- Andrea Capriotti capri...@debian.org -- Per REVOCARE l'iscrizione alla lista, inviare un email a debian-devel-italian-requ...@lists.debian.org con oggetto unsubscribe. Per problemi inviare un email in INGLESE a listmas...@lists.debian.org To UNSUBSCRIBE, email to debian-devel-italian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415617725.2943.6.ca...@debian.org
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
Ciao! On 2014-11-10 at 12:18 (CET), Andrea Capriotti wrote: Ciao a tutti, io sono nella lista e ho bisogno ancora di 1 firma sulla nuova chiave. Se qualcuno passa nei dintorni di Bologna si faccia sentire. Se vieni allo Ubuntu-it Meeting del 22 Novembre al Ramada Encore[1], ci trovi in tanti per una firmetta... reciproca ;-) A presto. [1] http://loco.ubuntu.com/events/ubuntu-it/2887-ubuntu-it-meeting/ -- Matteo F. Vescovi || Debian Developer GnuPG KeyID: 4096R/0x8062398983B2CF7A signature.asc Description: Digital signature
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On Nov 10, 2014 12:28 PM, Matteo F. Vescovi m...@debian.org wrote: Se vieni allo Ubuntu-it Meeting del 22 Novembre al Ramada Encore[1], ci trovi in tanti per una firmetta... reciproca ;-) Che c'è scritto Ubuntu ma manca poco che ci siano più (prospective) DD che altro ;p
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On 8 November 2014 17:05, Thijs Kinkhorst th...@debian.org wrote: On Sat, November 8, 2014 17:09, Jonathan McDowell wrote: We had hoped to be down to a small number of special cases to deal with by this point, but with the numbers still looking this bad we're not yet at a stage where we can work out appropriate next steps for those special cases. In the list you post, I see lots of names of people I know to be inactive for years now. Removing all those keys from the ring would therefore maybe not be such a disaster, because the majority is no longer regularly contributing to Debian. To make this a bit more concrete, I've matched the uids against echelon, and this is the outcome: 160 2014 Can the keys last used in 2013 or earlier (and not yet special cased / migrating) be moved to non-uploading keyring? This should not have any impact - no recent uploading usage, yet can vote still be a DD, etc. 42 2013 54 2012 31 2011 24 2010 31 2009 21 2008 17 2007 7 2006 5 2005 2 2004 1 2003 1 2002 So 160 keys were used this year, which is cause for concern if they are removed. However, it means 236 keys have not seen use in 2014 yet. And of those 160 keys have been used most recently in 2011; of those we can be rather certain that removing their key from the ring actually confirms the status quo rather than disrupt it. It therefore makes sense not to focus on the number of 436, but on the ones that have actually been used in 2014; get that first number of 160 closer to 0. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/edbe948c76a3d7abd9d0f5d126b237f9.squir...@aphrodite.kinkhorst.nl -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUg0dgsiAzQ3JkJKq3=_hie1y_dzhpek5zkmza12rqu...@mail.gmail.com
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On Sat, Nov 08, 2014 at 09:59:08PM +0100, Richard Hartmann wrote:
Can you put this list, and a count, in a place I can wget from?
You've trimmed all context so I'm not entirely clear if you're looking
for the key list or something else. If it's the key list you should be
able to calculate it yourself from the keyrings:
rsync -az keyring.debian.org::keyrings/keyrings/ .
gpg --no-default-keyring --list-keys --with-colons \
--keyring ./debian-keyring.gpg \
--keyring ./debian-maintainers.gpg | \
awk -F ':' '/^pub:.:1024:/ { print $5 $10 }'
This will give slightly more people than my list as I effectively did
the above on our working tree, which is not public, while the rsync will
provide the currently active keyring. At present the above lists 468
contributors, while the active tree has 429 with weak keys.
J.
--
] http://www.earth.li/~noodles/ []I'm a consultant because I'd [
] PGP/GPG Key @ the.earth.li [] rather be self-unemployed. [
] via keyserver, web or email. [] [
] RSA: 4096/2DA8B985[] [
signature.asc
Description: Digital signature
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On Nov 08, Jonathan McDowell nood...@earth.li wrote: Back in August I sent notification[0] about the fact that we will be removing all keys less than 2048 from our keyrings at the end of the year (31st December 2014). Sadly the response to this has been slower than expected, and we still have about 439 keys that require replacement. Vedo parecchi italiani nella lista, io sono sempre disponibile per firmare chiavi a Milano. -- ciao, Marco signature.asc Description: Digital signature
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On Sat, November 8, 2014 17:09, Jonathan McDowell wrote: We had hoped to be down to a small number of special cases to deal with by this point, but with the numbers still looking this bad we're not yet at a stage where we can work out appropriate next steps for those special cases. In the list you post, I see lots of names of people I know to be inactive for years now. Removing all those keys from the ring would therefore maybe not be such a disaster, because the majority is no longer regularly contributing to Debian. To make this a bit more concrete, I've matched the uids against echelon, and this is the outcome: 160 2014 42 2013 54 2012 31 2011 24 2010 31 2009 21 2008 17 2007 7 2006 5 2005 2 2004 1 2003 1 2002 So 160 keys were used this year, which is cause for concern if they are removed. However, it means 236 keys have not seen use in 2014 yet. And of those 160 keys have been used most recently in 2011; of those we can be rather certain that removing their key from the ring actually confirms the status quo rather than disrupt it. It therefore makes sense not to focus on the number of 436, but on the ones that have actually been used in 2014; get that first number of 160 closer to 0. Cheers, Thijs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/edbe948c76a3d7abd9d0f5d126b237f9.squir...@aphrodite.kinkhorst.nl
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
Can you put this list, and a count, in a place I can wget from? Richard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAD77+gSx377A0rG6ZYhszEfm27u0q5KW7bDtG9gi9aG43=z...@mail.gmail.com
Re: Removing 2048 bit keys from the Debian keyrings
peter green dijo [Sun, Aug 31, 2014 at 01:27:11PM +0100]: Jonathan McDowell wrote: I would ask that DDs make some effort to help those with weak keys get their new, stronger keys signed. Please sign responsibly[4], If you have signed someones old key is it considered responsible to sign their new key based on a transition statement signed by the old key? or is a new face-to-face meeting required? I've seen plenty of (sometimes conflicting) advice on signing keys of a person you have never signed keys for before but not much on the transition situation. (note: this is a general question to consider, I'm not personally in a position where it would apply) As you saw through others' answers to your question, it varies a lot. I personally also don't sign based on transition documents, but would do so in case the requester *really* needed it. Now, I know that if at some point my key were to be compromised, I'd also be in a needy situation (as I'm currently the only DD in a ~1000Km radius), and would have to find a way out. I have found several people who would sign based on transition documents, and it's also OK. It's completely a personal issue, although it does impact us all as a project. Yes, at some point we will need to make our rules a *little* bit more flexible, but I'd prefer that flexibility to be made on specific accounts' behalf (i.e. either by DAM or by keyring-maint, and based on specific checks such as a phone verification) than to suggest to everybody to relax. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908023701.ga124...@gwolf.org
Re: Removing 2048 bit keys from the Debian keyrings
On Tue, Sep 02 2014, Jeremy T. Bouse wrote: I don't know how the *-cert-level options in gpg/gpg2 match up with that section RFC480. Actually reading the sections in the man pages it reads very differently. I stand corrected. Now I just need to figure out how to resign the keys with the new options. manoj -- Winning isn't everything, but losing isn't anything. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878um1xmyi@glaurung.internal.golden-gryphon.com
Re: Removing 2048 bit keys from the Debian keyrings
On Tue, Sep 02 2014, Manoj Srivastava wrote: On Tue, Sep 02 2014, Jeremy T. Bouse wrote: I don't know how the *-cert-level options in gpg/gpg2 match up with that section RFC480. Actually reading the sections in the man pages it reads very differently. I stand corrected. Now I just need to figure out how to resign the keys with the new options. I figured out how to do the signatures; I am now torn between whether I should resign just to get the cert-level data in the signature, and effectively obscuring when the signature was actually made (well, or replacing the date when I had checked the ID with the current one). I'll re-sign the keys from the current debconf in a month, if they make their way to the keyservers, but i'll leave the historical signatures alone. I learned something today :-) manoj -- If I have not seen so far it is because I stood in giant's footsteps. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Removing 2048 bit keys from the Debian keyrings
On Sun, Aug 31, 2014 at 11:07:43AM -0700, Stefano Zacchiroli wrote: On Sun, Aug 31, 2014 at 01:27:11PM +0100, peter green wrote: If you have signed someones old key is it considered responsible to sign their new key based on a transition statement signed by the old key? or is a new face-to-face meeting required? I've seen plenty of (sometimes conflicting) advice on signing keys of a person you have never signed keys for before but not much on the transition situation. This topic is in the realm of personal signing policies, so it's probably normal to have conflicting advice among us. [posted something like this on debian-private but it should rather be in public] Signing a new key according to a transition statement IMHO just supports the I'm ranking higher in the signatures count competition. I have never signed any transition request since I'm really convinced about the fact that GPG signing is not a matter of technically checking a fingerprint and uploading a signature but rather learning to know your fellow DDs and seeing what *person* is behind a certain ID. Finally you assign a key to a person and not only to its ID card which only proves that the government of the country assumes that the person has this ID. From my point of view our web of trust should be based on personal contacts rather than technical documents. So meeting this person again and sign the new key is way more important than rather help the person to regain the original signature count. And yes, I know there are people who have trouble meeting a DD but I have never met one of them (probably due to this fact) and so even this argument is not valid in my case (and yes, I would consider helping out in trouble if it would be *really* needed). In practice, this might become a fairly strict requirement, and I've keysigned on the basis of a transition statement only twice over the past 5 years. YMMV. I had several chances to meet the people I met before in the last five years and so there was no point for me to sign any transition statement. I also never minded issuing a transition statement myself and I consider my key resonably integrated into the web of trust even if it is not featuring the number of signatures of my old key. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140902080129.gd20...@an3as.eu
Re: Removing 2048 bit keys from the Debian keyrings
Hi, Jakub Wilk: Do you have any non-joke documentation about signing responsibly? Signing a key is equivalent to saying that you think that the key belongs to a particular individual and/or identity. Whether that means I regularly hang out with them at DebConf or I met them in a keysigning queue last year, and their driver's license from $STATE looked reasonably legit is up to you; there's a GPG option (via the the *-cert-level options, see 'man gpg') to state how carefully you did verify their identity, but ultimately it's up to you. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140902102815.ge21...@smurf.noris.de
Re: Removing 2048 bit keys from the Debian keyrings
On Tue, Sep 02 2014, Matthias Urlichs wrote: there's a GPG option (via the the *-cert-level options, see 'man gpg') to state how carefully you did verify their identity, but ultimately it's up to you. That is not how I interpreted that option to mean. ,[ http://tools.ietf.org/html/rfc4880#section-5.2.3.13 ] | 5.2.3.13. Trust Signature | | | (1 octet level (depth), 1 octet of trust amount) | | Signer asserts that the key is not only valid but also trustworthy at | the specified level. Level 0 has the same meaning as an ordinary | validity signature. Level 1 means that the signed key is asserted to | be a valid trusted introducer, with the 2nd octet of the body | specifying the degree of trust. Level 2 means that the signed key is | asserted to be trusted to issue level 1 trust signatures, i.e., that | it is a meta introducer. Generally, a level n trust signature | asserts that a key is trusted to issue level n-1 trust signatures. | The trust amount is in a range from 0-255, interpreted such that | values less than 120 indicate partial trust and values of 120 or | greater indicate complete trust. Implementations SHOULD emit values | of 60 for partial trust and 120 for complete trust. ` For a personal (non-work) GPG key, I am not sure I ever want to sign above a level 0, and thus give the key a right to sign on my behalf. Also, it indicates a statement of belief in someone's ability to make proper certifications (and avoid improper ones), in addition to a statement of belief that the identity of the keyholder is correctly stated. I have no idea how to assess the former, except for the few people I have had a technical conversation with about their key signing policies, and even then, there are few people whose beliefs and conventions align closely to mine. Here is some more detail from the mailing lists: ,[ http://lists.gnupg.org/pipermail/gnupg-users/2005-May/025612.html ] | tsign is just like sign (or lsign) except that you are asked a few | more questions by GnuPG. Think of tsign as a combination of a regular | signature plus the ownertrust. This combines two different things | from the classic trust model into one signature. | | First you are asked: | |Please decide how far you trust this user to correctly verify other |users' keys (by looking at passports, checking fingerprints from |different sources, etc.) | | 1 = I trust marginally | 2 = I trust fully | | This is similar to the question you get asked when setting ownertrust. | What GnuPG is asking is not how much you trust the user, but how much | you trust the user to make good signatures. | The next question is: | |Please enter the depth of this trust signature. |A depth greater than 1 allows the key you are signing to make |trust signatures on your behalf. | | The signature depth is how many levels deep can the power granted by | this signature travel. For example, a level of 1 means that the key | you sign is valid for you (just like a regular signature), but also | that the ownertrust for this key is automatically set to MARGINAL or | FULL (depending on how you answered the first question). A level of 2 | means that the key you sign is valid for you, and the ownertrust is | automatically set, AND (assuming the trust made it to FULL) that this | key can issue signatures up to level 1 on your behalf. A level of 3 | means all that, plus the key can issue signatures up to level 2, etc. | | You can think of a regular signature as a trust signature with a depth | of 0. | | The next question: | |Please enter a domain to restrict this signature, or enter for none. | | This allows you to restrict (by domain name) the power of the | signature. For example, let's say that you wanted to make a level 2 | signature on a CA key for a particular company. You should be careful | with making any level above 1, so you want to restrict this to that | company. By giving a restriction of companyname.com here, only | signatures issued by the CA key on keys in companyname.com will take | effect. ` manoj -- Have at you! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C signature.asc Description: PGP signature
Re: Removing 2048 bit keys from the Debian keyrings
Manoj Srivastava sriva...@debian.org writes: On Tue, Sep 02 2014, Matthias Urlichs wrote: there's a GPG option (via the the *-cert-level options, see 'man gpg') to state how carefully you did verify their identity, but ultimately it's up to you. That is not how I interpreted that option to mean. ,[ http://tools.ietf.org/html/rfc4880#section-5.2.3.13 ] | 5.2.3.13. Trust Signature | (1 octet level (depth), 1 octet of trust amount) [...] ,[ http://lists.gnupg.org/pipermail/gnupg-users/2005-May/025612.html ] | tsign is just like sign (or lsign) except that you are asked a few | more questions by GnuPG. Think of tsign as a combination of a regular | signature plus the ownertrust. This combines two different things | from the classic trust model into one signature. You looked at trust signatures, not at the --*-cert-level options. These are unrelated to each other. Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8561h6oruu@tsukuyomi.43-1.org
Re: Removing 2048 bit keys from the Debian keyrings
On 09/02/2014 12:28 PM, Manoj Srivastava wrote: On Tue, Sep 02 2014, Matthias Urlichs wrote: there's a GPG option (via the the *-cert-level options, see 'man gpg') to state how carefully you did verify their identity, but ultimately it's up to you. That is not how I interpreted that option to mean. ,[ http://tools.ietf.org/html/rfc4880#section-5.2.3.13 ] | 5.2.3.13. Trust Signature | Manoj, I don't know how the *-cert-level options in gpg/gpg2 match up with that section RFC480. Actually reading the sections in the man pages it reads very differently. man gpg|gpg2 The default to use for the check level when signing a key. 0 means you make no particular claim as to how carefully you verified the key. 1 means you believe the key is owned by the person who claims to own it but you could not, or did not verify the key at all. This is useful for a persona verification, where you sign the key of a pseudonymous user. 2 means you did casual verification of the key. For example, this could mean that you verified the key fingerprint and checked the user ID on the key against a photo ID. 3 means you did extensive verification of the key. For example, this could mean that you verified the key finger‐ print with the owner of the key in person, and that you checked, by means of a hard to forge document with a photo ID (such as a passport) that the name of the key owner matches the name in the user ID on the key, and finally that you verified (by exchange of email) that the email address on the key belongs to the key owner. Note that the examples given above for levels 2 and 3 are just that: examples. In the end, it is up to you to decide just what casual and extensive mean to you. This option defaults to 0 (no particular claim). From that my understanding is it is a means by which I as the signer of a key can signify the verification taken to gain my signature on said key. This can understanding can also be emphasized if you include a *-policy-url which outlines your process and interpretation for others to check if they wish to determine whether to trust or not the key with the signature found on it. signature.asc Description: OpenPGP digital signature
Re: Removing 2048 bit keys from the Debian keyrings
Jonathan McDowell wrote: I would ask that DDs make some effort to help those with weak keys get their new, stronger keys signed. Please sign responsibly[4], If you have signed someones old key is it considered responsible to sign their new key based on a transition statement signed by the old key? or is a new face-to-face meeting required? I've seen plenty of (sometimes conflicting) advice on signing keys of a person you have never signed keys for before but not much on the transition situation. (note: this is a general question to consider, I'm not personally in a position where it would apply) My understanding is that the NSA and similar organisations can probablly crack 1024 bit keys but the cost of doing so (assuming there hasn't been some secret mathematical breakthrough) is likely sufficiently high that it would be cheaper to infiltrate debian the old-fasioned way (false passports, putting agents through the NM process etc). Is that understanding correct? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5403149f.40...@p10link.net
Re: Removing 2048 bit keys from the Debian keyrings
On Sun, Aug 31, 2014 at 01:27:11PM +0100, peter green wrote: If you have signed someones old key is it considered responsible to sign their new key based on a transition statement signed by the old key? or is a new face-to-face meeting required? I've seen plenty of (sometimes conflicting) advice on signing keys of a person you have never signed keys for before but not much on the transition situation. This topic is in the realm of personal signing policies, so it's probably normal to have conflicting advice among us. FWIW, my take on this is that I'm fine in trusting transition statements as a basis for signing new key, but only if I consider the person doing the transition to be an active member of our community with whom I interact on a regular basis (even remotely). My rationale for this is that if someone disappears from my radar for a very long time and then shows up just for transitioning to a new key, I'd have no way to figure out that something fishy with her key might be going on. In practice, this might become a fairly strict requirement, and I've keysigned on the basis of a transition statement only twice over the past 5 years. YMMV. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: Removing 2048 bit keys from the Debian keyrings
* Jonathan McDowell nood...@earth.li, 2014-08-31, 04:31: Please sign responsibly[4], [...] [4] http://xkcd.com/364/ Do you have any non-joke documentation about signing responsibly? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140831200905.gc6...@jwilk.net
Re: Removing 2048 bit keys from the Debian keyrings
Hi, On Sonntag, 31. August 2014, peter green wrote: My understanding is that the NSA and similar organisations can probablly crack 1024 bit keys but the cost of doing so (assuming there hasn't been some secret mathematical breakthrough) is likely sufficiently high that it would be cheaper to infiltrate debian the old-fasioned way (false passports, putting agents through the NM process etc). Is that understanding correct? besides that I dont think the costs are that high anymore (once you've build that/these computer/s, you've build it/them...) I also don't see what they would gain by activly infiltrating us (except risk of exposure): we work in the open, we don't have secrets. And they can read debian-private anyway... and there are plenty of known and unknown exploits too, to be able to run code. cheers, Holger, who will not sign keys based on transition statements... signature.asc Description: This is a digitally signed message part.
