From jeneva_fitchett@aigvalic.com Thu Jan 1 09:54:23 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D46C28C163 for ; Thu, 1 Jan 2009 09:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.689 X-Spam-Level: X-Spam-Status: No, score=-15.689 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpTQcTcwKTiT for ; Thu, 1 Jan 2009 09:54:22 -0800 (PST) Received: from alcoa.com.au (unknown [93.177.139.231]) by core3.amsl.com (Postfix) with SMTP id F12473A68B9 for ; Thu, 1 Jan 2009 09:54:13 -0800 (PST) To: Subject: New Hope 'N New Beginnings... From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090101175416.F12473A68B9@core3.amsl.com> Date: Thu, 1 Jan 2009 09:54:13 -0800 (PST)


Please do not reply to this email. To contact Max Volume, please visit us

This email message was sent to . If you do not wish to receive further communications from Max Volume, click here to unsubscribe.

If you've experience any difficulty in being removed from a Max Volume email list, click here for personalized help.

Copyright © 2008 Max Volume, Inc. All rights reserved.
65856 A Alaska, Luissvill, AT 43125

From kbooking@agcomm.com Sun Jan 4 09:09:25 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D0843A6A7E for ; Sun, 4 Jan 2009 09:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.805 X-Spam-Level: X-Spam-Status: No, score=-35.805 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl513I9SryIg for ; Sun, 4 Jan 2009 09:09:25 -0800 (PST) Received: from 173-17-145-96.client.mchsi.com (173-17-145-96.client.mchsi.com [173.17.145.96]) by core3.amsl.com (Postfix) with SMTP id 0C84F3A67A8 for ; Sun, 4 Jan 2009 09:09:23 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090104170924.0C84F3A67A8@core3.amsl.com> Date: Sun, 4 Jan 2009 09:09:23 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mschelah5@alphastaff.com Sun Jan 4 16:13:19 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0CC23A6A96 for ; Sun, 4 Jan 2009 16:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.535 X-Spam-Level: X-Spam-Status: No, score=-40.535 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzYKcaet-u3m for ; Sun, 4 Jan 2009 16:13:19 -0800 (PST) Received: from cpc3-horn1-0-0-cust143.cos2.cable.ntl.com (cpc3-horn1-0-0-cust143.cos2.cable.ntl.com [82.20.244.144]) by core3.amsl.com (Postfix) with SMTP id A9ACF3A67B3 for ; Sun, 4 Jan 2009 16:13:04 -0800 (PST) To: Subject: Your order 60474 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105001308.A9ACF3A67B3@core3.amsl.com> Date: Sun, 4 Jan 2009 16:13:04 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 36978
From lir7@agora.pl Tue Jan 6 08:06:56 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F323A6405 for ; Tue, 6 Jan 2009 08:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.558 X-Spam-Level: X-Spam-Status: No, score=-28.558 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_AU=0.377, HELO_EQ_CPE=0.5, HOST_EQ_AU=0.327, HOST_EQ_CPE=0.979, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKx1Wz35dMn0 for ; Tue, 6 Jan 2009 08:06:50 -0800 (PST) Received: from CPE-121-210-235-74.qld.bigpond.net.au (CPE-121-210-235-74.qld.bigpond.net.au [121.210.235.74]) by core3.amsl.com (Postfix) with SMTP id 56DE83A6774 for ; Tue, 6 Jan 2009 08:06:47 -0800 (PST) To: Subject: RE: Message 38619 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106160649.56DE83A6774@core3.amsl.com> Date: Tue, 6 Jan 2009 08:06:47 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 54762
From ogisa@amher.com.mx Tue Jan 6 20:12:09 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0213A695C for ; Tue, 6 Jan 2009 20:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5XLViavygEp for ; Tue, 6 Jan 2009 20:12:03 -0800 (PST) Received: from afo.net (unknown [92.9.148.249]) by core3.amsl.com (Postfix) with SMTP id 1A7F73A692F for ; Tue, 6 Jan 2009 20:12:01 -0800 (PST) To: Subject: Undeliverable Mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107041202.1A7F73A692F@core3.amsl.com> Date: Tue, 6 Jan 2009 20:12:01 -0800 (PST) About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From ogunay@akora.com.tr Wed Jan 7 00:58:21 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CEE3A6989 for ; Wed, 7 Jan 2009 00:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.993 X-Spam-Level: X-Spam-Status: No, score=-21.993 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwwqZYh-5+hr for ; Wed, 7 Jan 2009 00:58:20 -0800 (PST) Received: from cpe-76-179-3-205.maine.res.rr.com (cpe-76-179-3-205.maine.res.rr.com [76.179.3.205]) by core3.amsl.com (Postfix) with SMTP id 499353A6931 for ; Wed, 7 Jan 2009 00:58:18 -0800 (PST) To: Subject: This mail is refused message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107085819.499353A6931@core3.amsl.com> Date: Wed, 7 Jan 2009 00:58:18 -0800 (PST) About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From nookqll@affix-formation.fr Wed Jan 7 06:44:55 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91FC13A6858 for ; Wed, 7 Jan 2009 06:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.518 X-Spam-Level: X-Spam-Status: No, score=-22.518 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Cap30l4NagP for ; Wed, 7 Jan 2009 06:44:54 -0800 (PST) Received: from altbikeboard.com (unknown [200.204.182.131]) by core3.amsl.com (Postfix) with SMTP id 436983A6805 for ; Wed, 7 Jan 2009 06:44:50 -0800 (PST) To: Subject: Returned mail: Over quota From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107144452.436983A6805@core3.amsl.com> Date: Wed, 7 Jan 2009 06:44:50 -0800 (PST) About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

C2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 From mail@amberjewelry.ca Wed Jan 7 15:00:57 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 438B83A6A0D for ; Wed, 7 Jan 2009 15:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.718 X-Spam-Level: X-Spam-Status: No, score=0.718 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rID8o1MCAI6V for ; Wed, 7 Jan 2009 15:00:56 -0800 (PST) Received: from 201-74-245-82-am.cpe.vivax.com.br (201-74-245-82-am.cpe.vivax.com.br [201.74.245.82]) by core3.amsl.com (Postfix) with SMTP id 3CF973A67FB for ; Wed, 7 Jan 2009 15:00:53 -0800 (PST) To: Subject: We need your presence From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107230054.3CF973A67FB@core3.amsl.com> Date: Wed, 7 Jan 2009 15:00:53 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mercadorehabgraceland@aacpl.net Thu Jan 8 07:14:27 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E87A93A6942 for ; Thu, 8 Jan 2009 07:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.142 X-Spam-Level: X-Spam-Status: No, score=-12.142 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fiQ5BW2vDNRf for ; Thu, 8 Jan 2009 07:14:27 -0800 (PST) Received: from 83-152-64-174.rev.libertysurf.net (83-152-64-174.rev.libertysurf.net [83.152.64.174]) by core3.amsl.com (Postfix) with SMTP id 3B58D3A68BD for ; Thu, 8 Jan 2009 07:14:25 -0800 (PST) To: Subject: Don't go home now! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090108151426.3B58D3A68BD@core3.amsl.com> Date: Thu, 8 Jan 2009 07:14:25 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owner-ietf-openpgp@mail.imc.org Thu Jan 8 11:12:52 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3176F3A6ACE for ; Thu, 8 Jan 2009 11:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ld0AxtIjYe8J for ; Thu, 8 Jan 2009 11:12:51 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C6B273A688F for ; Thu, 8 Jan 2009 11:12:50 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08Ivslb066583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:57:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08IvsHM066582; Thu, 8 Jan 2009 11:57:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n08Ivg9K066569 for ; Thu, 8 Jan 2009 11:57:53 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 36098 invoked from network); 8 Jan 2009 18:57:41 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 8 Jan 2009 18:57:41 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49664D21.50403@fifthhorseman.net> Date: Thu, 08 Jan 2009 13:59:45 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Monkeysphere Developers Subject: A review of hash function brittleness in OpenPGP X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B8AC4F50DA64063949DE949" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B8AC4F50DA64063949DE949 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey folks-- I've been trying to evaluate RFC 4880's resistance to a hash function compromise in light of the recent activity exploiting weaknesses MD-5 in That Other PKI [0]. I'm quite pleased with the bulk of what i've found. OpenPGP's use of message digests is almost entirely parameterized, leaving the door open to forward-looking adoption of new hash algorithms and the smooth deprecation as older ones are demonstrated to be weak. So I've been looking for places in the spec where the choice of digest function is not parameterized. In particular, explicit and hardcoded reliance on SHA-1 could become problematic as it is already being deprecated. For example, reliance on SHA-1 must be eliminated in all US Gov't federal agencies by the end of 2010 [1]. Here are the concerns i've found so far: MDC --- The modification detection packets (sections 5.13 and 5.14) explicitly specify SHA-1, and basically acknowledge that this choice may need to be made more flexible in the future. Fingerprints ------------ Fingerprints (section 12.2) are specified as an SHA-1 computation. While this isn't an explicit reliance on SHA-1 for cryptographic security (and the RFC makes it clear that there is a non-zero chance of fingerprint collisions), the real-world use of fingerprints as unique identifiers for keys poses a serious risk to OpenPGP infrastructure should SHA-1 become further compromised. Revocation keys --------------- Section 5.2.3.15 defines a way that key A can allow key B to authoritatively issue revocation signatures on A's behalf, including key revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and certification revocation (sigtype 0x30). However, this mechanism relies on the fingerprint of B being unique. Since the fingerprint itself is bound to SHA-1, this presents a risk to users of this feature of the specification should SHA-1 become further compromised. As the IETF working group for OpenPGP, we probably should start actively working to resolve these issues so we can have infrastructure in place well before SHA-1 is similarly compromised. Any suggestions? I'm new to the WG, so i don't have any experience addressing concerns like this. I'm particularly concerned about fingerprints, since they is used widely in the real world (e.g. i have my fingerprint on my business card). I can imagine relatively straightforward technical measures to resolve the other concerns. Also, it's quite likely that i've missed things in my reading of the spec. If anyone sees any other problematic areas, it would be great to air them as soon as possible. Regards, --dkg [0] http://www.phreedom.org/research/rogue-ca/ [1] http://csrc.nist.gov/groups/ST/hash/statement.html --------------enig7B8AC4F50DA64063949DE949 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSWZNJszS7ZTSFznpAQIwog//b705lnuUoYzz1Tp6OHBbTmKtThS2myCX Cp8sgmkH9p/GtP4MEBKmR3TFkw0JxwyhRAPsRsDVp/JpDkv08oxdW3+Mqi8xgBIF x9zyBb+XmV3WNwYTTjkcNQ+WYVqqLzvWGDS2wZ3/BjQiezgV60C42vNBM05ZTp93 WS0cnh/txJ5Lex+rxqE+qiZOWaAubyxX4AmZ4e68uoXM3faSFT8TesZUzZRbd9zN SDBIxjb1FYgDLboaotlEHk5Zeq+Uy0nM3hQ3jqXZnmNk7bjajCkCl5zm/xUcUXVZ yDb/nSpDTrYfdfdhCrtqBoHzxlw+tzs5mu77Fc7wR2GNNJo6/xq8uRbabYDsyaaL cTlpNdvaz3Cj4Ncq5Ztqpjgpgw/NfG0Msp9B2Qw2sz1yDr8ZyH5WaB9QJCuDH8Zf DJapjUFqgqgtUQRZIU+DSpW0KtiAYa+3Bg8heQmfoJd9DnS9J+OILCZg/RNArt/5 5Gqe5GjvioWG6g09hmr9Uo8WAMVNDTk8YaWiMfQYvvi2Qa48ZzS09CYDMF1GR0ld K11czwkHqrNAXuWF/YBDkecv4jtmAj+Mu4ddVjHtuz59+AelCh/gy5FHyOtSWrvH KbYF4AQIUYwMdTTJiZ4RTG8PQtUxyy6H9sDGfrdpih9aBanseCQ+IEjFB02yqCbN VL0EXYVBOhM= =kw/q -----END PGP SIGNATURE----- --------------enig7B8AC4F50DA64063949DE949-- From openpositions@worldarena.com Thu Jan 8 11:33:45 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 196213A6A17 for ; Thu, 8 Jan 2009 11:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.654 X-Spam-Level: X-Spam-Status: No, score=-36.654 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_ALMOST_IP=1.889, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_SBL=20, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRHPSaoeiv-N for ; Thu, 8 Jan 2009 11:33:38 -0800 (PST) Received: from mta.email.webmd.com (ip-181.net-81-220-174.nice.rev.numericable.fr [81.220.174.181]) by core3.amsl.com (Postfix) with SMTP id D174D3A6940 for ; Thu, 8 Jan 2009 11:33:37 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20090108093325.4869.qmail@mta.email.webmd.com> From: "Doctor Jamel" To: openpgp-archive@ietf.org Subject: RE: (Canadian Pharmacy Message) Want to make pleasure more durable? MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 8 Jan 2009 11:33:37 -0800 (PST)
From owner-ietf-openpgp@mail.imc.org Thu Jan 8 14:47:21 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A7728C0E7 for ; Thu, 8 Jan 2009 14:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zB8vE5SY3LU6 for ; Thu, 8 Jan 2009 14:47:20 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C74DE3A6A47 for ; Thu, 8 Jan 2009 14:47:19 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08MYdo2077131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 15:34:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08MYd1T077130; Thu, 8 Jan 2009 15:34:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08MYRdZ077113 for ; Thu, 8 Jan 2009 15:34:37 -0700 (MST) (envelope-from tz2026@gmail.com) Received: by yw-out-1718.google.com with SMTP id 5so4319672ywr.4 for ; Thu, 08 Jan 2009 14:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=BlFUTgdejZ7cDfV+um7+KwJycPa2BSNo4VuMo0p9Ew4=; b=T2djD9o3QRYcC9cW3A/O/NIxQn9/nNjd5nRmMMY4HQHxp8iLu8V7YLOzeNC5bbvWdQ Z7G8EDjooee/HC0YNtdx5NKN4BZ+vMAeg/qBjt35kcF6+npMzonrbxjGyxsJhzH2yVqL hmBrMrFwYirhZvCvfhxtEvU3kVC6jMqnoC71s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=fUSOxgiq+Dk+nZMUiQ3Zh5dmLMDnHC279Gdp+MhZa0Dwoy4eRHPTgKWb10D6adVLv9 9yXUEbmqUl0l3v5tlJ+HHEbgevw7nACp45hVapqmBVTan0/x6b2M5t8D2WS5v3rRr3Z9 RZHqRdPrzYJN/EnbxZyBRlbYaWnyw9XoZDwpk= Received: by 10.100.105.15 with SMTP id d15mr13477706anc.69.1231454065991; Thu, 08 Jan 2009 14:34:25 -0800 (PST) Received: by 10.100.194.8 with HTTP; Thu, 8 Jan 2009 14:34:25 -0800 (PST) Message-ID: <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> Date: Thu, 8 Jan 2009 16:34:25 -0600 From: tz To: "Daniel Kahn Gillmor" Subject: Re: A review of hash function brittleness in OpenPGP Cc: "IETF OpenPGP Working Group" , "Monkeysphere Developers" In-Reply-To: <49664D21.50403@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49664D21.50403@fifthhorseman.net> X-Google-Sender-Auth: 6ff59723ce354869 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The other exploit was also complex and required finding collisions which was not trivial but possible with MD5. The key seemed to be that the separate bits of the certificate were in places which made the exploit easy, e.g. the top half was either static or predictable, but there was a comment field (which could be stuffed with the bits to generate the collision), then the big prime product. To analyze the RFC, the internal structure of the key certificates which are signed need to be analyzed (first there has to be a current source for new things with MD5 anyway, I'd have to come up with two things to be signed, a real one which will be signed and the rogue one that has the same MD5 hash). I think the simplicity of the certificates might make it more difficult, but that is where I would look. I don't think there are many such things in place, but I would look if there are any legacy signers (including prominent people with older keys or implementations). I think after PGP5 it would be very unlikely, but I would look for something that allowed, requested, or forced "backward compatibility", i.e. if there are bits or something else I can cause the hash algorithm to be MD5. On Thu, Jan 8, 2009 at 12:59 PM, Daniel Kahn Gillmor wrote: > Hey folks-- > > I've been trying to evaluate RFC 4880's resistance to a hash function > compromise in light of the recent activity exploiting weaknesses MD-5 in > That Other PKI [0]. > > I'm quite pleased with the bulk of what i've found. OpenPGP's use of > message digests is almost entirely parameterized, leaving the door open > to forward-looking adoption of new hash algorithms and the smooth > deprecation as older ones are demonstrated to be weak. > > So I've been looking for places in the spec where the choice of digest > function is not parameterized. In particular, explicit and hardcoded > reliance on SHA-1 could become problematic as it is already being > deprecated. For example, reliance on SHA-1 must be eliminated in all US > Gov't federal agencies by the end of 2010 [1]. > > Here are the concerns i've found so far: > > MDC > --- > > The modification detection packets (sections 5.13 and 5.14) explicitly > specify SHA-1, and basically acknowledge that this choice may need to be > made more flexible in the future. > > Fingerprints > ------------ > > Fingerprints (section 12.2) are specified as an SHA-1 computation. > While this isn't an explicit reliance on SHA-1 for cryptographic > security (and the RFC makes it clear that there is a non-zero chance of > fingerprint collisions), the real-world use of fingerprints as unique > identifiers for keys poses a serious risk to OpenPGP infrastructure > should SHA-1 become further compromised. > > Revocation keys > --------------- > > Section 5.2.3.15 defines a way that key A can allow key B to > authoritatively issue revocation signatures on A's behalf, including key > revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and > certification revocation (sigtype 0x30). However, this mechanism relies > on the fingerprint of B being unique. Since the fingerprint itself is > bound to SHA-1, this presents a risk to users of this feature of the > specification should SHA-1 become further compromised. > > > > As the IETF working group for OpenPGP, we probably should start actively > working to resolve these issues so we can have infrastructure in place > well before SHA-1 is similarly compromised. Any suggestions? I'm new > to the WG, so i don't have any experience addressing concerns like this. > > I'm particularly concerned about fingerprints, since they is used widely > in the real world (e.g. i have my fingerprint on my business card). I > can imagine relatively straightforward technical measures to resolve the > other concerns. > > Also, it's quite likely that i've missed things in my reading of the > spec. If anyone sees any other problematic areas, it would be great to > air them as soon as possible. > > Regards, > > --dkg > > [0] http://www.phreedom.org/research/rogue-ca/ > [1] http://csrc.nist.gov/groups/ST/hash/statement.html > > From owner-ietf-openpgp@mail.imc.org Thu Jan 8 15:13:40 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60A73A67FD for ; Thu, 8 Jan 2009 15:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MATTHiugBsLo for ; Thu, 8 Jan 2009 15:13:39 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 735E03A63D3 for ; Thu, 8 Jan 2009 15:13:39 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08N4pv8078211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 16:04:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08N4puY078210; Thu, 8 Jan 2009 16:04:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08N4cjc078193 for ; Thu, 8 Jan 2009 16:04:49 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 24D7E11A65C; Fri, 9 Jan 2009 00:04:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id AE425598099; Fri, 9 Jan 2009 00:04:35 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9eeKjzCCRkrV; Fri, 9 Jan 2009 00:04:35 +0100 (CET) Received: from [10.0.0.164] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id 5882F598092; Fri, 9 Jan 2009 00:04:35 +0100 (CET) Message-ID: <49668683.4070601@epointsystem.org> Date: Fri, 09 Jan 2009 00:04:35 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Daniel Kahn Gillmor CC: IETF OpenPGP Working Group , Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> In-Reply-To: <49664D21.50403@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD37C0D29BCC3DA75DB8EEFFA" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD37C0D29BCC3DA75DB8EEFFA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, First off, thank you for such a swift reaction to one of the most serious= cryptographic vulnerabilities discovered in recent times. Let me just com= ment on your comments. Daniel Kahn Gillmor wrote: > MDC > --- >=20 > The modification detection packets (sections 5.13 and 5.14) explicitly > specify SHA-1, and basically acknowledge that this choice may need to b= e > made more flexible in the future. We should be very careful here. By being more flexible on MDCs, one makes= the system less secure. After all, it is sufficient to forge ONE of the valid= MDC functions for the MDC-protected packet to check. There is a reason (with = a good discussion in the archives of this list, if I am not mistaken) why there = is no algorithm agility in OpenPGP MDC. Also, MDC needs to be secure against second pre-images, not against colli= sions. Collision-resistance is not a requirement for MDCs. > Fingerprints > ------------ >=20 > Fingerprints (section 12.2) are specified as an SHA-1 computation. > While this isn't an explicit reliance on SHA-1 for cryptographic > security (and the RFC makes it clear that there is a non-zero chance of= > fingerprint collisions), the real-world use of fingerprints as unique > identifiers for keys poses a serious risk to OpenPGP infrastructure > should SHA-1 become further compromised. There are many more problems with current OpenPGP key IDs and fingerprint= s. I think that these are in need of a major overhaul. Here are two other prob= lems with fingerprints and keyIDs: Creation date is hashed in the fingerprint, thereby allowing the same key= with different fingerprints of which 31 bits are of the attacker's choosing, effectively shaving off 31 bits off the attacker's task (in other words, = making it 2 billion times easier on average). Also, fingerprints and key IDs are hexadecimal, which makes them super-inconvenient with mobile phones with numeric keypads. > Revocation keys > --------------- >=20 > Section 5.2.3.15 defines a way that key A can allow key B to > authoritatively issue revocation signatures on A's behalf, including ke= y > revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and > certification revocation (sigtype 0x30). However, this mechanism relie= s > on the fingerprint of B being unique. Since the fingerprint itself is > bound to SHA-1, this presents a risk to users of this feature of the > specification should SHA-1 become further compromised. Again, collisions don't seem to be a problem here. > As the IETF working group for OpenPGP, we probably should start activel= y > working to resolve these issues so we can have infrastructure in place > well before SHA-1 is similarly compromised. Any suggestions? I'm new > to the WG, so i don't have any experience addressing concerns like this= =2E >=20 > I'm particularly concerned about fingerprints, since they is used widel= y > in the real world (e.g. i have my fingerprint on my business card). I > can imagine relatively straightforward technical measures to resolve th= e > other concerns. I think, fingerprints should be dealt with as part of the shift to v5 key= s. However, formulating reasonable requirements for fingerprints sounds like= a good way to kick off the design process of v5 key format specification. I will= write up a few ideas soon. Regards, --=20 Daniel --------------enigD37C0D29BCC3DA75DB8EEFFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAklmhoMACgkQi+vAY9cJzcIhRACdHfMgggT758vw286TCaPTVBya eHQAoKA9yY2f9E9rq7rdtZFB9Df18qfa =yOQD -----END PGP SIGNATURE----- --------------enigD37C0D29BCC3DA75DB8EEFFA-- From owner-ietf-openpgp@mail.imc.org Thu Jan 8 15:29:42 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8DB3A67FD for ; Thu, 8 Jan 2009 15:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSiq4cP41v2i for ; Thu, 8 Jan 2009 15:29:41 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EDE663A67A3 for ; Thu, 8 Jan 2009 15:29:40 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08NIbk4078835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 16:18:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08NIbSs078834; Thu, 8 Jan 2009 16:18:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n08NIQEg078820 for ; Thu, 8 Jan 2009 16:18:36 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 60353 invoked from network); 8 Jan 2009 23:18:24 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay03.pair.com with SMTP; 8 Jan 2009 23:18:24 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49668A41.1030402@fifthhorseman.net> Date: Thu, 08 Jan 2009 18:20:33 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> In-Reply-To: <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2424D1A17CE941F82629DA06" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2424D1A17CE941F82629DA06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/08/2009 05:34 PM, tz wrote: > To analyze the RFC, the internal structure of the key certificates > which are signed need to be analyzed (first there has to be a current > source for new things with MD5 anyway, I'd have to come up with two > things to be signed, a real one which will be signed and the rogue one > that has the same MD5 hash). =20 I suppose i should have been more explicit: i'm not concerned about this specific attack working against OpenPGP. It just got me to thinking about various ways that an abused hash function could cause a PKI failure, and how the community around that PKI could respond to such an attack. The X.509 community was able to respond by further deprecating MD5 because there was a parameterized method in place to switch to another hash function. OpenPGP currently has this in place almost everywhere a hash function is used. That's good! However, there are a few places where we don't have that agility, which is what i was trying to highlight. Actually doing the switch from one hash algorithm to another within a well-defined parameterized structure is a chore, but it's doable. My concern is that there are places in OpenPGP (fingerprints being the most worrisome place) where we would be unable to actually make such a transition should there be a cryptographic result rendering that hash function unusable. > I don't think there are many such things in place, but I would look if > there are any legacy signers (including prominent people with older > keys or implementations). I think after PGP5 it would be very > unlikely, but I would look for something that allowed, requested, or > forced "backward compatibility", i.e. if there are bits or something > else I can cause the hash algorithm to be MD5. Doing a test of common implementations of OpenPGP to see if they give adequate warnings based on use of deprecated algorithms would be good, though this was not intended to be the point of my initial message. For example, the following series of commands generates warnings on signature creation, but not on signature verification, afaict: echo test > test gpg --digest-algo MD5 --clearsign test gpg --verify test.asc Is this the desired behavior? Or should there be a warning during verification that the signature was based on a deprecated hash? What about during certification verification or web of trust calculations? How do other implementations approach this scenario? --dkg --------------enig2424D1A17CE941F82629DA06 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSWaKQszS7ZTSFznpAQIeow//R2qa8VORXDGsv7GqYVM6M+2/COFxo5iP YYNpybG5JVGFzQVXOX6/WXU5W+Z7B3MaHbT79aLduUFm9brQK2dU969y3Slgtq/C H5Y2ByzExGnX0ijfW3yNSaTVUTImlaTLcsMpVuJpDIX2Ho6jRLhlfe31NrXbcN2r lFpjQDWDY90FQVv8nFHszXhdVwhi9G0/SvLO/NoGa5+eDHthwxJEiLLqG3jG/w46 94A5JfWsVgL9IuYTT60/pO6/EmS+/+szRvzLGcjyxI1cTO0Wj7YzbFNb4fZmQiVg 09zPseaGKdz5CWK1mpXgTsE6lm7zbvqiOFUDJe9kFj/LPqzdSd7nUD1slyr7lYxm +ZHTfO8dvF38DtWXdFLUwak+BhqdiSGq2zV0vCC9vPJPT2bXCMGWORw3j99vi0pW TsSnlgVpehVWan38jjG9yJhCiSkQvOkotTxqcxG4t86nz1qsqxdkOgJNnk9ahLbi Jk9B8iusTI+crw8rAMP6YqVB5wFFFOKLEdzo0y3AgmgClveejA2BjJSIhzUki0Dp Xsqd5oRI8p+2n4AdfFosbPa+oasIyTSgjkWy8aKoixNfBH7ENnq8UgPGKAhIwoRl 8Wu0/l9k1J5ts0mwSJ/a+UacPnVBj/6dDi7mDm4JKvPiOE4Mqcwp20HXWu3BTnQv aJGeXCJ+fMw= =26t4 -----END PGP SIGNATURE----- --------------enig2424D1A17CE941F82629DA06-- From owner-ietf-openpgp@mail.imc.org Thu Jan 8 16:16:27 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABEA828C0EB for ; Thu, 8 Jan 2009 16:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jonqyZIwreJ7 for ; Thu, 8 Jan 2009 16:16:27 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8A9C728C0E8 for ; Thu, 8 Jan 2009 16:16:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09047I3081015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 17:04:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09047KT081014; Thu, 8 Jan 2009 17:04:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0903trO081002 for ; Thu, 8 Jan 2009 17:04:06 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 536F831A304; Fri, 9 Jan 2009 01:03:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id E6B00598099; Fri, 9 Jan 2009 01:03:53 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nD6e8urDQxDl; Fri, 9 Jan 2009 01:03:53 +0100 (CET) Received: from [10.0.0.164] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id A8ECA598092; Fri, 9 Jan 2009 01:03:53 +0100 (CET) Message-ID: <49669464.3030100@epointsystem.org> Date: Fri, 09 Jan 2009 01:03:48 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> <49668A41.1030402@fifthhorseman.net> In-Reply-To: <49668A41.1030402@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig38FEE6AF3B222376763F7771" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38FEE6AF3B222376763F7771 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > The X.509 community was able to respond by further deprecating MD5 > because there was a parameterized method in place to switch to another > hash function. OpenPGP currently has this in place almost everywhere a= > hash function is used. That's good! As far as I can judge, X.509 PKI is still in the state of catastrophic fa= ilure with no obvious way out. Right now, if my browser (or yours, or anybody else's) tells me that the = site I am browsing presented a certificate issued to it by a legitimate CA, I ca= nnot be sure that this assertion is true. Rejecting all certificates with MD5 in = their signatures is not a solution (there are too many out there and replacing = them requires non-trivial cooperation between different parties; no-one can do= it acting alone). Not issuing any more MD5-based certificates is not a solut= ion (who knows how many rogue CAs are already out there?). In fact, I do not = see an easy and cheap solution out of this mess. It is a good thought-experiment to assess the consequences of an existent= ial collision attack on SHA1 such as the one we have for MD5 on OpenPGP secur= ity, considering all the places where SHA1 is wired in. I haven't checked ever= y corner of RFC4880, but I can see no catastrophic failure akin to what hap= pened to X.509 PKI. --=20 Daniel --------------enig38FEE6AF3B222376763F7771 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAklmlGkACgkQi+vAY9cJzcKt9gCgmsVFjhMTIeBEzsnHAWq1DyJN ChUAnA/j8B1AlHDeYcxBs6Qd52KZ0w6C =9C8G -----END PGP SIGNATURE----- --------------enig38FEE6AF3B222376763F7771-- From owner-ietf-openpgp@mail.imc.org Fri Jan 9 07:05:56 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CE23A68FF for ; Fri, 9 Jan 2009 07:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 861qGeErhc4n for ; Fri, 9 Jan 2009 07:05:55 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C647F3A6358 for ; Fri, 9 Jan 2009 07:05:54 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09EpLTZ020162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 07:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09EpKYM020161; Fri, 9 Jan 2009 07:51:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09Ep7rs020150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2009 07:51:20 -0700 (MST) (envelope-from ben@links.org) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5669933C1F; Fri, 9 Jan 2009 14:52:40 +0000 (GMT) Message-ID: <4967645F.5090206@links.org> Date: Fri, 09 Jan 2009 14:51:11 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Cryptography , OpenPGP Subject: OpenPGP:SDK v0.9 released X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I thought people might be interested in this now somewhat-complete, BSD-licensed OpenPGP library... http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9 -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From openrehearsal@rpo.co.uk Fri Jan 9 07:57:27 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A213A6889 for ; Fri, 9 Jan 2009 07:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -48.613 X-Spam-Level: X-Spam-Status: No, score=-48.613 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d54Q+iiIEz72 for ; Fri, 9 Jan 2009 07:57:27 -0800 (PST) Received: from mta.email.webmd.com (unknown [94.178.28.179]) by core3.amsl.com (Postfix) with SMTP id 39D7A3A680D for ; Fri, 9 Jan 2009 07:57:25 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20090109055710.7306.qmail@mta.email.webmd.com> From: "Doctor Yale Shulman, MD" To: openpgp-archive@ietf.org Subject:&&&&58553975 Stamford Hospital/Medicine/Endocrinology &r&i MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Fri, 9 Jan 2009 07:57:25 -0800 (PST)
From owner-ietf-openpgp@mail.imc.org Fri Jan 9 15:43:35 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFF803A684F for ; Fri, 9 Jan 2009 15:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNhpZW6XRWrS for ; Fri, 9 Jan 2009 15:43:34 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 17EA13A6819 for ; Fri, 9 Jan 2009 15:43:33 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09NSQbV048916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 16:28:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09NSQKS048915; Fri, 9 Jan 2009 16:28:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09NSEAe048909 for ; Fri, 9 Jan 2009 16:28:24 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id D02832E0DF for ; Fri, 9 Jan 2009 15:28:40 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13602-08 for ; Fri, 9 Jan 2009 15:28:33 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 868952E0C9 for ; Fri, 9 Jan 2009 15:28:33 -0800 (PST) Received: from [192.168.2.91] ([64.1.215.244]) by keys.merrymeet.com (PGP Universal service); Fri, 09 Jan 2009 14:29:07 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 09 Jan 2009 14:29:07 -0800 Cc: IETF OpenPGP Working Group , Monkeysphere Developers Message-Id: <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> From: Jon Callas To: Daniel Kahn Gillmor In-Reply-To: <49664D21.50403@fifthhorseman.net> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: A review of hash function brittleness in OpenPGP Date: Fri, 9 Jan 2009 15:28:03 -0800 References: <49664D21.50403@fifthhorseman.net> X-Mailer: Apple Mail (2.929.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2009, at 10:59 AM, Daniel Kahn Gillmor wrote: > * PGP Signed by an unknown key > > Hey folks-- > > I've been trying to evaluate RFC 4880's resistance to a hash function > compromise in light of the recent activity exploiting weaknesses > MD-5 in > That Other PKI [0]. > > I'm quite pleased with the bulk of what i've found. OpenPGP's use of > message digests is almost entirely parameterized, leaving the door > open > to forward-looking adoption of new hash algorithms and the smooth > deprecation as older ones are demonstrated to be weak. Great comments. > > > So I've been looking for places in the spec where the choice of digest > function is not parameterized. In particular, explicit and hardcoded > reliance on SHA-1 could become problematic as it is already being > deprecated. For example, reliance on SHA-1 must be eliminated in > all US > Gov't federal agencies by the end of 2010 [1]. > > Here are the concerns i've found so far: > > MDC > --- > > The modification detection packets (sections 5.13 and 5.14) explicitly > specify SHA-1, and basically acknowledge that this choice may need > to be > made more flexible in the future. Yes. Let me add an historic note. The MDC occupies an odd position. There is an obvious, easy, supported way to create an integrity- protected message: you sign it. The problem is that an unsigned message is pretty vulnerable to many problems from cut-and-paste attacks on. A number of people wanted to do something about that problem -- you want an unsigned message that has a reasonable guarantee that it arrived whole. Most people didn't see the threat. Outside this working group, almost no one did. Even inside the working group we were ambivalent about it. The solution as you see it was a compromise among us, and as a compromise it means we're all a bit ambivalent about it. In retrospect, an MAC would have been a better solution, but brought up a new set of issues like what key to use. HMACs were developed *during* the MDC discussions, and the proof of security for HMAC was done *after* we all agreed. The implementors didn't want to do an HMAC for performance reasons, especially for streaming, and again -- there was no proof of security. HMAC was this new thing that Hugo and Shai did. Since then, there are also obvious answers for KDFs as well. Despite this, it's a fine construction. It does what it was intended to do, and the known weaknesses of SHA-1 do not affect it at all. We are not relying on collision-resistance, we are relying on one- wayness. Remember, this is an *unauthenticated*, but whole message. If you want to authenticate the message, we have some nice digital signatures to offer you. Since then, there have been several attacks against the OpenPGP formats that are thwarted by the MDC. If we want to upgrade the MDC, we know how to do it, that's outlined in 4880. (Let me put on my hash-designer's hat for a moment. In Skein, we created a one-pass MAC construction that can replace HMAC. It also has a proof of security. I think it would be best to wait a while longer to see what comes out of the SHA3 competition, because it's likely that it will yield KDFs and hash-based MACs that answer all of the concerns that lead us to the present MDC compromise. They'll be fast, easy, and one-pass.) > > > Fingerprints > ------------ > > Fingerprints (section 12.2) are specified as an SHA-1 computation. > While this isn't an explicit reliance on SHA-1 for cryptographic > security (and the RFC makes it clear that there is a non-zero chance > of > fingerprint collisions), the real-world use of fingerprints as unique > identifiers for keys poses a serious risk to OpenPGP infrastructure > should SHA-1 become further compromised. There's a proposal for a new way to do fingerprints. I will do it the injustice of summarizing it: You express a fingerprint as the algorithm number, a colon, and then the hexadecimal. Truncations are handled in some obvious manner. Presently, for better or worse, a key id is the low-order 64 bits of a fingerprint, so we probably have to stick with that, despite the gnashing of teeth many of us will have. Under that proposal, one of my fingerprints (DFA7 517E 2BF4 6834 6C15 C029 B137 9D59 9383 DE06) could also be expressed as (2:DFA7 517E 2BF4 6834 6C15 C029 B137 9D59 9383 DE06) because SHA-1 has the algorithm number of 2. All we need is someone to write this up as an I-D -- or code it up preemptively. > > > Revocation keys > --------------- > > Section 5.2.3.15 defines a way that key A can allow key B to > authoritatively issue revocation signatures on A's behalf, including > key > revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and > certification revocation (sigtype 0x30). However, this mechanism > relies > on the fingerprint of B being unique. Since the fingerprint itself is > bound to SHA-1, this presents a risk to users of this feature of the > specification should SHA-1 become further compromised. > Solved by upgrading fingerprints and three more paragraphs of text. > > > As the IETF working group for OpenPGP, we probably should start > actively > working to resolve these issues so we can have infrastructure in place > well before SHA-1 is similarly compromised. Any suggestions? I'm new > to the WG, so i don't have any experience addressing concerns like > this. > > I'm particularly concerned about fingerprints, since they is used > widely > in the real world (e.g. i have my fingerprint on my business card). I > can imagine relatively straightforward technical measures to resolve > the > other concerns. > > Also, it's quite likely that i've missed things in my reading of the > spec. If anyone sees any other problematic areas, it would be great > to > air them as soon as possible. Are you volunteering to write a document? > > > Regards, > > --dkg > > [0] http://www.phreedom.org/research/rogue-ca/ > [1] http://csrc.nist.gov/groups/ST/hash/statement.html > > > * Unknown Key > * 0xD21739E9 -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJZ8+zsTedWZOD3gYRAkutAJ0Wo0iRVUNDaF1KAw//GocHyI+PbwCgzdZ8 pWhsc6izhtYXW5MYUnkiwVA= =6Xt5 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 9 16:26:03 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A00F3A684F for ; Fri, 9 Jan 2009 16:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+vIPpIJ0sTW for ; Fri, 9 Jan 2009 16:26:02 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BB6773A6767 for ; Fri, 9 Jan 2009 16:26:01 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0A0GVvn051307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 17:16:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0A0GVbo051306; Fri, 9 Jan 2009 17:16:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0A0GJR8051296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2009 17:16:31 -0700 (MST) (envelope-from ben@links.org) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 820F733C1E; Sat, 10 Jan 2009 00:17:52 +0000 (GMT) Message-ID: <4967E8D7.6000505@links.org> Date: Sat, 10 Jan 2009 00:16:23 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Jon Callas CC: Daniel Kahn Gillmor , IETF OpenPGP Working Group , Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> In-Reply-To: <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > (Let me put on my hash-designer's hat for a moment. In Skein, we > created a one-pass MAC construction that can replace HMAC. It also has > a proof of security. I wish people would stop saying that things have "a proof of security". Rot13 has a proof of security, but I don't want to use it. You need to state what security properties you have proved. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From janos.demko@allianz.hu Sat Jan 10 05:24:18 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC1028C1AE for ; Sat, 10 Jan 2009 05:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.829 X-Spam-Level: X-Spam-Status: No, score=-33.829 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_RU=0.595, HOST_EQ_BROADBND=1.118, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh21+fTM2B8U for ; Sat, 10 Jan 2009 05:24:16 -0800 (PST) Received: from 93-80-201-11.broadband.corbina.ru (93-80-201-11.broadband.corbina.ru [93.80.201.11]) by core3.amsl.com (Postfix) with SMTP id 2A9C928C19E for ; Sat, 10 Jan 2009 05:24:14 -0800 (PST) To: Subject: Your order 60740 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110132415.2A9C928C19E@core3.amsl.com> Date: Sat, 10 Jan 2009 05:24:14 -0800 (PST)

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 22832
From nblecleeclere@ab1cs.com Sat Jan 10 10:31:39 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3922D3A6874 for ; Sat, 10 Jan 2009 10:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.783 X-Spam-Level: X-Spam-Status: No, score=-14.783 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c++2lMUuJazJ for ; Sat, 10 Jan 2009 10:31:37 -0800 (PST) Received: from 201.86.132.31.adsl.gvt.net.br (189.27.17.229.adsl.gvt.net.br [189.27.17.229]) by core3.amsl.com (Postfix) with SMTP id 395C33A6828 for ; Sat, 10 Jan 2009 10:31:35 -0800 (PST) To: Subject: Your order 52250 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110183136.395C33A6828@core3.amsl.com> Date: Sat, 10 Jan 2009 10:31:35 -0800 (PST)

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 31201
From owner-ietf-openpgp@mail.imc.org Sat Jan 10 14:09:11 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40D03A6921 for ; Sat, 10 Jan 2009 14:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHau7UgyUTpk for ; Sat, 10 Jan 2009 14:09:10 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0C0C93A6861 for ; Sat, 10 Jan 2009 14:09:09 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ALujgG007107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 14:56:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0ALuj2F007106; Sat, 10 Jan 2009 14:56:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ALuXnD007094 for ; Sat, 10 Jan 2009 14:56:43 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 619DE2E215 for ; Sat, 10 Jan 2009 13:57:00 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 48622-06 for ; Sat, 10 Jan 2009 13:56:55 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 6194E2E0D5 for ; Sat, 10 Jan 2009 13:56:55 -0800 (PST) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Sat, 10 Jan 2009 12:57:28 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sat, 10 Jan 2009 12:57:28 -0800 Cc: Daniel Kahn Gillmor , IETF OpenPGP Working Group , Monkeysphere Developers Message-Id: <40B5334D-6A89-4121-98AA-04654DE91C86@callas.org> From: Jon Callas To: Ben Laurie In-Reply-To: <4967E8D7.6000505@links.org> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: A review of hash function brittleness in OpenPGP Date: Sat, 10 Jan 2009 13:56:24 -0800 References: <49664D21.50403@fifthhorseman.net> <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> <4967E8D7.6000505@links.org> X-Mailer: Apple Mail (2.929.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote: > > Jon Callas wrote: >> (Let me put on my hash-designer's hat for a moment. In Skein, we >> created a one-pass MAC construction that can replace HMAC. It also >> has >> a proof of security. > > I wish people would stop saying that things have "a proof of > security". > Rot13 has a proof of security, but I don't want to use it. You need to > state what security properties you have proved. If we're going to get picky, Rot-13 is not a cipher, it's a code. It has similar security properies to ASCII, which is a related code. But you're right -- on another list I'm on, there was someone who made the comment that there's no theoretically perfect cryptography. I almost replied that the Caesar cipher (which is ROT-N) has perfect security, just an inadequate key space. Nonetheless, you're right. Many people including me sneer at security proofs. The list of things that have had proofs of security and then fallen over is large. There are plenty of proofs of security that have some people raise an eyebrow. For example, we say that HMAC is secure on today's slightly dodgy hash functions because of a proof of security, but that proof relies on properties of the hash function we're not sure they have. (Niels Ferguson was the first person I know to bring this up, and for the most part, we all whistle as we walk by his observations.) I think that security proofs are fundamentally lacking in basic foundations. There's a sense in which you can start with the Peano postulates for arithmetic and end up with double entry bookkeeping. We can't do anything like that in security, and it's a huge lack. Nonetheless, it's better to have a proof than not to have one. And I didn't want to turn this into a Skein discussion, I was making the aside that there are people looking at verification constructions that have properties programmers like, and I know this because I've worked on one. Go read the Skein paper. It's at . I think we've addressed your comments, because we feel the same way. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJaQu4sTedWZOD3gYRAik5AKDB0wYRnOll/Wpj0FJF9AhFMN1rfwCgkyfP 5AMtf+fg4q4y1m0Iu+h/7WA= =REWI -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Jan 11 09:24:58 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800EC28C21A for ; Sun, 11 Jan 2009 09:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEo29YgdR6yE for ; Sun, 11 Jan 2009 09:24:57 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 6B08C28C212 for ; Sun, 11 Jan 2009 09:24:57 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BH4J4L056382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 10:04:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BH4Jwn056381; Sun, 11 Jan 2009 10:04:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BH45Gk056368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 11 Jan 2009 10:04:18 -0700 (MST) (envelope-from fw@deneb.enyo.de) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1LM3jH-0007yw-D5; Sun, 11 Jan 2009 18:04:03 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1LM3jG-0006vJ-R0; Sun, 11 Jan 2009 18:04:02 +0100 From: Florian Weimer To: Daniel Kahn Gillmor Cc: IETF OpenPGP Working Group Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> Date: Sun, 11 Jan 2009 18:04:02 +0100 In-Reply-To: <49664D21.50403@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 08 Jan 2009 13:59:45 -0500") Message-ID: <87sknp22rh.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Daniel Kahn Gillmor: > Also, it's quite likely that i've missed things in my reading of the > spec. If anyone sees any other problematic areas, it would be great to > air them as soon as possible. There's the issue of V3 keys. If packet formats are changed once again, it could make sense to incorporate random blobs near the start of the packets, so that an attacker cannot predict the internal state of the hash function when a signature is created. OpenPGP does not need the convergent property of hash functions. From netafricadivesafarisdul@africadivesafaris.com Mon Jan 12 11:14:27 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC4563A6A40 for ; Mon, 12 Jan 2009 11:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.673 X-Spam-Level: X-Spam-Status: No, score=-34.673 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WqMwhE1X80N for ; Mon, 12 Jan 2009 11:14:27 -0800 (PST) Received: from 84-252-55-212.2073194174.ddns-lan.pz.ekk.bg (84-252-55-212.2073194174.ddns-lan.pz.ekk.bg [84.252.55.212]) by core3.amsl.com (Postfix) with SMTP id F3D903A68F7 for ; Mon, 12 Jan 2009 11:14:24 -0800 (PST) To: Subject: RE: Message 76118 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112191425.F3D903A68F7@core3.amsl.com> Date: Mon, 12 Jan 2009 11:14:24 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 02362
From lucia.cooper@akzonobel.com Mon Jan 12 22:30:02 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325FB3A67ED for ; Mon, 12 Jan 2009 22:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.768 X-Spam-Level: X-Spam-Status: No, score=-31.768 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaL91EN+Or1Z for ; Mon, 12 Jan 2009 22:29:56 -0800 (PST) Received: from 217.102.221.62.dyn.idknet.com (217.102.221.62.dyn.idknet.com [62.221.102.217]) by core3.amsl.com (Postfix) with SMTP id 62B653A67D1 for ; Mon, 12 Jan 2009 22:29:54 -0800 (PST) To: Subject: Re: Order status 55133 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113062955.62B653A67D1@core3.amsl.com> Date: Mon, 12 Jan 2009 22:29:54 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 43362
From owner-ietf-openpgp@mail.imc.org Mon Jan 12 23:07:20 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5F93A68CB for ; Mon, 12 Jan 2009 23:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.984 X-Spam-Level: X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qs0tMj2L+43q for ; Mon, 12 Jan 2009 23:07:20 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A860E3A6886 for ; Mon, 12 Jan 2009 23:07:19 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0D6oT9t064670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 23:50:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0D6oTkF064669; Mon, 12 Jan 2009 23:50:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0D6oIM0064659 for ; Mon, 12 Jan 2009 23:50:29 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 12BBF19A6C for ; Tue, 13 Jan 2009 19:50:17 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqwP3V-CJ321 for ; Tue, 13 Jan 2009 19:50:16 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0039219AB3 for ; Tue, 13 Jan 2009 19:50:11 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 801AA1AE4003 for ; Tue, 13 Jan 2009 19:50:10 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LMd6I-0007Fr-CP for ietf-openpgp@imc.org; Tue, 13 Jan 2009 19:50:10 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org Subject: Re: A review of hash function brittleness in OpenPGP Message-Id: Date: Tue, 13 Jan 2009 19:50:10 +1300 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes: >Jon Callas wrote: >> (Let me put on my hash-designer's hat for a moment. In Skein, we >> created a one-pass MAC construction that can replace HMAC. It also has >> a proof of security. > >I wish people would stop saying that things have "a proof of security". Rot13 >has a proof of security, but I don't want to use it. You need to state what >security properties you have proved. On the subject of provable security, I've just been reading a paper that provides a rigorous proof that a particular security mechanism is secure (under appropriate assumptions regarding the cryptographic functions used). Unfortunately this is a mechanism that's a slight variant of "click-OK-to- continue", which means that it's close to worthless in practice (this result both anecdotally and from a number of HCI papers that have evaluated it). So this would be a prime example of a rigorous provably-secure crypto mechanism that thirty seconds of googling or a beer's worth of analysis would show doesn't actually work. (I haven't mentioned the paper name because I'm not trying to attack the author, just using it as a nice example of a provably secure but practically insecure mechanism, I can provide details in private email if anyone really wants to know). Peter. From owner-ietf-openpgp@mail.imc.org Tue Jan 13 03:48:45 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C793A69BF for ; Tue, 13 Jan 2009 03:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3i9m+GTsEtz for ; Tue, 13 Jan 2009 03:48:44 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 620B43A68B0 for ; Tue, 13 Jan 2009 03:48:44 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DBUiTb081619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 04:30:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DBUinV081618; Tue, 13 Jan 2009 04:30:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DBUUYT081607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2009 04:30:42 -0700 (MST) (envelope-from ben@links.org) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AD45C33C21; Tue, 13 Jan 2009 11:32:02 +0000 (GMT) Message-ID: <496C7B5D.7010908@links.org> Date: Tue, 13 Jan 2009 11:30:37 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Jon Callas CC: Daniel Kahn Gillmor , IETF OpenPGP Working Group , Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> <4967E8D7.6000505@links.org> <40B5334D-6A89-4121-98AA-04654DE91C86@callas.org> In-Reply-To: <40B5334D-6A89-4121-98AA-04654DE91C86@callas.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote: > >> Jon Callas wrote: >>> (Let me put on my hash-designer's hat for a moment. In Skein, we >>> created a one-pass MAC construction that can replace HMAC. It also >>> has >>> a proof of security. >> I wish people would stop saying that things have "a proof of >> security". >> Rot13 has a proof of security, but I don't want to use it. You need to >> state what security properties you have proved. > > If we're going to get picky, Rot-13 is not a cipher, it's a code. So what? > It > has similar security properies to ASCII, which is a related code. But > you're right -- on another list I'm on, there was someone who made the > comment that there's no theoretically perfect cryptography. I almost > replied that the Caesar cipher (which is ROT-N) has perfect security, > just an inadequate key space. > > Nonetheless, you're right. Many people including me sneer at security > proofs. Then why mention them? > The list of things that have had proofs of security and then > fallen over is large. There are plenty of proofs of security that have > some people raise an eyebrow. For example, we say that HMAC is secure > on today's slightly dodgy hash functions because of a proof of > security, but that proof relies on properties of the hash function > we're not sure they have. (Niels Ferguson was the first person I know > to bring this up, and for the most part, we all whistle as we walk by > his observations.) > > I think that security proofs are fundamentally lacking in basic > foundations. There's a sense in which you can start with the Peano > postulates for arithmetic and end up with double entry bookkeeping. We > can't do anything like that in security, and it's a huge lack. > > Nonetheless, it's better to have a proof than not to have one. If the proof proves something useful, then indeed it is better. But once more, saying "it has a security proof" provides no useful information. > And I > didn't want to turn this into a Skein discussion, I was making the > aside that there are people looking at verification constructions that > have properties programmers like, and I know this because I've worked > on one. > > Go read the Skein paper. It's at . I think > we've addressed your comments, because we feel the same way. I have read the Skein paper. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From jprasadd@aig.com Tue Jan 13 13:27:02 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D736D3A69C9 for ; Tue, 13 Jan 2009 13:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.839 X-Spam-Level: X-Spam-Status: No, score=-11.839 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0I5jClk1TYJg for ; Tue, 13 Jan 2009 13:27:02 -0800 (PST) Received: from ahm.honda.com (unknown [189.13.188.8]) by core3.amsl.com (Postfix) with SMTP id 21D673A689E for ; Tue, 13 Jan 2009 13:26:58 -0800 (PST) To: Subject: Your order 87959 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113212701.21D673A689E@core3.amsl.com> Date: Tue, 13 Jan 2009 13:26:58 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 56085
From lcm@amchk.com Wed Jan 14 12:44:11 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6C33A688B for ; Wed, 14 Jan 2009 12:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.889 X-Spam-Level: X-Spam-Status: No, score=-6.889 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5W1jc6c+Ac8 for ; Wed, 14 Jan 2009 12:44:10 -0800 (PST) Received: from ip-212-59-24-31.static.b4net.lt (ip-212-59-24-31.static.b4net.lt [212.59.24.31]) by core3.amsl.com (Postfix) with SMTP id 26E583A68C3 for ; Wed, 14 Jan 2009 12:44:08 -0800 (PST) To: Subject: Re: Order status 16247 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114204409.26E583A68C3@core3.amsl.com> Date: Wed, 14 Jan 2009 12:44:08 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 25131
From mbrodriguez@afip.gov.ar Sat Jan 17 14:05:49 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAAD3A6B44 for ; Sat, 17 Jan 2009 14:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YLirAcBZYLE for ; Sat, 17 Jan 2009 14:05:46 -0800 (PST) Received: from 201-1-215-86.dsl.telesp.net.br (201-1-215-86.dsl.telesp.net.br [201.1.215.86]) by core3.amsl.com (Postfix) with SMTP id 3A6C73A6A9E for ; Sat, 17 Jan 2009 14:05:42 -0800 (PST) To: Subject: News from Microsoft From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090117220544.3A6C73A6A9E@core3.amsl.com> Date: Sat, 17 Jan 2009 14:05:42 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 73522
From mannarino@ageofawareness.com Sat Jan 17 23:57:38 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98293A6810 for ; Sat, 17 Jan 2009 23:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wonFL955-qg6 for ; Sat, 17 Jan 2009 23:57:37 -0800 (PST) Received: from 85-250-50-194.bb.netvision.net.il (85-250-50-194.bb.netvision.net.il [85.250.50.194]) by core3.amsl.com (Postfix) with SMTP id 6D0083A67B3 for ; Sat, 17 Jan 2009 23:57:35 -0800 (PST) To: Subject: Re: SPECIAL OFFERS From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090118075736.6D0083A67B3@core3.amsl.com> Date: Sat, 17 Jan 2009 23:57:35 -0800 (PST)
January 16, 2009 | "SPECIAL OFFERS"-Pfizer Company!




Contact: Email Administrator, Pfizer World Headquarters 629 E. 42nd Street New York, NY 85781
® 2001-2009 Pfizer Inc. All rights reserved!
Pfizer is a licensee of the TRUSTe Privacy Program!, click here.

» Help  »Advertise  »Terms of Service  »Privacy Policy
From kmellwood@agpcommunity.com Sun Jan 18 03:24:32 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE3F28C105 for ; Sun, 18 Jan 2009 03:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.896 X-Spam-Level: X-Spam-Status: No, score=-11.896 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6wBkMX+AcCQ for ; Sun, 18 Jan 2009 03:24:31 -0800 (PST) Received: from amada.com (unknown [118.233.35.95]) by core3.amsl.com (Postfix) with SMTP id 9F63628C0F6 for ; Sun, 18 Jan 2009 03:24:28 -0800 (PST) To: Subject: Re: Pfizer Admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 081004-0, 2008/10/04), Outbound message X-Antivirus-Status: Clean Message-Id: <20090118112429.9F63628C0F6@core3.amsl.com> Date: Sun, 18 Jan 2009 03:24:28 -0800 (PST)
January 16, 2009 | "SPECIAL OFFERS"-Pfizer Company!




Contact: Email Administrator, Pfizer World Headquarters 399 E. 42nd Street New York, NY 13734
® 2001-2009 Pfizer Inc. All rights reserved!
Pfizer is a licensee of the TRUSTe Privacy Program!, click here.

» Help  »Advertise  »Terms of Service  »Privacy Policy
From kloomis@acns.colostate.edu Mon Jan 19 08:49:09 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925E428C186 for ; Mon, 19 Jan 2009 08:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.139 X-Spam-Level: X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV0eyveFDq3Z for ; Mon, 19 Jan 2009 08:49:08 -0800 (PST) Received: from 201-27-216-21.dsl.telesp.net.br (201-27-216-21.dsl.telesp.net.br [201.27.216.21]) by core3.amsl.com (Postfix) with SMTP id 937D13A6A04 for ; Mon, 19 Jan 2009 08:49:06 -0800 (PST) To: Subject: Re: Getting the best results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119164907.937D13A6A04@core3.amsl.com> Date: Mon, 19 Jan 2009 08:49:06 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.casechair.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 6, B423. 576 Clements Road. London. SE68 6DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From kxptgicdkudjv@aida-event.de Mon Jan 19 13:30:30 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C36F63A6912 for ; Mon, 19 Jan 2009 13:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.303 X-Spam-Level: X-Spam-Status: No, score=-22.303 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, RELAY_IS_203=0.994, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym2LG3-SDHCQ for ; Mon, 19 Jan 2009 13:30:30 -0800 (PST) Received: from aluform.be (unknown [203.199.206.155]) by core3.amsl.com (Postfix) with SMTP id 3D5763A691E for ; Mon, 19 Jan 2009 13:30:26 -0800 (PST) To: Subject: Your order 23315 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119213028.3D5763A691E@core3.amsl.com> Date: Mon, 19 Jan 2009 13:30:26 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

c2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 27661
From libcat@agora.bungi.com Tue Jan 20 09:12:04 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41C113A6915 for ; Tue, 20 Jan 2009 09:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.461 X-Spam-Level: X-Spam-Status: No, score=-17.461 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0vH30A+2Ocx for ; Tue, 20 Jan 2009 09:11:59 -0800 (PST) Received: from chello089173141035.chello.sk (chello089173141035.chello.sk [89.173.141.35]) by core3.amsl.com (Postfix) with SMTP id 077AA3A6A53 for ; Tue, 20 Jan 2009 09:11:57 -0800 (PST) To: Subject: RE: Administrator From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120171158.077AA3A6A53@core3.amsl.com> Date: Tue, 20 Jan 2009 09:11:57 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Dont see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.coolintegrity.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://coolintegrity.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B808. 844 Clements Road. London. SE61 7DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From lmiyabiwpiltyjlg3@adc.co.jp Wed Jan 21 00:59:11 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCC2B3A6A33 for ; Wed, 21 Jan 2009 00:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.188 X-Spam-Level: X-Spam-Status: No, score=-15.188 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1AHXpfiDoOm for ; Wed, 21 Jan 2009 00:59:11 -0800 (PST) Received: from cust-78-89.on3.ontelecoms.gr (cust-78-89.on3.ontelecoms.gr [91.132.78.89]) by core3.amsl.com (Postfix) with SMTP id AAB4F3A6AB7 for ; Wed, 21 Jan 2009 00:59:09 -0800 (PST) To: Subject: Administrator, BRANDKEYWORD From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121085909.AAB4F3A6AB7@core3.amsl.com> Date: Wed, 21 Jan 2009 00:59:09 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.notedefinition.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B445. 322 Clements Road. London. SE71 1DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From jpharesi@acadian.com Wed Jan 21 04:31:56 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A6D28C0F6 for ; Wed, 21 Jan 2009 04:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.739 X-Spam-Level: X-Spam-Status: No, score=-19.739 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n61o6O4oSTWI for ; Wed, 21 Jan 2009 04:31:55 -0800 (PST) Received: from 201-94-178-73.jau.flash.tv.br (201-94-178-73.jau.flash.tv.br [201.94.178.73]) by core3.amsl.com (Postfix) with SMTP id 777C13A677E for ; Wed, 21 Jan 2009 04:31:17 -0800 (PST) To: Subject: Receipt for Your Payment From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121123120.777C13A677E@core3.amsl.com> Date: Wed, 21 Jan 2009 04:31:17 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.oilaspiration.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://oilaspiration.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B102. 926 Clements Road. London. SE99 8DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From nhyjypgjcpbj@altdesign.co.nz Wed Jan 21 08:18:46 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A8928C1EC for ; Wed, 21 Jan 2009 08:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.063 X-Spam-Level: X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, FH_HOST_EQ_DYNAMICIP=2.177, GB_I_LETTER=-2, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpf52VLpQW6v for ; Wed, 21 Jan 2009 08:18:46 -0800 (PST) Received: from 114.Red-79-146-238.dynamicIP.rima-tde.net (114.Red-79-146-238.dynamicIP.rima-tde.net [79.146.238.114]) by core3.amsl.com (Postfix) with SMTP id 79E943A699F for ; Wed, 21 Jan 2009 08:18:43 -0800 (PST) To: Subject: Welcome to eBay! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121161844.79E943A699F@core3.amsl.com> Date: Wed, 21 Jan 2009 08:18:43 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.advocacygame.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://advocacygame.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B571. 034 Clements Road. London. SE27 6DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From laserca65@amex.com Wed Jan 21 16:58:19 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0103A6A5D for ; Wed, 21 Jan 2009 16:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -44.109 X-Spam-Level: X-Spam-Status: No, score=-44.109 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOkddaBEEyxd for ; Wed, 21 Jan 2009 16:58:13 -0800 (PST) Received: from amel.tds.net (unknown [200.31.171.93]) by core3.amsl.com (Postfix) with SMTP id D17DD28C220 for ; Wed, 21 Jan 2009 16:58:10 -0800 (PST) To: Subject: Your Payment Has Been Initiated From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090122005811.D17DD28C220@core3.amsl.com> Date: Wed, 21 Jan 2009 16:58:10 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.achievementsimilar.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://achievementsimilar.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B555. 915 Clements Road. London. SE90 0DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From bounce-cgi-ipw.justinjo@eigbox.net Sat Jan 24 08:30:33 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4168028C1C8 for ; Sat, 24 Jan 2009 08:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.48 X-Spam-Level: ** X-Spam-Status: No, score=2.48 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, AWL=0.346, BAYES_60=1, GB_I_LETTER=-2, INVALID_MSGID=1.9] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT4DMCY7JQfg for ; Sat, 24 Jan 2009 08:30:32 -0800 (PST) Received: from bosmailout14.eigbox.net (bosmailout14.eigbox.net [66.96.186.14]) by core3.amsl.com (Postfix) with ESMTP id 8412328C0E5 for ; Sat, 24 Jan 2009 08:30:32 -0800 (PST) Received: from bosmailscan09.eigbox.net ([10.20.15.9]) by bosmailout14.eigbox.net with esmtp (Exim) id 1LQlOh-0003Xl-Gp for openpgp-archive@ietf.org; Sat, 24 Jan 2009 11:30:15 -0500 Received: from bosimpout01.eigbox.net ([10.20.55.1]) by bosmailscan09.eigbox.net with esmtp (Exim) id 1LQlOh-0004gY-A7 for openpgp-archive@ietf.org; Sat, 24 Jan 2009 11:30:15 -0500 Received: from boscgi1404.eigbox.net ([10.20.12.144]) by bosimpout01.eigbox.net with NO UCE id 7QDu1b00D36UUX60000000; Sat, 24 Jan 2009 07:13:54 -0500 X-EN-OrigOutIP: 10.20.12.144 X-EN-IMPSID: 7QDu1b00D36UUX60000000 Received: from ipw.justinjo by boscgi1404.eigbox.net with local (Exim) id 1LQlNz-0005Vh-D8 for openpgp-archive@ietf.org; Sat, 24 Jan 2009 11:29:31 -0500 X-EN-Info: U=ipw.justinjo P=/images/emailer.php X-EN-CGIUser: ipw.justinjo X-EN-CGIPath: /images/emailer.php X-EN-OrigIP: 212.100.69.11 Message-Id: 1232814571-ipw.justinjo@boscgi1404.eigbox.net To: openpgp-archive@ietf.org Subject: Inherited Fund From: Jonathan Archer Reply-To: jarch_rotima01@yahoo.ie MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-EN-Timestamp: Sat, 24 Jan 2009 11:29:31 -0500 Date: Sat, 24 Jan 2009 11:29:31 -0500 Sender: Jonathan Archer Hello, This is for your attention.We wish to notify you again that you were listed as a beneficiary to the total sum of £4,600,000.00GBP (Four million Six hundred thousand British Pounds Sterling) in the intent of the deceased (names now withheld since this is our second letter to you). We contacted you because you bear the surname identity and therefore can present you as the beneficiary to the inheritance since there is no written will. Our legal services aim to provide our private clients with a complete service. We are happy to prepare wills, set-up and administer Trusts, carry out the administration of estates and prepare and administer powers of attorney.All the papers will be processed in your acceptance. Upon your acceptance of this deal, we request that you kindly forward to us your letter of acceptance, reconfirming names in details ,your current telephone and fax numbers and a forwarding address to enable us file necessary documents at our High court probate division for the release of this sum of fund. Yours faithfully. Jonathan Archer Tel:+ 44 702 408 6396 From owner-ietf-openpgp@mail.imc.org Tue Jan 27 14:07:25 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4523A6A57 for ; Tue, 27 Jan 2009 14:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzMcypqYPtTc for ; Tue, 27 Jan 2009 14:07:24 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 63AC43A685C for ; Tue, 27 Jan 2009 14:07:23 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RLsMY1003991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 14:54:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RLsM4g003990; Tue, 27 Jan 2009 14:54:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RLsATv003980 for ; Tue, 27 Jan 2009 14:54:21 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so1830868fxm.10 for ; Tue, 27 Jan 2009 13:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=uwJBG5PYdKcSt2bwmfl4G/PIGYdYf+Xv6gWs7xeCI2k=; b=XCvMmOnpnL2y5drf+hQM3vw5ZKhemvi5RAYQM48G/v3uL+RTdh3xsC+Tpsusg/dZNO gOLJ6NCogwZjxXmVu6zUCP67S0lqb04hzJ1y3racaZKbe0qdZ+KnxFfCAoyI4JZSldCM ifF1AxEDDR1qL536USO34CQSkfye1hJ3vShes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZMn6UsThggh+K3wLkIBAPCkvQq1PDW3uRjPY5+7ri9mR+zi5Jqvar71iSWcF38X+uy TCxKbbicVvKdB0pS/gIPQbsFAldTT6zjJxaYmGO3FTKS6r+4yOC0F2CHaCR7WBarqDDe y1kPrnJ29tYD5M6SqYnhClVn17LQPlO+/47RM= MIME-Version: 1.0 Received: by 10.181.4.1 with SMTP id g1mr1708453bki.100.1233093249429; Tue, 27 Jan 2009 13:54:09 -0800 (PST) Date: Tue, 27 Jan 2009 22:54:09 +0100 Message-ID: <9ef756150901271354r48975a90qe93051006346dd07@mail.gmail.com> Subject: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello list. As you can see from the subject this is already the 4th email in a series of questions about OpenPGP (and in some cases gnupg). After the first three David Shaw, who perfectly answered my questions so far (lots of thanks again), asked me to move here, as it became more and more OpenPGP specific. For those who are interested (the previous ones also contained questions about OpenPGP itself, and some very great answers) you can find the other ones here: http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035445.html http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035458.html http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035467.html This time it's all about signature subpackets: Sorry that this got longer, but I think these points are all somehow connected. So feel free to split up as you like :-) I know that these questions are more about OpenPGP itself than gnupg, but perhaps you, David, can have a look at them here, before I post it on their mailing list (don't want to look stupid there ^^ and I'm still quite new in OpenPGP's standard). 1) gnupg (and as far as I can see other implementations, too) don't set the critical bit on much signature subpackets by default. The RFC (AFAIK) doesn't demand any subpacket to be understood by applications. Unknown subpackets should be ignored, except the critical bit is set. Correct so far? Now when I go through the currently defined signature subpackets, I see several which are or at least could be critical for security and for the correct evaluation of signatures: 2, 3: a signature might not be valid yet, or might be expired already 7: an attacker might manage to revoke an irrevocable signature 9: they key is expired and the owner does not want it to be used any longer (maybe also due to security reasons) 12: if an implementation doesn't understand this, it might not notice, that a key/UID is already revoked 26: the policy may contain critical information for security (e.g. "this key signs any applicant without validating his personal data) 27: it might be a security issue, if a key that was marked for certification-only (0x01) has signed some casual data 31: required for revocation signatures and thus possibly security critical 32: required for the signing subkey backsigs (0x19) I'd even consider the following as critical: 28: the signer might want to express that a specific role/UID made the signature, and this might be security critical depending on the policy Of course no one can force the user to actually read and follow these subpackets (the policy (26) is the best example for this ^^), but wouldn't it make sense that the RFC _REQUIRES_ these subpackets to be understood by conforming implementations? Just an idea, though :-) 2) Selfsignatures and possible ambiguities: In an email before David told me that it's fully ok that some signature subpackets are on 0x13 and/or 0x1F self signatures. I said I'll come back to this; here it is. The RFC is very clear (5.2.3.3) about which signature types may be self-signatures, namely 0x10-0x13, 0x1F and 0x18 (I assume 0x19 is let out, as it's made by the subkey, right?). This chapter also says that an implementation should interpret it as narrowly as possible. a) That's by the way the first "problem" which _could_ lead to secrutiy issues, as the standard doesn't define for every case what "as narrowly as possible" mean. Of course everyone could say "just follow the common human sense" but this is always problematic, isn't it? ;-) b) What for example, if a 0x13 and a 0x1F have conflicting key expiration times? Should an implementation use the time in the most recent of the two? Should it use the information from the 0x1F, as key expiration time is "clearly" related to the key, and not the the User ID? Should it just use the smallest value of the two? Should it use the value accordingly by which the key was found (if by Key ID -> use 0x1F, if by User ID -> use 0x13). One can easily think of similar examples for other subpacket types, and its easy to think of examples where this could lead to security problems (Imagine a user resets the expiration time of his key to denote that it should not longer be used. His implementation updates only the 0x13 self-signature but not the "unlimited" in the 0x1F, made by some other implementation. A third implementation may now choose the "right one" or not.) c) It's nowhere clearly specified if and what meaning these supackets have on the subkey binding self-signature (0x18) A solution would be, that the RFC clearly specifies which subpackets MAY go to which self-signature, which one takes priority, and for which the implementation is allowed to choose itself (e.g. according to the way the key was found). btw: The example on page 27 "If the key is located via Key ID => use the subpacket from the primary User ID self-signature also shows the conflict with 0x1F signatures that could arise in that case. 3) This is probably clear for everybody, but the part on revocation signatures should perhaps highlight, that all subpackets in revoked signatures MUST NOT be used, e.g. imagine the key expiration time is only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets revoked, the key has no longer an expiration time. btw: Is it specified what happens when possibly security critical subpackets like the expiration time or key usage are absent? 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration time is reset by a user (of course this cannot be prevented as the key expiration time is no longer part of the key itself). Isn't this possibility comparable to revoke a revocation? I mean the creators states: "This key SHOULD NOT be used after ." for example because he thinks an RSA786 key SHOULD no longer be used in 10 years. An attacker might simply revoke this (implicit) revocation by issuing a new self-signature with an updated date. 5) Chapter 5.2.3.3. also says what should happen when multiple self-signatures are encountered by an implementation. Wouldn't it be more secure to require that ONLY the most recent self signature of a given type (per primary key in the case of 0x1F, per User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) may be used and if that one could not be parsed (e.g. because of unknown subpackets with the critical bit set) no self-signature MUST be considered as valid? My idea is about this: Imagine a very old self-signature that still uses MD5 (which is now broken, isn't it?) and a newer (in the sense of it's signature creation time) self-signature which uses say SHA512. Both self-signatures specify a designated revoker (subpacket 12). Now an implementation doesn't understand SHA512 signatures and thus uses the older one with MD5 (as far as I understand the RFC allows to do so). But than one is probably a forged one by an attacker which doesn't contain the subpacket 12. See what I mean? I think it's quite easy to create similar examples with other subpackets involved. So a solution would be that the RFC requires, that always and only the most recent self-signature is used. Ok,.. enough for now,.. but I fear that I'm still not finished :-( Is it possible to donate a few bugs to gnupg in order to compensate the time you spend for answering my questions? Cheerio, Peter From openmindcentre@yahoo.co.uk Wed Jan 28 00:20:09 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094663A69BB for ; Wed, 28 Jan 2009 00:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.535 X-Spam-Level: X-Spam-Status: No, score=-34.535 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_DB=0.888, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYsW6CF9cdH6 for ; Wed, 28 Jan 2009 00:20:05 -0800 (PST) Received: from amerblind.outbound.ed10.com (3e44a9e7.adsl.enternet.hu [62.68.169.231]) by core3.amsl.com (Postfix) with SMTP id C783A3A6BDE for ; Wed, 28 Jan 2009 00:20:04 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: openpgp-archive@ietf.org Subject: RE: Canadian Pharmacy Message 0856172 From: openpgp-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090128082004.C783A3A6BDE@core3.amsl.com> Date: Wed, 28 Jan 2009 00:20:04 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-ietf-openpgp@mail.imc.org Wed Jan 28 11:42:06 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 385F13A693C for ; Wed, 28 Jan 2009 11:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJsgArIIhA6q for ; Wed, 28 Jan 2009 11:42:05 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 75F1E3A67DF for ; Wed, 28 Jan 2009 11:42:04 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJP3g8064984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 12:25:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SJP3B8064983; Wed, 28 Jan 2009 12:25:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJOphU064964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Jan 2009 12:25:02 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id E28D614F6E1; Wed, 28 Jan 2009 10:48:24 -0800 (PST) To: ietf-openpgp@imc.org, p4.thomas@googlemail.com Subject: Re: Series of minor questions about OpenPGP 4 Message-Id: <20090128184824.E28D614F6E1@finney.org> Date: Wed, 28 Jan 2009 10:48:24 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Peter - I will answer your questions on the assumption that you are writing OpenPGP compliant software. You are therefore asking about how you should implement your software. > 1) gnupg (and as far as I can see other implementations, too) don't > set the critical bit on much signature subpackets by default. The RFC > (AFAIK) doesn't demand any subpacket to be understood by applications. > Unknown subpackets should be ignored, except the critical bit is set. > Correct so far? > Now when I go through the currently defined signature subpackets, I > see several which are or at least could be critical for security and > for the correct evaluation of signatures: > 2, 3: a signature might not be valid yet, or might be expired already > 7: an attacker might manage to revoke an irrevocable signature > 9: they key is expired and the owner does not want it to be used any > longer (maybe also due to security reasons) > 12: if an implementation doesn't understand this, it might not notice, > that a key/UID is already revoked > 26: the policy may contain critical information for security (e.g. > "this key signs any applicant without validating his personal data) > 27: it might be a security issue, if a key that was marked for > certification-only (0x01) has signed some casual data > 31: required for revocation signatures and thus possibly security critical > 32: required for the signing subkey backsigs (0x19) > > I'd even consider the following as critical: > 28: the signer might want to express that a specific role/UID made the > signature, and this might be security critical depending on the policy > > Of course no one can force the user to actually read and follow these > subpackets (the policy (26) is the best example for this ^^), but > wouldn't it make sense that the RFC _REQUIRES_ these subpackets to be > understood by conforming implementations? > Just an idea, though :-) I would certainly encourage you to set the critical bit on these and other signature subpackets that you view as critical to the security. You might also want to require the critical bit to be set on those packets, although that will impair interoperability. > 2) Selfsignatures and possible ambiguities: > In an email before David told me that it's fully ok that some > signature subpackets are on 0x13 and/or 0x1F self signatures. I said > I'll come back to this; here it is. > The RFC is very clear (5.2.3.3) about which signature types may be > self-signatures, namely 0x10-0x13, 0x1F and 0x18 (I assume 0x19 is let > out, as it's made by the subkey, right?). > This chapter also says that an implementation should interpret it as > narrowly as possible. > a) That's by the way the first "problem" which _could_ lead to > secrutiy issues, as the standard doesn't define for every case what > "as narrowly as possible" mean. Of course everyone could say "just > follow the common human sense" but this is always problematic, isn't > it? ;-) In your software, you should make your own judgements about this. > b) What for example, if a 0x13 and a 0x1F have conflicting key > expiration times? Should an implementation use the time in the most > recent of the two? Should it use the information from the 0x1F, as key > expiration time is "clearly" related to the key, and not the the User > ID? Should it just use the smallest value of the two? Should it use > the value accordingly by which the key was found (if by Key ID -> use > 0x1F, if by User ID -> use 0x13). I would encourage you to make sure your software does not create keys which have this problem. If you do receive keys with this kind of inconsistency, you should decide for yourself how to interpret it. There is no one right answer for what to do with keys with this problem. > One can easily think of similar examples for other subpacket types, > and its easy to think of examples where this could lead to security > problems (Imagine a user resets the expiration time of his key to > denote that it should not longer be used. His implementation updates > only the 0x13 self-signature but not the "unlimited" in the 0x1F, made > by some other implementation. A third implementation may now choose > the "right one" or not.) I hope you will write your software not to make this mistake. > c) It's nowhere clearly specified if and what meaning these supackets > have on the subkey binding self-signature (0x18) You should probably not put subpackets into such signatures which do not have clearly defined meanings. > A solution would be, that the RFC clearly specifies which subpackets > MAY go to which self-signature, which one takes priority, and for > which the implementation is allowed to choose itself (e.g. according > to the way the key was found). That is probably not going to happen. It took us many years to come up with the latest RFC. I doubt that we would see another revision before 2012 at the earliest. > btw: The example on page 27 "If the key is located via Key ID => use > the subpacket from the primary User ID self-signature also shows the > conflict with 0x1F signatures that could arise in that case. > > 3) This is probably clear for everybody, but the part on revocation > signatures should perhaps highlight, that all subpackets in revoked > signatures MUST NOT be used, e.g. imagine the key expiration time is > only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets > revoked, the key has no longer an expiration time. I would recommend that your software follow this principle. > btw: Is it specified what happens when possibly security critical > subpackets like the expiration time or key usage are absent? > > 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration > time is reset by a user (of course this cannot be prevented as the key > expiration time is no longer part of the key itself). Isn't this > possibility comparable to revoke a revocation? > I mean the creators states: "This key SHOULD NOT be used after expiration>." for example because he thinks an RSA786 key SHOULD no > longer be used in 10 years. An attacker might simply revoke this > (implicit) revocation by issuing a new self-signature with an updated > date. If the attacker got the private key. > 5) Chapter 5.2.3.3. also says what should happen when multiple > self-signatures are encountered by an implementation. > Wouldn't it be more secure to require that ONLY the most recent self > signature of a given type (per primary key in the case of 0x1F, per > User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) > may be used and if that one could not be parsed (e.g. because of > unknown subpackets with the critical bit set) no self-signature MUST > be considered as valid? I would encourage you to consider this design concept in your software. > My idea is about this: > Imagine a very old self-signature that still uses MD5 (which is now > broken, isn't it?) and a newer (in the sense of it's signature > creation time) self-signature which uses say SHA512. Both > self-signatures specify a designated revoker (subpacket 12). > Now an implementation doesn't understand SHA512 signatures and thus > uses the older one with MD5 (as far as I understand the RFC allows to > do so). But than one is probably a forged one by an attacker which > doesn't contain the subpacket 12. > See what I mean? I think it's quite easy to create similar examples > with other subpackets involved. > > So a solution would be that the RFC requires, that always and only the > most recent self-signature is used. Again, there will be no new RFC, not for many years at least. You must solve them in your software using the current RFC. If you want to ask more specific and practically oriented questions, like, what should I do when I see this kind of key, we can try to give you more specific advice. > Ok,.. enough for now,.. but I fear that I'm still not finished :-( > Is it possible to donate a few bugs to gnupg in order to compensate > the time you spend for answering my questions? Feel free to ask more, but I think on this list, for me at least the information I can give you is limited to advice along the lines I have outlined above. Maybe you can persuade David or someone else to change his software to be more to your liking, or failing that you can write your own to address your concerns. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Jan 29 09:53:44 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A594C3A6AFA for ; Thu, 29 Jan 2009 09:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWlyXYNzDrUZ for ; Thu, 29 Jan 2009 09:53:43 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0F2943A6AF9 for ; Thu, 29 Jan 2009 09:53:42 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0THgaIk031182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 10:42:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0THgal6031181; Thu, 29 Jan 2009 10:42:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0THgNnS031166 for ; Thu, 29 Jan 2009 10:42:35 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by mu-out-0910.google.com with SMTP id w9so22497mue.4 for ; Thu, 29 Jan 2009 09:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/MauQVHKGqZwAiJyA/77g6Jvg4TeUY/x97vxH7p2Lfg=; b=jcbb0kMWrWvPlL+CpiOCrS6A49U8RYUHD+fvxQff5AtYSbq96M2OiSaBt24YB6rJRL Y00wnvI1Is1p2x//aa362ChegH8Hqv70Zt57LMr/MX1+nvCZDOztOitvPIPPmmXThJCV yawej7raOdZXX1cTepLz2YVTW3I/NXXHWyl8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d8ew50WoTxp8UWDQAqKrdRPEW6NMo4YxWIcgVzPXMwDnBBlmy50GN5nQckrAgZi+IX T2tmMY/gGM3mKCNYw5VVZdhbOlRquFHaY+6EQ4G0zR+BPCAILeD3tjkyrLZIvgnRga6Z 4crFGvwWCKcLZrUnoYsKtjnaUfu+nAF+dncus= MIME-Version: 1.0 Received: by 10.181.209.1 with SMTP id l1mr95381bkq.113.1233250942921; Thu, 29 Jan 2009 09:42:22 -0800 (PST) In-Reply-To: <20090128184824.E28D614F6E1@finney.org> References: <20090128184824.E28D614F6E1@finney.org> Date: Thu, 29 Jan 2009 18:42:22 +0100 Message-ID: <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: Hal Finney Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Hal. On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" wrote: > I will answer your questions on the assumption that you are writing > OpenPGP compliant software. You are therefore asking about how you should > implement your software. Yes and no. I'm actually thinking about writing an OpenPGP key editor (perhaps using parts of gnupg as backend) which can do nearly everything that the RFC allows to give geeks and freaks the opportunity to try out everything which shouldn't be possible for the average user (that said I fully like the way gnupg - and probably other implementations - "guide" the user). But my discussion here is more about how could the RFC be improved. Please don't get me wrong, I don't wanna say the RFC is crap or anyone here did make wrong things or so and I'm fully aware that I'm really a newbie here. But what I see is that X.509 based PKIs which are based on a strict hierarchical trust model are spread more and more. And personally I dislike it and consider hierarchical trust models inferior to what OpenPGP allows. Most governments fully set on X.509 based PKIs and don't consider or even support OpenPGP and even most technical standards or applications are only X.509 aware (see SSL/TLS, although we have RFC 5081). What it all comes down to is: I think there are places where the RFC and thus OpenPGP could be improved maybe I'm wrong but nevertheless I'll tell this list my ideas. Of course some of them would be difficult to implement or even break compatibility. I'm aware of the time that was needed for this RFC and fully respect the effort the WG put in it and I'm also aware that a new RFC won't come up tomorrow, but anyway I'd like to tell you what I think. You still can say shut up and go away ;-) > I would certainly encourage you to set the critical bit on these and > other signature subpackets that you view as critical to the security. Unfortunately I have no idea how to do this with gnupg (my used implementation)... perhaps David can comment on this. But even if would do modifications to set the critical bit on them I fear compatibility issues with other implementations. > You > might also want to require the critical bit to be set on those packets, > although that will impair interoperability. What do you mean with this? Require it by the RFC? >> c) It's nowhere clearly specified if and what meaning these supackets >> have on the subkey binding self-signature (0x18) > You should probably not put subpackets into such signatures which do > not have clearly defined meanings. But this is the point. Which have clearly defined meanings? Hast the policy URI a meaning on 0x18s (e.g. as the policy for signatures made by that subkey)? >> 3) This is probably clear for everybody, but the part on revocation >> signatures should perhaps highlight, that all subpackets in revoked >> signatures MUST NOT be used, e.g. imagine the key expiration time is >> only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets >> revoked, the key has no longer an expiration time. > I would recommend that your software follow this principle. Oh my mistake,... an absent key expiration time means unlimited ;-) Anyway I think the original problem remains,.. what is the semantical meaning e.g. when there are different key expiration time values on (perhaps even multiple) 0x13s and a 0x1F? >> 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration >> time is reset by a user (of course this cannot be prevented as the key >> expiration time is no longer part of the key itself). Isn't this >> possibility comparable to revoke a revocation? >> I mean the creators states: "This key SHOULD NOT be used after > expiration>." for example because he thinks an RSA786 key SHOULD no >> longer be used in 10 years. An attacker might simply revoke this >> (implicit) revocation by issuing a new self-signature with an updated >> date. > If the attacker got the private key. What was the reason that the key expiration time was taken out of the key itself (I think it was there before?)? > Again, there will be no new RFC, not for many years at least. You must > solve them in your software using the current RFC. If you want to ask > more specific and practically oriented questions, like, what should I > do when I see this kind of key, we can try to give you more specific > advice. Thanks again for your advices. But if you're interested in and find the time I'd like to see your comments and ideas about the "issues" themselves. Of course it's possible to find and implement a reasonable solution, which is what you suggested me in most of your comments :-) At some point the RFC says that it's a little bit "vague". In my opinion (and I really don't want to offend anybody) this is bad for a cryptologic. Everything should be exactly defined. For example I'd like to see those possible (at leas in my opinion) security critical subpackets to be REQUIRED by an future RFC. Of course no one can force an implementation to really adhere to the standard, but that's always the case. Would be nice if you and perhaps even the other authors of the RFC (David for example has give me already some very deep insight) could comment on the "issues" themselves. I promise that I don't request you to write a new RFC immediately ;-) > Maybe you can persuade David or someone else to change > his software to be more to your liking, or failing that you can write > your own to address your concerns. Well this would be great,.. I mean the current MAIN implementations of OpenPGP are probably GnuPG and PGP. I think David and Werner who represent GnuPG are reading this list and you, are you still at PGP Corporation? If some or all of you find suggestions that I made or will make worth to implement (e.g. that critical bit issues) we could put this in practice even before having (perhaps at some day) a new RFC. Thanks for allowing me to ask additional questions, I have "plenty" left ;-) But I'll start new threads for them. Best wishes, Peter From owner-ietf-openpgp@mail.imc.org Thu Jan 29 10:38:59 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2B728C245 for ; Thu, 29 Jan 2009 10:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK4rWrFyioLa for ; Thu, 29 Jan 2009 10:38:58 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7123728C1FC for ; Thu, 29 Jan 2009 10:38:58 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TINH0Y033137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 11:23:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TINHU2033136; Thu, 29 Jan 2009 11:23:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TIN5uS033128 for ; Thu, 29 Jan 2009 11:23:16 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fg-out-1718.google.com with SMTP id e12so34945fga.26 for ; Thu, 29 Jan 2009 10:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=HsNbnf3/ZWPC7iS5U40PHXSjDTCokMiw43gK0piomhA=; b=HC9T6zBLGgRPCDyqLcda4o9XeVTKIe2dECyksxbFGRfdhUUga6A8EfmP9aFvNChp4b GxWPE98XttNhe49LlGCKwgFirS2BGqIImRRiU2Q1mrCgVTjx7l6fyW1EOHtNaBHyDdD8 6HX4FLGSCh87c8MTizJrdVNYOaruK2G/7zxmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=EXW2PmUveNAvAHF2SC6Hrei3sjA0nwC7r0tNkr/zcRmm4pCRn6sMkc7i5sAYR14GRJ t4EIenwQBhTuDIxpNIXWzTsgJ66OHtIuko7RlSQRICDs+ZP7ZTPWa2myJk5ZjDWsBaWt uKNTef/+o+z3wmqJOB2tjMK2QpOC5jjBW7iAg= MIME-Version: 1.0 Received: by 10.181.28.15 with SMTP id f15mr111264bkj.75.1233253384691; Thu, 29 Jan 2009 10:23:04 -0800 (PST) Date: Thu, 29 Jan 2009 19:23:04 +0100 Message-ID: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> Subject: Ideas on new user attribute types and image formats From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi list. This is not an official proposal or request. I haven't read RFC2434 yet ;-) Just wanted to ask about opinions and ideas for new user attribute types and image formats. First perhaps the image formats as these are easier to discuss: Of course JPEG is in principle enough and it's probably a very bad idea to include any image type GIMP can open ;-) but I think the following might be worth thinking about: 1) PNG (ISO 15948, RFC 2083) Advantages: - just as JPEG, nearly everybody can open these image format in the meantime (even MS IE as far as I know) - well standardized (ISO/IETF RFC) - "We" call our "product" OpenPGP but JPEPG is - as far as I know - patent encumbered, but PGP is fully free. - Is providing an alpha-channel an argument?! ;-) - lossless compression Disadvantages: - lossless compression leading to much bigger packets than with JPEG 2) JPEG 2000 (ISO/IEC 15444) Advantages: - well standardized (ISO) ... ok one could question that ^^ - provides even better/smaller quality/image sizes than JPEG (And I think to keep image-packets small was the main reason for choosing JPEG) Disadvantages: - no widespread support - standard is still incomplete (at least some additional parts, but that wouldn't hurt "us" anyway) 3) SVG Probably my most adventurous suggestion ^^ RFC 4880 say in chapter 5.12.1 that the image is not necessarily that of the key owner. I'm not fully sure what this means, but could it mean that an image attribute subpacket is used to store for example an heraldic device ("I'm the king of Belgium and I'd like to include my emblem in my key" *G*)? If so, SVG would be useful file format (see Wikipedia for dozens of heraldic devices in hight quality). Second, ideas for user attributes: This is more a: "Has anybody ideas how usage of user attributes could be extended?" than a "I have this and that proposal.", so I'd really love to see your ideas. I personally think of the user ID packet (not the user attribute packet) as kind of primary key (in the sense of databases). The RFC says in chapter 5.11. that it is "intended to represent the name and email address of the keyholder"; it doesn't say it must (which is good in my opinion). That way some organization, a company or university could use the User ID like primary keys and set them to some staff or student number. Most people surely follow the recommendation to use name/email with RFC 2822 style. This also fit's with my thinking of user IDs as some kind of primary key as the email address makes the whole thing unique. The user attribute packet introduced ways to better represent properties of the key-holder. Take my name "Peter Thomas" from just the user ID "Peter Thomas" you cannot definitely say whether "Peter" or "Thomas" is the first- or family-name. The naming schemes in other cultures might be even "worse", just consider Arabic names (http://en.wikipedia.org/wiki/Arabic_name). Having attributes like: - common name - family names - given names - Kunya (Arabic) - Nasab (Arabic) may be something worth to implement. Consider the following two example: My full name would be "Peter Marvolo Thomas" a) My User ID only has "Peter Thomas" and my passport has the full name "Peter Marvolo Thomas" When another person validates my identity he can either sign it and accept that it's missing part of my official name, or he can decline to do so. With the above user attributes, he could decide to just sign the family name, but not the given names filed. b) The example above vice versa, with full name in the user id, but not in the passport. Think of similar examples with Arabic names where it is much clearer that this would be an advantage (as for example most western government documents simply drop parts of Arabic names). Other attributes that might be worth to implement: -birthday (perhaps as UNIX time code ^^) -birthplace/country/etc. -other fixed body attributes like natural color of eyes and hairs One could even think of stuff like: - Jabber ID - etc. When you comment on this please remember that these are just ideas and not proposals that I've thought about hours ;-) Looking forward to see your comments, Peter From owner-ietf-openpgp@mail.imc.org Thu Jan 29 10:53:54 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40A413A6AC2 for ; Thu, 29 Jan 2009 10:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H98urYd229aT for ; Thu, 29 Jan 2009 10:53:53 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EED0B3A684A for ; Thu, 29 Jan 2009 10:53:52 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TIhCD1034458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 11:43:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TIhCOi034457; Thu, 29 Jan 2009 11:43:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TIh0Ln034446 for ; Thu, 29 Jan 2009 11:43:11 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fg-out-1718.google.com with SMTP id e12so40499fga.26 for ; Thu, 29 Jan 2009 10:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z8fPO7O1oL9o+6BcSkCYDZgeEmMFDVGsXwJKOP0ZVys=; b=QDv8L0fb9+KJT0u9JB2yfvLJX7kphS8ULU0kem1sa09QAYUAu39JCiGGwVR3PEgZS7 s2QrJMZJBTLpGxYd3USGvWJ4j4os0eKiJ+XsA33gAZk5waeRaPNumV8uk7M8U52IkLXG U+oksQSrHX2zs7d4Kz4Lc8uEXFSuO5RpDCK6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xVjpjUWRwd3NJ1QzOD79jJ93fbQqaGf2S9Feqlpgv3ZR/YA11+s84l7bOO78IYMA1m LZ47T+91px5ldKl5kT0AyLoZEuaG3vfyc/5i2BBAzrbWiplKz/W8SGNb3TeO9cdsogVo PV69CKdB5SgfYbYuae6a4NJLSN7mCTXZ9jg3I= MIME-Version: 1.0 Received: by 10.181.158.16 with SMTP id k16mr105919bko.208.1233254579308; Thu, 29 Jan 2009 10:42:59 -0800 (PST) In-Reply-To: <20090128184824.E28D614F6E1@finney.org> References: <20090128184824.E28D614F6E1@finney.org> Date: Thu, 29 Jan 2009 19:42:59 +0100 Message-ID: <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: Hal Finney , David Shaw Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One probably stupid idea on this *G* On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" wrote: >> 5) Chapter 5.2.3.3. also says what should happen when multiple >> self-signatures are encountered by an implementation. >> Wouldn't it be more secure to require that ONLY the most recent self >> signature of a given type (per primary key in the case of 0x1F, per >> User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) >> may be used and if that one could not be parsed (e.g. because of >> unknown subpackets with the critical bit set) no self-signature MUST >> be considered as valid? > I would encourage you to consider this design concept in your software. I thought about how this "issue" could be solved with the current means of the standard. I mean how can I secure that only the most recent self-signature (no matter whether 0x10-0x13, 0x1F or 0x18) is used by ANY conforming implementation. Perhaps this is really stupid, so better sit down ;-) What if I'd revoke the old self-signatures to mark them clearly as superseded and to force ANY conforming OpenPGP implementation not to use them. 0x10-0x13 self-sigs could be revoked with a 0x30 certification revocation signature 0x18 self-sigs could be revoked with a 0x28 subkey revocation signautre 0x1F: which one would I have to use for that? A 0x20 key revocation signature? Or would the completely revoke the whole key. What would be the most fitting reasons for revocation? For 0x10-0x13 probably 32 (user id information no longer valid), but for the others? Or should one use 0 (no reason specified). Does the whole thing make sense anyway? I mean would it be a clean or at least working way to force ANY implementation to use only the most recent self-signatures? Would it work with the mayor implementations, PGP and GnuPG? Lots of thanks for your comments and ideas, Peter :-) *who is now going home* From owner-ietf-openpgp@mail.imc.org Thu Jan 29 11:38:01 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A992428C0EC for ; Thu, 29 Jan 2009 11:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWP46j9YaNYH for ; Thu, 29 Jan 2009 11:37:59 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 40DF028C0FD for ; Thu, 29 Jan 2009 11:37:59 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJTB8h036547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 12:29:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TJTB9S036546; Thu, 29 Jan 2009 12:29:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJSxA5036536 for ; Thu, 29 Jan 2009 12:29:10 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id F2FD22E1D6 for ; Thu, 29 Jan 2009 11:29:49 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 46802-01 for ; Thu, 29 Jan 2009 11:29:47 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 135E02E13E for ; Thu, 29 Jan 2009 11:29:47 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Thu, 29 Jan 2009 10:29:57 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 29 Jan 2009 10:29:57 -0800 Cc: ietf-openpgp@imc.org Message-Id: <7B27ABCD-D17C-4651-B7DE-9AFDC2D61AFD@callas.org> From: Jon Callas To: Peter Thomas In-Reply-To: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Ideas on new user attribute types and image formats Date: Thu, 29 Jan 2009 11:28:53 -0800 References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 29, 2009, at 10:23 AM, Peter Thomas wrote: > > Hi list. > > This is not an official proposal or request. I haven't read RFC2434 > yet ;-) > > Just wanted to ask about opinions and ideas for new user attribute > types and image formats. I think you understand the pros and cons well enough. My personal opinion is that there's an argument for PNG, but not much else. And so far as I know, JPEG is not encumbered by patents at all, but there are people who would like it to be, especially if it's their patent. I have no idea why you'd want to do SVG, and you seem to know anything I could say as to why not. So I'll just say that anything you put in would be a MAY, and if you put in something that no one's going to implement, you are arguably wasting your time. However: Write it up! Especially your thoughts about structured user information. The Jabber one is also good, since Jabber directly supports OpenPGP. Do it informally here first, but also start looking at how to edit up an Internet Draft. The XML tools make it a lot easier than it used to be. Oh, and you can't do birthday as a time_t. As shocking as it may sound, there are still living people who were born before 1-Jan-1970. Some of them even use computers. Jon > > > > > First perhaps the image formats as these are easier to discuss: > Of course JPEG is in principle enough and it's probably a very bad > idea to include any image type GIMP can open ;-) but I think the > following might be worth thinking about: > 1) PNG (ISO 15948, RFC 2083) > Advantages: > - just as JPEG, nearly everybody can open these image format in the > meantime (even MS IE as far as I know) > - well standardized (ISO/IETF RFC) > - "We" call our "product" OpenPGP but JPEPG is - as far as I know - > patent encumbered, but PGP is fully free. > - Is providing an alpha-channel an argument?! ;-) > - lossless compression > > Disadvantages: > - lossless compression leading to much bigger packets than with JPEG > > 2) JPEG 2000 (ISO/IEC 15444) > Advantages: > - well standardized (ISO) ... ok one could question that ^^ > - provides even better/smaller quality/image sizes than JPEG > (And I think to keep image-packets small was the main reason for > choosing JPEG) > > Disadvantages: > - no widespread support > - standard is still incomplete (at least some additional parts, but > that wouldn't hurt "us" anyway) > > 3) SVG > Probably my most adventurous suggestion ^^ > RFC 4880 say in chapter 5.12.1 that the image is not necessarily that > of the key owner. > I'm not fully sure what this means, but could it mean that an image > attribute subpacket is used to store for example an heraldic device > ("I'm the king of Belgium and I'd like to include my emblem in my key" > *G*)? > If so, SVG would be useful file format (see Wikipedia for dozens of > heraldic devices in hight quality). > > > > > Second, ideas for user attributes: > This is more a: "Has anybody ideas how usage of user attributes could > be extended?" than a "I have this and that proposal.", so I'd really > love to see your ideas. > > I personally think of the user ID packet (not the user attribute > packet) as kind of primary key (in the sense of databases). > The RFC says in chapter 5.11. that it is "intended to represent the > name and email address of the keyholder"; it doesn't say it must > (which is good in my opinion). > That way some organization, a company or university could use the User > ID like primary keys and set them to some staff or student number. > > Most people surely follow the recommendation to use name/email with > RFC 2822 style. > This also fit's with my thinking of user IDs as some kind of primary > key as the email address makes the whole thing unique. > > The user attribute packet introduced ways to better represent > properties of the key-holder. > Take my name "Peter Thomas" from just the user ID "Peter Thomas" > you cannot definitely say whether "Peter" > or "Thomas" is the first- or family-name. The naming schemes in other > cultures might be even "worse", just consider Arabic names > (http://en.wikipedia.org/wiki/Arabic_name). > Having attributes like: > - common name > - family names > - given names > - Kunya (Arabic) > - Nasab (Arabic) > may be something worth to implement. > > Consider the following two example: My full name would be "Peter > Marvolo Thomas" > a) My User ID only has "Peter Thomas" and my passport has the full > name "Peter Marvolo Thomas" > When another person validates my identity he can either sign it and > accept that it's missing part of my official name, or he can decline > to do so. > With the above user attributes, he could decide to just sign the > family name, but not the given names filed. > b) The example above vice versa, with full name in the user id, but > not in the passport. > > Think of similar examples with Arabic names where it is much clearer > that this would be an advantage (as for example most western > government documents simply drop parts of Arabic names). > > Other attributes that might be worth to implement: > -birthday (perhaps as UNIX time code ^^) > -birthplace/country/etc. > -other fixed body attributes like natural color of eyes and hairs > > One could even think of stuff like: > - Jabber ID > - etc. > > When you comment on this please remember that these are just ideas and > not proposals that I've thought about hours ;-) > > > Looking forward to see your comments, > Peter > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJgfWlsTedWZOD3gYRAvplAJ0UwXyEhqJzoXrnbZiCdKkqoMU6EACfbWqg Scf7WNYhYlH5TSStmsAcnho= =oBkh -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jan 29 11:48:04 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50C6E3A690E for ; Thu, 29 Jan 2009 11:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwGBZySqDcxO for ; Thu, 29 Jan 2009 11:48:03 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 023363A6981 for ; Thu, 29 Jan 2009 11:48:02 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJbVbH037068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 12:37:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TJbV2x037067; Thu, 29 Jan 2009 12:37:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJbUlR037060 for ; Thu, 29 Jan 2009 12:37:30 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 603952E13E for ; Thu, 29 Jan 2009 11:38:21 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 46812-09 for ; Thu, 29 Jan 2009 11:38:18 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 2037E2E15B for ; Thu, 29 Jan 2009 11:38:18 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Thu, 29 Jan 2009 10:38:28 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 29 Jan 2009 10:38:28 -0800 Message-Id: <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> From: Jon Callas To: OpenPGP In-Reply-To: <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Thu, 29 Jan 2009 11:37:25 -0800 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > You still can say shut up and go away ;-) On the contrary, I think you should start discussing things here and start writing drafts. >> You >> might also want to require the critical bit to be set on those >> packets, >> although that will impair interoperability. > What do you mean with this? Require it by the RFC? No, the critical bit means that you want an operation to be 100% correct or to fail. If there is any doubt in anyone's mind, you want the system to halt with an unrecoverable error. Hal points out that this will mar interoperability. >>> 4) In chapter 5.2.3.3 it is explicitly allowed that the key >>> expiration >>> time is reset by a user (of course this cannot be prevented as the >>> key >>> expiration time is no longer part of the key itself). Isn't this >>> possibility comparable to revoke a revocation? >>> I mean the creators states: "This key SHOULD NOT be used after >> expiration>." for example because he thinks an RSA786 key SHOULD no >>> longer be used in 10 years. An attacker might simply revoke this >>> (implicit) revocation by issuing a new self-signature with an >>> updated >>> date. >> If the attacker got the private key. > What was the reason that the key expiration time was taken out of the > key itself (I think it was there before?)? Because in PGP 3, a number of attributes were moved to the self-sigs with the thought that you might have a key with different user ids and different features. For example, I might have a user id in which a cipher is allowed, and one in which it is not. You might also want to have different expirations on those user ids. >> > Well this would be great,.. I mean the current MAIN implementations of > OpenPGP are probably GnuPG and PGP. I think David and Werner who > represent GnuPG are reading this list and you, are you still at PGP > Corporation? Yes. > > Best wishes, > Peter > To you too! It's nice to see enthusiastic new blood. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJgfeksTedWZOD3gYRAmLQAKChmG6pgdkCdkZDIslxMEUupmLCQACgxAQj H8YuyCyhFF697rSGw40BBBQ= =+IVy -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jan 29 12:47:14 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A0B3A6A55 for ; Thu, 29 Jan 2009 12:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHfo--vJkkpC for ; Thu, 29 Jan 2009 12:47:13 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C1EB73A68D7 for ; Thu, 29 Jan 2009 12:47:12 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKcLhs039719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 13:38:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TKcLjw039718; Thu, 29 Jan 2009 13:38:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKcAna039707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2009 13:38:21 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0TKc92W024377 for ; Thu, 29 Jan 2009 15:38:09 -0500 Date: Thu, 29 Jan 2009 15:38:09 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090129203809.GA16331@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 06:42:22PM +0100, Peter Thomas wrote: > > I would certainly encourage you to set the critical bit on these and > > other signature subpackets that you view as critical to the security. > Unfortunately I have no idea how to do this with gnupg (my used > implementation)... perhaps David can comment on this. But even if > would do modifications to set the critical bit on them I fear > compatibility issues with other implementations. That's basically the point of the critical bit. You can think of it as a way to force a (quasi) compatibility break. The critical bit means "This subpacket is so important to the signature that I'd rather you treat the whole signature is invalid than you not understand this subpacket". For example, GPG sets the critical bit on signatures that have an expiration date set. Thus, if the signature is read by an implementation that doesn't understand expiring signatures, the whole signature is invalid. This was deemed better than the alternative - a "expired" signature being treated as still usable because the recipient implementation didn't know to ignore it. > >> c) It's nowhere clearly specified if and what meaning these supackets > >> have on the subkey binding self-signature (0x18) > > You should probably not put subpackets into such signatures which do > > not have clearly defined meanings. > But this is the point. Which have clearly defined meanings? Hast the > policy URI a meaning on 0x18s (e.g. as the policy for signatures made > by that subkey)? It is the policy under which the subkey itself was certified. The Policy URI for signatures made by that subkey would be in those signatures. > >> 3) This is probably clear for everybody, but the part on revocation > >> signatures should perhaps highlight, that all subpackets in revoked > >> signatures MUST NOT be used, e.g. imagine the key expiration time is > >> only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets > >> revoked, the key has no longer an expiration time. > > I would recommend that your software follow this principle. > Oh my mistake,... an absent key expiration time means unlimited ;-) > Anyway I think the original problem remains,.. what is the semantical > meaning e.g. when there are different key expiration time values on > (perhaps even multiple) 0x13s and a 0x1F? Section 5.2.3.3: An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self- signature. I suspect that most software follows this recommendation. GPG does. > For example I'd like to see those possible (at leas in my opinion) > security critical subpackets to be REQUIRED by an future RFC. Of > course no one can force an implementation to really adhere to the > standard, but that's always the case. The problem here is that what one use case requires as security critical may not be what another one does. The critical bit is a more flexible way for an implementation to require which subpackets are understood. David From owner-ietf-openpgp@mail.imc.org Thu Jan 29 13:02:58 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1A433A6A97 for ; Thu, 29 Jan 2009 13:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhDLwQ6PMKjQ for ; Thu, 29 Jan 2009 13:02:57 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D1F203A6A84 for ; Thu, 29 Jan 2009 13:02:56 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKrNK7040178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 13:53:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TKrNUB040177; Thu, 29 Jan 2009 13:53:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKrL2I040170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2009 13:53:23 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0TKrLiO024475 for ; Thu, 29 Jan 2009 15:53:21 -0500 Date: Thu, 29 Jan 2009 15:53:21 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090129205321.GB16331@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 07:42:59PM +0100, Peter Thomas wrote: > What if I'd revoke the old self-signatures to mark them clearly as > superseded and to force ANY conforming OpenPGP implementation not to > use them. > 0x10-0x13 self-sigs could be revoked with a 0x30 certification > revocation signature > 0x18 self-sigs could be revoked with a 0x28 subkey revocation signautre > 0x1F: which one would I have to use for that? A 0x20 key revocation > signature? Or would the completely revoke the whole key. You revoke a 0x1F with a 0x30, same as you would use to revoke a 0x10-0x13. 0x1F is a certification. > Does the whole thing make sense anyway? I mean would it be a clean or > at least working way to force ANY implementation to use only the most > recent self-signatures? I suspect it wouldn't hurt, but wouldn't help much either. For example, given this: Signature === January 1 Signature === January 3 Signature === January 5 it is clear that the January 5 signature is the latest and the one to use. Given this: Signature === January 1 Revocation === January 2 Signature === January 3 Revocation === January 4 Signature === January 5 It's still clear which signature is the right one. I suppose if you had an implementation that insisted on using the first signature, regardless of the date, then the revocations would force it to look at the last signature.. but then, an implementation that did that may have other odd semantics elsewhere. It may conclude that there is no signature at all (after all, the one signature it was looking at is revoked). > Would it work with the mayor implementations, PGP and GnuPG? It would work in GnuPG. David From owner-ietf-openpgp@mail.imc.org Thu Jan 29 14:13:44 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980293A69DB for ; Thu, 29 Jan 2009 14:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+V5cIz947v6 for ; Thu, 29 Jan 2009 14:13:42 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 27ABB3A67B0 for ; Thu, 29 Jan 2009 14:13:41 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TM315f042609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 15:03:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TM312k042608; Thu, 29 Jan 2009 15:03:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TM2oLU042595 for ; Thu, 29 Jan 2009 15:03:01 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 248C231A42B for ; Thu, 29 Jan 2009 23:02:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 9129A59809B for ; Fri, 30 Jan 2009 00:02:08 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wRQhpcuMrQ41 for ; Fri, 30 Jan 2009 00:02:08 +0100 (CET) Received: from [157.181.227.130] (dhcp130.cs.elte.hu [157.181.227.130]) by mail.agileight.com (Postfix) with ESMTP id 48D9B598099 for ; Fri, 30 Jan 2009 00:02:08 +0100 (CET) Message-ID: <49822782.5090405@epointsystem.org> Date: Thu, 29 Jan 2009 23:02:42 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> In-Reply-To: <20090129205321.GB16331@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig919D7290F134DCBE799FC8AA" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig919D7290F134DCBE799FC8AA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Shaw wrote: > You revoke a 0x1F with a 0x30, same as you would use to revoke a > 0x10-0x13. 0x1F is a certification. Hold on here. What you write here obviously follows from the text of the = RFC, so I do not question it, but it does raise a semantic question. Obviously, one reason for attaching certifications directly to a key rath= er than to particular user IDs is to make them stick even if any particular user = ID is revoked or expires (or even all of them). So, if I want to make a stateme= nt about a certain person rather than a user ID (concerning, e.g., his/her trustworthiness as a certifier), I'd attach it directly to the key. There= may be several certifications by several people saying different things about th= e person. The question: how does one revoke one of them? A 0x30 computed directly o= n the key (as the RFC specifies) revokes all of them (for which it is a designa= ted revoker), doesn't it? Is there no way to revoke just one? --=20 Daniel --------------enig919D7290F134DCBE799FC8AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmCJ4YACgkQi+vAY9cJzcIMBwCeKNqR7RxsMKdvhcIsELBs7EDm tjcAnRMqwXYcnuNvBT8c2mhw4pIMC7St =n0lV -----END PGP SIGNATURE----- --------------enig919D7290F134DCBE799FC8AA-- From owner-ietf-openpgp@mail.imc.org Thu Jan 29 14:39:26 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF8603A6981 for ; Thu, 29 Jan 2009 14:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9NWumL3pU+r for ; Thu, 29 Jan 2009 14:39:26 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9441E3A6814 for ; Thu, 29 Jan 2009 14:39:24 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMUlx9043711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 15:30:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TMUl0S043710; Thu, 29 Jan 2009 15:30:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMUjY7043703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2009 15:30:46 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0TMUjxW025184 for ; Thu, 29 Jan 2009 17:30:45 -0500 Date: Thu, 29 Jan 2009 17:30:45 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090129223044.GA16884@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49822782.5090405@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 11:02:42PM +0100, Daniel A. Nagy wrote: > David Shaw wrote: > > You revoke a 0x1F with a 0x30, same as you would use to revoke a > > 0x10-0x13. 0x1F is a certification. > > Hold on here. What you write here obviously follows from the text of > the RFC, so I do not question it, but it does raise a semantic > question. > > Obviously, one reason for attaching certifications directly to a key > rather than to particular user IDs is to make them stick even if any > particular user ID is revoked or expires (or even all of them). So, > if I want to make a statement about a certain person rather than a > user ID (concerning, e.g., his/her trustworthiness as a certifier), > I'd attach it directly to the key. There may be several > certifications by several people saying different things about the > person. > > The question: how does one revoke one of them? A 0x30 computed > directly on the key (as the RFC specifies) revokes all of them (for > which it is a designated revoker), doesn't it? Is there no way to > revoke just one? It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F signature revokes (potentially) all of them that are a) from the same issuer (or from that issuer's designated revoker), and b) timestamped earlier than the revocation. It cannot revoke ones that come after it. Even then there is the possibility of confusion of which signature you intend to revoke. In those cases, you can always specify a particular signature to revoke using the Signature Target subpacket in the revocation. Arguably, you could even revoke multiple signatures with one revocation by using multiple subpackets. Not, it should be pointed out, that many (any?) implementations support Signature Targets yet. But the semantics are there. David From owner-ietf-openpgp@mail.imc.org Thu Jan 29 16:13:54 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20D943A6859 for ; Thu, 29 Jan 2009 16:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QysILJBf4qcf for ; Thu, 29 Jan 2009 16:13:53 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 09CC73A6883 for ; Thu, 29 Jan 2009 16:13:52 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U02WbY047250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 17:02:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0U02Wk2047249; Thu, 29 Jan 2009 17:02:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U02KAF047219 for ; Thu, 29 Jan 2009 17:02:31 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 68D3B11A17B for ; Fri, 30 Jan 2009 01:02:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 3CB0B598099 for ; Fri, 30 Jan 2009 02:01:38 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fkMPpPuQUncc for ; Fri, 30 Jan 2009 02:01:38 +0100 (CET) Received: from [10.0.0.164] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id E5FE0598092 for ; Fri, 30 Jan 2009 02:01:37 +0100 (CET) Message-ID: <49824380.3020501@epointsystem.org> Date: Fri, 30 Jan 2009 01:02:08 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> In-Reply-To: <20090129223044.GA16884@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8E1FEA9E4A3B02E8F099DA30" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E1FEA9E4A3B02E8F099DA30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Shaw wrote: > It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F > signature revokes (potentially) all of them that are a) from the same > issuer (or from that issuer's designated revoker), and b) timestamped > earlier than the revocation. It cannot revoke ones that come after > it. Of course. Sorry for the sloppy wording of my email. This is what I meant= =2E > Even then there is the possibility of confusion of which signature you > intend to revoke. In those cases, you can always specify a particular > signature to revoke using the Signature Target subpacket in the > revocation. Arguably, you could even revoke multiple signatures with > one revocation by using multiple subpackets. > > Not, it should be pointed out, that many (any?) implementations > support Signature Targets yet. But the semantics are there. Thank you, this answers my question. Haven't paid attention to Signature Targets, because I haven't seen a single one in the wild. But they are, i= ndeed, truly useful and as such worth implementing as soon as OpenPGP gets used = for serious legal purposes. I might do it myself. --=20 Daniel --------------enig8E1FEA9E4A3B02E8F099DA30 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmCQ4cACgkQi+vAY9cJzcIb3ACfYFJbJZ8vyTMzSO6I6gQz+GzN HzcAn1w9kTucoQU9+i7xkvSCQr0qKOV6 =3FRq -----END PGP SIGNATURE----- --------------enig8E1FEA9E4A3B02E8F099DA30-- From openphilipp.morgan@belhasa.ae Fri Jan 30 07:30:58 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2303628C0DD for ; Fri, 30 Jan 2009 07:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.716 X-Spam-Level: X-Spam-Status: No, score=-76.716 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHvhzjQRkjKb for ; Fri, 30 Jan 2009 07:30:51 -0800 (PST) Received: from amerblind.outbound.ed10.com (unknown [88.87.69.47]) by core3.amsl.com (Postfix) with SMTP id 3C0623A69ED for ; Fri, 30 Jan 2009 07:30:49 -0800 (PST) Content-Return: allowed X-Mailer: devMail.Net (3.0.1854.22234-2) To: openpgp-archive@ietf.org Subject: RE: Canadian Pharmacy Message 25746 From: openpgp-archive@ietf.org MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-Id: <20090130153050.3C0623A69ED@core3.amsl.com> Date: Fri, 30 Jan 2009 07:30:49 -0800 (PST)
Click Here!
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2009 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From owner-ietf-openpgp@mail.imc.org Fri Jan 30 07:40:30 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C955B3A6B0F for ; Fri, 30 Jan 2009 07:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.183 X-Spam-Level: X-Spam-Status: No, score=-3.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFr6y0mL14Gh for ; Fri, 30 Jan 2009 07:40:29 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 705433A6A4B for ; Fri, 30 Jan 2009 07:40:29 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UFLHG9088875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 08:21:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UFLHoT088874; Fri, 30 Jan 2009 08:21:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UFL5jA088865 for ; Fri, 30 Jan 2009 08:21:16 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 27421 invoked from network); 30 Jan 2009 15:21:04 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay02.pair.com with SMTP; 30 Jan 2009 15:21:04 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49831B83.7060704@fifthhorseman.net> Date: Fri, 30 Jan 2009 10:23:47 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Peter Thomas CC: ietf-openpgp@imc.org, Duane Groth Subject: Re: Ideas on new user attribute types and image formats References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> In-Reply-To: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig135E313878988A444AA8C823" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig135E313878988A444AA8C823 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/29/2009 01:23 PM, Peter Thomas wrote: > 1) PNG (ISO 15948, RFC 2083) I fully agree that we should be supporting PNG here. That's long overdue, and you don't have to do lossless compression in png, iiuc. > 2) JPEG 2000 (ISO/IEC 15444) Given how ill-specified and implemented this is, i suggest waiting on this until it is more mature. > 3) SVG SVG can potentially contain way more than images; it can contain javascript, for example, and other semi-executable nastiness. As much as i love svg, I think it might be a can of worms best left unopened until we're prepared to seriously think through the potential security consequences. > Second, ideas for user attributes: > This is more a: "Has anybody ideas how usage of user attributes could > be extended?" than a "I have this and that proposal.", so I'd really > love to see your ideas. Duane Groth has proposed making a new User Attribute type that just maps to the possible values of the X.509 subjectAltName specification: http://open-pgp.info/wiki/index.php?title=3DStandardisation_of_OpenPGP_Ke= ys_for_Server_Purposes#New_User_Attribute_Type_--_subjectAltNames What's nice about this proposal is that it doesn't require the creation of a new registry, implementors can potentially piggyback on existing ASN.1 parsers (they wouldn't need to write their own), and the specification can cover a range of ideas automatically. --dkg --------------enig135E313878988A444AA8C823 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYMbhMzS7ZTSFznpAQKm5BAAhHAZKYCGzOOSLHVN/JVYARPjhpotEMc8 plPwErShrTfurhfxxjAxV75mJxWcenAqFDmbIEustjZwp+vqUMvEd+v3EH7A/UPQ tmLCfEUnPOwuJ24PVBBiz6GUyzBj4wLvIMjy4dF7MkWXtymKgenc7FS1qR7FOkkK yajrEwVyvV1fRO3mmk5bxwacKX0zcIwbQGE+g0zloHbWDhe4euyfHF6icxS5gPZo 5hriY8dA23qUfhKjP3OCjfXZ8JkYWN4Bu3BrFjNGmnxYkmpq34K7RYNMRAmgUrsX LzyLxrqrtNcxyIkd+5FntVHbdInUHy9jKs0dvnL6D/PPlxslXmjMDOm7l0WlhCb/ vg8WTv2QlwxzMW5W7DNwLo3akULVpKvMwPR5ObzkYUd0/7Io8ENbGzGwoOCqI2vY v3JJaA1Nbaxk6mXH0xF1xBobMD5w2h9MeCJI8LoSDezrL9ijc2Ug1ynLx5OPtC7N iHqNU/XWf2m2QYXMe/5IEVwYZFnSwN2bknL1Y9CVe7+cWWPrz5caiA8paK3RfTBM AUVdevi1haSscYMgbyEBGVmOJPKYwStwCeDaybI0rNgXM8kRYTbyQMnVeM/5Q0ts bkR+ZmrbEHTHJttYQkHqxnbYCfyoYIzU4PNccP2FOP4aHiJuOzkjcYsa6s21Q3GF CUi0G1wDMco= =u8Ze -----END PGP SIGNATURE----- --------------enig135E313878988A444AA8C823-- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 07:40:54 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941093A6A4B for ; Fri, 30 Jan 2009 07:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.321 X-Spam-Level: X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uV5QqeVITZPX for ; Fri, 30 Jan 2009 07:40:53 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7A1913A6863 for ; Fri, 30 Jan 2009 07:40:53 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UFRjtx089091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 08:27:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UFRjgd089090; Fri, 30 Jan 2009 08:27:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UFRjZ7089084 for ; Fri, 30 Jan 2009 08:27:45 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 30412 invoked from network); 30 Jan 2009 15:27:44 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay02.pair.com with SMTP; 30 Jan 2009 15:27:44 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49831D14.4030804@fifthhorseman.net> Date: Fri, 30 Jan 2009 10:30:28 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> In-Reply-To: <20090129205321.GB16331@jabberwocky.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0E96254D1723DA3223AF8A1" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0E96254D1723DA3223AF8A1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/29/2009 03:53 PM, David Shaw wrote: > I suppose if you had an implementation that insisted on using the > first signature, regardless of the date, then the revocations would > force it to look at the last signature.. but then, an implementation > that did that may have other odd semantics elsewhere. It may conclude > that there is no signature at all (after all, the one signature it was > looking at is revoked). This would be a particularly odd implementation because "the first signature regardless of date" has no meaning in OpenPGP, iiuc. There's nothing stopping a re-ordering of signature packets, and a certificate that looks like this: primary_key \-uid +--sigX \--sigY Is semantically equivalent to this: primary_key \-uid +--sigY \--sigX And in fact, keyservers will often have to re-order signature packets if they gather data from disparate sources. --dkg --------------enigC0E96254D1723DA3223AF8A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYMdFczS7ZTSFznpAQJY4RAAq+1NvJRyCKh3HuExp47nB13oniWt5o/+ 7cIBUtqPEirrxU88WIwXQqoHrX2pNCzf1hky6iaE9vSWf0yjGvhevHDYvvBkr99j wvLRNwuBJkVpwIRZYU44wrCJTqjtWvLmPbn9VkbJ9B90HVWbDRBw21NkYxEJV+gQ t/7JjYs6v2jZuWOQMXt8FPM0CJ3LGT+0eYLGBKfo9vg7JAmnnhEMxj3DKsW1lnHH 8tgxKPtlbBk6+PrafFvvU8aiTzxYAfRD9R3xNgTzFL+kJxTjzfG6p6PFeXqkmXAZ qFxErsl1sHGib6A1dPKBwmlvEsedWeyAyqc7BQMWr/JycecgT1WhM8MpVTGnkzg9 Bnk6tsfgUPVIIEvCNUzdscI4dnjgMjqvFed/6cjyS507rLdBz4XkyFtrZu0Fa00m 03kAdE+ItsOWUxZPofe7PtUkSY5yqm8SaBGYBh8Rk6PeBT3mOBWqf08YjEvp1qEF tv9vH0qWV3Cb64vXKuqqas7zS3kz22L1ibIugfIJUJcBPBpLSB6fSMLHExKjSMxq /ZrNGvCv/B/0Zg1LeALE9VXJTaIS0HFLEn1k8Duz82IprWWmRPsx3yzuZK0M+yXr 9IuKTUxA2jnIv61Of7Q6fpi+qRCnLmtrS7lLZ8ZaNw19Ld7ymLXluj6eK08jXHmj c7pCdwq8Qcs= =Rvx9 -----END PGP SIGNATURE----- --------------enigC0E96254D1723DA3223AF8A1-- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 08:15:49 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10E473A6AB7 for ; Fri, 30 Jan 2009 08:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg4hb1Gq6xC5 for ; Fri, 30 Jan 2009 08:15:48 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EC36F3A6B0F for ; Fri, 30 Jan 2009 08:15:47 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UG3feN090644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:03:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UG3fNt090643; Fri, 30 Jan 2009 09:03:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UG3UQ4090612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 09:03:41 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0UG3TKk008614 for ; Fri, 30 Jan 2009 11:03:29 -0500 Date: Fri, 30 Jan 2009 11:03:29 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090130160329.GA19809@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49831D14.4030804@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49831D14.4030804@fifthhorseman.net> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 10:30:28AM -0500, Daniel Kahn Gillmor wrote: > On 01/29/2009 03:53 PM, David Shaw wrote: > > I suppose if you had an implementation that insisted on using the > > first signature, regardless of the date, then the revocations would > > force it to look at the last signature.. but then, an implementation > > that did that may have other odd semantics elsewhere. It may conclude > > that there is no signature at all (after all, the one signature it was > > looking at is revoked). > > This would be a particularly odd implementation because "the first > signature regardless of date" has no meaning in OpenPGP, iiuc. There's > nothing stopping a re-ordering of signature packets, and a certificate > that looks like this: Yes, it was particularly odd. I've seen it happen, but it's broken for all the reasons you say. David From owner-ietf-openpgp@mail.imc.org Fri Jan 30 08:33:51 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16F6B3A6B9C for ; Fri, 30 Jan 2009 08:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aso4Hh5+8yFd for ; Fri, 30 Jan 2009 08:33:50 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 27F9A3A6B93 for ; Fri, 30 Jan 2009 08:33:48 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGNnQr091609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UGNnEC091608; Fri, 30 Jan 2009 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGNmad091602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 09:23:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0UGNlVf008723 for ; Fri, 30 Jan 2009 11:23:47 -0500 Date: Fri, 30 Jan 2009 11:23:47 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Ideas on new user attribute types and image formats Message-ID: <20090130162347.GB19809@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49831B83.7060704@fifthhorseman.net> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 10:23:47AM -0500, Daniel Kahn Gillmor wrote: > On 01/29/2009 01:23 PM, Peter Thomas wrote: > > 1) PNG (ISO 15948, RFC 2083) > > I fully agree that we should be supporting PNG here. That's long > overdue, and you don't have to do lossless compression in png, iiuc. We need (in the abstract) a way to store a picture in an OpenPGP user ID, and we have that now. What does adding a second way to store that picture buy us that we don't have already? I'm not really for or against PNG in OpenPGP, but I don't yet see the point here. David From lbragap@alicorp.com.pe Fri Jan 30 09:13:03 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09243A6A8B for ; Fri, 30 Jan 2009 09:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.692 X-Spam-Level: X-Spam-Status: No, score=-3.692 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCZqxUfxKQYd for ; Fri, 30 Jan 2009 09:13:03 -0800 (PST) Received: from host-89-228-33-154.elk.mm.pl (host-89-228-33-154.elk.mm.pl [89.228.33.154]) by core3.amsl.com (Postfix) with SMTP id 766483A6A53 for ; Fri, 30 Jan 2009 09:12:59 -0800 (PST) To: Subject: Customer Receipt/Purchase Confirmation From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130171300.766483A6A53@core3.amsl.com> Date: Fri, 30 Jan 2009 09:12:59 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.juicypious.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://juicypious.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 6, B839. 105 Clements Road. London. SE69 4DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From owner-ietf-openpgp@mail.imc.org Fri Jan 30 09:49:17 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C9F53A6965 for ; Fri, 30 Jan 2009 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.391 X-Spam-Level: X-Spam-Status: No, score=-3.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-3-3NCF2-YR for ; Fri, 30 Jan 2009 09:49:17 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8B0973A690B for ; Fri, 30 Jan 2009 09:49:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UHeAtt096105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 10:40:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UHeAvD096103; Fri, 30 Jan 2009 10:40:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UHdxgq096083 for ; Fri, 30 Jan 2009 10:40:10 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 4091 invoked from network); 30 Jan 2009 17:39:57 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 30 Jan 2009 17:39:57 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49833C0E.8010605@fifthhorseman.net> Date: Fri, 30 Jan 2009 12:42:38 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Ideas on new user attribute types and image formats References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> In-Reply-To: <20090130162347.GB19809@jabberwocky.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CD7643A5DEA3431196DB021" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6CD7643A5DEA3431196DB021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 11:23 AM, David Shaw wrote: > We need (in the abstract) a way to store a picture in an OpenPGP user > ID, and we have that now. What does adding a second way to store that > picture buy us that we don't have already? hpng supports features that jpeg doesn't, including at least: * indexed colormaps * alpha-channel transparency Both of these are useful features in some not uncommon circumstances (e.g. logos and "hackergotchi"/floating-head images that discard background/non-identity information). I'm not suggesting that OpenPGP is worthless without PNG, of course. But it would be useful to support it. --dkg --------------enig6CD7643A5DEA3431196DB021 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYM8E8zS7ZTSFznpAQJCURAApmgXUi17aM5FTZqK8bh7GaSk1Inw0uu3 nM332UPCBnSLPtfUizWvI6/ntLC4QaulwUTLFDqCwS0Puo+w8SFzipVuPKeG2xEY r10cgU0e8cml5w24giYpv5hNvy/ilrJOLN8AT3i1O2Ouq+3T2WRn+6uIrcpaYIyp 3vceNwzdBqiUtnUgqQuH4qm43xqYvaUedkYf3w4oSUOo+17yaIYCIEBvW2anLVqu FwEs2KeK9SJcuf0ttKsAKo2kQOgSL6ESUHxy7YqDghFO3U1XQtCHbem6PZm1zorl mHuPHfH2TsReKyJmvgD1WdVWqpiZXhiTxvoYFwCWEC/XENq8QgQgLJ57LtBAAOq5 40mYy0tgyT5/PeGfLC8w4jJw+v8u9VMuJQi1S/8D7oTdtNiJirZgpyN+bc2MbDwv U6bI30+2/9Z22qyIenaJNE+MzMPdnm4r6P7jePpGJem1pk5f295JFI4duFXNsy5q WThofsI8yg56m8xvtSg6ilG00TXwSjtLV+uR52AkW5qFD9EgskesUoZLacTFLhOf A3W4KAHWqjAUbHDpBey/ZTaGxyBqJ3NYAU/m3ukepuwsK7r1v8SIm8xgEvxWDhv5 5UHEs6AkK09ZbUf04YNYM3GiRVMBAWjxuP4GXLiwf55wYucikGd5VziyoX3BjLdX skTcpBLYVwc= =lyhD -----END PGP SIGNATURE----- --------------enig6CD7643A5DEA3431196DB021-- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 10:17:22 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3DF28C250 for ; Fri, 30 Jan 2009 10:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyvzB2VO2Mh0 for ; Fri, 30 Jan 2009 10:17:21 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C3FDF28C19D for ; Fri, 30 Jan 2009 10:17:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UI5FA8097518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:05:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UI5F5Z097517; Fri, 30 Jan 2009 11:05:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UI530S097507 for ; Fri, 30 Jan 2009 11:05:14 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fk-out-0910.google.com with SMTP id 19so559934fkr.10 for ; Fri, 30 Jan 2009 10:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=J5To2d0GXmlw7Jc2/1fN10oraqlznP5KZoD+U+rdl8s=; b=QW7h/c0HSH1MME99xH6wrJTHGW0VntOLHx6n1HaJCv2MwZ86Xjtr4MjZLjo1oC8Kud EJ4cwQe0vE5b6CcTOkKkfRe7wgB8hqPsghojOC1jdHaK9mSnf4yUT6P+vFqiRQe4DRQl RBjuaEuAoCKzCvOVL5C0/bPqG6odnH1pDMfPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=k6OXNcllaNEMnqfid1AfaAiTjC3bY2rkbAdF6r/lud4aJxmzsDWTTA1OBaPuUVFAtW eWrXztTaXHiRjHFE7lVXKLlx7Zemxz23/JLj9HCEQOQff1CZ/9aYUEUc0Z3wEZNNeyVt 7gkomPm4PkHhMBJv3x3JOgq0AFiqSZCmBorsQ= MIME-Version: 1.0 Received: by 10.181.199.16 with SMTP id b16mr509791bkq.142.1233338702872; Fri, 30 Jan 2009 10:05:02 -0800 (PST) In-Reply-To: <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> Date: Fri, 30 Jan 2009 19:05:02 +0100 Message-ID: <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: OpenPGP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 8:37 PM, Jon Callas wrote: > On the contrary, I think you should start discussing things here and > start writing drafts. I don't believe I'm technically skilled enough for doing this. And I must admit that I've borrowed some (of course not all) ideas here from some threads I've found on the gnupg mailing lists. I've already contacted the author (Christoph Mitterer) of that threads and I hope he'll have a look at the currently ongoing discussion. >>> You >>> might also want to require the critical bit to be set on those >>> packets, >>> although that will impair interoperability. >> What do you mean with this? Require it by the RFC? > No, the critical bit means that you want an operation to be 100% > correct or to fail. If there is any doubt in anyone's mind, you want > the system to halt with an unrecoverable error. Would you guys here, I mean Hal/Jon from PGP and David from gnupg suggest, that I set critical bits on the subpackets I listed before? Would your implementations (PGP/GnuPG) support this? Would you (and of course the other list members) support the idea of having the security critical subpackets REQUIRED per default by a future RFC? > Hal points out that this will mar interoperability. We'll but that was the idea. An implementation that does not support e.g. signature expiration should better fail at all. >> What was the reason that the key expiration time was taken out of the >> key itself (I think it was there before?)? > Because in PGP 3, a number of attributes were moved to the self-sigs > with the thought that you might have a key with different user ids and > different features. For example, I might have a user id in which a > cipher is allowed, and one in which it is not. You might also want to > have different expirations on those user ids. Well my idea is the following: We have the key expiration time, we have the User ID self-signatures and we have signature expiration. - If a user wants to just expire the key with one specific User ID, he could either revoke the corresponding self-signature or set an signature expiration time on it. He could even re-set it later by creating a new self-signature. - If all self-signatures (0x10-0x13 and 0x1F) are expired or revoked it's basically the same as if the whole key expired/revoked. So I think the key expiration flags somehow doubles that functionality and to me it made more sense when it was part of the key itself and thus kind of a promise that could not be changed later (e.g. by issuing a new self-signature) >> Well this would be great,.. I mean the current MAIN implementations of >> OpenPGP are probably GnuPG and PGP. I think David and Werner who >> represent GnuPG are reading this list and you, are you still at PGP >> Corporation? > Yes. Great, so you can comment whether you'd support such changes as I propose for the criticality of signature subpackets. Cheers, Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 10:25:48 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 275383A6AC8 for ; Fri, 30 Jan 2009 10:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u96o8clL1jFR for ; Fri, 30 Jan 2009 10:25:47 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EB6CF3A6965 for ; Fri, 30 Jan 2009 10:25:46 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIFjHs098072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:15:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIFjw1098071; Fri, 30 Jan 2009 11:15:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIFXXH098058 for ; Fri, 30 Jan 2009 11:15:44 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by bwz5 with SMTP id 5so187282bwz.10 for ; Fri, 30 Jan 2009 10:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=C/4EXuZ3MJdJGF41ZdS3/YOT0SYHOmjdT/0IuX3d4Ug=; b=csDQyYZ+hVbDGcP9qp7IwVZs9F2oQ+KNiSmswUk3OPXts0VVyjq06UFQgi0y9U9WH+ NZElM8JGUQF1yq3MxjRvZH3DC61dug2/p6HfSWmKEiE/fvwCnSisvakXhSWksaqyPX0h xZq67V1BSn0YLePuo5htRCQ/uubZW+GhYeToQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cC4MmgrBmhpTcDSLgrDWiJt5QqW0GW5hrPYjfpFTTxhL9bsDefyP49/cjJSPF2ZePh /YNMQwsGpATSFpzJaVkNiH5rdgbM8LjU3YX4LtugZ/mbOOD995gG4ilpaV5zYm2bNQKI ydwm5y72eR3Cta/kMVzouHsXMBHLft/4n8ltg= MIME-Version: 1.0 Received: by 10.181.28.15 with SMTP id f15mr509295bkj.187.1233339332435; Fri, 30 Jan 2009 10:15:32 -0800 (PST) In-Reply-To: <20090129203809.GA16331@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> Date: Fri, 30 Jan 2009 19:15:32 +0100 Message-ID: <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 9:38 PM, David Shaw wrote: > That's basically the point of the critical bit. You can think of it > as a way to force a (quasi) compatibility break. The critical bit > means "This subpacket is so important to the signature that I'd rather > you treat the whole signature is invalid than you not understand this > subpacket". Yes :-) > For example, GPG sets the critical bit on signatures that have an > expiration date set. Thus, if the signature is read by an > implementation that doesn't understand expiring signatures, the whole > signature is invalid. This was deemed better than the alternative - a > "expired" signature being treated as still usable because the > recipient implementation didn't know to ignore it. Ok that's already great,.. what do you think about the other subpackets that I've suggested for being critical in my initial post? Would you for example change gpg, that for example it issues the critical bit with the signature creation time, key expiration and key usage, too? >> But this is the point. Which have clearly defined meanings? Hast the >> policy URI a meaning on 0x18s (e.g. as the policy for signatures made >> by that subkey)? > It is the policy under which the subkey itself was certified. The > Policy URI for signatures made by that subkey would be in those > signatures. Ah, you're right ^^ I'm always messing this up. But by the way: This would be another thing that one could think of in future revisions of the RFC. Policy-URI on self-signatures: 0x10-0x13: The policy that is used for signing, with the corresponding UserID. 0x1F: The global policy for the whole key, when signing anything (especially other keys/UIDs) with that key 0x18: The policy used when making signatures with this key Policy-URI on other signatures: The policy under which this signature was issued. (Just like it is interpreted now) > Section 5.2.3.3: > > An implementation that encounters multiple self-signatures on the > same object may resolve the ambiguity in any way it sees fit, but > it is RECOMMENDED that priority be given to the most recent self- > signature. > > I suspect that most software follows this recommendation. GPG does. Of course,.. and in principle this is fine,.. but I'd even go so far to change this recommendation to a MUST. > The problem here is that what one use case requires as security > critical may not be what another one does. The critical bit is a more > flexible way for an implementation to require which subpackets are > understood. Hm, ok you're the expert :-) I just thought that the subpackets from my initial posting would be critical in ANY case ^^ Best wishes, Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 10:35:16 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC8E28C2C0 for ; Fri, 30 Jan 2009 10:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEeh5n-wQli6 for ; Fri, 30 Jan 2009 10:35:15 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 39FA028C19D for ; Fri, 30 Jan 2009 10:35:15 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIP1cP098404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:25:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIP163098403; Fri, 30 Jan 2009 11:25:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIOmwP098387 for ; Fri, 30 Jan 2009 11:24:59 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so365365fxm.10 for ; Fri, 30 Jan 2009 10:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=H5YTxjSH+ojIuxYFDQwRUf2co3UCdwuXKO+dqP04Iy4=; b=q5CvP7H8e5y61l9hqGIcdpOmUW+YDXL283mHEyESuz2vR8yoMKuDuKH30MjlrbZSlK vwTpHJ+Ifxv7UdS2F/TaaS+hMVTJxKMng8EKPBbtqKziZ51NxtUIPnGcPfv5MkcFgmFp fk7xJxSZXjFl6jxKR+NFCvfV0hxl9mAZMJW2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=r8K6wsOQhuu0M0mOKhwfhumtF3Dau00+S1qInZGdNjBVbESBzuIlcmPpNBuL88DQls sgd4ApVpSTzw4yJ5VmAblFYSMxQLoXvmC9IRIUNONnvmprI9+MnKYGKmIzgWFJhDjg7c fcAWR3TIcbYGATWB41KadA6l8C9nuvQpOyghw= MIME-Version: 1.0 Received: by 10.180.204.10 with SMTP id b10mr510432bkg.201.1233339887809; Fri, 30 Jan 2009 10:24:47 -0800 (PST) In-Reply-To: <20090129205321.GB16331@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> Date: Fri, 30 Jan 2009 19:24:47 +0100 Message-ID: <9ef756150901301024i3c62a79cuc1a357bef8685d4b@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 9:53 PM, David Shaw wrote: >> 0x1F: which one would I have to use for that? A 0x20 key revocation >> signature? Or would the completely revoke the whole key. > You revoke a 0x1F with a 0x30, same as you would use to revoke a > 0x10-0x13. 0x1F is a certification. Ooops XD >> Does the whole thing make sense anyway? I mean would it be a clean or >> at least working way to force ANY implementation to use only the most >> recent self-signatures? > I suspect it wouldn't hurt, but wouldn't help much either. For > example, given this: > > Signature === January 1 > Signature === January 3 > Signature === January 5 > > it is clear that the January 5 signature is the latest and the one to > use. Given this: > > Signature === January 1 > Revocation === January 2 > Signature === January 3 > Revocation === January 4 > Signature === January 5 > > It's still clear which signature is the right one. Yes, but it's not only clear. It is the ONLY way when following the RFC. But in the example from above (I've added some information to it): Signature using MD5 === January 1 Signature using MD5 === January 3 Signature using SHA256 === January 5 and implementation could say "oh I just understand MD5 and SHA1, but not SHA256... well the MD5 from 03.01. isn't the most recent, but at leas I understand it" > I suppose if you had an implementation that insisted on using the > first signature, regardless of the date, then the revocations would > force it to look at the last signature.. but then, an implementation > that did that may have other odd semantics elsewhere. Of course... > It may conclude > that there is no signature at all (after all, the one signature it was > looking at is revoked). Well,... even better than perhaps using the "dangerous" signature from January the 1st, isn't it? >> Would it work with the mayor implementations, PGP and GnuPG? > It would work in GnuPG. Hal, Jon, would it work with PGP? And would you experts here suggest to do the whole revoke-old-self-sigs-trick in order to prevent that kind of "downgrade attacks" (and possibly other evil things) I tried to describe above? Thanks for your advice, Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 10:46:41 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D414028C19D for ; Fri, 30 Jan 2009 10:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.132 X-Spam-Level: X-Spam-Status: No, score=-3.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOXuOvI7-xNv for ; Fri, 30 Jan 2009 10:46:41 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AB07C28C17D for ; Fri, 30 Jan 2009 10:46:40 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIZHwL098897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:35:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIZHES098896; Fri, 30 Jan 2009 11:35:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UIZ62o098887 for ; Fri, 30 Jan 2009 11:35:17 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 56019 invoked from network); 30 Jan 2009 18:35:05 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 30 Jan 2009 18:35:05 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <498348F9.5030708@fifthhorseman.net> Date: Fri, 30 Jan 2009 13:37:45 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Peter Thomas CC: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> In-Reply-To: <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig00D63C42AC6D682BB8B7BF9C" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00D63C42AC6D682BB8B7BF9C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 01:15 PM, Peter Thomas wrote: > But by the way: This would be another thing that one could think of in > future revisions of the RFC. > Policy-URI on self-signatures: > 0x10-0x13: The policy that is used for signing, with the corresponding = UserID. > 0x1F: The global policy for the whole key, when signing anything > (especially other keys/UIDs) with that key > 0x18: The policy used when making signatures with this key >=20 > Policy-URI on other signatures: > The policy under which this signature was issued. (Just like it is > interpreted now) I'd disagree with such a change, if only because it seems to force a semantic change on signatures that may already be in existence. It'd be weird if i made a signature that i knew meant "foo", and then came back later to find that according to the new RFC, i'd actually stated "bar". If you want to propose a new subpacket with the above semantics (perhaps one that would be invalid on anything but a self-sig), i wouldn't be opposed, though i'm not sure how useful it would be. And how would you interpret the following situation: Key A has a self-sig with policy X Key A signs B's key,uid pair and includes a with policy-URI Y. which policy governs the A's signature on B? why? --dkg --------------enig00D63C42AC6D682BB8B7BF9C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYNI/szS7ZTSFznpAQJudw/9GTj28ll3kG2iNOhUG0JGizEVXycMxbBP AgSXNdAfeZow7AUCGFa7dVT9E1YHkzuW2xYWs9CWnP5ZbN/Nrez1/7VP+bDVsSyq Z5rkd5t0S3hfn0p9Wl8RnjaBWwrb6rrg93wWJyj1QFL+sGzp0iz8IoI5PQ7kuMzC 7ebmIHb461uuxvu873GUsiRTUv3bRKLMJfwGSi+R2Iizh45hdJhpg5X5F6WJfdCx pJVnbC7yhMTkyCFQHa+cYljAAwEyrfyxRRlMOpnmKcg7rqRyNAgOxarA2wzGBQWq xZ7lfrkN2tH6ID4O8yaUlKTGJOf/6uS7mxdqELn8S1r0Ks/XihVXCiXIqy+Kdn7A /LNLc/CfT7IsxptsWiNnw6DHM2s2AnQBYD6sx0jCPC3YviQiM2162I8xSLHwxbI/ ipqyc0SlGIaUgCM24ByR6HioMUCiB9k0bzKeXhshhmyGAbDMS2PzKyFQYtNoDDw+ DKWlPb5IokRbqVK+WzQtElc01e7QIDmhK8UCMvpqp0z73+xqQkgxgLOKFOCxvan7 8/NTOKDCvqpTu4ry4G9I8xAdePJr6+uYhN22KHCxGeey5/ky5fiYmH7UlD76DiNh iDR0RYrldAkwEki5lx9opbCDlI+JSnk7lJRfiQkMp08sAhZxoIbJza+N4TDdZWot p4/glC78op8= =F6Lb -----END PGP SIGNATURE----- --------------enig00D63C42AC6D682BB8B7BF9C-- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 11:28:28 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B163A696B for ; Fri, 30 Jan 2009 11:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDoYBCN6AoEx for ; Fri, 30 Jan 2009 11:28:27 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 107A53A67CF for ; Fri, 30 Jan 2009 11:28:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJHjpe000741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:17:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJHjSq000740; Fri, 30 Jan 2009 12:17:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJHgI1000726 for ; Fri, 30 Jan 2009 12:17:44 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by bwz5 with SMTP id 5so220177bwz.10 for ; Fri, 30 Jan 2009 11:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B7v8e/GplcI9ofc0Y9PMidZ+yGRq86q+F2t+2V7tWUg=; b=WP+/doenbQkJNzBf6JNh37/TBFB28zvPI2PUW+/qh9Ge9XjjVSbsh3WTInasIIBv1o QRGiw8EXv58zDm3Kf6kUOlLXbbs8vWzSmLrNG0MSU93sZYm+WL/uLwPaj3rUHGbYUiUW UmOCSDQz0HfxbLHbu3J4KSO3Hw/aDFaKKQ3LQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=wPc++H6fvcCyWfUJwW36nVrkMgn1WRWzN48gtQS/AVjZdxUdqZOSEoz3K9R6504qIy OHxYPlY/Lewo2bJQ1HC+9Apv6t2rs/SPbSP0TH2ZgSt0oJeHtiVLiE30qsxnlCWspKNS dNsv7GGsqTpAZAsEkigmanE0TLspDi31sQLE4= MIME-Version: 1.0 Received: by 10.181.135.5 with SMTP id m5mr534320bkn.87.1233343061915; Fri, 30 Jan 2009 11:17:41 -0800 (PST) In-Reply-To: <20090129223044.GA16884@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> Date: Fri, 30 Jan 2009 20:17:41 +0100 Message-ID: <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 11:30 PM, David Shaw wrote: > It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F > signature revokes (potentially) all of them that are a) from the same > issuer (or from that issuer's designated revoker), and b) timestamped > earlier than the revocation. It cannot revoke ones that come after > it. Uhm? Why this? I'd thought it would only revoke the specifically revoked signature, as "the signature is computed over the same data as the certificate that it revokes". Am I missing something? > Even then there is the possibility of confusion of which signature you > intend to revoke. In those cases, you can always specify a particular > signature to revoke using the Signature Target subpacket in the > revocation. Arguably, you could even revoke multiple signatures with > one revocation by using multiple subpackets. > > Not, it should be pointed out, that many (any?) implementations > support Signature Targets yet. But the semantics are there. Uhm ok,.. so how does an implementation figure out which certificate is revoked by a revocation signature? From owner-ietf-openpgp@mail.imc.org Fri Jan 30 11:49:27 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3613D28C132 for ; Fri, 30 Jan 2009 11:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0Sa-Rhrxo-4 for ; Fri, 30 Jan 2009 11:49:26 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C9E4B3A67CF for ; Fri, 30 Jan 2009 11:49:25 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJc9VS001431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:38:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJc94G001430; Fri, 30 Jan 2009 12:38:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJc7LJ001424 for ; Fri, 30 Jan 2009 12:38:08 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so405190fxm.10 for ; Fri, 30 Jan 2009 11:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Wanj2eHOqRoq4IXM9p5rM+j0coyyKgBPsjDzxCAzDjM=; b=JgGJ4j0nHot+0KCcASgMbl9DPiPG7Qe55bkeSEGEYmEDCL0s/kJ7tUAnN91iKf6F4e pvdQh8nP+hKg6t36pKGkrptoSqvs4lvCtFiSgkqn0CgvSU68By4QUYpmhEGVwl5FKvdA Q1vo2xyIO49++d7/Yg6Y9hAKZ3HfeCzmpFtCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JHJW5oKsq5EeE205CtuOkcqHJc69kWjw6ZKDmpKDW+tf/pH6BG/wNgzsphpKpiwnxV h3yPQObzGzWxSVBJgasiBwmyaoVuoZ615KYMIkxMbSZ23oIEtI6lpNeUBLCAmkDSxaSi C5BYKoQNGgHOBLb0+EHsfF9E8Ain7O2e7WcsM= MIME-Version: 1.0 Received: by 10.181.60.14 with SMTP id n14mr546741bkk.23.1233344286380; Fri, 30 Jan 2009 11:38:06 -0800 (PST) In-Reply-To: <498348F9.5030708@fifthhorseman.net> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> <498348F9.5030708@fifthhorseman.net> Date: Fri, 30 Jan 2009 20:38:06 +0100 Message-ID: <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: IETF OpenPGP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 7:37 PM, Daniel Kahn Gillmor wrote: > I'd disagree with such a change, if only because it seems to force a > semantic change on signatures that may already be in existence. It'd be > weird if i made a signature that i knew meant "foo", and then came back > later to find that according to the new RFC, i'd actually stated "bar". I'm not sure if I understand what you mean. Currently policy URI subpackets are allowed on any signature, right? Their meaning is "The policy under which that signature was maid", right? Ok for signatures on other keys or data I didn't propose a semantical change. For policy-URIs on self-sigs: What would this mean at the moment: "The policy under which I signed my own key", right? Does this make any sense? I mean what could one tell in such a policy? "I trust myself", "I checked my own identity"? That was the idea why I suggested that idea, because I think otherwise it does not make much sense at all. Or do you know anything I didn't think ok? :-) > And how would you interpret the following situation: > > Key A has a self-sig with policy X > > Key A signs B's key,uid pair and includes a with policy-URI Y. > > which policy governs the A's signature on B? why? This is actually a problem. Currently the Policy URI is only meaningful for the signature itself ("The Policy under which the signature was maid"). If my suggestions for policy URIs on self-signatures would be implemented, conflicts could arise, just as you showed in your example above. I think it would be actually worse, as one could have different self-signatures (0x13,0x1F,0x18) that might apply in addition to the signature on the data iself. While conflicts are possible they "should" be unlikely in practice as all these policies are under the control of the key holder (and hopefully he have set them up without conflicts). If not one could specify the following: In case of a conflict: 1) Look at all policies whether they specify how to resolve conflicts. 2) If the actual conflict remains, or if the conflict resolution processes of the different policies are in conflict, the policies have priority in the following order: a) the policy specified in the signature of the signed data b) the policy on the User ID self-signature,.. IF the signers user ID was specified in the signature on the actual data c) the policy on the (most recent) 0x1F signature d) the policy on the 0x18 signature, from the key that was used to create the signature on the actual data Of course one would have to discuss which order fits best. Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:08:23 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B61A928C2A9 for ; Fri, 30 Jan 2009 12:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LP9Q1qUkRDm for ; Fri, 30 Jan 2009 12:08:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D8C9A28C2E7 for ; Fri, 30 Jan 2009 12:08:20 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJxUmM002268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJxUKm002267; Fri, 30 Jan 2009 12:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJxI9U002259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 12:59:29 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0UJxHt1010375 for ; Fri, 30 Jan 2009 14:59:17 -0500 Date: Fri, 30 Jan 2009 14:59:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090130195917.GC19809@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 08:17:41PM +0100, Peter Thomas wrote: > > On Thu, Jan 29, 2009 at 11:30 PM, David Shaw wrote: > > It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F > > signature revokes (potentially) all of them that are a) from the same > > issuer (or from that issuer's designated revoker), and b) timestamped > > earlier than the revocation. It cannot revoke ones that come after > > it. > Uhm? Why this? I'd thought it would only revoke the specifically > revoked signature, as "the signature is computed over the same data as > the certificate that it revokes". > Am I missing something? Take this example: User ID 0x10 signature on that user ID (timestamp 1) 0x10 signature on that user ID (timestamp 2) 0x30 revocation (timestamp 3) Which signature is being revoked? Without a signature target, it's not clear. > > Even then there is the possibility of confusion of which signature you > > intend to revoke. In those cases, you can always specify a particular > > signature to revoke using the Signature Target subpacket in the > > revocation. Arguably, you could even revoke multiple signatures with > > one revocation by using multiple subpackets. > > > > Not, it should be pointed out, that many (any?) implementations > > support Signature Targets yet. But the semantics are there. > Uhm ok,.. so how does an implementation figure out which certificate > is revoked by a revocation signature? I can't speak to any other program, but GPG finds the latest (i.e. most recent) signature or revocation from the issuer. If that turns out to be a revocation, then there is effectively no signature. Note that using the example above (sig+sig+revoke), this would result in there being effectively no signature. That is intentional, not a bug: the second signature superseded the first signature, and then the revocation revoked the second. End result: no signature. David From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:14:09 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AAAF28C2A9 for ; Fri, 30 Jan 2009 12:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALigdEL8iZ16 for ; Fri, 30 Jan 2009 12:14:08 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D8D8F28C1A3 for ; Fri, 30 Jan 2009 12:14:07 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UK3Yfl002455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 13:03:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UK3YC1002454; Fri, 30 Jan 2009 13:03:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UK3XU5002447 for ; Fri, 30 Jan 2009 13:03:33 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 71211 invoked from network); 30 Jan 2009 20:03:32 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 30 Jan 2009 20:03:32 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49835DB4.1040409@fifthhorseman.net> Date: Fri, 30 Jan 2009 15:06:12 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Peter Thomas CC: IETF OpenPGP Working Group Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> <498348F9.5030708@fifthhorseman.net> <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> In-Reply-To: <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF87E6C5E2432703861AE0346" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF87E6C5E2432703861AE0346 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 02:38 PM, Peter Thomas wrote: > For policy-URIs on self-sigs: What would this mean at the moment: "The > policy under which I signed my own key", right? > Does this make any sense? I mean what could one tell in such a policy? > "I trust myself", "I checked my own identity"? > That was the idea why I suggested that idea, because I think otherwise > it does not make much sense at all. I don't have an immediate example (i haven't used policy URIs on self-sigs or anywhere else). But simply saying "these two policy-type statements don't make sense" is different from saying "there could be no possible policy statement that you would like to reference in a self-signature." For example, here's a policy statement: "This identity is found on official government documents in the legitimate possession of the keyhold= er" Say Margaret has two user IDs: "Margaret Kantor " "Maggie Kantor " Since her gov't id doesn't have anything with "Maggie Kantor" on it (but she's known by all of her friends as maggie) she might want to assert the above policy for the former self-sig but not the latter. I'm not saying it's a great use case, but it would be really unfortunate if she had done that and then later found that it meant that all signatures issued by the Margaret Kantor uid (if she used a Signer's User ID subpacket, for example) suddenly meant that she had verified specific gov't-issued ID. > 1) Look at all policies whether they specify how to resolve conflicts. this assumes that the policies are machine-parseable in a form that includes conflict resolution, no? what form are you proposing? my reading of the RFC is that there is no restriction on what can be contained in the policy URI. > 2) If the actual conflict remains, or if the conflict resolution > processes of the different policies are in conflict, the policies have > priority in the following order: > a) the policy specified in the signature of the signed data > b) the policy on the User ID self-signature,.. IF the signers user ID > was specified in the signature on the actual data > c) the policy on the (most recent) 0x1F signature > d) the policy on the 0x18 signature, from the key that was used to > create the signature on the actual data >=20 > Of course one would have to discuss which order fits best. Wow, that sounds like a lot of heavy, fairly arbitrary work and hassle to hash out the spec, let alone an implementation. If we're ok with saying something like: "well-implemented clients should be configured well enough to know to not make any conflicts", why not just tell the well-implemented clients to embed the policy URI subpacket in every signature they make, and not introduce this special case at all? That seems simpler all around to me, and wouldn't require any retroactive changes to the specification. btw, please don't take my opposition to this particular idea as opposition to you proposing changes to the OpenPGP specification in general. It's great to see this sort of discussion. Thanks for raising = it! --dkg --------------enigF87E6C5E2432703861AE0346 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYNduczS7ZTSFznpAQLEhw//dbQlFQoWdu7nRMrs5CIezc8l5Hmf+Xs8 gqIkviy82a2HKOegv8VACB8lgvYTppepRBeYU0J9TRn7zWJAj1OPgPK97nKgR2IR kAx7eb0/qyoIyTz9/4NWSsAvrtnAdoCFcHwKrieMguh8aIIao2ULhcJ5MC/308UF DyKSYSl0z9kJ+kpfRtplIYf1dO5SURDVFPFlDUBHb8RZKRUchRP3yr8IEKy5cC4O h3uokrcoWR+YBJ03sc6X8j1obykH5B5Lbk4aTIUp9ZO7RZg+mlj5Apt4ikfo+jHL RVh7Rkx8289ZO17sDMlNv/8uhHXnwYFgE+P2ZAP1aIdVFQSSV2bZNqRaREkGz/s6 NDn3I1rQgBSUFsGdvDm1PQs42+jpMUzkUk3E6uajVksVZUMMC+KUXQDmq1qdxrXk tUsHlkJtp6sVNSyS3nFyAToVLPE9hEKREwP4bD8HqH5soIVL2zU1IX1OM72p6Uq1 /lDVj38jsWWj2MhAcHzXCzCEcdeJgltKUtV6Qy+jIlT9tSkUuZlfO4XkV9Rh1Cem jw5CD5sLU2YE8XR9xI5RAUa+MLmAjm5qlBW60cTG9PP6VHMI/m4xhBqt0oXbRW2s 8H/dKop/CUfMjzZBa/4W8PdjKhBA5JKqJPeyz1tM5VAodmS4I6xuMZPO9dRiTT0L ZcGW+UodjuY= =+1xp -----END PGP SIGNATURE----- --------------enigF87E6C5E2432703861AE0346-- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 14:26:29 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A812D3A6971 for ; Fri, 30 Jan 2009 14:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk9Ks6DKO3ta for ; Fri, 30 Jan 2009 14:26:28 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DE21D3A68C0 for ; Fri, 30 Jan 2009 14:26:27 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UMEhWH007810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 15:14:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UMEhB7007809; Fri, 30 Jan 2009 15:14:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UMEVlY007802 for ; Fri, 30 Jan 2009 15:14:42 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fk-out-0910.google.com with SMTP id 19so631093fkr.10 for ; Fri, 30 Jan 2009 14:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ipr6EbCWnpoxJd6XFpV34kYHbnWyMYlAGN+BRgD2XFQ=; b=EPmdWGBLjVr1P0AHTqYpPNhJJIaSXULKpbxnKhbDTcGm9CtUTSavsRhiyYVtRLlR1G 3OLlhYeT1TANtwvByVoQIxhk0wi0vTWf37h/jP99wcYbHp+hWAEWv59Pu9w2Z85+R3K+ PG6zRR9bMYxAwi4+iXWk3ktd1KV7yKgxCk0bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WJpkMBsuCgvSuToEDIlc2Vqnry15CjuRxJuCXjosDggE837YVJgxgHSYqDZ+OI15iZ y/oFMoSHP3G/WAPP3QTO5hCNQOcQbjHlUKn3kawBdDVQpvL8eFAyhuRq7q6WUd4V1QNN mWLeZtdc45i4OnwoM9qoW16cgUIPTP0oe1JBM= MIME-Version: 1.0 Received: by 10.181.37.6 with SMTP id p6mr589956bkj.29.1233353671340; Fri, 30 Jan 2009 14:14:31 -0800 (PST) Date: Fri, 30 Jan 2009 23:14:31 +0100 Message-ID: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> Subject: Series of minor questions about OpenPGP 6 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings. I've already threatened that I'd have more questions so here they are ;-) The following is about the correct interpretation of several signature subpackets on the different types of self-signatures. It would be great if you could tell me whether my interpretation of the CURRENT rfc and thus my interpretations of the semantical meanings are correct. I) General questions about the sematics: 1) signature creation time (2) Does the RFC imply, that a signature (of any type) is to be considered invalid, if the current time is not after the signature creation time? If so this would even mean that a key from the future is "unusable" if all self-signatures are invalid because of this, right? 2) signature expiration time (3) If the signature is expired it is to be considered invalid. It my thus have the same effect as key expiration time when all self-signatures are invalided because they're expired, right? 3) key expiration time (9) I've probably asked this before. But, what happens if different key expiration times are specified in the self-signatures? Is it left to the implementation to decide what to do? 4) exportable certification (4) Does this have a meaning on subkey binding signatures (0x18)? E.g. something like don't import the signature itself and neither the subkey? 5) Is it allowed that more than on subpackets of the same type exist in the same signature? E.g. Two policy URIs in on 0x13, or two preferred key servers. And what would it mean? I tried to create the following example and wonder whether my interpretation is always correct: Given is a public key, with several User IDs signed with 0x13s, a direct key signature 0x1F and several subkeys signed with an 0x18: (look closely as there are minor differences between the stuff below ;-) ) I) Subpackets on the 0x1F direct key signature (there should be only one of it): - signature creation/expiration time In principle it has only a meaning for the 0x1F itself, but it might also expire the key as described int I) 1 and I) 2 above. - key expiration time The expiration time of the WHOLE key with all UIDs, subkeys, etc. An implementation MAY decide when to use the key expiration from the 0x1F. Reasonable ways would be: * when no other self-sig specify one (thus it works globally for the key) * when the key was found/selected by the KeyID (this is questionable, isn't it?) * or it may even take priority in favor of all other key expiration times on other signatures, like 0x13's (but not 0x18s because subkeys have their own expiration time!!!!) - preferred symmetric/hash/compression algorithm An implementation MAY decide when to use these from the 0x1F. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when the key was found/selected by the Key ID (here I think this is NOT questionable as above) * or it may even take priority in favor of all other preferred algorithms on other signatures, like 0x13's and 0x18's - key server preferences / preferred key server / key flags / features An implementation MAY decide when to use these from the 0x1F. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when the key was found/selected by the Key ID (here I think this is NOT questionable as above) * or it may even take priority in favor of all other preferred algorithms on other signatures, like 0x13's and 0x18's II) Subpackets on any of the 0x10-0x13 certification signatures: - signature creation/expiration time In principle it has only a meaning for the 0x10-0x13 itself, but it might also expire the specific User ID (if there is no other valid self-signature on it). - key expiration time The expiration time of the WHOLE key with all UIDs, subkeys, etc. An implementation MAY decide when to use the key expiration from the 0x10-0x13. Reasonable ways would be: * when no other self-sig specify one (thus it works globally for the key) * when there is no global setting via a 0x1F self-signature * when the key was found/selected by the specific User ID (this is questionable, isn't it?), or it was specified as Signers User ID subpacket - preferred symmetric/hash/compression algorithm An implementation MAY decide when to use these from the 0x10-0x13. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature * when the key was found/selected by the specific User ID (here I think this is NOT questionable as above), or it was specified as Signers User ID subpacket - key server preferences / preferred key server / key flags / features An implementation MAY decide when to use these from the 0x10-0x13. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature * when the key was found/selected by the specific User ID (here I think this is NOT questionable as above), or it was specified as Signers User ID subpacket III) Subpackets on the 0x18 subkey binding signature: - signature creation/expiration time In principle it has only a meaning for the 0x18 itself, but it might also expire the specific subkey (if there is no other valid self-signature on it). - key expiration time The expiration time ONLY of the specific subkey, not of any other subkey, any User ID or even the whole primary key. This only applies to the specifix subkey, so an implementation cannot choose anything (as with the key expiration times above) - preferred symmetric/hash/compression algorithm An implementation MAY decide when to use these from the 0x18. Reasonable ways would be: * when that specific subkey was used for encryption/signing/or selected somehow else and optionally (the above condition seems nearly mandatory): * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature - key server preferences / preferred key server / key flags / features An implementation MAY decide when to use these from the 0x18. Reasonable ways would be: * when that specific subkey was used for encryption/signing/or selected somehow else and optionally (the above condition seems nearly mandatory): * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature Is this all correct / ok / within the borders of the CURRENT rfc? Ok that was a lot ^^ Lots of thanks in advance, Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 15:51:45 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0603A6975 for ; Fri, 30 Jan 2009 15:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxRS5NqVK6nc for ; Fri, 30 Jan 2009 15:51:44 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 700883A6778 for ; Fri, 30 Jan 2009 15:51:43 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UNdKXB010908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 16:39:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UNdKuu010907; Fri, 30 Jan 2009 16:39:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UNdIut010901 for ; Fri, 30 Jan 2009 16:39:19 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fk-out-0910.google.com with SMTP id 19so648022fkr.10 for ; Fri, 30 Jan 2009 15:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7mNTNlVKfHbWW9cSaw18stPcvbQIpCPoLrnCwcL2EHc=; b=Qf322S+p/Jt4jJlurfrv92YQaDIXnE4QVa02W0dF7+u2LB6sv6iR9hPHX4atBU0CrB /IWX3L/DU8+1F4k1zQbq+Jm8+wGuWCR+DI5wX9scEZiD6L1c8e4DfM+YsmbD6dlySOcS Ee/qBFSW+CRhoojKNDVHuh5oDPxRFACEq8QqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=gp1dzjhpp2mLTaanDRh79vxOnzCVd8Z++VY4o294sNSVkm+vhnoD4jFqFXYqfoYqK+ vKNfOWoHd2ah4FrDf3u+SqWa6DWr/rBspNGW2NuREYTDb8ERA/eYH0iYYJMthUPjwtmS 4hpFflPpQW3n1kVpUIagIvkQRchQxDM5pnpuI= MIME-Version: 1.0 Received: by 10.181.61.2 with SMTP id o2mr610272bkk.101.1233358757141; Fri, 30 Jan 2009 15:39:17 -0800 (PST) In-Reply-To: <49835DB4.1040409@fifthhorseman.net> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> <498348F9.5030708@fifthhorseman.net> <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> <49835DB4.1040409@fifthhorseman.net> Date: Sat, 31 Jan 2009 00:39:17 +0100 Message-ID: <9ef756150901301539m64a6ef17p1d4e5e7f2d0fec72@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: IETF OpenPGP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 9:06 PM, Daniel Kahn Gillmor wrote: > I don't have an immediate example (i haven't used policy URIs on > self-sigs or anywhere else). But simply saying "these two policy-type > statements don't make sense" is different from saying "there could be no > possible policy statement that you would like to reference in a > self-signature." Uhm,... well I'm not sure what the others are thinking. Of course I see your point in preserving compatibility, but even if this semantical change would be introduced in a future version of the RFC it wouldn't probably hurt that much, would it? I mean policy URIs are quite rare and everybody could still interpret it as he wants ;-) > For example, here's a policy statement: "This identity is found on > official government documents in the legitimate possession of the keyholder" > > Say Margaret has two user IDs: > > "Margaret Kantor " > "Maggie Kantor " > > Since her gov't id doesn't have anything with "Maggie Kantor" on it (but > she's known by all of her friends as maggie) she might want to assert > the above policy for the former self-sig but not the latter. > > I'm not saying it's a great use case, but it would be really unfortunate > if she had done that and then later found that it meant that all > signatures issued by the Margaret Kantor uid (if she used a Signer's > User ID subpacket, for example) suddenly meant that she had verified > specific gov't-issued ID. Not sure if I understand what you mean. A goverment could simply just sign the first UID and specify perhaps the governmental policy that was used (but this is of course not on the self signature). Which information would you exactly put in the policy from the self-signature's Policy URI? (I actually believe that there might be reasonable cases, and just want to understand yours correctly :-) ) >> 1) Look at all policies whether they specify how to resolve conflicts. > this assumes that the policies are machine-parseable in a form that > includes conflict resolution, no? Why? All policies might have a human readable chapter "X. In case of policy conflicts", where they explain what should happen. > what form are you proposing? my > reading of the RFC is that there is no restriction on what can be > contained in the policy URI. I don't see that point why this would have to be machine-readable. > If we're ok with saying something like: "well-implemented clients should > be configured well enough to know to not make any conflicts", why not > just tell the well-implemented clients to embed the policy URI subpacket > in every signature they make, and not introduce this special case at > all? This is actually a good point and in principle you're right (and this could be done without changing the RFC at all). But my model would allow to implement a more mighty policy model imagine the following: The policy "in" the self-signature is used as I proposed above. It could contain information like the following: - How is the key secured (security building, fences, safes, guards) - What are the procedures in case of a security compromise - How are other key/UIDs certified (e.g. when is a 0x10, 0x11, 0x12 or 0x13 issued) All these are very general information. The policy of the non-self-signatures could contain additional information about just that single signed document (for example). > That seems simpler all around to me, and wouldn't require any > retroactive changes to the specification. Well that's a point. But the whole idea with the semantic addition/change to the policy URI was just an idea, that I wanted to be discussed by all these wonderful experts here. I don't claim that I have the proof that it makes sense or is the best and only solution ;-) > btw, please don't take my opposition to this particular idea as > opposition to you Oh and I was just about to add you to my deadly enemy list ;-) (just kidding) > proposing changes to the OpenPGP specification in > general. It's great to see this sort of discussion. Thanks for raising it! Thank you :-) ... but again I was inspired by some threads I've found on the gnupg-lists,... so I must thank Christoph Mitterer ;-) Cheers, Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 16:16:15 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28A5C3A67D9 for ; Fri, 30 Jan 2009 16:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7meSfFDymaAu for ; Fri, 30 Jan 2009 16:16:14 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C53A33A6778 for ; Fri, 30 Jan 2009 16:16:13 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V04kUm011726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 17:04:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V04kxN011725; Fri, 30 Jan 2009 17:04:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V04Y7W011710 for ; Fri, 30 Jan 2009 17:04:45 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so516830fxm.10 for ; Fri, 30 Jan 2009 16:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sTta7PrnpfrsWPHjwdhXRSuU0oglYfMrwsE8SftkVOk=; b=O8kpOWaBoHG6ILMcM6Kq2Yg6l/KRqMbQ+PduWozfAUj4aE3y2g0YqsUGkbGyjaPL/T 8kfMX1m6+sNysWnoGrdHaZzClGRYvJhbF4K0GlNmTa/Jl1eKDI9lELOUGUB8jovuIp7y yWlcWg5xuW0D/BrSU68l3kPFYO90fONL4LlkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=al0kg8oimlOr3NAO+iInE82KBTBN6LZuL4JAdy29hN+/Lb8my9WyrIodZfgQWSbh0H /getIYTjX02SU5hPQQ6/B0R/nwsTR8O3tpUvIYoifTU/7u/1lmVYAJqCdvG/bioMD7+M 9yHr9Ikwbr8E7KWLIU4uhdi3F2SeWAtiE+STs= MIME-Version: 1.0 Received: by 10.181.152.14 with SMTP id e14mr611005bko.189.1233360273305; Fri, 30 Jan 2009 16:04:33 -0800 (PST) In-Reply-To: <20090130195917.GC19809@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> Date: Sat, 31 Jan 2009 01:04:33 +0100 Message-ID: <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 8:59 PM, David Shaw wrote: >> Uhm? Why this? I'd thought it would only revoke the specifically >> revoked signature, as "the signature is computed over the same data as >> the certificate that it revokes". >> Am I missing something? > > Take this example: > > User ID > 0x10 signature on that user ID (timestamp 1) > 0x10 signature on that user ID (timestamp 2) > 0x30 revocation (timestamp 3) > > Which signature is being revoked? Without a signature target, it's > not clear. Ahhhh.... First of all,.. the different types of revocation signatures are NOT calculated of the signature they revoke, but the data the signature to be revoked was calculated over, right? Ok then it's clear. Why is it not simply calculated over the signature to be revoked? But the following is still unclear: a) when I use a 0x20 key revocation signature: Am I correct that the explanation on page 21 says: A key having a revocation signature is completely invalid including all it's UIDs, subkeys, etc. and this cannot be undone in any way? (Of course the subkeys could still be used attached to another primary.) I mean the following doesn't work, right? Primary key |->UID |--->0x13 on that UID |->Subkey |--->0x18 on that subkey now I add a: |-> 0x20 key revocation at 12:00 making the key unusable (forever?) at 13:00 I add new UID's/0x13s/Subkeys/0x18s |->UID2 |--->0x13 on that UID2 |->Subkey2 |--->0x18 on that subkey2 But the whole thing would still be revoked, right? b) when I use a 0x28 key revocation signature: Does this (according to the RFC) make the subkey forever unusable, as above with the 0x20s? Or would issuing a subkey binding signature more recent than the 0x28 bring it (the subkey) back? c) when I use a 0x30 certification revocation signautre. Here the whole thing is different to a) and b) (as far as I understand). The RFC says "This signature revokes an EARLIER User ID certification signature..." Does this now exactly mean,.. that it revokes ALL earlier user id certification signatures? > I can't speak to any other program, but GPG finds the latest > (i.e. most recent) signature or revocation from the issuer. If that > turns out to be a revocation, then there is effectively no signature. > > Note that using the example above (sig+sig+revoke), this would result > in there being effectively no signature. That is intentional, not a > bug: the second signature superseded the first signature, and then the > revocation revoked the second. End result: no signature. Ok I see. And what does this now mean for my idea on how to force an implementation to use only the most recent signatures? Will the following work, as long as the signature creation times are correct? And I mean would it be correct even when strictly following the RFC? Public Key UID1 0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below) UID2 0x13 signature on that user ID (timestamp 1) 0x13 signature on that user ID (timestamp 2) 0x30 revocation (timestamp 3) (revokes every 0x10,0x11,0x12,0x13,0x1F on UID2 BUT NOT on UID1 BEFORE timestamp 3 0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above) Thanks for your help, Peter From owner-ietf-openpgp@mail.imc.org Fri Jan 30 17:07:07 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4671F3A69EF for ; Fri, 30 Jan 2009 17:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7lRNdXcYZNu for ; Fri, 30 Jan 2009 17:07:06 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2FE2F3A69FA for ; Fri, 30 Jan 2009 17:07:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V0sH0l013465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 17:54:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V0sH1A013464; Fri, 30 Jan 2009 17:54:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V0s6gj013458 for ; Fri, 30 Jan 2009 17:54:16 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 9FCAB2E2B5 for ; Fri, 30 Jan 2009 16:54:58 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63093-08 for ; Fri, 30 Jan 2009 16:54:55 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 822D92E2B3 for ; Fri, 30 Jan 2009 16:54:55 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Jan 2009 15:55:04 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Jan 2009 15:55:04 -0800 Message-Id: <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> From: Jon Callas To: IETF OpenPGP Working Group In-Reply-To: <49833C0E.8010605@fifthhorseman.net> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Ideas on new user attribute types and image formats Date: Fri, 30 Jan 2009 16:54:01 -0800 References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> <49833C0E.8010605@fifthhorseman.net> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > > hpng supports features that jpeg doesn't, including at least: > > * indexed colormaps > * alpha-channel transparency > > Both of these are useful features in some not uncommon circumstances > (e.g. logos and "hackergotchi"/floating-head images that discard > background/non-identity information). > > I'm not suggesting that OpenPGP is worthless without PNG, of course. > But it would be useful to support it. I'll add in that I think adding PNG is fine with me, and that's why I'll also be devil's advocate. So what? I think that "because it would be cool" is a fine answer. We should say it, if that's why. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJg5NYsTedWZOD3gYRAlQ8AKC+/nDZwYxkom6iWB1AS7JyM1hoSACfR0J1 RPkh1wD8WtKv8kPWJHbB074= =wzs4 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 17:12:08 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C6B3A67D9 for ; Fri, 30 Jan 2009 17:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwfd8icO3xxP for ; Fri, 30 Jan 2009 17:12:06 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 12C0E3A67AE for ; Fri, 30 Jan 2009 17:12:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V134Wm013743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 18:03:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V134sI013742; Fri, 30 Jan 2009 18:03:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V133wI013736 for ; Fri, 30 Jan 2009 18:03:03 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id B3AAE2E2B3 for ; Fri, 30 Jan 2009 17:03:55 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63161-07 for ; Fri, 30 Jan 2009 17:03:48 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id AFCF72E2B4 for ; Fri, 30 Jan 2009 17:03:48 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Jan 2009 16:03:57 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Jan 2009 16:03:57 -0800 Cc: ietf-openpgp@imc.org Message-Id: From: Jon Callas To: Peter Thomas In-Reply-To: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 6 Date: Fri, 30 Jan 2009 17:02:54 -0800 References: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I) General questions about the sematics: > 1) signature creation time (2) > Does the RFC imply, that a signature (of any type) is to be considered > invalid, if the current time is not after the signature creation time? > If so this would even mean that a key from the future is "unusable" if > all self-signatures are invalid because of this, right? In general, we want to let someone sign something for the future. There are many times when a signed object needs to be created in advance. That we call it "creation time" rather than "not before" is an eccentricity with an obvious right thing to do. So yeah, if someone creates a key that has a creation time of tomorrow, it's not valid yet. > > > 2) signature expiration time (3) > If the signature is expired it is to be considered invalid. It my thus > have the same effect as key expiration time when all self-signatures > are invalided because they're expired, right? Yes. > > > 3) key expiration time (9) > I've probably asked this before. But, what happens if different key > expiration times are specified in the self-signatures? Is it left to > the implementation to decide what to do? Yes. There are plenty of obvious right things to do. Let's suppose I am moving from example.com to foobar.com next Monday, but I quit example.com effective today (and set an expiration time that reflects that). From now until Monday, neither user name is valid. > > > 4) exportable certification (4) > Does this have a meaning on subkey binding signatures (0x18)? E.g. > something like don't import the signature itself and neither the > subkey? I have applications for this, myself. Yes. Here is my example for which this is a possible solution. PGP Corporation has a public key for "security@pgp.com" so people can send us security reports that are encrypted. I want to have the encryption subkey on my personal key, but I don't want to publish it. A non-exportable binding signature is a possible solution. > > > 5) Is it allowed that more than on subpackets of the same type exist > in the same signature? > E.g. Two policy URIs in on 0x13, or two preferred key servers. And > what would it mean? It makes sense to me to have two preferred keyservers. I don't have an opinion about policy URIs, but I wouldn't discount it automatically out of hand. > > > > > > I tried to create the following example and wonder whether my > interpretation is always correct: > Given is a public key, with several User IDs signed with 0x13s, a > direct key signature 0x1F and several subkeys signed with an 0x18: > (look closely as there are minor differences between the stuff > below ;-) ) I'm not going to comment further, but only because I'm in a hurry and haven't memorized the hex values. > > > I) Subpackets on the 0x1F direct key signature (there should be only > one of it): > - signature creation/expiration time > In principle it has only a meaning for the 0x1F itself, but it might > also expire the key as described int I) 1 and I) 2 above. > > - key expiration time > The expiration time of the WHOLE key with all UIDs, subkeys, etc. > An implementation MAY decide when to use the key expiration from the > 0x1F. Reasonable ways would be: > * when no other self-sig specify one (thus it works globally for the > key) > * when the key was found/selected by the KeyID (this is > questionable, isn't it?) > * or it may even take priority in favor of all other key expiration > times on other signatures, like 0x13's (but not 0x18s because subkeys > have their own expiration time!!!!) > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's > > > II) Subpackets on any of the 0x10-0x13 certification signatures: > - signature creation/expiration time > In principle it has only a meaning for the 0x10-0x13 itself, but it > might also expire the specific User ID (if there is no other valid > self-signature on it). > > - key expiration time > The expiration time of the WHOLE key with all UIDs, subkeys, etc. > An implementation MAY decide when to use the key expiration from the > 0x10-0x13. Reasonable ways would be: > * when no other self-sig specify one (thus it works globally for the > key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (this is > questionable, isn't it?), or it was specified as Signers User ID > subpacket > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x10-0x13. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (here I > think this is NOT questionable as above), or it was specified as > Signers User ID subpacket > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x10-0x13. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (here I > think this is NOT questionable as above), or it was specified as > Signers User ID subpacket > > > III) Subpackets on the 0x18 subkey binding signature: > - signature creation/expiration time > In principle it has only a meaning for the 0x18 itself, but it might > also expire the specific subkey (if there is no other valid > self-signature on it). > > - key expiration time > The expiration time ONLY of the specific subkey, not of any other > subkey, any User ID or even the whole primary key. > This only applies to the specifix subkey, so an implementation cannot > choose anything (as with the key expiration times above) > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > Is this all correct / ok / within the borders of the CURRENT rfc? > > Ok that was a lot ^^ > > > Lots of thanks in advance, > Peter > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJg5VtsTedWZOD3gYRAjEWAKCzTgK60jwnkNc6gV6NT0rlBpOe3ACfQTf1 GqW0aFDRQds5vFJHEP2HWzg= =xP4T -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 17:13:07 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D35223A69EF for ; Fri, 30 Jan 2009 17:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkCbAd5VxHA4 for ; Fri, 30 Jan 2009 17:13:07 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C64AD3A67EF for ; Fri, 30 Jan 2009 17:13:06 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V14cAJ013871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 18:04:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V14crW013870; Fri, 30 Jan 2009 18:04:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V14c5A013864 for ; Fri, 30 Jan 2009 18:04:38 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 0A0D52E2B5 for ; Fri, 30 Jan 2009 17:05:30 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63161-08 for ; Fri, 30 Jan 2009 17:05:26 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id E2C452E1E4 for ; Fri, 30 Jan 2009 17:05:26 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Jan 2009 16:05:35 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Jan 2009 16:05:35 -0800 Cc: OpenPGP Message-Id: <86EB229A-0E6D-47F3-9911-BC7F47D8B526@callas.org> From: Jon Callas To: Peter Thomas In-Reply-To: <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Fri, 30 Jan 2009 17:04:32 -0800 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 30, 2009, at 10:05 AM, Peter Thomas wrote: > > On Thu, Jan 29, 2009 at 8:37 PM, Jon Callas wrote: >> On the contrary, I think you should start discussing things here and >> start writing drafts. > I don't believe I'm technically skilled enough for doing this. And I > must admit that I've borrowed some (of course not all) ideas here from > some threads I've found on the gnupg mailing lists. I've already > contacted the author (Christoph Mitterer) of that threads and I hope > he'll have a look at the currently ongoing discussion. Of course you are skilled enough. And so what that you've borrowed ideas. Shakespeare borrowed all his plots. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJg5XPsTedWZOD3gYRAnTfAKCLk2TcIeyu2vyBPAnVkhJCCIqOHgCgtm7B k41rFL00AjX6B1APB8Qiif8= =BWdo -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 17:48:28 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2874C3A693E for ; Fri, 30 Jan 2009 17:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnoRptAx-Kws for ; Fri, 30 Jan 2009 17:48:27 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B65363A68BA for ; Fri, 30 Jan 2009 17:48:26 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V1ac9f014848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 18:36:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V1acrV014847; Fri, 30 Jan 2009 18:36:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V1aPS0014839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 18:36:37 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-62-216-219-24.dynamic.mnet-online.de [62.216.219.24]) by mailgw01.dd24.net (Postfix) with ESMTPA id B60367CC5BE; Sat, 31 Jan 2009 01:36:24 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: Peter Thomas Cc: OpenPGP In-Reply-To: <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-a2zdl3WhkIRphpiliK9b" Date: Sat, 31 Jan 2009 02:36:23 +0100 Message-Id: <1233365783.16857.17.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-a2zdl3WhkIRphpiliK9b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello WG and Peter. I'm constantly following what's happening here on the WG's list and also gnupg's lists, well at least more or less. I've already read most of your threads and I wonder whether you can read my minds or so ;) ... well we seem to have at least many common ideas. I'm especially happy with your suggestions in "improving" the usage of User Attributes =3D) On Fri, 2009-01-30 at 19:05 +0100, Peter Thomas wrote: > I don't believe I'm technically skilled enough for doing this. We'll I wouldn't consider myself to be skilled enough, too. At least I haven't looked into to the process of writing ID's yet. But I'd have a strong interest in doing so :-) of course only if the WG supports this. > And I > must admit that I've borrowed some (of course not all) ideas here from > some threads I've found on the gnupg mailing lists. I should sue you, what?! ;-P > I've already > contacted the author (Christoph Mitterer) of that threads and I hope > he'll have a look at the currently ongoing discussion. See above. I'm currently on some official trip (I miss it being a student ;) ) but when I'm back I could put together a list with the ideas the were discussed here. Of course everybody may add topics. Afterwards the WG could discuss which points would find broad support in a future RFC, wouldn't break backward-compatibility too much (or even better not at all), et cetera. I think it's much easier to split things up a little bit and discuss each point on its own, than writing a new draft-RFC that contains all the ideas presented here. Especially because probably not everything will find support ;) In the meantime: Happy discussing =3D) --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-a2zdl3WhkIRphpiliK9b Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTAxMzYyMVowIwYJKoZIhvcNAQkEMRYEFAtvDtgRAynsvtUHbSdCHDvEs3YpMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB AGZqQxLPULJtS0hxEXNqBlpw2uWjzD4LEu2fo/MNYyapZtOGa/KbFUYUhkUxN9dBr87MtPOHJexi EBcnifQ/s0MsU8zaY7RODxxZKE7bgcMzyG/8Vj1ny9h/KM4bXA3NCuYYOa4zcIy/wwkLHsq+/7Vl p/NP9GoFl13DzTAvFicfTBAXq5KIwWqnmhtkFA7RAH4ljB0fS5WoeaO2hJwRvDUgRMfaltVA+z6a +wIfmu77K5pBYo0XZwSazN6lqp+sAzeFksznV2HBagTU33/t8iaW3jivNtTXyexk2nJ0u+jqxPfh UHflhWJEhKuX2U1pvkolucuISnYuY8gmqdXH+cAAAAAAAAA= --=-a2zdl3WhkIRphpiliK9b-- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 19:57:39 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D948B3A6A41 for ; Fri, 30 Jan 2009 19:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGtEYscF1h5L for ; Fri, 30 Jan 2009 19:57:38 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4DB483A6901 for ; Fri, 30 Jan 2009 19:57:38 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V3mqfK018981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 20:48:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V3mqHQ018980; Fri, 30 Jan 2009 20:48:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V3me6Y018971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 20:48:51 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0V3mecY013269 for ; Fri, 30 Jan 2009 22:48:40 -0500 Date: Fri, 30 Jan 2009 22:48:40 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090131034840.GA21364@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2009 at 01:04:33AM +0100, Peter Thomas wrote: > > On Fri, Jan 30, 2009 at 8:59 PM, David Shaw wrote: > >> Uhm? Why this? I'd thought it would only revoke the specifically > >> revoked signature, as "the signature is computed over the same data as > >> the certificate that it revokes". > >> Am I missing something? > > > > Take this example: > > > > User ID > > 0x10 signature on that user ID (timestamp 1) > > 0x10 signature on that user ID (timestamp 2) > > 0x30 revocation (timestamp 3) > > > > Which signature is being revoked? Without a signature target, it's > > not clear. > Ahhhh.... > First of all,.. the different types of revocation signatures are NOT > calculated of the signature they revoke, but the data the signature to > be revoked was calculated over, right? Right. > But the following is still unclear: > a) when I use a 0x20 key revocation signature: > Am I correct that the explanation on page 21 says: A key having a > revocation signature is completely invalid including all it's UIDs, > subkeys, etc. and this cannot be undone in any way? Yes. However note that you can un-revoke a key by removing the revocation signature. That's very difficult to do in practice (keyservers would have the revoked copy). > (Of course the subkeys could still be used attached to another primary.) Right. > I mean the following doesn't work, right? > Primary key > |->UID > |--->0x13 on that UID > |->Subkey > |--->0x18 on that subkey > > now I add a: > |-> 0x20 key revocation at 12:00 making the key unusable (forever?) > > at 13:00 I add new UID's/0x13s/Subkeys/0x18s > |->UID2 > |--->0x13 on that UID2 > |->Subkey2 > |--->0x18 on that subkey2 > > But the whole thing would still be revoked, right? Right. > b) when I use a 0x28 key revocation signature: > Does this (according to the RFC) make the subkey forever unusable, as > above with the 0x20s? > Or would issuing a subkey binding signature more recent than the 0x28 > bring it (the subkey) back? That's a good question. The RFC specifies that a subkey may have one (and only one) binding signature, and zero or one revocations. Thus you cannot resign a subkey to un-revoke it. I don't recall if that is the reason the key grammar enforces exactly one binding signature, but it would seem to follow naturally from that grammar. Of course, you could strip off both the binding sig and revocation sig and just make a new signature, but then you're back in the distribution problem I mentioned earlier with un-revoking whole keys. Part of the design of OpenPGP is that subkeys are cheap - you should be able to make new ones easily. In fact, there was a proposal for perfect forward security in OpenPGP a few years ago that involved generating new subkeys very frequently (even to the point of a new subkey per message): http://www.apache-ssl.org/openpgp-pfs.txt > c) when I use a 0x30 certification revocation signautre. > Here the whole thing is different to a) and b) (as far as I understand). > The RFC says "This signature revokes an EARLIER User ID certification > signature..." > Does this now exactly mean,.. that it revokes ALL earlier user id > certification signatures? Not exactly - it revokes one signature. However if there is more than one signature, the earlier signature should be superseded by the later one. > And what does this now mean for my idea on how to force an > implementation to use only the most recent signatures? > Will the following work, as long as the signature creation times are > correct? And I mean would it be correct even when strictly following > the RFC? > > Public Key > UID1 > 0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below) > UID2 > 0x13 signature on that user ID (timestamp 1) > 0x13 signature on that user ID (timestamp 2) > 0x30 revocation (timestamp 3) (revokes every > 0x10,0x11,0x12,0x13,0x1F on UID2 BUT NOT on UID1 BEFORE > timestamp 3 > 0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above) This will work in GPG, but I don't think it is necessary - the same thing would happen even if you removed the revocations (Note, though, that you can't have a 0x1F on a UID. 0x1F is a direct key signature and is not issued on a UID). David From owner-ietf-openpgp@mail.imc.org Fri Jan 30 20:11:34 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFEED3A6848 for ; Fri, 30 Jan 2009 20:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0-a4xvjgK-T for ; Fri, 30 Jan 2009 20:11:33 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2D9653A6A41 for ; Fri, 30 Jan 2009 20:11:32 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V446qN019449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 21:04:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V446rC019448; Fri, 30 Jan 2009 21:04:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V444ZV019438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 21:04:05 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n0V444VB013376 for ; Fri, 30 Jan 2009 23:04:04 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 6 Date: Fri, 30 Jan 2009 23:04:04 -0500 References: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 30, 2009, at 5:14 PM, Peter Thomas wrote: (skipping the ones Jon answered) > I tried to create the following example and wonder whether my > interpretation is always correct: > Given is a public key, with several User IDs signed with 0x13s, a > direct key signature 0x1F and several subkeys signed with an 0x18: > (look closely as there are minor differences between the stuff > below ;-) ) > > I) Subpackets on the 0x1F direct key signature (there should be only > one of it): > - signature creation/expiration time > In principle it has only a meaning for the 0x1F itself, but it might > also expire the key as described int I) 1 and I) 2 above. > > - key expiration time > The expiration time of the WHOLE key with all UIDs, subkeys, etc. > An implementation MAY decide when to use the key expiration from the > 0x1F. Reasonable ways would be: > * when no other self-sig specify one (thus it works globally for the > key) > * when the key was found/selected by the KeyID (this is > questionable, isn't it?) > * or it may even take priority in favor of all other key expiration > times on other signatures, like 0x13's (but not 0x18s because subkeys > have their own expiration time!!!!) Use the shortest expiration time. If the 0x1F says you have 10 days, and the 0x13 says you have 5 days, you have 5 days. As you note, the subkeys have their own expiration time - but not if they exceed the whole key expiration time. You can't have a subkey that lives beyond its primary key. > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's If you have preferred algorithms in both the 0x1F and a 0x13, then you use the one with the narrowest scope. So, if the key was chosen by a particular user ID, you use the preferred algorithms from that user ID's selfsig. If that selfsig does not have preferred algorithms, use the one in the 0x1F. If the key was chosen by key ID (so there is no one particular user ID) you use the preferred algorithm from the primary user ID. As before, if there is no preferred algorithm there, use the one from the 0x1F. If there is preferred algorithms on a 0x18, I think I'd take the union of those algorithms with the ones from the user ID or 0x1F. > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's > > > II) Subpackets on any of the 0x10-0x13 certification signatures: > - signature creation/expiration time > In principle it has only a meaning for the 0x10-0x13 itself, but it > might also expire the specific User ID (if there is no other valid > self-signature on it). > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x10-0x13. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (here I > think this is NOT questionable as above), or it was specified as > Signers User ID subpacket > > > III) Subpackets on the 0x18 subkey binding signature: > - signature creation/expiration time > In principle it has only a meaning for the 0x18 itself, but it might > also expire the specific subkey (if there is no other valid > self-signature on it). > > - key expiration time > The expiration time ONLY of the specific subkey, not of any other > subkey, any User ID or even the whole primary key. > This only applies to the specifix subkey, so an implementation cannot > choose anything (as with the key expiration times above) > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > Is this all correct / ok / within the borders of the CURRENT rfc? > > Ok that was a lot ^^ > > > Lots of thanks in advance, > Peter > From owner-ietf-openpgp@mail.imc.org Sat Jan 31 08:37:23 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999A33A685B for ; Sat, 31 Jan 2009 08:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za2wMQ6d+o86 for ; Sat, 31 Jan 2009 08:37:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 621673A67DD for ; Sat, 31 Jan 2009 08:37:21 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VGP0fL048354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 09:25:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VGP0BL048353; Sat, 31 Jan 2009 09:25:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0VGOm90048343 for ; Sat, 31 Jan 2009 09:24:59 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 50444 invoked from network); 31 Jan 2009 16:24:47 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay00.pair.com with SMTP; 31 Jan 2009 16:24:47 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49847BF1.90306@fifthhorseman.net> Date: Sat, 31 Jan 2009 11:27:29 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Jon Callas CC: IETF OpenPGP Working Group Subject: Re: Ideas on new user attribute types and image formats References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> <49833C0E.8010605@fifthhorseman.net> <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> In-Reply-To: <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D1905824B75BAAC23BDF3CE" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D1905824B75BAAC23BDF3CE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 07:54 PM, Jon Callas wrote: > I'll add in that I think adding PNG is fine with me, and that's why =20 > I'll also be devil's advocate. So what? >=20 > I think that "because it would be cool" is a fine answer. We should =20 > say it, if that's why. Good point! FWIW, i actually have a couple specific implementation possibilities in mind, because i'm interested in seeing an expansion of places where OpenPGP is used [0]. The following ideas don't have anything close to a concrete implementation yet, but transparent PNGs would make them even more aesthetically appealing. * instant messaging: OTR [1] is a platform-agnostic IM encryption/authentication layer, which currently uses RSA keys for mutual authentication. I'd love to see OTR be able to use the OpenPGP web of trust to handle the actual authentication (though it currently does not). If it did, then PNG User Attribute support would allow graphical OTR-compliant IM implementations to automatically select hackergotchi-style images for pretty IM conversation displays (think "word-balloon" style). * I'd like to see better cryptographic verification tools that take advantage of OpenPGP's WoT to display human-comprehensible descriptions of relevant trust paths to an attempted validation. Since most people use graphical environments, and most people recognize people by their faces even more quickly than by their names, it would be great to show such trust paths with images in them (e.g. "Mary says that this is Joe" is useful, but a picture of Mary saying "this is Joe" would be even more appealing to many users). Plus, it would be cool ;) These are just some ideas to chew on. i wish i had more time to work on such craziness. --dkg [0] http://web.monkeysphere.info/ is the furthest advanced implementation of any push to extend the reach of the OpenPGP web-of-trust that i'm involved in. [1] http://www.cypherpunks.ca/otr/ --------------enig5D1905824B75BAAC23BDF3CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYR79szS7ZTSFznpAQK21Q//czc1oydZBnW/D7fQT3jNHmRgOaZqqmAn jdUHbwuM0q/mpL+N6k5oP9McUMAOg954ik3aFe9zXCGTBy58w9TiPtesO/XXYarC juClNNO3/Jc1l2jzztn7RL7aKYvA7vjyrDr04wabdGna0jTsoGw9qkErZA5fjLOx PqJxXHDYRhBCsgX6IClg8mrFz/HZiOX9j2NUeotrkljluEaggalC+/9bCDCTIA/4 Lm8DmAUn2Mm6LLbaXCHcX0iIN+lrdOhcMtYO7l9e2SlDOnNmicZxo8rYHheU6WB6 aeGy9FTjFN8iFxhVMvwPTf0SzBSX1wnPNL95v/1WuqXXdPSiaU68wM95y8PXFPpm lCO86irMLiKyNkd/p51IiKDihKka2cN0aSHMwLqeUaTi4VIDxO1nYu0q01cpcd5D L+OkLQWWs22mRvDTteav6GaFyzSKG9Ck3uFz8WY5oeXML3pnTCAolxJLu3lTEszv McY5ecNbU5QJrPbGoZZMO/KBuW+IwvyI+VZFlaaztijbUuHqAlITNt9YsNjLXRYV xTcZJj49aGrMszmCJr9+6V35nIEB0YrPYMDVcRZmQcIkqCBHcQk721eNdeXDmoWH PQS0bUqu4NZjC+n58binF5+tQW5hnQWe/N75gZZO6Wc3eHrhJlqe3ACstbjDai9n 8NRC/eYk5CQ= =dNqV -----END PGP SIGNATURE----- --------------enig5D1905824B75BAAC23BDF3CE-- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 13:13:07 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A75443A67F6 for ; Sat, 31 Jan 2009 13:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAmaa75FR+BM for ; Sat, 31 Jan 2009 13:13:06 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 233093A67E9 for ; Sat, 31 Jan 2009 13:13:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VL0Jr8057953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:00:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VL0JKR057952; Sat, 31 Jan 2009 14:00:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VL0606057937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:00:18 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id BF9DC7CCC8B for ; Sat, 31 Jan 2009 20:59:16 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: ietf-openpgp@imc.org In-Reply-To: <20090130195917.GC19809@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-Gx8EiQTEsNPhwrfamHlI" Date: Sat, 31 Jan 2009 21:59:15 +0100 Message-Id: <1233435556.4262.19.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-Gx8EiQTEsNPhwrfamHlI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. On Fri, 2009-01-30 at 14:59 -0500, David Shaw wrote: > Which signature is being revoked? Without a signature target, it's > not clear. In a future revision of the RFC I'd suggest to add a "implementations SHOULD use signature targets when revoking one or more signatures". But the current way should still be allowed. I'd even clarify that it works like this in the text. btw: As far as I understand this works the following way: - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the revocation signature AND with an earlier timestamp than the revocation signature BUT ONLY when calculated over the same data, which effectively means: * Either all the 0x1Fs from the specific key (primary or sub) * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID but NOT: * from all User IDs or even all 0x10-0x13s and 0x1Fs - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME creator as the revocation signature AND with an earlier timestamp than the revocation signature BUT ONLY when calculated over the same data, which effectively means: * Only on the specific subkey, not from the other subkeys - a 0x20 recovers everything and cannot be undone (with timestamp tricks) Is this correct? Do these timestamp tricks work with subkeys and 0x28 revocation signatures (and 0x18 subkey binding signatures)? The RFC doesn't say anything whether the 0x28 should only affect signatures BEFORE its own timestamp. > Note that using the example above (sig+sig+revoke), this would result > in there being effectively no signature. That is intentional, not a > bug: the second signature superseded the first signature, and then the > revocation revoked the second. End result: no signature. This is in my opinion the "best" and probably "only" way it should be handled. Peter's idea that only the most recent valid signature per class (where 0x10-0x13 is one class, 0x1F is one, and 0x18 is one) MUST be used by an implementation has a very little problem: What if the most recent is revoked? This would mean, that the earlier signature is used which is possibly bad. So I'd suggest the way of gnupg (and perhaps other implementations?) to be mandatory in a future RFC: Let me copy it from David: > the second signature superseded the first signature, and then the > revocation revoked the second. End result: no signature Regards, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-Gx8EiQTEsNPhwrfamHlI Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTIwNTkxM1owIwYJKoZIhvcNAQkEMRYEFM/q4yCdSvS9OcYrz9ST7Bur4F9uMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB AHrMvWK+1rqU/zXrcrsnnz4ceWLSn8JOEh0pyNQTK4g8oDNw+Ovs4kdbUpDCkVE1xvNrNwBMdJ1W 8WhrhDUxPga4r4VuC2J0TvjlR38mIDleZDE/Q14devc4XT/dkbHz/MNQxSOY/CtpFHgnNqCFFaZF 4oE4uGM3ldvtiaYPTRRMsOLORY1TgoGZBTyebPvdY0vjDNMilclVRpJFxZL+msBAMcg+mReEGdsm 69Zxsyv1qe2qw2ufrPspa3C2SEM/1A4/xmB7UgcKGmjExfBF1TCApTvZLBzkSoDEoPrUWZj2qVZS aQ4U84FH91pY2gqr3RjTdXe72HVDa9P4I+/4XKQAAAAAAAA= --=-Gx8EiQTEsNPhwrfamHlI-- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 13:31:08 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194103A682D for ; Sat, 31 Jan 2009 13:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnyAjmhiFaUH for ; Sat, 31 Jan 2009 13:31:07 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A1DAF3A67E9 for ; Sat, 31 Jan 2009 13:31:06 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLHCbc058676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:17:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLHC2q058675; Sat, 31 Jan 2009 14:17:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLHAg3058669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:17:11 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id CEB317CC364 for ; Sat, 31 Jan 2009 21:17:09 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: ietf-openpgp@imc.org In-Reply-To: <20090129205321.GB16331@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-x5emVcJYmKLf9v7gskHU" Date: Sat, 31 Jan 2009 22:17:08 +0100 Message-Id: <1233436628.4262.37.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-x5emVcJYmKLf9v7gskHU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2009-01-29 at 15:53 -0500, David Shaw wrote: > I suspect it wouldn't hurt, but wouldn't help much either. Why not? It would solve the problem! Or am I wrong? > For > example, given this: >=20 > Signature =3D=3D=3D January 1 > Signature =3D=3D=3D January 3 > Signature =3D=3D=3D January 5 >=20 > it is clear that the January 5 signature is the latest and the one to > use. Given this: >=20 > Signature =3D=3D=3D January 1 > Revocation =3D=3D=3D January 2 > Signature =3D=3D=3D January 3 > Revocation =3D=3D=3D January 4 > Signature =3D=3D=3D January 5 >=20 > It's still clear which signature is the right one. >=20 > I suppose if you had an implementation that insisted on using the > first signature, regardless of the date, then the revocations would > force it to look at the last signature.. Yes and this is the point here, isn't it?! ;) > It may conclude > that there is no signature at all (after all, the one signature it was > looking at is revoked). Well and I think that's what Peter actually wants. And that's what I'd suggest, too. Better to fail at all than using something probably evil, just like you at gnupg decided with the critical bit at the signature expiration time. I tried to think a little bit about the whole issue with revoking previous self-sigs. I'm not sure so pleas help me with the following: One dangerous type of attack in cryptosystems are downgrade attacks. I build some examples in order to find out whether an attacker could do downgrade attacks on self-sigs (e.g. with different hash algorithms and other different and security critical subpackets) and if this would be prevented by _generally_ revoking old self-sigs that were replaced by new ones. I think for these kind of attacks, revoking the old self-sigs wouldn't help anything, would it? Because an attacker could always strip of newer self-signatures and revocation signatures as he likes, and thus users and actually the whole OpenPGP-PKI really _RELY_ on functional keyservers the distribute the complete and up-to-date version of the key. Or do you see anything that I've missed? Anyway, as long as the RFC allows implementations the choose which self-signature they use (and "just" RECOMMEND to use the most recent), I'd vote to suggest to use that revocation trick. At least if it would work at all ^^ Have we already found a definite answer here? Best wishes, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-x5emVcJYmKLf9v7gskHU Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTIxMTcwOFowIwYJKoZIhvcNAQkEMRYEFEDZC4dMZSDvRhqOOjTqgKB++UkeMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB AKXr/qLJk4lBtSjrIKWl1gWE20/TxQGF833o7VjCPBOydbQ+dUqUMPqNy6fTpA9MqdelIr4xOFoK +9HaafugBuhTMvTwksn9haVhPUIgX6iyBMz2xSD8/v32lVCq3VEYYNpY8bHukoonPMDyWSS9f4Ex 2lVGWaO9XDqOGh/HfDWkMXid5tekD9ipf76Chc+Scafl+pDjVAMWw7fY4JtFxkKa7Y1APSc9zPcD YD9O58yIN2w6jR4Ngc1QD/i0Mq2tVkswtiHBSdomxXYJ3mJ7Il9rgRR5M4cFN7DiwenhwUC0IgeI q4z91gkiA6SEiNU39tzk5OVmHclrRiXTZV81dNgAAAAAAAA= --=-x5emVcJYmKLf9v7gskHU-- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 13:51:06 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62393A67E9 for ; Sat, 31 Jan 2009 13:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS15W8pjBWZz for ; Sat, 31 Jan 2009 13:51:05 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7EEFE3A682D for ; Sat, 31 Jan 2009 13:51:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLdaK7059496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:39:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLdaxf059495; Sat, 31 Jan 2009 14:39:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLdPCq059486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:39:36 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n0VLdObx004044 for ; Sat, 31 Jan 2009 16:39:24 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <1233435556.4262.19.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 16:39:24 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <1233435556.4262.19.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 3:59 PM, Christoph Anton Mitterer wrote: > Hi. > > > On Fri, 2009-01-30 at 14:59 -0500, David Shaw wrote: >> Which signature is being revoked? Without a signature target, it's >> not clear. > In a future revision of the RFC I'd suggest to add a "implementations > SHOULD use signature targets when revoking one or more signatures". > > But the current way should still be allowed. I'd even clarify that it > works like this in the text. > > btw: As far as I understand this works the following way: > - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the > revocation signature AND with an earlier timestamp than the revocation > signature > BUT ONLY when calculated over the same data, which effectively means: > * Either all the 0x1Fs from the specific key (primary or sub) > * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID > but NOT: > * from all User IDs or even all 0x10-0x13s and 0x1Fs > > - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME > creator as the revocation signature AND with an earlier timestamp than > the revocation signature > BUT ONLY when calculated over the same data, which effectively means: > * Only on the specific subkey, not from the other subkeys > > - a 0x20 recovers everything and cannot be undone (with timestamp > tricks) > > Is this correct? Not exactly. A revocation revokes *one* signature. Given this: Signature (timestamp 1) Signature (timestamp 2) Revocation (timestamp 3) The end result is no signature - but the reason is not because the revocation has revoked both signatures. The reason is because the signature at timestamp 2 has replaced the signature at timestamp 1, leaving this: Signature (timestamp 2) Revocation (timestamp 3) And then the revocation revokes the one remaining signature. David From owner-ietf-openpgp@mail.imc.org Sat Jan 31 14:00:36 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8713A67D7 for ; Sat, 31 Jan 2009 14:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MUPhDn32H5O for ; Sat, 31 Jan 2009 14:00:36 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8EE263A67A1 for ; Sat, 31 Jan 2009 14:00:35 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLo2Yg059723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:50:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLo2Lx059721; Sat, 31 Jan 2009 14:50:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLo0g4059715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:50:01 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n0VLo0qu004084 for ; Sat, 31 Jan 2009 16:50:00 -0500 Message-Id: <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> From: David Shaw To: OpenPGP In-Reply-To: <1233436628.4262.37.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 16:50:00 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <1233436628.4262.37.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 4:17 PM, Christoph Anton Mitterer wrote: > On Thu, 2009-01-29 at 15:53 -0500, David Shaw wrote: >> I suspect it wouldn't hurt, but wouldn't help much either. > Why not? It would solve the problem! Or am I wrong? > >> For >> example, given this: >> >> Signature === January 1 >> Signature === January 3 >> Signature === January 5 >> >> it is clear that the January 5 signature is the latest and the one to >> use. Given this: >> >> Signature === January 1 >> Revocation === January 2 >> Signature === January 3 >> Revocation === January 4 >> Signature === January 5 >> >> It's still clear which signature is the right one. >> >> I suppose if you had an implementation that insisted on using the >> first signature, regardless of the date, then the revocations would >> force it to look at the last signature.. > Yes and this is the point here, isn't it?! ;) > > >> It may conclude >> that there is no signature at all (after all, the one signature it >> was >> looking at is revoked). > Well and I think that's what Peter actually wants. And that's what I'd > suggest, too. The point I was trying to make is a little different. The RFC specifies a (RECOMMENDed) way to handle this problem, so that the extra revocations are not needed for any implementation that is compliant with that advice. This method with extra revocations is an attempt to force non-compliant implementations into doing the right thing. I suspect this may be tilting at windmills. These implementations are already disregarding the RFC advice. It is difficult to use RFC advice to get a non-RFC advice following implementation to do the right thing. In other words, why should they follow the RFC with regards to these extra revocations? They're already disregarding the RFC advice with regards to signature selection. Applications that follow the RFC advice don't need the extra revocations. Applications that don't follow the RFC advice anyway can't be expected to follow a new piece of advice. > I tried to think a little bit about the whole issue with revoking > previous self-sigs. I'm not sure so pleas help me with the following: > One dangerous type of attack in cryptosystems are downgrade attacks. > I build some examples in order to find out whether an attacker could > do > downgrade attacks on self-sigs (e.g. with different hash algorithms > and > other different and security critical subpackets) and if this would be > prevented by _generally_ revoking old self-sigs that were replaced by > new ones. > > I think for these kind of attacks, revoking the old self-sigs wouldn't > help anything, would it? > Because an attacker could always strip of newer self-signatures and > revocation signatures as he likes, and thus users and actually the > whole > OpenPGP-PKI really _RELY_ on functional keyservers the distribute the > complete and up-to-date version of the key. Exactly right. David From owner-ietf-openpgp@mail.imc.org Sat Jan 31 15:07:00 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811DE3A6956 for ; Sat, 31 Jan 2009 15:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixBRBpeSrGjd for ; Sat, 31 Jan 2009 15:06:59 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 039233A67D1 for ; Sat, 31 Jan 2009 15:06:58 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VMtHTI061777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 15:55:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VMtHOI061776; Sat, 31 Jan 2009 15:55:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VMtEJH061754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 15:55:16 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id 75A357CCCB3 for ; Sat, 31 Jan 2009 22:54:49 +0000 (GMT) Subject: Do we need to secure our keyservers against kind of DoS Attacks From: Christoph Anton Mitterer To: ietf-openpgp@imc.org Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-fI4cA5PVR5NpFuKeqTKZ" Date: Sat, 31 Jan 2009 23:54:48 +0100 Message-Id: <1233442488.4262.56.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-fI4cA5PVR5NpFuKeqTKZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. I having the following issue on my OpenPGP "TODO" list for some very long time now, and David just remembered me on it. On Fri, 2009-01-30 at 22:48 -0500, David Shaw wrote:=20 > Yes. However note that you can un-revoke a key by removing the > revocation signature. That's very difficult to do in practice > (keyservers would have the revoked copy). Keyservers are very critical for any PKI to work, aren't they? I mean there are plenty of "attacks" which would be possible without them: - we couldn't get revocations - we prone to attacks where someone simply removes some subpackets (e.g. a revocation signature, or a newer and updated self-signature) - there might be even more cases I can't think of Of course our keyservers work quite well, I can to some "upgrade my keyring" command and get the new keys and all added packets. And the big advantage is that no one can remove anything from them (it's even difficult for the admins, though probably not impossible). But there is the possibility of a kind of a DoS-Attack; service in the sense of "deliver the whole key and everything belonging to it to the requester". Imagine that my ISP is evil, tracks my connections and always removes some revocation signatures when I get the data. Are there currently working means to prevent this? One possibility would be do static_cast(DNSSEC) and implement a secured keyserver protocol. Of course we should use OpenPGP for this :-) A keyring could always sign the data he sends to a user, and the user could have the public key from that keyserver set up somewhere in his implementation as valid for acting as keyserver. Of course one could build trust-paths to the keyserver's public keys, et cetera, et cetera. Now the ISP could only block the whole keyserver, but at least I'd notice it and an implementation could WARN me if for example regularly updates of the keyrings don't work. Just an idea,... :-) Regards, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-fI4cA5PVR5NpFuKeqTKZ Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTIyNTQ0OFowIwYJKoZIhvcNAQkEMRYEFJlO1wHCrBfw7LDGGGbznH6ZtxOjMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB ANkqHlGiSDPOzI5DPS6SlFTkI0XeI9JIJkIirfcET8DpWiVyA9Y9AwenH2d0ttAnp8g2oQCQLd7f MMRVHRHA5EtSyh50WJow0o80JBwAcBPmG95Kswy2RsjyhRVoAickkXvuhUmTbAbRdJeZAZQyUXWz lD4VIMcq/vpPJOJTo6vl3A3i68b9smVJnn4nUF19qgIlesDO62WS/ksH4zCmFnK6cprEWeuzzI88 EmNGlxRlB4oBOJ0y0+b51Tug092Wksox7r0Hx2VKLuKp1lJGWVVOvvaxLAv51y+K6RBuuBPbAjx6 w31OYGwnmn+QvoNxvJp1PAcxmYQjdUoHVvptnvAAAAAAAAA= --=-fI4cA5PVR5NpFuKeqTKZ-- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 15:51:55 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCBC53A6A74 for ; Sat, 31 Jan 2009 15:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87uCQOfHwBmT for ; Sat, 31 Jan 2009 15:51:54 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DC2163A6827 for ; Sat, 31 Jan 2009 15:51:53 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VNfYMO063322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 16:41:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VNfYax063321; Sat, 31 Jan 2009 16:41:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VNfLZs063298 for ; Sat, 31 Jan 2009 16:41:33 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so898014fxm.10 for ; Sat, 31 Jan 2009 15:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hAKtxLZ2phdRDRhI5EwQlDEjiqfy7mtmOy4siLtwENI=; b=wJeG4W9PWbS9Qh7f/1kgos/EE+fsC6TRoJAJxSmKrNeExMKTu1Wyj9Pg+fm87XvfQH nZfdvo8X1wXaBG21urdElZB876WUhk5htBmGhewdOlEWfYoWZhxMRiEcPBAUWnXhMwGM q6pYijiBNOOQLPF/NFhLKlJ/HeqpJzLUr8290= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=fAhzMyb7a9mFp/kIgiyCddYgENuzwc5YFuTax20Q4MMjob8bvROmgXRCN4HoP4w2Ff U2TVzOhzpUptOKC8MCpGE6FdTLjoGqufwiV0B9UCzqFjT0j8SN71QfiexGY4QfPEEYWe v/qmPbpJTHKdciNGb9+BKbEHz+TQ6GpWVsmcE= MIME-Version: 1.0 Received: by 10.181.226.5 with SMTP id d5mr1028754bkr.116.1233445280765; Sat, 31 Jan 2009 15:41:20 -0800 (PST) In-Reply-To: <20090131034840.GA21364@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> <20090131034840.GA21364@jabberwocky.com> Date: Sun, 1 Feb 2009 00:41:20 +0100 Message-ID: <9ef756150901311541v7d656e9crb8cfd34faecffc1e@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2009 at 4:48 AM, David Shaw wrote: >> a) when I use a 0x20 key revocation signature: >> Am I correct that the explanation on page 21 says: A key having a >> revocation signature is completely invalid including all it's UIDs, >> subkeys, etc. and this cannot be undone in any way? > Yes. However note that you can un-revoke a key by removing the > revocation signature. That's very difficult to do in practice > (keyservers would have the revoked copy). Of course,... >> b) when I use a 0x28 key revocation signature: >> Does this (according to the RFC) make the subkey forever unusable, as >> above with the 0x20s? >> Or would issuing a subkey binding signature more recent than the 0x28 >> bring it (the subkey) back? > That's a good question. The RFC specifies that a subkey may have one > (and only one) binding signature, and zero or one revocations. Wow,.. uhm could you please point me to the location that mandates this? > Thus you cannot resign a subkey to un-revoke it. Uhm what do you mean with this? > I don't recall if that is > the reason the key grammar enforces exactly one binding signature, but > it would seem to follow naturally from that grammar. Ok,.. uhm let me think. This would also mean, that it's not possible to later change the properties of a subkey (e.g. preferred algorithms or it's key flags) while all this IS possible for the primary key and for UIDs, right? > Of course, you could strip off both the binding sig and revocation sig > and just make a new signature, but then you're back in the > distribution problem I mentioned earlier with un-revoking whole keys. Yeah,.. the keyservers would prevent this. > Part of the design of OpenPGP is that subkeys are cheap - you should > be able to make new ones easily. That's true, of course. But it could be annoying if people expect particular (sub)key ids, as they're used to it (e.g. when using a subkey for a special role like "work" or "home"). > In fact, there was a proposal for > perfect forward security in OpenPGP a few years ago that involved > generating new subkeys very frequently (even to the point of a new subkey per message) Wouldn't this actually create new security problems? I'm by no means a crypto-expert, but AFAIK the more one uses a key to sign/encrypt data, the more it is likely that someone can use all this data for statistical attacks. And this would be especially bad for the primary key, as far as I understand? >> c) when I use a 0x30 certification revocation signautre. >> Here the whole thing is different to a) and b) (as far as I understand). >> The RFC says "This signature revokes an EARLIER User ID certification >> signature..." >> Does this now exactly mean,.. that it revokes ALL earlier user id >> certification signatures? > Not exactly - it revokes one signature. However if there is more than > one signature, the earlier signature should be superseded by the later > one. I must apologize myself,.. but I don't understand this. The RFC must somehow specify which of the earlier self-signatures is revoked by it, or not? Or does it always revoke the MOST RECENT found signature BEFORE its own timestamp? If so where is this specified (I'm just curious, not that I wouldn't believe you ;-) )? And if that's the case we must remember that an implementation is allowed to use any self-signature, it's just RECOMMENDED to use the most recent. This would mean the following: Public Key User ID 0x13 timestamp 1 0x13 timestamp 2 0x30 revokes the 0x13 from timestamp 2 or: Public Key User ID 0x13 timestamp 1 0x30 still revokes the 0x13 from timestamp 2 0x13 timestamp 2 but now it's effectively as if we'd just have: Public Key User ID 0x13 timestamp 1 (isn't this what gnupg does when doing a minimize? removing all unusable signatures?) And even if not actually removed, an implementation would now be allowed (as far as I understand the RFC) to use the 0x13 from timestamp 1? Ok gnupg doesn't do this like this, as you explained in that (sig+sig+revoc) example before, but other could. I think I become mad ^^ > This will work in GPG, but I don't think it is necessary - Sorry when I'm nasty, but just think of the example directly above this text? Or the other examples I gave (with the older self-signature using MD5 and the new SHAsomething, or other differing subpackets). Of course probably any reasonable implementation will follow the recommendation and just use the most recent self-sig like gnupg does (sig+sig+revoc), but others might not. What's the opinion on the others on this? > the same thing would happen even if you removed the revocations Ok but for this we have the keyservers... (thank god) ^^ > (Note, > though, that you can't have a 0x1F on a UID. 0x1F is a direct key > signature and is not issued on a UID). Oopps,.. of course,.. that was a typo ;-) Thanks again in advance, Peter From owner-ietf-openpgp@mail.imc.org Sat Jan 31 16:40:07 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FDFD28C101 for ; Sat, 31 Jan 2009 16:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc2tamd3Jkbi for ; Sat, 31 Jan 2009 16:40:06 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C85BD28C10F for ; Sat, 31 Jan 2009 16:40:05 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110TcrB064404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 17:29:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n110TckO064403; Sat, 31 Jan 2009 17:29:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110TPNB064395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 17:29:37 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id 053037CCCB3 for ; Sun, 1 Feb 2009 00:29:24 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: OpenPGP In-Reply-To: References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <1233435556.4262.19.camel@fermat.scientia.net> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-Y+ib95DYU5whaLgBOtzE" Date: Sun, 01 Feb 2009 01:29:24 +0100 Message-Id: <1233448164.4262.64.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-Y+ib95DYU5whaLgBOtzE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I haven't seen that Peter has nearly asked the same... On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote: > > btw: As far as I understand this works the following way: > > - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the > > revocation signature AND with an earlier timestamp than the revocation > > signature > > BUT ONLY when calculated over the same data, which effectively means: > > * Either all the 0x1Fs from the specific key (primary or sub) > > * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID > > but NOT: > > * from all User IDs or even all 0x10-0x13s and 0x1Fs > > - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME > > creator as the revocation signature AND with an earlier timestamp than > > the revocation signature > > BUT ONLY when calculated over the same data, which effectively means: > > * Only on the specific subkey, not from the other subkeys I've seen you other mail that for subkeys this isn't possible at all, as only one 0x18 and corresponding revocation is allowed. > > - a 0x20 recovers everything and cannot be undone (with timestamp > > tricks) > > > > Is this correct? >=20 > Not exactly. A revocation revokes *one* signature. Given this: >=20 > Signature (timestamp 1) > Signature (timestamp 2) > Revocation (timestamp 3) >=20 > The end result is no signature - but the reason is not because the =20 > revocation has revoked both signatures. The reason is because the =20 > signature at timestamp 2 has replaced the signature at timestamp 1, =20 > leaving this: >=20 > Signature (timestamp 2) > Revocation (timestamp 3) >=20 > And then the revocation revokes the one remaining signature. OK I'm a little bit confused on how this works when an implementation doesn't follow the recommendation to use the most recent self-sig, because then it would matter whether "Revocation (timestamp 3)" applies to "Signature (timestamp 1)" or "Signature (timestamp 2)". But I've seen that Peter has asked nearly the same before (this time I've got his mail in time ;) ) and so I watch there for an answer. But on more thing: What I wrote above, with the "classes" and that it applies only to the specific UID,.. this is actually true, right? Greets, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-Y+ib95DYU5whaLgBOtzE Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDIwMTAwMjkyNFowIwYJKoZIhvcNAQkEMRYEFE8Ix7ofjb4aNWxThu3dN/COqM9IMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB ANSDJRlkm1Tm65LdwPlPbE/7ME+OJUNaVFWMNj2rbxec7jhMcd7Xxy4GIWAQrjqYgx5i503PjacL /zz/blLoPTlDQPi+38+vmliorNeXqTQm4lxMPC3G4L/9S2HGEw8CHoW30ZuahV+X1pi40PL1afWj AqBlW/vV40xk9A6bgBCTh0dH+BEQMXkG3mT/pRXhLYT+W7I0Vq2gbgp247hJIU4nXtiHwgy9lRSH iDMWywhRkmHfBHoJe+XE+wdiQygP//XPrMAntixy63kK/57ukPxzjhH77Znoscl1JzPbyiNvEQ6t yl76PagYmRe100WUuK8CzrHnew72EfmI8nwUQxgAAAAAAAA= --=-Y+ib95DYU5whaLgBOtzE-- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 16:42:38 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64EC33A693C for ; Sat, 31 Jan 2009 16:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRVR50SMHTzy for ; Sat, 31 Jan 2009 16:42:37 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EC2273A67E2 for ; Sat, 31 Jan 2009 16:42:36 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110UOrx064425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 17:30:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n110UOdG064424; Sat, 31 Jan 2009 17:30:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from underhill.hhhh.org (underhill.hhhh.org [209.221.140.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110UDtJ064417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 17:30:24 -0700 (MST) (envelope-from wiml@hhhh.org) Received: from [IPv6:2001:470:1f01:444:1000::1:1f] (bzzzt.hhhh.org [IPv6:2001:470:1f01:444:1000:0:1:1f]) by underhill.hhhh.org (Postfix) with ESMTPS id 933F52EDCBB; Sat, 31 Jan 2009 16:30:12 -0800 (PST) In-Reply-To: <1233442488.4262.56.camel@fermat.scientia.net> References: <1233442488.4262.56.camel@fermat.scientia.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D63BE86-F20D-42B0-B445-09F3196C6278@hhhh.org> Cc: Christoph Anton Mitterer Content-Transfer-Encoding: 7bit From: Wim Lewis Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks Date: Sat, 31 Jan 2009 16:30:10 -0800 To: ietf-openpgp@imc.org X-Mailer: Apple Mail (2.753.1) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (Attention Conservation Notice: non-expert explaining why he thinks the current system is almost-good-enough without securing keyservers) This is an interesting point. After thinking about it a little, though, I think that securing the keyserver (or the communication with the keyserver) isn't quite the right approach. One of the strengths of the PGP setup, I think, is that you don't have to trust the keyserver; all it's doing is making it easier for you to get information that you can in theory get elsewhere. An end-to-end approach is better, IMHO. (It also protects against the opposite side of the equation: is Mallory secretly stripping the revocation certificate out of your friend's uploads to the keyserver? Also, I don't want to have to make trust/policy decisions based on how much I trust the people running the keyserver, how strong my trust path is to their key, and so on. That way lies X.509...) Notionally, I want some sort of periodic, signed communication from other keyholders, saying, "The official state of my key-and- subpackets is X. Expect another message before date Y". However, not all of the subpackets are really important: if I'm missing a signature from someone else, or an alternate user ID, I'm not going to trust you any *more* than if I have it. So this thing only needs to cover packets which reduce trust --- revocations, I guess. (Am I missing a scenario here?) But is this actually any different from periodically renewing a set of expiring signatures? (I don't think so, but I could easily be missing stuff.) In which case, OpenPGP already supplies everything needed to prevent this sort of denial-of-key-distribution attack. For this to work, the spec has to follow a principle: any subpacket must either (a) only increase trust, not decrease it; or (b) be more- or-less equivalent to early expiration of another subpacket. How close is OpenPGP to this? Actual implementations might get in the way, on the other hand. In the past I have tried maintaining a key with a non-expiring signature on the signing key and a rotating, expiring signature on the (sole) encryption subkey. A lot of software seemed to dislike this, and seemed to assume that if the encryption subkey had *any* expired signatures, it was invalid, even if it had a later, still-valid signature. As a UI detail, it might be nice to have a bit on an expiring signature indicating whether a renewed signature is expected, possibly in the form of an "expiration reason" field a la RFC4880-5.2.3.23. This shouldn't, I think, be acted upon by the trust- computation code, but might be useful to help decide whether to try to refresh that key. On the other hand, maybe the software should just infer this bit from the existence of previous, expired signatures in the keyring. > One possibility would be do static_cast(DNSSEC) and > implement a secured keyserver protocol. Of course I think securing the keyserver communication is *also* good, as long as the trust model doesn't depend on it. :) If nothing else, doing a keyring refresh broadcasts to a listener or MITM the contents of your keyring, which you might consider sensitive information. From owner-ietf-openpgp@mail.imc.org Sat Jan 31 17:29:15 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DB628C0F4 for ; Sat, 31 Jan 2009 17:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNJPKMvw-CwR for ; Sat, 31 Jan 2009 17:29:14 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9E7AA3A6888 for ; Sat, 31 Jan 2009 17:29:13 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n111IlKQ065837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 18:18:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n111Ildo065836; Sat, 31 Jan 2009 18:18:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n111IZ17065829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 18:18:46 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw02.dd24.net (Postfix) with ESMTPA id 7905A3557E6 for ; Sun, 1 Feb 2009 01:18:34 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: OpenPGP In-Reply-To: <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <1233436628.4262.37.camel@fermat.scientia.net> <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-ejjO4YdNwXfBCtVKk5DF" Date: Sun, 01 Feb 2009 02:18:33 +0100 Message-Id: <1233451113.4262.84.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-ejjO4YdNwXfBCtVKk5DF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote: > The point I was trying to make is a little different. The RFC =20 > specifies a (RECOMMENDed) way to handle this problem, so that the =20 > extra revocations are not needed for any implementation that is =20 > compliant with that advice. Ok,.. in that case (if an implementation follows that advice, we don't have to talk, as you're right and everything is fine :-) > This method with extra revocations is an =20 > attempt to force non-compliant implementations into doing the right =20 > thing. I suspect this may be tilting at windmills. These =20 > implementations are already disregarding the RFC advice. It is =20 > difficult to use RFC advice to get a non-RFC advice following =20 > implementation to do the right thing. Ok I got your point,.. and the following is probably a little bit pedantic and quibbling. The point I was trying to make is: As this "use the most recent" is "only" a RECOMMENDS, an implementation might not follow this advice, and would be still conforming, right? As you've said, it's only an advice. We cannot do anything about really-non-conforming implementations (the ones that breaks the MUSTs and so on), so lets forget about them. But the just plain (very) stupid ones which are compliant (and thus would follow the revocations of the previous self-sigs, as Peter suggested) but don't follow that advice/recommendation would break and possibly do bad things. And this could be avoided by following Peters ideas. To conclude: Public Key 0x1F (timestamp 1) 0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1 0x1F (timestamp 3) 0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3 0x1F (timestamp 5) UID 0x13 (timestamp 1) 0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 0x13 (timestamp 3) 0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3 0x13 (timestamp 5) would work as I described in the example, and ONLY: 0x1F (timestamp 5) 0x13 (timestamp 5) would be usable, right? But something like: Subkey 0x18 (timestamp 1) 0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 0x18 (timestamp 3) doesn't work, and the subkey will still be revoked. Is this correct so far, and something we can agree on? :-) I don't want to judge whether this is really necessary for the real world, as probably most sane implementations follow the advice, to use the most recent only, and thus the sig+sig+revoc thingy will work. (Of course for all of this, a working key server infrastructure is needed) Personally I'd prefer that a future version of the RFC really enforces that advice, in order to be 100% sure, that in every conforming application, the sig1+sig2+revoc example or sig1+sig2 example works as expected. > > I think for these kind of attacks, revoking the old self-sigs wouldn't > > help anything, would it? > > Because an attacker could always strip of newer self-signatures and > > revocation signatures as he likes, and thus users and actually the =20 > > whole > > OpenPGP-PKI really _RELY_ on functional keyservers the distribute the > > complete and up-to-date version of the key. > Exactly right. Excellent :-) Good night (at least in my time zone ;) ), --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-ejjO4YdNwXfBCtVKk5DF Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDIwMTAxMTgzM1owIwYJKoZIhvcNAQkEMRYEFLRWZ/Y1ewQiocuv7jkaVmkiDe7DMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB ALLw7UbHMGwfYPZc3GdkPxDPihwu6Wx8cjRLN4x248MhQpNZPNG8V4DE+rXtvfRrwE0ROvSA6yuy lLT8nlx+Ju4Gw8xBCEQ/OyulTV0o09SeZNEwJcS/VXVBLGmksPLguxKhx9Eohk+z3zbDlWlr6hG0 HJlSdPE6k4evm864jxvetz+2QtDtUimpfOAPmd5n2TlIfimL64z2BMr4+yeP14zqU63pkP7d3yWZ bqv4VRo1POa2ByVuWXFLpSYBG4x4xzA5Sbch3muNpnS1m5gcbGkqdm0V40MR+2v7a3fL4E+oqMBg 9zIUjannVbVbzhcRTXvFqnpBy6at7kc2Nv+4a1wAAAAAAAA= --=-ejjO4YdNwXfBCtVKk5DF-- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 19:29:47 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69F63A691C for ; Sat, 31 Jan 2009 19:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwQbS8m4oMS9 for ; Sat, 31 Jan 2009 19:29:47 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 815633A677C for ; Sat, 31 Jan 2009 19:29:46 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113IBW5069070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:18:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113IBUm069069; Sat, 31 Jan 2009 20:18:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113Hxm8069063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:18:10 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113HwrG005574 for ; Sat, 31 Jan 2009 22:17:58 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <9ef756150901311541v7d656e9crb8cfd34faecffc1e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 22:17:58 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> <20090131034840.GA21364@jabberwocky.com> <9ef756150901311541v7d656e9crb8cfd34faecffc1e@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 6:41 PM, Peter Thomas wrote: >>> b) when I use a 0x28 key revocation signature: >>> Does this (according to the RFC) make the subkey forever unusable, >>> as >>> above with the 0x20s? >>> Or would issuing a subkey binding signature more recent than the >>> 0x28 >>> bring it (the subkey) back? >> That's a good question. The RFC specifies that a subkey may have one >> (and only one) binding signature, and zero or one revocations. > Wow,.. uhm could you please point me to the location that mandates > this? Section 11.1. But notice what that section is: Transferable Public Keys. This doesn't really mean you *can't* re-sign a subkey. It just means that once you *have* re-signed a subkey, you need to remove the old signature (and revocation, if any) before you give the key to anyone else. >> Part of the design of OpenPGP is that subkeys are cheap - you should >> be able to make new ones easily. > That's true, of course. But it could be annoying if people expect > particular (sub)key ids, as they're used to it (e.g. when using a > subkey for a special role like "work" or "home"). Subkeys aren't really usable for roles. User IDs make great roles. Subkeys can be used by anyone who cares to, so if you have two encryption keys, even though you intend one for "home" and one for "work", you have no way to tell me which one you want me to use, and even if you did, I could use the other one if I wanted to. >>> c) when I use a 0x30 certification revocation signautre. >>> Here the whole thing is different to a) and b) (as far as I >>> understand). >>> The RFC says "This signature revokes an EARLIER User ID >>> certification >>> signature..." >>> Does this now exactly mean,.. that it revokes ALL earlier user id >>> certification signatures? >> Not exactly - it revokes one signature. However if there is more >> than >> one signature, the earlier signature should be superseded by the >> later >> one. > I must apologize myself,.. but I don't understand this. > The RFC must somehow specify which of the earlier self-signatures is > revoked by it, or not? Or does it always revoke the MOST RECENT found > signature BEFORE its own timestamp? If so where is this specified (I'm > just curious, not that I wouldn't believe you ;-) )? The RFC specifies the signature target which lets a revocation indicate which signature is being revoked. Aside from that, there is no indication at all beyond that the revocation is issued over the same data as the signature being revoked, and that it is dated after the original signature. It's not most recent, it's not least recent, it's simply not specified. David From owner-ietf-openpgp@mail.imc.org Sat Jan 31 19:48:23 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7A463A693C for ; Sat, 31 Jan 2009 19:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX7C36uVNley for ; Sat, 31 Jan 2009 19:48:22 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5D3493A6882 for ; Sat, 31 Jan 2009 19:48:22 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113aeaO069459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:36:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113ae7N069458; Sat, 31 Jan 2009 20:36:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113ac9P069442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:36:39 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113aLRU005680 for ; Sat, 31 Jan 2009 22:36:38 -0500 Message-Id: <35E4BA10-0E81-4F67-8751-FE69FC5EA32A@jabberwocky.com> From: David Shaw To: OpenPGP In-Reply-To: <1233448164.4262.64.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 22:36:38 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <1233435556.4262.19.camel@fermat.scientia.net> <1233448164.4262.64.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 7:29 PM, Christoph Anton Mitterer wrote: > Sorry, I haven't seen that Peter has nearly asked the same... > > On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote: >>> btw: As far as I understand this works the following way: >>> - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as >>> the >>> revocation signature AND with an earlier timestamp than the >>> revocation >>> signature >>> BUT ONLY when calculated over the same data, which effectively >>> means: >>> * Either all the 0x1Fs from the specific key (primary or sub) >>> * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID >>> but NOT: >>> * from all User IDs or even all 0x10-0x13s and 0x1Fs > > >>> - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the >>> SAME >>> creator as the revocation signature AND with an earlier timestamp >>> than >>> the revocation signature >>> BUT ONLY when calculated over the same data, which effectively >>> means: >>> * Only on the specific subkey, not from the other subkeys > I've seen you other mail that for subkeys this isn't possible at > all, as > only one 0x18 and corresponding revocation is allowed. Unless you strip off the old 0x18 and revocation. >>> - a 0x20 recovers everything and cannot be undone (with timestamp >>> tricks) >>> >>> Is this correct? >> >> Not exactly. A revocation revokes *one* signature. Given this: >> >> Signature (timestamp 1) >> Signature (timestamp 2) >> Revocation (timestamp 3) >> >> The end result is no signature - but the reason is not because the >> revocation has revoked both signatures. The reason is because the >> signature at timestamp 2 has replaced the signature at timestamp 1, >> leaving this: >> >> Signature (timestamp 2) >> Revocation (timestamp 3) >> >> And then the revocation revokes the one remaining signature. > OK I'm a little bit confused on how this works when an implementation > doesn't follow the recommendation to use the most recent self-sig, > because then it would matter whether "Revocation (timestamp 3)" > applies > to "Signature (timestamp 1)" or "Signature (timestamp 2)". If an implementation doesn't follow the recommendation, then most of the bets are off. You can't really predict what it will do. Will it decide that signature 2 is revoked, and thus act on signature 1? Maybe. Will it decide that signature 1 is revoked, and thus act on signature 2? Maybe. Again, though, I have to stress that this is RFC pedantic nitpickery. In the real world, no implementation does this, as it would make little sense. > But I've seen that Peter has asked nearly the same before (this time > I've got his mail in time ;) ) and so I watch there for an answer. > > But on more thing: What I wrote above, with the "classes" and that it > applies only to the specific UID,.. this is actually true, right? I'm not sure I understand the question here. David From owner-ietf-openpgp@mail.imc.org Sat Jan 31 19:55:56 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E473A6B52 for ; Sat, 31 Jan 2009 19:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GRpbi2AL+VP for ; Sat, 31 Jan 2009 19:55:55 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4BBD63A6B51 for ; Sat, 31 Jan 2009 19:55:55 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113kuLU069672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:46:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113kuvQ069671; Sat, 31 Jan 2009 20:46:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113ktKs069665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:46:56 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113ktH0005720 for ; Sat, 31 Jan 2009 22:46:55 -0500 Message-Id: <5299FDD5-2B44-473E-A211-D56389B3286F@jabberwocky.com> From: David Shaw To: IETF OpenPGP Working Group In-Reply-To: <49847BF1.90306@fifthhorseman.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Ideas on new user attribute types and image formats Date: Sat, 31 Jan 2009 22:46:55 -0500 References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> <49833C0E.8010605@fifthhorseman.net> <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> <49847BF1.90306@fifthhorseman.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 11:27 AM, Daniel Kahn Gillmor wrote: > * I'd like to see better cryptographic verification tools that take > advantage of OpenPGP's WoT to display human-comprehensible > descriptions > of relevant trust paths to an attempted validation. Since most people > use graphical environments, and most people recognize people by their > faces even more quickly than by their names, it would be great to show > such trust paths with images in them (e.g. "Mary says that this is > Joe" > is useful, but a picture of Mary saying "this is Joe" would be even > more > appealing to many users). I like this one in particular. The WoT is one of the least understood parts of OpenPGP. Doing it graphically would help. > Plus, it would be cool ;) Yes. David From owner-ietf-openpgp@mail.imc.org Sat Jan 31 20:09:32 2009 Return-Path: X-Original-To: ietfarch-openpgp-archive@core3.amsl.com Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E31D3A6B52 for ; Sat, 31 Jan 2009 20:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi-krXAZefct for ; Sat, 31 Jan 2009 20:09:31 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EA2553A6B53 for ; Sat, 31 Jan 2009 20:09:30 -0800 (PST) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113aNcx069437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:36:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113aNVa069436; Sat, 31 Jan 2009 20:36:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113aLXt069430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:36:22 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113aLRT005680 for ; Sat, 31 Jan 2009 22:36:21 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <1233451113.4262.84.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 22:36:20 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <1233436628.4262.37.camel@fermat.scientia.net> <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> <1233451113.4262.84.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 8:18 PM, Christoph Anton Mitterer wrote: > On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote: >> The point I was trying to make is a little different. The RFC >> specifies a (RECOMMENDed) way to handle this problem, so that the >> extra revocations are not needed for any implementation that is >> compliant with that advice. > Ok,.. in that case (if an implementation follows that advice, we don't > have to talk, as you're right and everything is fine :-) > >> This method with extra revocations is an >> attempt to force non-compliant implementations into doing the right >> thing. I suspect this may be tilting at windmills. These >> implementations are already disregarding the RFC advice. It is >> difficult to use RFC advice to get a non-RFC advice following >> implementation to do the right thing. > Ok I got your point,.. and the following is probably a little bit > pedantic and quibbling. The point I was trying to make is: > As this "use the most recent" is "only" a RECOMMENDS, an > implementation > might not follow this advice, and would be still conforming, right? > As you've said, it's only an advice. > > We cannot do anything about really-non-conforming implementations (the > ones that breaks the MUSTs and so on), so lets forget about them. > > But the just plain (very) stupid ones which are compliant (and thus > would follow the revocations of the previous self-sigs, as Peter > suggested) but don't follow that advice/recommendation would break and > possibly do bad things. > And this could be avoided by following Peters ideas. > > To conclude: > > Public Key > 0x1F (timestamp 1) > 0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1 > 0x1F (timestamp 3) > 0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3 > 0x1F (timestamp 5) > UID > 0x13 (timestamp 1) > 0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 > 0x13 (timestamp 3) > 0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3 > 0x13 (timestamp 5) > > would work as I described in the example, and ONLY: > 0x1F (timestamp 5) > 0x13 (timestamp 5) > would be usable, right? > > But something like: > Subkey > 0x18 (timestamp 1) > 0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 > 0x18 (timestamp 3) > doesn't work, and the subkey will still be revoked. > > > Is this correct so far, and something we can agree on? :-) No, because that implementation, completely in accordance with the RFC, does not have to regard that user ID as valid after seeing a single revocation. An implementation is free to treat any user ID with a revocation on it as permanently dead. I understand what you're trying to accomplish, I really do. Unfortunately, the RFC doesn't give you the tools to do what you want. Luckily, the problem you're trying to solve isn't actually a problem with any known implementation of OpenPGP. If you want to generate extra revocations, go right ahead (it should work fine), but understand it is not a "RFC safe" way of doing things. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113kuLU069672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:46:57 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113kuvQ069671; Sat, 31 Jan 2009 20:46:56 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113ktKs069665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:46:56 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113ktH0005720 for ; Sat, 31 Jan 2009 22:46:55 -0500 Message-Id: <5299FDD5-2B44-473E-A211-D56389B3286F@jabberwocky.com> From: David Shaw To: IETF OpenPGP Working Group In-Reply-To: <49847BF1.90306@fifthhorseman.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Ideas on new user attribute types and image formats Date: Sat, 31 Jan 2009 22:46:55 -0500 References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> <49833C0E.8010605@fifthhorseman.net> <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> <49847BF1.90306@fifthhorseman.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 11:27 AM, Daniel Kahn Gillmor wrote: > * I'd like to see better cryptographic verification tools that take > advantage of OpenPGP's WoT to display human-comprehensible > descriptions > of relevant trust paths to an attempted validation. Since most people > use graphical environments, and most people recognize people by their > faces even more quickly than by their names, it would be great to show > such trust paths with images in them (e.g. "Mary says that this is > Joe" > is useful, but a picture of Mary saying "this is Joe" would be even > more > appealing to many users). I like this one in particular. The WoT is one of the least understood parts of OpenPGP. Doing it graphically would help. > Plus, it would be cool ;) Yes. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113aeaO069459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:36:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113ae7N069458; Sat, 31 Jan 2009 20:36:40 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113ac9P069442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:36:39 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113aLRU005680 for ; Sat, 31 Jan 2009 22:36:38 -0500 Message-Id: <35E4BA10-0E81-4F67-8751-FE69FC5EA32A@jabberwocky.com> From: David Shaw To: OpenPGP In-Reply-To: <1233448164.4262.64.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 22:36:38 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <1233435556.4262.19.camel@fermat.scientia.net> <1233448164.4262.64.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 7:29 PM, Christoph Anton Mitterer wrote: > Sorry, I haven't seen that Peter has nearly asked the same... > > On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote: >>> btw: As far as I understand this works the following way: >>> - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as >>> the >>> revocation signature AND with an earlier timestamp than the >>> revocation >>> signature >>> BUT ONLY when calculated over the same data, which effectively >>> means: >>> * Either all the 0x1Fs from the specific key (primary or sub) >>> * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID >>> but NOT: >>> * from all User IDs or even all 0x10-0x13s and 0x1Fs > > >>> - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the >>> SAME >>> creator as the revocation signature AND with an earlier timestamp >>> than >>> the revocation signature >>> BUT ONLY when calculated over the same data, which effectively >>> means: >>> * Only on the specific subkey, not from the other subkeys > I've seen you other mail that for subkeys this isn't possible at > all, as > only one 0x18 and corresponding revocation is allowed. Unless you strip off the old 0x18 and revocation. >>> - a 0x20 recovers everything and cannot be undone (with timestamp >>> tricks) >>> >>> Is this correct? >> >> Not exactly. A revocation revokes *one* signature. Given this: >> >> Signature (timestamp 1) >> Signature (timestamp 2) >> Revocation (timestamp 3) >> >> The end result is no signature - but the reason is not because the >> revocation has revoked both signatures. The reason is because the >> signature at timestamp 2 has replaced the signature at timestamp 1, >> leaving this: >> >> Signature (timestamp 2) >> Revocation (timestamp 3) >> >> And then the revocation revokes the one remaining signature. > OK I'm a little bit confused on how this works when an implementation > doesn't follow the recommendation to use the most recent self-sig, > because then it would matter whether "Revocation (timestamp 3)" > applies > to "Signature (timestamp 1)" or "Signature (timestamp 2)". If an implementation doesn't follow the recommendation, then most of the bets are off. You can't really predict what it will do. Will it decide that signature 2 is revoked, and thus act on signature 1? Maybe. Will it decide that signature 1 is revoked, and thus act on signature 2? Maybe. Again, though, I have to stress that this is RFC pedantic nitpickery. In the real world, no implementation does this, as it would make little sense. > But I've seen that Peter has asked nearly the same before (this time > I've got his mail in time ;) ) and so I watch there for an answer. > > But on more thing: What I wrote above, with the "classes" and that it > applies only to the specific UID,.. this is actually true, right? I'm not sure I understand the question here. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113aNcx069437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:36:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113aNVa069436; Sat, 31 Jan 2009 20:36:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113aLXt069430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:36:22 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113aLRT005680 for ; Sat, 31 Jan 2009 22:36:21 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <1233451113.4262.84.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 22:36:20 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <1233436628.4262.37.camel@fermat.scientia.net> <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> <1233451113.4262.84.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 8:18 PM, Christoph Anton Mitterer wrote: > On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote: >> The point I was trying to make is a little different. The RFC >> specifies a (RECOMMENDed) way to handle this problem, so that the >> extra revocations are not needed for any implementation that is >> compliant with that advice. > Ok,.. in that case (if an implementation follows that advice, we don't > have to talk, as you're right and everything is fine :-) > >> This method with extra revocations is an >> attempt to force non-compliant implementations into doing the right >> thing. I suspect this may be tilting at windmills. These >> implementations are already disregarding the RFC advice. It is >> difficult to use RFC advice to get a non-RFC advice following >> implementation to do the right thing. > Ok I got your point,.. and the following is probably a little bit > pedantic and quibbling. The point I was trying to make is: > As this "use the most recent" is "only" a RECOMMENDS, an > implementation > might not follow this advice, and would be still conforming, right? > As you've said, it's only an advice. > > We cannot do anything about really-non-conforming implementations (the > ones that breaks the MUSTs and so on), so lets forget about them. > > But the just plain (very) stupid ones which are compliant (and thus > would follow the revocations of the previous self-sigs, as Peter > suggested) but don't follow that advice/recommendation would break and > possibly do bad things. > And this could be avoided by following Peters ideas. > > To conclude: > > Public Key > 0x1F (timestamp 1) > 0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1 > 0x1F (timestamp 3) > 0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3 > 0x1F (timestamp 5) > UID > 0x13 (timestamp 1) > 0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 > 0x13 (timestamp 3) > 0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3 > 0x13 (timestamp 5) > > would work as I described in the example, and ONLY: > 0x1F (timestamp 5) > 0x13 (timestamp 5) > would be usable, right? > > But something like: > Subkey > 0x18 (timestamp 1) > 0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 > 0x18 (timestamp 3) > doesn't work, and the subkey will still be revoked. > > > Is this correct so far, and something we can agree on? :-) No, because that implementation, completely in accordance with the RFC, does not have to regard that user ID as valid after seeing a single revocation. An implementation is free to treat any user ID with a revocation on it as permanently dead. I understand what you're trying to accomplish, I really do. Unfortunately, the RFC doesn't give you the tools to do what you want. Luckily, the problem you're trying to solve isn't actually a problem with any known implementation of OpenPGP. If you want to generate extra revocations, go right ahead (it should work fine), but understand it is not a "RFC safe" way of doing things. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113IBW5069070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 20:18:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n113IBUm069069; Sat, 31 Jan 2009 20:18:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n113Hxm8069063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 20:18:10 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n113HwrG005574 for ; Sat, 31 Jan 2009 22:17:58 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <9ef756150901311541v7d656e9crb8cfd34faecffc1e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 22:17:58 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> <20090131034840.GA21364@jabberwocky.com> <9ef756150901311541v7d656e9crb8cfd34faecffc1e@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 6:41 PM, Peter Thomas wrote: >>> b) when I use a 0x28 key revocation signature: >>> Does this (according to the RFC) make the subkey forever unusable, >>> as >>> above with the 0x20s? >>> Or would issuing a subkey binding signature more recent than the >>> 0x28 >>> bring it (the subkey) back? >> That's a good question. The RFC specifies that a subkey may have one >> (and only one) binding signature, and zero or one revocations. > Wow,.. uhm could you please point me to the location that mandates > this? Section 11.1. But notice what that section is: Transferable Public Keys. This doesn't really mean you *can't* re-sign a subkey. It just means that once you *have* re-signed a subkey, you need to remove the old signature (and revocation, if any) before you give the key to anyone else. >> Part of the design of OpenPGP is that subkeys are cheap - you should >> be able to make new ones easily. > That's true, of course. But it could be annoying if people expect > particular (sub)key ids, as they're used to it (e.g. when using a > subkey for a special role like "work" or "home"). Subkeys aren't really usable for roles. User IDs make great roles. Subkeys can be used by anyone who cares to, so if you have two encryption keys, even though you intend one for "home" and one for "work", you have no way to tell me which one you want me to use, and even if you did, I could use the other one if I wanted to. >>> c) when I use a 0x30 certification revocation signautre. >>> Here the whole thing is different to a) and b) (as far as I >>> understand). >>> The RFC says "This signature revokes an EARLIER User ID >>> certification >>> signature..." >>> Does this now exactly mean,.. that it revokes ALL earlier user id >>> certification signatures? >> Not exactly - it revokes one signature. However if there is more >> than >> one signature, the earlier signature should be superseded by the >> later >> one. > I must apologize myself,.. but I don't understand this. > The RFC must somehow specify which of the earlier self-signatures is > revoked by it, or not? Or does it always revoke the MOST RECENT found > signature BEFORE its own timestamp? If so where is this specified (I'm > just curious, not that I wouldn't believe you ;-) )? The RFC specifies the signature target which lets a revocation indicate which signature is being revoked. Aside from that, there is no indication at all beyond that the revocation is issued over the same data as the signature being revoked, and that it is dated after the original signature. It's not most recent, it's not least recent, it's simply not specified. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n111IlKQ065837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 18:18:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n111Ildo065836; Sat, 31 Jan 2009 18:18:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw02.dd24.net (mailgw02.dd24.net [217.188.214.197]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n111IZ17065829 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 18:18:46 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw02.dd24.net (Postfix) with ESMTPA id 7905A3557E6 for ; Sun, 1 Feb 2009 01:18:34 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: OpenPGP In-Reply-To: <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <1233436628.4262.37.camel@fermat.scientia.net> <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-ejjO4YdNwXfBCtVKk5DF" Date: Sun, 01 Feb 2009 02:18:33 +0100 Message-Id: <1233451113.4262.84.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-ejjO4YdNwXfBCtVKk5DF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, 2009-01-31 at 16:50 -0500, David Shaw wrote: > The point I was trying to make is a little different. The RFC =20 > specifies a (RECOMMENDed) way to handle this problem, so that the =20 > extra revocations are not needed for any implementation that is =20 > compliant with that advice. Ok,.. in that case (if an implementation follows that advice, we don't have to talk, as you're right and everything is fine :-) > This method with extra revocations is an =20 > attempt to force non-compliant implementations into doing the right =20 > thing. I suspect this may be tilting at windmills. These =20 > implementations are already disregarding the RFC advice. It is =20 > difficult to use RFC advice to get a non-RFC advice following =20 > implementation to do the right thing. Ok I got your point,.. and the following is probably a little bit pedantic and quibbling. The point I was trying to make is: As this "use the most recent" is "only" a RECOMMENDS, an implementation might not follow this advice, and would be still conforming, right? As you've said, it's only an advice. We cannot do anything about really-non-conforming implementations (the ones that breaks the MUSTs and so on), so lets forget about them. But the just plain (very) stupid ones which are compliant (and thus would follow the revocations of the previous self-sigs, as Peter suggested) but don't follow that advice/recommendation would break and possibly do bad things. And this could be avoided by following Peters ideas. To conclude: Public Key 0x1F (timestamp 1) 0x30 (timestamp 2) revokes ONLY the 0x1F from timestamp 1 0x1F (timestamp 3) 0x30 (timestamp 4) revokes ONLY the 0x1F from timestamp 3 0x1F (timestamp 5) UID 0x13 (timestamp 1) 0x30 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 0x13 (timestamp 3) 0x30 (timestamp 4) revokes ONLY the 0x13 from timestamp 3 0x13 (timestamp 5) would work as I described in the example, and ONLY: 0x1F (timestamp 5) 0x13 (timestamp 5) would be usable, right? But something like: Subkey 0x18 (timestamp 1) 0x28 (timestamp 2) revokes ONLY the 0x13 from timestamp 1 0x18 (timestamp 3) doesn't work, and the subkey will still be revoked. Is this correct so far, and something we can agree on? :-) I don't want to judge whether this is really necessary for the real world, as probably most sane implementations follow the advice, to use the most recent only, and thus the sig+sig+revoc thingy will work. (Of course for all of this, a working key server infrastructure is needed) Personally I'd prefer that a future version of the RFC really enforces that advice, in order to be 100% sure, that in every conforming application, the sig1+sig2+revoc example or sig1+sig2 example works as expected. > > I think for these kind of attacks, revoking the old self-sigs wouldn't > > help anything, would it? > > Because an attacker could always strip of newer self-signatures and > > revocation signatures as he likes, and thus users and actually the =20 > > whole > > OpenPGP-PKI really _RELY_ on functional keyservers the distribute the > > complete and up-to-date version of the key. > Exactly right. Excellent :-) Good night (at least in my time zone ;) ), --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-ejjO4YdNwXfBCtVKk5DF Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDIwMTAxMTgzM1owIwYJKoZIhvcNAQkEMRYEFLRWZ/Y1ewQiocuv7jkaVmkiDe7DMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB ALLw7UbHMGwfYPZc3GdkPxDPihwu6Wx8cjRLN4x248MhQpNZPNG8V4DE+rXtvfRrwE0ROvSA6yuy lLT8nlx+Ju4Gw8xBCEQ/OyulTV0o09SeZNEwJcS/VXVBLGmksPLguxKhx9Eohk+z3zbDlWlr6hG0 HJlSdPE6k4evm864jxvetz+2QtDtUimpfOAPmd5n2TlIfimL64z2BMr4+yeP14zqU63pkP7d3yWZ bqv4VRo1POa2ByVuWXFLpSYBG4x4xzA5Sbch3muNpnS1m5gcbGkqdm0V40MR+2v7a3fL4E+oqMBg 9zIUjannVbVbzhcRTXvFqnpBy6at7kc2Nv+4a1wAAAAAAAA= --=-ejjO4YdNwXfBCtVKk5DF-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110UOrx064425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 17:30:25 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n110UOdG064424; Sat, 31 Jan 2009 17:30:24 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from underhill.hhhh.org (underhill.hhhh.org [209.221.140.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110UDtJ064417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 17:30:24 -0700 (MST) (envelope-from wiml@hhhh.org) Received: from [IPv6:2001:470:1f01:444:1000::1:1f] (bzzzt.hhhh.org [IPv6:2001:470:1f01:444:1000:0:1:1f]) by underhill.hhhh.org (Postfix) with ESMTPS id 933F52EDCBB; Sat, 31 Jan 2009 16:30:12 -0800 (PST) In-Reply-To: <1233442488.4262.56.camel@fermat.scientia.net> References: <1233442488.4262.56.camel@fermat.scientia.net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D63BE86-F20D-42B0-B445-09F3196C6278@hhhh.org> Cc: Christoph Anton Mitterer Content-Transfer-Encoding: 7bit From: Wim Lewis Subject: Re: Do we need to secure our keyservers against kind of DoS Attacks Date: Sat, 31 Jan 2009 16:30:10 -0800 To: ietf-openpgp@imc.org X-Mailer: Apple Mail (2.753.1) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: (Attention Conservation Notice: non-expert explaining why he thinks the current system is almost-good-enough without securing keyservers) This is an interesting point. After thinking about it a little, though, I think that securing the keyserver (or the communication with the keyserver) isn't quite the right approach. One of the strengths of the PGP setup, I think, is that you don't have to trust the keyserver; all it's doing is making it easier for you to get information that you can in theory get elsewhere. An end-to-end approach is better, IMHO. (It also protects against the opposite side of the equation: is Mallory secretly stripping the revocation certificate out of your friend's uploads to the keyserver? Also, I don't want to have to make trust/policy decisions based on how much I trust the people running the keyserver, how strong my trust path is to their key, and so on. That way lies X.509...) Notionally, I want some sort of periodic, signed communication from other keyholders, saying, "The official state of my key-and- subpackets is X. Expect another message before date Y". However, not all of the subpackets are really important: if I'm missing a signature from someone else, or an alternate user ID, I'm not going to trust you any *more* than if I have it. So this thing only needs to cover packets which reduce trust --- revocations, I guess. (Am I missing a scenario here?) But is this actually any different from periodically renewing a set of expiring signatures? (I don't think so, but I could easily be missing stuff.) In which case, OpenPGP already supplies everything needed to prevent this sort of denial-of-key-distribution attack. For this to work, the spec has to follow a principle: any subpacket must either (a) only increase trust, not decrease it; or (b) be more- or-less equivalent to early expiration of another subpacket. How close is OpenPGP to this? Actual implementations might get in the way, on the other hand. In the past I have tried maintaining a key with a non-expiring signature on the signing key and a rotating, expiring signature on the (sole) encryption subkey. A lot of software seemed to dislike this, and seemed to assume that if the encryption subkey had *any* expired signatures, it was invalid, even if it had a later, still-valid signature. As a UI detail, it might be nice to have a bit on an expiring signature indicating whether a renewed signature is expected, possibly in the form of an "expiration reason" field a la RFC4880-5.2.3.23. This shouldn't, I think, be acted upon by the trust- computation code, but might be useful to help decide whether to try to refresh that key. On the other hand, maybe the software should just infer this bit from the existence of previous, expired signatures in the keyring. > One possibility would be do static_cast(DNSSEC) and > implement a secured keyserver protocol. Of course I think securing the keyserver communication is *also* good, as long as the trust model doesn't depend on it. :) If nothing else, doing a keyring refresh broadcasts to a listener or MITM the contents of your keyring, which you might consider sensitive information. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110TcrB064404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 17:29:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n110TckO064403; Sat, 31 Jan 2009 17:29:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n110TPNB064395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 17:29:37 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id 053037CCCB3 for ; Sun, 1 Feb 2009 00:29:24 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: OpenPGP In-Reply-To: References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <1233435556.4262.19.camel@fermat.scientia.net> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-Y+ib95DYU5whaLgBOtzE" Date: Sun, 01 Feb 2009 01:29:24 +0100 Message-Id: <1233448164.4262.64.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-Y+ib95DYU5whaLgBOtzE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, I haven't seen that Peter has nearly asked the same... On Sat, 2009-01-31 at 16:39 -0500, David Shaw wrote: > > btw: As far as I understand this works the following way: > > - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the > > revocation signature AND with an earlier timestamp than the revocation > > signature > > BUT ONLY when calculated over the same data, which effectively means: > > * Either all the 0x1Fs from the specific key (primary or sub) > > * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID > > but NOT: > > * from all User IDs or even all 0x10-0x13s and 0x1Fs > > - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME > > creator as the revocation signature AND with an earlier timestamp than > > the revocation signature > > BUT ONLY when calculated over the same data, which effectively means: > > * Only on the specific subkey, not from the other subkeys I've seen you other mail that for subkeys this isn't possible at all, as only one 0x18 and corresponding revocation is allowed. > > - a 0x20 recovers everything and cannot be undone (with timestamp > > tricks) > > > > Is this correct? >=20 > Not exactly. A revocation revokes *one* signature. Given this: >=20 > Signature (timestamp 1) > Signature (timestamp 2) > Revocation (timestamp 3) >=20 > The end result is no signature - but the reason is not because the =20 > revocation has revoked both signatures. The reason is because the =20 > signature at timestamp 2 has replaced the signature at timestamp 1, =20 > leaving this: >=20 > Signature (timestamp 2) > Revocation (timestamp 3) >=20 > And then the revocation revokes the one remaining signature. OK I'm a little bit confused on how this works when an implementation doesn't follow the recommendation to use the most recent self-sig, because then it would matter whether "Revocation (timestamp 3)" applies to "Signature (timestamp 1)" or "Signature (timestamp 2)". But I've seen that Peter has asked nearly the same before (this time I've got his mail in time ;) ) and so I watch there for an answer. But on more thing: What I wrote above, with the "classes" and that it applies only to the specific UID,.. this is actually true, right? Greets, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-Y+ib95DYU5whaLgBOtzE Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDIwMTAwMjkyNFowIwYJKoZIhvcNAQkEMRYEFE8Ix7ofjb4aNWxThu3dN/COqM9IMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB ANSDJRlkm1Tm65LdwPlPbE/7ME+OJUNaVFWMNj2rbxec7jhMcd7Xxy4GIWAQrjqYgx5i503PjacL /zz/blLoPTlDQPi+38+vmliorNeXqTQm4lxMPC3G4L/9S2HGEw8CHoW30ZuahV+X1pi40PL1afWj AqBlW/vV40xk9A6bgBCTh0dH+BEQMXkG3mT/pRXhLYT+W7I0Vq2gbgp247hJIU4nXtiHwgy9lRSH iDMWywhRkmHfBHoJe+XE+wdiQygP//XPrMAntixy63kK/57ukPxzjhH77Znoscl1JzPbyiNvEQ6t yl76PagYmRe100WUuK8CzrHnew72EfmI8nwUQxgAAAAAAAA= --=-Y+ib95DYU5whaLgBOtzE-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VNfYMO063322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 16:41:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VNfYax063321; Sat, 31 Jan 2009 16:41:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VNfLZs063298 for ; Sat, 31 Jan 2009 16:41:33 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so898014fxm.10 for ; Sat, 31 Jan 2009 15:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=hAKtxLZ2phdRDRhI5EwQlDEjiqfy7mtmOy4siLtwENI=; b=wJeG4W9PWbS9Qh7f/1kgos/EE+fsC6TRoJAJxSmKrNeExMKTu1Wyj9Pg+fm87XvfQH nZfdvo8X1wXaBG21urdElZB876WUhk5htBmGhewdOlEWfYoWZhxMRiEcPBAUWnXhMwGM q6pYijiBNOOQLPF/NFhLKlJ/HeqpJzLUr8290= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=fAhzMyb7a9mFp/kIgiyCddYgENuzwc5YFuTax20Q4MMjob8bvROmgXRCN4HoP4w2Ff U2TVzOhzpUptOKC8MCpGE6FdTLjoGqufwiV0B9UCzqFjT0j8SN71QfiexGY4QfPEEYWe v/qmPbpJTHKdciNGb9+BKbEHz+TQ6GpWVsmcE= MIME-Version: 1.0 Received: by 10.181.226.5 with SMTP id d5mr1028754bkr.116.1233445280765; Sat, 31 Jan 2009 15:41:20 -0800 (PST) In-Reply-To: <20090131034840.GA21364@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> <20090131034840.GA21364@jabberwocky.com> Date: Sun, 1 Feb 2009 00:41:20 +0100 Message-ID: <9ef756150901311541v7d656e9crb8cfd34faecffc1e@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2009 at 4:48 AM, David Shaw wrote: >> a) when I use a 0x20 key revocation signature: >> Am I correct that the explanation on page 21 says: A key having a >> revocation signature is completely invalid including all it's UIDs, >> subkeys, etc. and this cannot be undone in any way? > Yes. However note that you can un-revoke a key by removing the > revocation signature. That's very difficult to do in practice > (keyservers would have the revoked copy). Of course,... >> b) when I use a 0x28 key revocation signature: >> Does this (according to the RFC) make the subkey forever unusable, as >> above with the 0x20s? >> Or would issuing a subkey binding signature more recent than the 0x28 >> bring it (the subkey) back? > That's a good question. The RFC specifies that a subkey may have one > (and only one) binding signature, and zero or one revocations. Wow,.. uhm could you please point me to the location that mandates this? > Thus you cannot resign a subkey to un-revoke it. Uhm what do you mean with this? > I don't recall if that is > the reason the key grammar enforces exactly one binding signature, but > it would seem to follow naturally from that grammar. Ok,.. uhm let me think. This would also mean, that it's not possible to later change the properties of a subkey (e.g. preferred algorithms or it's key flags) while all this IS possible for the primary key and for UIDs, right? > Of course, you could strip off both the binding sig and revocation sig > and just make a new signature, but then you're back in the > distribution problem I mentioned earlier with un-revoking whole keys. Yeah,.. the keyservers would prevent this. > Part of the design of OpenPGP is that subkeys are cheap - you should > be able to make new ones easily. That's true, of course. But it could be annoying if people expect particular (sub)key ids, as they're used to it (e.g. when using a subkey for a special role like "work" or "home"). > In fact, there was a proposal for > perfect forward security in OpenPGP a few years ago that involved > generating new subkeys very frequently (even to the point of a new subkey per message) Wouldn't this actually create new security problems? I'm by no means a crypto-expert, but AFAIK the more one uses a key to sign/encrypt data, the more it is likely that someone can use all this data for statistical attacks. And this would be especially bad for the primary key, as far as I understand? >> c) when I use a 0x30 certification revocation signautre. >> Here the whole thing is different to a) and b) (as far as I understand). >> The RFC says "This signature revokes an EARLIER User ID certification >> signature..." >> Does this now exactly mean,.. that it revokes ALL earlier user id >> certification signatures? > Not exactly - it revokes one signature. However if there is more than > one signature, the earlier signature should be superseded by the later > one. I must apologize myself,.. but I don't understand this. The RFC must somehow specify which of the earlier self-signatures is revoked by it, or not? Or does it always revoke the MOST RECENT found signature BEFORE its own timestamp? If so where is this specified (I'm just curious, not that I wouldn't believe you ;-) )? And if that's the case we must remember that an implementation is allowed to use any self-signature, it's just RECOMMENDED to use the most recent. This would mean the following: Public Key User ID 0x13 timestamp 1 0x13 timestamp 2 0x30 revokes the 0x13 from timestamp 2 or: Public Key User ID 0x13 timestamp 1 0x30 still revokes the 0x13 from timestamp 2 0x13 timestamp 2 but now it's effectively as if we'd just have: Public Key User ID 0x13 timestamp 1 (isn't this what gnupg does when doing a minimize? removing all unusable signatures?) And even if not actually removed, an implementation would now be allowed (as far as I understand the RFC) to use the 0x13 from timestamp 1? Ok gnupg doesn't do this like this, as you explained in that (sig+sig+revoc) example before, but other could. I think I become mad ^^ > This will work in GPG, but I don't think it is necessary - Sorry when I'm nasty, but just think of the example directly above this text? Or the other examples I gave (with the older self-signature using MD5 and the new SHAsomething, or other differing subpackets). Of course probably any reasonable implementation will follow the recommendation and just use the most recent self-sig like gnupg does (sig+sig+revoc), but others might not. What's the opinion on the others on this? > the same thing would happen even if you removed the revocations Ok but for this we have the keyservers... (thank god) ^^ > (Note, > though, that you can't have a 0x1F on a UID. 0x1F is a direct key > signature and is not issued on a UID). Oopps,.. of course,.. that was a typo ;-) Thanks again in advance, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VMtHTI061777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 15:55:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VMtHOI061776; Sat, 31 Jan 2009 15:55:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VMtEJH061754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 15:55:16 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id 75A357CCCB3 for ; Sat, 31 Jan 2009 22:54:49 +0000 (GMT) Subject: Do we need to secure our keyservers against kind of DoS Attacks From: Christoph Anton Mitterer To: ietf-openpgp@imc.org Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-fI4cA5PVR5NpFuKeqTKZ" Date: Sat, 31 Jan 2009 23:54:48 +0100 Message-Id: <1233442488.4262.56.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-fI4cA5PVR5NpFuKeqTKZ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. I having the following issue on my OpenPGP "TODO" list for some very long time now, and David just remembered me on it. On Fri, 2009-01-30 at 22:48 -0500, David Shaw wrote:=20 > Yes. However note that you can un-revoke a key by removing the > revocation signature. That's very difficult to do in practice > (keyservers would have the revoked copy). Keyservers are very critical for any PKI to work, aren't they? I mean there are plenty of "attacks" which would be possible without them: - we couldn't get revocations - we prone to attacks where someone simply removes some subpackets (e.g. a revocation signature, or a newer and updated self-signature) - there might be even more cases I can't think of Of course our keyservers work quite well, I can to some "upgrade my keyring" command and get the new keys and all added packets. And the big advantage is that no one can remove anything from them (it's even difficult for the admins, though probably not impossible). But there is the possibility of a kind of a DoS-Attack; service in the sense of "deliver the whole key and everything belonging to it to the requester". Imagine that my ISP is evil, tracks my connections and always removes some revocation signatures when I get the data. Are there currently working means to prevent this? One possibility would be do static_cast(DNSSEC) and implement a secured keyserver protocol. Of course we should use OpenPGP for this :-) A keyring could always sign the data he sends to a user, and the user could have the public key from that keyserver set up somewhere in his implementation as valid for acting as keyserver. Of course one could build trust-paths to the keyserver's public keys, et cetera, et cetera. Now the ISP could only block the whole keyserver, but at least I'd notice it and an implementation could WARN me if for example regularly updates of the keyrings don't work. Just an idea,... :-) Regards, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-fI4cA5PVR5NpFuKeqTKZ Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTIyNTQ0OFowIwYJKoZIhvcNAQkEMRYEFJlO1wHCrBfw7LDGGGbznH6ZtxOjMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB ANkqHlGiSDPOzI5DPS6SlFTkI0XeI9JIJkIirfcET8DpWiVyA9Y9AwenH2d0ttAnp8g2oQCQLd7f MMRVHRHA5EtSyh50WJow0o80JBwAcBPmG95Kswy2RsjyhRVoAickkXvuhUmTbAbRdJeZAZQyUXWz lD4VIMcq/vpPJOJTo6vl3A3i68b9smVJnn4nUF19qgIlesDO62WS/ksH4zCmFnK6cprEWeuzzI88 EmNGlxRlB4oBOJ0y0+b51Tug092Wksox7r0Hx2VKLuKp1lJGWVVOvvaxLAv51y+K6RBuuBPbAjx6 w31OYGwnmn+QvoNxvJp1PAcxmYQjdUoHVvptnvAAAAAAAAA= --=-fI4cA5PVR5NpFuKeqTKZ-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLo2Yg059723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:50:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLo2Lx059721; Sat, 31 Jan 2009 14:50:02 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLo0g4059715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:50:01 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n0VLo0qu004084 for ; Sat, 31 Jan 2009 16:50:00 -0500 Message-Id: <08B1FCB2-C206-4FF7-A802-BDD6386E79EA@jabberwocky.com> From: David Shaw To: OpenPGP In-Reply-To: <1233436628.4262.37.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 16:50:00 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <1233436628.4262.37.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 4:17 PM, Christoph Anton Mitterer wrote: > On Thu, 2009-01-29 at 15:53 -0500, David Shaw wrote: >> I suspect it wouldn't hurt, but wouldn't help much either. > Why not? It would solve the problem! Or am I wrong? > >> For >> example, given this: >> >> Signature === January 1 >> Signature === January 3 >> Signature === January 5 >> >> it is clear that the January 5 signature is the latest and the one to >> use. Given this: >> >> Signature === January 1 >> Revocation === January 2 >> Signature === January 3 >> Revocation === January 4 >> Signature === January 5 >> >> It's still clear which signature is the right one. >> >> I suppose if you had an implementation that insisted on using the >> first signature, regardless of the date, then the revocations would >> force it to look at the last signature.. > Yes and this is the point here, isn't it?! ;) > > >> It may conclude >> that there is no signature at all (after all, the one signature it >> was >> looking at is revoked). > Well and I think that's what Peter actually wants. And that's what I'd > suggest, too. The point I was trying to make is a little different. The RFC specifies a (RECOMMENDed) way to handle this problem, so that the extra revocations are not needed for any implementation that is compliant with that advice. This method with extra revocations is an attempt to force non-compliant implementations into doing the right thing. I suspect this may be tilting at windmills. These implementations are already disregarding the RFC advice. It is difficult to use RFC advice to get a non-RFC advice following implementation to do the right thing. In other words, why should they follow the RFC with regards to these extra revocations? They're already disregarding the RFC advice with regards to signature selection. Applications that follow the RFC advice don't need the extra revocations. Applications that don't follow the RFC advice anyway can't be expected to follow a new piece of advice. > I tried to think a little bit about the whole issue with revoking > previous self-sigs. I'm not sure so pleas help me with the following: > One dangerous type of attack in cryptosystems are downgrade attacks. > I build some examples in order to find out whether an attacker could > do > downgrade attacks on self-sigs (e.g. with different hash algorithms > and > other different and security critical subpackets) and if this would be > prevented by _generally_ revoking old self-sigs that were replaced by > new ones. > > I think for these kind of attacks, revoking the old self-sigs wouldn't > help anything, would it? > Because an attacker could always strip of newer self-signatures and > revocation signatures as he likes, and thus users and actually the > whole > OpenPGP-PKI really _RELY_ on functional keyservers the distribute the > complete and up-to-date version of the key. Exactly right. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLdaK7059496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:39:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLdaxf059495; Sat, 31 Jan 2009 14:39:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLdPCq059486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:39:36 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n0VLdObx004044 for ; Sat, 31 Jan 2009 16:39:24 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <1233435556.4262.19.camel@fermat.scientia.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Sat, 31 Jan 2009 16:39:24 -0500 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <1233435556.4262.19.camel@fermat.scientia.net> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 31, 2009, at 3:59 PM, Christoph Anton Mitterer wrote: > Hi. > > > On Fri, 2009-01-30 at 14:59 -0500, David Shaw wrote: >> Which signature is being revoked? Without a signature target, it's >> not clear. > In a future revision of the RFC I'd suggest to add a "implementations > SHOULD use signature targets when revoking one or more signatures". > > But the current way should still be allowed. I'd even clarify that it > works like this in the text. > > btw: As far as I understand this works the following way: > - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the > revocation signature AND with an earlier timestamp than the revocation > signature > BUT ONLY when calculated over the same data, which effectively means: > * Either all the 0x1Fs from the specific key (primary or sub) > * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID > but NOT: > * from all User IDs or even all 0x10-0x13s and 0x1Fs > > - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME > creator as the revocation signature AND with an earlier timestamp than > the revocation signature > BUT ONLY when calculated over the same data, which effectively means: > * Only on the specific subkey, not from the other subkeys > > - a 0x20 recovers everything and cannot be undone (with timestamp > tricks) > > Is this correct? Not exactly. A revocation revokes *one* signature. Given this: Signature (timestamp 1) Signature (timestamp 2) Revocation (timestamp 3) The end result is no signature - but the reason is not because the revocation has revoked both signatures. The reason is because the signature at timestamp 2 has replaced the signature at timestamp 1, leaving this: Signature (timestamp 2) Revocation (timestamp 3) And then the revocation revokes the one remaining signature. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLHCbc058676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:17:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VLHC2q058675; Sat, 31 Jan 2009 14:17:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VLHAg3058669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:17:11 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id CEB317CC364 for ; Sat, 31 Jan 2009 21:17:09 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: ietf-openpgp@imc.org In-Reply-To: <20090129205321.GB16331@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-x5emVcJYmKLf9v7gskHU" Date: Sat, 31 Jan 2009 22:17:08 +0100 Message-Id: <1233436628.4262.37.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-x5emVcJYmKLf9v7gskHU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2009-01-29 at 15:53 -0500, David Shaw wrote: > I suspect it wouldn't hurt, but wouldn't help much either. Why not? It would solve the problem! Or am I wrong? > For > example, given this: >=20 > Signature =3D=3D=3D January 1 > Signature =3D=3D=3D January 3 > Signature =3D=3D=3D January 5 >=20 > it is clear that the January 5 signature is the latest and the one to > use. Given this: >=20 > Signature =3D=3D=3D January 1 > Revocation =3D=3D=3D January 2 > Signature =3D=3D=3D January 3 > Revocation =3D=3D=3D January 4 > Signature =3D=3D=3D January 5 >=20 > It's still clear which signature is the right one. >=20 > I suppose if you had an implementation that insisted on using the > first signature, regardless of the date, then the revocations would > force it to look at the last signature.. Yes and this is the point here, isn't it?! ;) > It may conclude > that there is no signature at all (after all, the one signature it was > looking at is revoked). Well and I think that's what Peter actually wants. And that's what I'd suggest, too. Better to fail at all than using something probably evil, just like you at gnupg decided with the critical bit at the signature expiration time. I tried to think a little bit about the whole issue with revoking previous self-sigs. I'm not sure so pleas help me with the following: One dangerous type of attack in cryptosystems are downgrade attacks. I build some examples in order to find out whether an attacker could do downgrade attacks on self-sigs (e.g. with different hash algorithms and other different and security critical subpackets) and if this would be prevented by _generally_ revoking old self-sigs that were replaced by new ones. I think for these kind of attacks, revoking the old self-sigs wouldn't help anything, would it? Because an attacker could always strip of newer self-signatures and revocation signatures as he likes, and thus users and actually the whole OpenPGP-PKI really _RELY_ on functional keyservers the distribute the complete and up-to-date version of the key. Or do you see anything that I've missed? Anyway, as long as the RFC allows implementations the choose which self-signature they use (and "just" RECOMMEND to use the most recent), I'd vote to suggest to use that revocation trick. At least if it would work at all ^^ Have we already found a definite answer here? Best wishes, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-x5emVcJYmKLf9v7gskHU Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTIxMTcwOFowIwYJKoZIhvcNAQkEMRYEFEDZC4dMZSDvRhqOOjTqgKB++UkeMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB AKXr/qLJk4lBtSjrIKWl1gWE20/TxQGF833o7VjCPBOydbQ+dUqUMPqNy6fTpA9MqdelIr4xOFoK +9HaafugBuhTMvTwksn9haVhPUIgX6iyBMz2xSD8/v32lVCq3VEYYNpY8bHukoonPMDyWSS9f4Ex 2lVGWaO9XDqOGh/HfDWkMXid5tekD9ipf76Chc+Scafl+pDjVAMWw7fY4JtFxkKa7Y1APSc9zPcD YD9O58yIN2w6jR4Ngc1QD/i0Mq2tVkswtiHBSdomxXYJ3mJ7Il9rgRR5M4cFN7DiwenhwUC0IgeI q4z91gkiA6SEiNU39tzk5OVmHclrRiXTZV81dNgAAAAAAAA= --=-x5emVcJYmKLf9v7gskHU-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VL0Jr8057953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 14:00:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VL0JKR057952; Sat, 31 Jan 2009 14:00:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VL0606057937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 31 Jan 2009 14:00:18 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-93-104-104-7.dynamic.mnet-online.de [93.104.104.7]) by mailgw01.dd24.net (Postfix) with ESMTPA id BF9DC7CCC8B for ; Sat, 31 Jan 2009 20:59:16 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: ietf-openpgp@imc.org In-Reply-To: <20090130195917.GC19809@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-Gx8EiQTEsNPhwrfamHlI" Date: Sat, 31 Jan 2009 21:59:15 +0100 Message-Id: <1233435556.4262.19.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-Gx8EiQTEsNPhwrfamHlI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. On Fri, 2009-01-30 at 14:59 -0500, David Shaw wrote: > Which signature is being revoked? Without a signature target, it's > not clear. In a future revision of the RFC I'd suggest to add a "implementations SHOULD use signature targets when revoking one or more signatures". But the current way should still be allowed. I'd even clarify that it works like this in the text. btw: As far as I understand this works the following way: - a 0x30 revokes ALL 0x10-0x13s and 0x1Fs with the SAME creator as the revocation signature AND with an earlier timestamp than the revocation signature BUT ONLY when calculated over the same data, which effectively means: * Either all the 0x1Fs from the specific key (primary or sub) * Or ALL 0x10,0x11,0x12,0x13s from the specific User ID but NOT: * from all User IDs or even all 0x10-0x13s and 0x1Fs - a 0x28 revokes ALL 0x18s (and thus the embedded 0x19s) with the SAME creator as the revocation signature AND with an earlier timestamp than the revocation signature BUT ONLY when calculated over the same data, which effectively means: * Only on the specific subkey, not from the other subkeys - a 0x20 recovers everything and cannot be undone (with timestamp tricks) Is this correct? Do these timestamp tricks work with subkeys and 0x28 revocation signatures (and 0x18 subkey binding signatures)? The RFC doesn't say anything whether the 0x28 should only affect signatures BEFORE its own timestamp. > Note that using the example above (sig+sig+revoke), this would result > in there being effectively no signature. That is intentional, not a > bug: the second signature superseded the first signature, and then the > revocation revoked the second. End result: no signature. This is in my opinion the "best" and probably "only" way it should be handled. Peter's idea that only the most recent valid signature per class (where 0x10-0x13 is one class, 0x1F is one, and 0x18 is one) MUST be used by an implementation has a very little problem: What if the most recent is revoked? This would mean, that the earlier signature is used which is possibly bad. So I'd suggest the way of gnupg (and perhaps other implementations?) to be mandatory in a future RFC: Let me copy it from David: > the second signature superseded the first signature, and then the > revocation revoked the second. End result: no signature Regards, --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-Gx8EiQTEsNPhwrfamHlI Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTIwNTkxM1owIwYJKoZIhvcNAQkEMRYEFM/q4yCdSvS9OcYrz9ST7Bur4F9uMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB AHrMvWK+1rqU/zXrcrsnnz4ceWLSn8JOEh0pyNQTK4g8oDNw+Ovs4kdbUpDCkVE1xvNrNwBMdJ1W 8WhrhDUxPga4r4VuC2J0TvjlR38mIDleZDE/Q14devc4XT/dkbHz/MNQxSOY/CtpFHgnNqCFFaZF 4oE4uGM3ldvtiaYPTRRMsOLORY1TgoGZBTyebPvdY0vjDNMilclVRpJFxZL+msBAMcg+mReEGdsm 69Zxsyv1qe2qw2ufrPspa3C2SEM/1A4/xmB7UgcKGmjExfBF1TCApTvZLBzkSoDEoPrUWZj2qVZS aQ4U84FH91pY2gqr3RjTdXe72HVDa9P4I+/4XKQAAAAAAAA= --=-Gx8EiQTEsNPhwrfamHlI-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0VGP0fL048354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Jan 2009 09:25:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0VGP0BL048353; Sat, 31 Jan 2009 09:25:00 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0VGOm90048343 for ; Sat, 31 Jan 2009 09:24:59 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 50444 invoked from network); 31 Jan 2009 16:24:47 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay00.pair.com with SMTP; 31 Jan 2009 16:24:47 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49847BF1.90306@fifthhorseman.net> Date: Sat, 31 Jan 2009 11:27:29 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Jon Callas CC: IETF OpenPGP Working Group Subject: Re: Ideas on new user attribute types and image formats References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> <49833C0E.8010605@fifthhorseman.net> <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> In-Reply-To: <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5D1905824B75BAAC23BDF3CE" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5D1905824B75BAAC23BDF3CE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 07:54 PM, Jon Callas wrote: > I'll add in that I think adding PNG is fine with me, and that's why =20 > I'll also be devil's advocate. So what? >=20 > I think that "because it would be cool" is a fine answer. We should =20 > say it, if that's why. Good point! FWIW, i actually have a couple specific implementation possibilities in mind, because i'm interested in seeing an expansion of places where OpenPGP is used [0]. The following ideas don't have anything close to a concrete implementation yet, but transparent PNGs would make them even more aesthetically appealing. * instant messaging: OTR [1] is a platform-agnostic IM encryption/authentication layer, which currently uses RSA keys for mutual authentication. I'd love to see OTR be able to use the OpenPGP web of trust to handle the actual authentication (though it currently does not). If it did, then PNG User Attribute support would allow graphical OTR-compliant IM implementations to automatically select hackergotchi-style images for pretty IM conversation displays (think "word-balloon" style). * I'd like to see better cryptographic verification tools that take advantage of OpenPGP's WoT to display human-comprehensible descriptions of relevant trust paths to an attempted validation. Since most people use graphical environments, and most people recognize people by their faces even more quickly than by their names, it would be great to show such trust paths with images in them (e.g. "Mary says that this is Joe" is useful, but a picture of Mary saying "this is Joe" would be even more appealing to many users). Plus, it would be cool ;) These are just some ideas to chew on. i wish i had more time to work on such craziness. --dkg [0] http://web.monkeysphere.info/ is the furthest advanced implementation of any push to extend the reach of the OpenPGP web-of-trust that i'm involved in. [1] http://www.cypherpunks.ca/otr/ --------------enig5D1905824B75BAAC23BDF3CE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYR79szS7ZTSFznpAQK21Q//czc1oydZBnW/D7fQT3jNHmRgOaZqqmAn jdUHbwuM0q/mpL+N6k5oP9McUMAOg954ik3aFe9zXCGTBy58w9TiPtesO/XXYarC juClNNO3/Jc1l2jzztn7RL7aKYvA7vjyrDr04wabdGna0jTsoGw9qkErZA5fjLOx PqJxXHDYRhBCsgX6IClg8mrFz/HZiOX9j2NUeotrkljluEaggalC+/9bCDCTIA/4 Lm8DmAUn2Mm6LLbaXCHcX0iIN+lrdOhcMtYO7l9e2SlDOnNmicZxo8rYHheU6WB6 aeGy9FTjFN8iFxhVMvwPTf0SzBSX1wnPNL95v/1WuqXXdPSiaU68wM95y8PXFPpm lCO86irMLiKyNkd/p51IiKDihKka2cN0aSHMwLqeUaTi4VIDxO1nYu0q01cpcd5D L+OkLQWWs22mRvDTteav6GaFyzSKG9Ck3uFz8WY5oeXML3pnTCAolxJLu3lTEszv McY5ecNbU5QJrPbGoZZMO/KBuW+IwvyI+VZFlaaztijbUuHqAlITNt9YsNjLXRYV xTcZJj49aGrMszmCJr9+6V35nIEB0YrPYMDVcRZmQcIkqCBHcQk721eNdeXDmoWH PQS0bUqu4NZjC+n58binF5+tQW5hnQWe/N75gZZO6Wc3eHrhJlqe3ACstbjDai9n 8NRC/eYk5CQ= =dNqV -----END PGP SIGNATURE----- --------------enig5D1905824B75BAAC23BDF3CE-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V446qN019449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 21:04:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V446rC019448; Fri, 30 Jan 2009 21:04:06 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V444ZV019438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 21:04:05 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from [172.24.84.28] (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n0V444VB013376 for ; Fri, 30 Jan 2009 23:04:04 -0500 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 6 Date: Fri, 30 Jan 2009 23:04:04 -0500 References: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Jan 30, 2009, at 5:14 PM, Peter Thomas wrote: (skipping the ones Jon answered) > I tried to create the following example and wonder whether my > interpretation is always correct: > Given is a public key, with several User IDs signed with 0x13s, a > direct key signature 0x1F and several subkeys signed with an 0x18: > (look closely as there are minor differences between the stuff > below ;-) ) > > I) Subpackets on the 0x1F direct key signature (there should be only > one of it): > - signature creation/expiration time > In principle it has only a meaning for the 0x1F itself, but it might > also expire the key as described int I) 1 and I) 2 above. > > - key expiration time > The expiration time of the WHOLE key with all UIDs, subkeys, etc. > An implementation MAY decide when to use the key expiration from the > 0x1F. Reasonable ways would be: > * when no other self-sig specify one (thus it works globally for the > key) > * when the key was found/selected by the KeyID (this is > questionable, isn't it?) > * or it may even take priority in favor of all other key expiration > times on other signatures, like 0x13's (but not 0x18s because subkeys > have their own expiration time!!!!) Use the shortest expiration time. If the 0x1F says you have 10 days, and the 0x13 says you have 5 days, you have 5 days. As you note, the subkeys have their own expiration time - but not if they exceed the whole key expiration time. You can't have a subkey that lives beyond its primary key. > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's If you have preferred algorithms in both the 0x1F and a 0x13, then you use the one with the narrowest scope. So, if the key was chosen by a particular user ID, you use the preferred algorithms from that user ID's selfsig. If that selfsig does not have preferred algorithms, use the one in the 0x1F. If the key was chosen by key ID (so there is no one particular user ID) you use the preferred algorithm from the primary user ID. As before, if there is no preferred algorithm there, use the one from the 0x1F. If there is preferred algorithms on a 0x18, I think I'd take the union of those algorithms with the ones from the user ID or 0x1F. > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's > > > II) Subpackets on any of the 0x10-0x13 certification signatures: > - signature creation/expiration time > In principle it has only a meaning for the 0x10-0x13 itself, but it > might also expire the specific User ID (if there is no other valid > self-signature on it). > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x10-0x13. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (here I > think this is NOT questionable as above), or it was specified as > Signers User ID subpacket > > > III) Subpackets on the 0x18 subkey binding signature: > - signature creation/expiration time > In principle it has only a meaning for the 0x18 itself, but it might > also expire the specific subkey (if there is no other valid > self-signature on it). > > - key expiration time > The expiration time ONLY of the specific subkey, not of any other > subkey, any User ID or even the whole primary key. > This only applies to the specifix subkey, so an implementation cannot > choose anything (as with the key expiration times above) > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > Is this all correct / ok / within the borders of the CURRENT rfc? > > Ok that was a lot ^^ > > > Lots of thanks in advance, > Peter > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V3mqfK018981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 20:48:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V3mqHQ018980; Fri, 30 Jan 2009 20:48:52 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V3me6Y018971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 20:48:51 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0V3mecY013269 for ; Fri, 30 Jan 2009 22:48:40 -0500 Date: Fri, 30 Jan 2009 22:48:40 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090131034840.GA21364@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2009 at 01:04:33AM +0100, Peter Thomas wrote: > > On Fri, Jan 30, 2009 at 8:59 PM, David Shaw wrote: > >> Uhm? Why this? I'd thought it would only revoke the specifically > >> revoked signature, as "the signature is computed over the same data as > >> the certificate that it revokes". > >> Am I missing something? > > > > Take this example: > > > > User ID > > 0x10 signature on that user ID (timestamp 1) > > 0x10 signature on that user ID (timestamp 2) > > 0x30 revocation (timestamp 3) > > > > Which signature is being revoked? Without a signature target, it's > > not clear. > Ahhhh.... > First of all,.. the different types of revocation signatures are NOT > calculated of the signature they revoke, but the data the signature to > be revoked was calculated over, right? Right. > But the following is still unclear: > a) when I use a 0x20 key revocation signature: > Am I correct that the explanation on page 21 says: A key having a > revocation signature is completely invalid including all it's UIDs, > subkeys, etc. and this cannot be undone in any way? Yes. However note that you can un-revoke a key by removing the revocation signature. That's very difficult to do in practice (keyservers would have the revoked copy). > (Of course the subkeys could still be used attached to another primary.) Right. > I mean the following doesn't work, right? > Primary key > |->UID > |--->0x13 on that UID > |->Subkey > |--->0x18 on that subkey > > now I add a: > |-> 0x20 key revocation at 12:00 making the key unusable (forever?) > > at 13:00 I add new UID's/0x13s/Subkeys/0x18s > |->UID2 > |--->0x13 on that UID2 > |->Subkey2 > |--->0x18 on that subkey2 > > But the whole thing would still be revoked, right? Right. > b) when I use a 0x28 key revocation signature: > Does this (according to the RFC) make the subkey forever unusable, as > above with the 0x20s? > Or would issuing a subkey binding signature more recent than the 0x28 > bring it (the subkey) back? That's a good question. The RFC specifies that a subkey may have one (and only one) binding signature, and zero or one revocations. Thus you cannot resign a subkey to un-revoke it. I don't recall if that is the reason the key grammar enforces exactly one binding signature, but it would seem to follow naturally from that grammar. Of course, you could strip off both the binding sig and revocation sig and just make a new signature, but then you're back in the distribution problem I mentioned earlier with un-revoking whole keys. Part of the design of OpenPGP is that subkeys are cheap - you should be able to make new ones easily. In fact, there was a proposal for perfect forward security in OpenPGP a few years ago that involved generating new subkeys very frequently (even to the point of a new subkey per message): http://www.apache-ssl.org/openpgp-pfs.txt > c) when I use a 0x30 certification revocation signautre. > Here the whole thing is different to a) and b) (as far as I understand). > The RFC says "This signature revokes an EARLIER User ID certification > signature..." > Does this now exactly mean,.. that it revokes ALL earlier user id > certification signatures? Not exactly - it revokes one signature. However if there is more than one signature, the earlier signature should be superseded by the later one. > And what does this now mean for my idea on how to force an > implementation to use only the most recent signatures? > Will the following work, as long as the signature creation times are > correct? And I mean would it be correct even when strictly following > the RFC? > > Public Key > UID1 > 0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below) > UID2 > 0x13 signature on that user ID (timestamp 1) > 0x13 signature on that user ID (timestamp 2) > 0x30 revocation (timestamp 3) (revokes every > 0x10,0x11,0x12,0x13,0x1F on UID2 BUT NOT on UID1 BEFORE > timestamp 3 > 0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above) This will work in GPG, but I don't think it is necessary - the same thing would happen even if you removed the revocations (Note, though, that you can't have a 0x1F on a UID. 0x1F is a direct key signature and is not issued on a UID). David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V1ac9f014848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 18:36:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V1acrV014847; Fri, 30 Jan 2009 18:36:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgw01.dd24.net (mailgw01.dd24.net [217.188.214.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V1aPS0014839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 18:36:37 -0700 (MST) (envelope-from calestyo@scientia.net) Received: from [192.168.0.101] (ppp-62-216-219-24.dynamic.mnet-online.de [62.216.219.24]) by mailgw01.dd24.net (Postfix) with ESMTPA id B60367CC5BE; Sat, 31 Jan 2009 01:36:24 +0000 (GMT) Subject: Re: Series of minor questions about OpenPGP 4 From: Christoph Anton Mitterer To: Peter Thomas Cc: OpenPGP In-Reply-To: <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> Content-Type: multipart/signed; micalg=sha1; protocol="application/x-pkcs7-signature"; boundary="=-a2zdl3WhkIRphpiliK9b" Date: Sat, 31 Jan 2009 02:36:23 +0100 Message-Id: <1233365783.16857.17.camel@fermat.scientia.net> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-a2zdl3WhkIRphpiliK9b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello WG and Peter. I'm constantly following what's happening here on the WG's list and also gnupg's lists, well at least more or less. I've already read most of your threads and I wonder whether you can read my minds or so ;) ... well we seem to have at least many common ideas. I'm especially happy with your suggestions in "improving" the usage of User Attributes =3D) On Fri, 2009-01-30 at 19:05 +0100, Peter Thomas wrote: > I don't believe I'm technically skilled enough for doing this. We'll I wouldn't consider myself to be skilled enough, too. At least I haven't looked into to the process of writing ID's yet. But I'd have a strong interest in doing so :-) of course only if the WG supports this. > And I > must admit that I've borrowed some (of course not all) ideas here from > some threads I've found on the gnupg mailing lists. I should sue you, what?! ;-P > I've already > contacted the author (Christoph Mitterer) of that threads and I hope > he'll have a look at the currently ongoing discussion. See above. I'm currently on some official trip (I miss it being a student ;) ) but when I'm back I could put together a list with the ideas the were discussed here. Of course everybody may add topics. Afterwards the WG could discuss which points would find broad support in a future RFC, wouldn't break backward-compatibility too much (or even better not at all), et cetera. I think it's much easier to split things up a little bit and discuss each point on its own, than writing a new draft-RFC that contains all the ideas presented here. Especially because probably not everything will find support ;) In the meantime: Happy discussing =3D) --=20 Christoph Anton Mitterer Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen christoph.anton.mitterer@physik.uni-muenchen.de mail@christoph.anton.mitterer.name --=-a2zdl3WhkIRphpiliK9b Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ/DCCBXQw ggNcoAMCAQICAjh/MA0GCSqGSIb3DQEBBQUAMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYD VQQLExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3Qw HhcNMDcxMDI0MTkyNzQxWhcNMDkxMDIzMTkyNzQxWjB8MSEwHwYDVQQDExhDaHJpc3RvcGggQW50 b24gTWl0dGVyZXIxJDAiBgkqhkiG9w0BCQEWFWNhbGVzdHlvQHNjaWVudGlhLm5ldDExMC8GCSqG SIb3DQEJARYibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPgLlUBy3NRbH25w8pOnhF+qtj4GN04aG7ur+JsXTcEkFNOZWZ5I al2PaQWP7GfEEp5lL0w/LdYXPfnLNohp4l/Nb+db8aHUeVBYgGBTPGF+mJHfJGeochfvZo78u6Bp KkCrDAw2BKN1JNxw+OxmWuunCmXSFM9gqRfBnfmc25P6ba9tQlDXGLKZA8/JKXLMKcTTS7dIkroE bM5FTSaAmGWkvwnD6fpxjFgWNLXjagNqlQD6+q+a//+gXNOGP34aZ3qPnLPR/gUi/yqrQuAVvGep GAhl4B1Kn+c7eROoodq33Ghomoznh8hogBkDJXp+Xq4k8measwtN99ZUdMaFeJsCAwEAAaOCASYw ggEiMAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZp Y2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMEAGA1UdJQQ5 MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYBBAGCNwoDAwYJYIZIAYb4QgQB MDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzBEBgNV HREEPTA7gRVjYWxlc3R5b0BzY2llbnRpYS5uZXSBIm1haWxAY2hyaXN0b3BoLmFudG9uLm1pdHRl cmVyLm5hbWUwDQYJKoZIhvcNAQEFBQADggIBAKZI/PvI6ynlgITrRTU7WaFlllAtkWCC6MGKEE16 hUebNwK/ccjUquHLfDg2LYbp/WHx3zZQxkj7CarzMUqnoDTnJMbKovDOdZ3vqbs6p6fKuRUjTkaE cN/0ZDllc4Bewa5ZUfdD2Ml3ObxF2oK7wmTw4tQCSKZlPcq+ML5hV3Exag2fBcGzeR+G/QUWKcmY laOpRj8Vu8ZMXpzSD8T+Tp2nKP+iqa2lv+UCI6cSXJ+fdyVMB1Tw98TdRo2ogk38ZhdlxpEDRonW kWuBmS9e7lABqVpyfVAuODF3cKfbxWJnFBkipEJzkpSUsCFQ0SSxs5xkad/bAFF3g1p+E9+EnZMe UJ55L2ZEEtFfgfsPo0N/M7QvWS8COPSwttdSgiXFm9/WHPxu10D6mb/ghNeUFRTrn8miZOer+3p+ 8TRruFMazmsak0emJ8dxsTCdbWZzJEqgz833uttaqZWbHsNY7FuIcj242RTsgetkIRHzaxpKxmUY NnF78vxm3HW/ZX1OpOQsLIT5t+7YDKuLGB15dJnQjQFy9w8TZFaoFUSd39rFdrFtfps7FWb73yov Zcz42a8MrxBcWpZWzpif59TT34IJEEN1/+bXPMGELyT417DIoV8faB6GPKCFV0l7G1TEJTYlobbZ rYVb8B7a0Uu1lPgyxLWlZLWiTYDQF2y8U3KWMIIFdDCCA1ygAwIBAgICOH8wDQYJKoZIhvcNAQEF BQAwVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9y ZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDAeFw0wNzEwMjQxOTI3NDFaFw0wOTEwMjMx OTI3NDFaMHwxITAfBgNVBAMTGENocmlzdG9waCBBbnRvbiBNaXR0ZXJlcjEkMCIGCSqGSIb3DQEJ ARYVY2FsZXN0eW9Ac2NpZW50aWEubmV0MTEwLwYJKoZIhvcNAQkBFiJtYWlsQGNocmlzdG9waC5h bnRvbi5taXR0ZXJlci5uYW1lMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA+AuVQHLc 1FsfbnDyk6eEX6q2PgY3Thobu6v4mxdNwSQU05lZnkhqXY9pBY/sZ8QSnmUvTD8t1hc9+cs2iGni X81v51vxodR5UFiAYFM8YX6Ykd8kZ6hyF+9mjvy7oGkqQKsMDDYEo3Uk3HD47GZa66cKZdIUz2Cp F8Gd+Zzbk/ptr21CUNcYspkDz8kpcswpxNNLt0iSugRszkVNJoCYZaS/CcPp+nGMWBY0teNqA2qV APr6r5r//6Bc04Y/fhpneo+cs9H+BSL/KqtC4BW8Z6kYCGXgHUqf5zt5E6ih2rfcaGiajOeHyGiA GQMlen5eriTyZ5qzC0331lR0xoV4mwIDAQABo4IBJjCCASIwDAYDVR0TAQH/BAIwADBWBglghkgB hvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0 byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgor BgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUF BzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMEQGA1UdEQQ9MDuBFWNhbGVzdHlvQHNjaWVudGlh Lm5ldIEibWFpbEBjaHJpc3RvcGguYW50b24ubWl0dGVyZXIubmFtZTANBgkqhkiG9w0BAQUFAAOC AgEApkj8+8jrKeWAhOtFNTtZoWWWUC2RYILowYoQTXqFR5s3Ar9xyNSq4ct8ODYthun9YfHfNlDG SPsJqvMxSqegNOckxsqi8M51ne+puzqnp8q5FSNORoRw3/RkOWVzgF7BrllR90PYyXc5vEXagrvC ZPDi1AJIpmU9yr4wvmFXcTFqDZ8FwbN5H4b9BRYpyZiVo6lGPxW7xkxenNIPxP5Onaco/6KpraW/ 5QIjpxJcn593JUwHVPD3xN1GjaiCTfxmF2XGkQNGidaRa4GZL17uUAGpWnJ9UC44MXdwp9vFYmcU GSKkQnOSlJSwIVDRJLGznGRp39sAUXeDWn4T34Sdkx5QnnkvZkQS0V+B+w+jQ38ztC9ZLwI49LC2 11KCJcWb39Yc/G7XQPqZv+CE15QVFOufyaJk56v7en7xNGu4UxrOaxqTR6Ynx3GxMJ1tZnMkSqDP zfe621qplZsew1jsW4hyPbjZFOyB62QhEfNrGkrGZRg2cXvy/Gbcdb9lfU6k5CwshPm37tgMq4sY HXl0mdCNAXL3DxNkVqgVRJ3f2sV2sW1+mzsVZvvfKi9lzPjZrwyvEFxallbOmJ/n1NPfggkQQ3X/ 5tc8wYQvJPjXsMihXx9oHoY8oIVXSXsbVMQlNiWhttmthVvwHtrRS7WU+DLEtaVktaJNgNAXbLxT cpYwggYIMIID8KADAgECAgEBMA0GCSqGSIb3DQEBBAUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1 dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTA1MTAxNDA3MzY1 NVoXDTMzMDMyODA3MzY1NVowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6 Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZI hvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++ty kA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUo qMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+ lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rV O5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcD rb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvq Tpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/ KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6 JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ 92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgb8wgbwwDwYDVR0TAQH/BAUwAwEB/zBdBggrBgEF BQcBAQRRME8wIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCgGCCsGAQUFBzAC hhxodHRwOi8vd3d3LkNBY2VydC5vcmcvY2EuY3J0MEoGA1UdIARDMEEwPwYIKwYBBAGBkEowMzAx BggrBgEFBQcCARYlaHR0cDovL3d3dy5DQWNlcnQub3JnL2luZGV4LnBocD9pZD0xMDANBgkqhkiG 9w0BAQQFAAOCAgEAfwiIodoaUEnaifuhCHLzivcexDq0eVsgMLFF3sJd02Vp8cJdVFQ8hV+5e0KR wpn9G1Gbq0aloRBTnm2IrHNuLDOm8PSe4HXBPohFqeFmQ/5WWtF6QXj3QNpKOvELW6W7FgbmwueT uYVNl0+xHjhDgO+bDYzvuKdgAIdXfR5EHMsj75s8mZ2vtSkcRXkWlk0nbfEcbMPCVWSzvBTi86Qf HjL8JxUFz90urj6CYXvwIRAY9kTqUzn53NCaIODGu+C7Wk/EmcgHvbW9otsuYg1CNEG8/4uK9VEi qogwAOKw1Ly+ZbrVA1d5m+jcyE34UO2RpVIooqz7Nlg+6ZQrkVCHG9Ze1ozM9w8QDFJO0BZh5eUK bL8Xx3JGV5yY9WxgY3pvXrlOL8i5ubtqhbyYDe35PpeENJSuAK+h5eeSbk698+LZFItc0usBbKAX pS0Q65x6Sr297s797SJAq3A4iPUKh2rCqwVgyUgF2lPB3kR3arPzPDztgLymOEopJF/+WTubJXpW YwBkuV2kYn1XNk+tg+8fklOgjndX3eVhET0jAJBMPPqjYJMEo6819g5qj09KYKeFBWxGoY/0x3bj oVlX93GyxG4UXG1tQWbfG5Ox1ADD7svPPD0hgKlfY2X83eBfpPQr8IVxQdRnJfsasZeu1pmCE0HS bqUbmSeA5wupqAAxggK6MIICtgIBATBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQL ExVodHRwOi8vd3d3LkNBY2VydC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/ MAkGBSsOAwIaBQCgggE1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTA5MDEzMTAxMzYyMVowIwYJKoZIhvcNAQkEMRYEFAtvDtgRAynsvtUHbSdCHDvEs3YpMGkGCSsG AQQBgjcQBDFcMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cu Q0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdAICOH8wawYLKoZIhvcNAQkQ AgsxXKBaMFQxFDASBgNVBAoTC0NBY2VydCBJbmMuMR4wHAYDVQQLExVodHRwOi8vd3d3LkNBY2Vy dC5vcmcxHDAaBgNVBAMTE0NBY2VydCBDbGFzcyAzIFJvb3QCAjh/MA0GCSqGSIb3DQEBAQUABIIB AGZqQxLPULJtS0hxEXNqBlpw2uWjzD4LEu2fo/MNYyapZtOGa/KbFUYUhkUxN9dBr87MtPOHJexi EBcnifQ/s0MsU8zaY7RODxxZKE7bgcMzyG/8Vj1ny9h/KM4bXA3NCuYYOa4zcIy/wwkLHsq+/7Vl p/NP9GoFl13DzTAvFicfTBAXq5KIwWqnmhtkFA7RAH4ljB0fS5WoeaO2hJwRvDUgRMfaltVA+z6a +wIfmu77K5pBYo0XZwSazN6lqp+sAzeFksznV2HBagTU33/t8iaW3jivNtTXyexk2nJ0u+jqxPfh UHflhWJEhKuX2U1pvkolucuISnYuY8gmqdXH+cAAAAAAAAA= --=-a2zdl3WhkIRphpiliK9b-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V14cAJ013871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 18:04:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V14crW013870; Fri, 30 Jan 2009 18:04:38 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V14c5A013864 for ; Fri, 30 Jan 2009 18:04:38 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 0A0D52E2B5 for ; Fri, 30 Jan 2009 17:05:30 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63161-08 for ; Fri, 30 Jan 2009 17:05:26 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id E2C452E1E4 for ; Fri, 30 Jan 2009 17:05:26 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Jan 2009 16:05:35 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Jan 2009 16:05:35 -0800 Cc: OpenPGP Message-Id: <86EB229A-0E6D-47F3-9911-BC7F47D8B526@callas.org> From: Jon Callas To: Peter Thomas In-Reply-To: <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Fri, 30 Jan 2009 17:04:32 -0800 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 30, 2009, at 10:05 AM, Peter Thomas wrote: > > On Thu, Jan 29, 2009 at 8:37 PM, Jon Callas wrote: >> On the contrary, I think you should start discussing things here and >> start writing drafts. > I don't believe I'm technically skilled enough for doing this. And I > must admit that I've borrowed some (of course not all) ideas here from > some threads I've found on the gnupg mailing lists. I've already > contacted the author (Christoph Mitterer) of that threads and I hope > he'll have a look at the currently ongoing discussion. Of course you are skilled enough. And so what that you've borrowed ideas. Shakespeare borrowed all his plots. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJg5XPsTedWZOD3gYRAnTfAKCLk2TcIeyu2vyBPAnVkhJCCIqOHgCgtm7B k41rFL00AjX6B1APB8Qiif8= =BWdo -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V134Wm013743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 18:03:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V134sI013742; Fri, 30 Jan 2009 18:03:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V133wI013736 for ; Fri, 30 Jan 2009 18:03:03 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id B3AAE2E2B3 for ; Fri, 30 Jan 2009 17:03:55 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63161-07 for ; Fri, 30 Jan 2009 17:03:48 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id AFCF72E2B4 for ; Fri, 30 Jan 2009 17:03:48 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Jan 2009 16:03:57 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Jan 2009 16:03:57 -0800 Cc: ietf-openpgp@imc.org Message-Id: From: Jon Callas To: Peter Thomas In-Reply-To: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 6 Date: Fri, 30 Jan 2009 17:02:54 -0800 References: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I) General questions about the sematics: > 1) signature creation time (2) > Does the RFC imply, that a signature (of any type) is to be considered > invalid, if the current time is not after the signature creation time? > If so this would even mean that a key from the future is "unusable" if > all self-signatures are invalid because of this, right? In general, we want to let someone sign something for the future. There are many times when a signed object needs to be created in advance. That we call it "creation time" rather than "not before" is an eccentricity with an obvious right thing to do. So yeah, if someone creates a key that has a creation time of tomorrow, it's not valid yet. > > > 2) signature expiration time (3) > If the signature is expired it is to be considered invalid. It my thus > have the same effect as key expiration time when all self-signatures > are invalided because they're expired, right? Yes. > > > 3) key expiration time (9) > I've probably asked this before. But, what happens if different key > expiration times are specified in the self-signatures? Is it left to > the implementation to decide what to do? Yes. There are plenty of obvious right things to do. Let's suppose I am moving from example.com to foobar.com next Monday, but I quit example.com effective today (and set an expiration time that reflects that). From now until Monday, neither user name is valid. > > > 4) exportable certification (4) > Does this have a meaning on subkey binding signatures (0x18)? E.g. > something like don't import the signature itself and neither the > subkey? I have applications for this, myself. Yes. Here is my example for which this is a possible solution. PGP Corporation has a public key for "security@pgp.com" so people can send us security reports that are encrypted. I want to have the encryption subkey on my personal key, but I don't want to publish it. A non-exportable binding signature is a possible solution. > > > 5) Is it allowed that more than on subpackets of the same type exist > in the same signature? > E.g. Two policy URIs in on 0x13, or two preferred key servers. And > what would it mean? It makes sense to me to have two preferred keyservers. I don't have an opinion about policy URIs, but I wouldn't discount it automatically out of hand. > > > > > > I tried to create the following example and wonder whether my > interpretation is always correct: > Given is a public key, with several User IDs signed with 0x13s, a > direct key signature 0x1F and several subkeys signed with an 0x18: > (look closely as there are minor differences between the stuff > below ;-) ) I'm not going to comment further, but only because I'm in a hurry and haven't memorized the hex values. > > > I) Subpackets on the 0x1F direct key signature (there should be only > one of it): > - signature creation/expiration time > In principle it has only a meaning for the 0x1F itself, but it might > also expire the key as described int I) 1 and I) 2 above. > > - key expiration time > The expiration time of the WHOLE key with all UIDs, subkeys, etc. > An implementation MAY decide when to use the key expiration from the > 0x1F. Reasonable ways would be: > * when no other self-sig specify one (thus it works globally for the > key) > * when the key was found/selected by the KeyID (this is > questionable, isn't it?) > * or it may even take priority in favor of all other key expiration > times on other signatures, like 0x13's (but not 0x18s because subkeys > have their own expiration time!!!!) > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x1F. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when the key was found/selected by the Key ID (here I think this is > NOT questionable as above) > * or it may even take priority in favor of all other preferred > algorithms on other signatures, like 0x13's and 0x18's > > > II) Subpackets on any of the 0x10-0x13 certification signatures: > - signature creation/expiration time > In principle it has only a meaning for the 0x10-0x13 itself, but it > might also expire the specific User ID (if there is no other valid > self-signature on it). > > - key expiration time > The expiration time of the WHOLE key with all UIDs, subkeys, etc. > An implementation MAY decide when to use the key expiration from the > 0x10-0x13. Reasonable ways would be: > * when no other self-sig specify one (thus it works globally for the > key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (this is > questionable, isn't it?), or it was specified as Signers User ID > subpacket > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x10-0x13. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (here I > think this is NOT questionable as above), or it was specified as > Signers User ID subpacket > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x10-0x13. > Reasonable ways would be: > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > * when the key was found/selected by the specific User ID (here I > think this is NOT questionable as above), or it was specified as > Signers User ID subpacket > > > III) Subpackets on the 0x18 subkey binding signature: > - signature creation/expiration time > In principle it has only a meaning for the 0x18 itself, but it might > also expire the specific subkey (if there is no other valid > self-signature on it). > > - key expiration time > The expiration time ONLY of the specific subkey, not of any other > subkey, any User ID or even the whole primary key. > This only applies to the specifix subkey, so an implementation cannot > choose anything (as with the key expiration times above) > > - preferred symmetric/hash/compression algorithm > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > - key server preferences / preferred key server / key flags / features > An implementation MAY decide when to use these from the 0x18. > Reasonable ways would be: > * when that specific subkey was used for encryption/signing/or > selected somehow else > and optionally (the above condition seems nearly mandatory): > * when no other self-sig specifies them (thus they work globally for > the key) > * when there is no global setting via a 0x1F self-signature > > Is this all correct / ok / within the borders of the CURRENT rfc? > > Ok that was a lot ^^ > > > Lots of thanks in advance, > Peter > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJg5VtsTedWZOD3gYRAjEWAKCzTgK60jwnkNc6gV6NT0rlBpOe3ACfQTf1 GqW0aFDRQds5vFJHEP2HWzg= =xP4T -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V0sH0l013465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 17:54:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V0sH1A013464; Fri, 30 Jan 2009 17:54:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V0s6gj013458 for ; Fri, 30 Jan 2009 17:54:16 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 9FCAB2E2B5 for ; Fri, 30 Jan 2009 16:54:58 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 63093-08 for ; Fri, 30 Jan 2009 16:54:55 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 822D92E2B3 for ; Fri, 30 Jan 2009 16:54:55 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Jan 2009 15:55:04 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Jan 2009 15:55:04 -0800 Message-Id: <52B9E41F-4AD8-40AE-9F80-41CEADDBFD8B@callas.org> From: Jon Callas To: IETF OpenPGP Working Group In-Reply-To: <49833C0E.8010605@fifthhorseman.net> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Ideas on new user attribute types and image formats Date: Fri, 30 Jan 2009 16:54:01 -0800 References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> <49833C0E.8010605@fifthhorseman.net> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> > > hpng supports features that jpeg doesn't, including at least: > > * indexed colormaps > * alpha-channel transparency > > Both of these are useful features in some not uncommon circumstances > (e.g. logos and "hackergotchi"/floating-head images that discard > background/non-identity information). > > I'm not suggesting that OpenPGP is worthless without PNG, of course. > But it would be useful to support it. I'll add in that I think adding PNG is fine with me, and that's why I'll also be devil's advocate. So what? I think that "because it would be cool" is a fine answer. We should say it, if that's why. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJg5NYsTedWZOD3gYRAlQ8AKC+/nDZwYxkom6iWB1AS7JyM1hoSACfR0J1 RPkh1wD8WtKv8kPWJHbB074= =wzs4 -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V04kUm011726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 17:04:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0V04kxN011725; Fri, 30 Jan 2009 17:04:46 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0V04Y7W011710 for ; Fri, 30 Jan 2009 17:04:45 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so516830fxm.10 for ; Fri, 30 Jan 2009 16:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=sTta7PrnpfrsWPHjwdhXRSuU0oglYfMrwsE8SftkVOk=; b=O8kpOWaBoHG6ILMcM6Kq2Yg6l/KRqMbQ+PduWozfAUj4aE3y2g0YqsUGkbGyjaPL/T 8kfMX1m6+sNysWnoGrdHaZzClGRYvJhbF4K0GlNmTa/Jl1eKDI9lELOUGUB8jovuIp7y yWlcWg5xuW0D/BrSU68l3kPFYO90fONL4LlkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=al0kg8oimlOr3NAO+iInE82KBTBN6LZuL4JAdy29hN+/Lb8my9WyrIodZfgQWSbh0H /getIYTjX02SU5hPQQ6/B0R/nwsTR8O3tpUvIYoifTU/7u/1lmVYAJqCdvG/bioMD7+M 9yHr9Ikwbr8E7KWLIU4uhdi3F2SeWAtiE+STs= MIME-Version: 1.0 Received: by 10.181.152.14 with SMTP id e14mr611005bko.189.1233360273305; Fri, 30 Jan 2009 16:04:33 -0800 (PST) In-Reply-To: <20090130195917.GC19809@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> <20090130195917.GC19809@jabberwocky.com> Date: Sat, 31 Jan 2009 01:04:33 +0100 Message-ID: <9ef756150901301604o6ca950e8ucc85547710f12c22@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 8:59 PM, David Shaw wrote: >> Uhm? Why this? I'd thought it would only revoke the specifically >> revoked signature, as "the signature is computed over the same data as >> the certificate that it revokes". >> Am I missing something? > > Take this example: > > User ID > 0x10 signature on that user ID (timestamp 1) > 0x10 signature on that user ID (timestamp 2) > 0x30 revocation (timestamp 3) > > Which signature is being revoked? Without a signature target, it's > not clear. Ahhhh.... First of all,.. the different types of revocation signatures are NOT calculated of the signature they revoke, but the data the signature to be revoked was calculated over, right? Ok then it's clear. Why is it not simply calculated over the signature to be revoked? But the following is still unclear: a) when I use a 0x20 key revocation signature: Am I correct that the explanation on page 21 says: A key having a revocation signature is completely invalid including all it's UIDs, subkeys, etc. and this cannot be undone in any way? (Of course the subkeys could still be used attached to another primary.) I mean the following doesn't work, right? Primary key |->UID |--->0x13 on that UID |->Subkey |--->0x18 on that subkey now I add a: |-> 0x20 key revocation at 12:00 making the key unusable (forever?) at 13:00 I add new UID's/0x13s/Subkeys/0x18s |->UID2 |--->0x13 on that UID2 |->Subkey2 |--->0x18 on that subkey2 But the whole thing would still be revoked, right? b) when I use a 0x28 key revocation signature: Does this (according to the RFC) make the subkey forever unusable, as above with the 0x20s? Or would issuing a subkey binding signature more recent than the 0x28 bring it (the subkey) back? c) when I use a 0x30 certification revocation signautre. Here the whole thing is different to a) and b) (as far as I understand). The RFC says "This signature revokes an EARLIER User ID certification signature..." Does this now exactly mean,.. that it revokes ALL earlier user id certification signatures? > I can't speak to any other program, but GPG finds the latest > (i.e. most recent) signature or revocation from the issuer. If that > turns out to be a revocation, then there is effectively no signature. > > Note that using the example above (sig+sig+revoke), this would result > in there being effectively no signature. That is intentional, not a > bug: the second signature superseded the first signature, and then the > revocation revoked the second. End result: no signature. Ok I see. And what does this now mean for my idea on how to force an implementation to use only the most recent signatures? Will the following work, as long as the signature creation times are correct? And I mean would it be correct even when strictly following the RFC? Public Key UID1 0x13 signature on that user ID (timestamp 1) (is not revoked by the 0x30 below) UID2 0x13 signature on that user ID (timestamp 1) 0x13 signature on that user ID (timestamp 2) 0x30 revocation (timestamp 3) (revokes every 0x10,0x11,0x12,0x13,0x1F on UID2 BUT NOT on UID1 BEFORE timestamp 3 0x13 signature on that user ID (timestamp 4) (is not revoked by the 0x30 above) Thanks for your help, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UNdKXB010908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 16:39:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UNdKuu010907; Fri, 30 Jan 2009 16:39:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UNdIut010901 for ; Fri, 30 Jan 2009 16:39:19 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fk-out-0910.google.com with SMTP id 19so648022fkr.10 for ; Fri, 30 Jan 2009 15:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7mNTNlVKfHbWW9cSaw18stPcvbQIpCPoLrnCwcL2EHc=; b=Qf322S+p/Jt4jJlurfrv92YQaDIXnE4QVa02W0dF7+u2LB6sv6iR9hPHX4atBU0CrB /IWX3L/DU8+1F4k1zQbq+Jm8+wGuWCR+DI5wX9scEZiD6L1c8e4DfM+YsmbD6dlySOcS Ee/qBFSW+CRhoojKNDVHuh5oDPxRFACEq8QqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=gp1dzjhpp2mLTaanDRh79vxOnzCVd8Z++VY4o294sNSVkm+vhnoD4jFqFXYqfoYqK+ vKNfOWoHd2ah4FrDf3u+SqWa6DWr/rBspNGW2NuREYTDb8ERA/eYH0iYYJMthUPjwtmS 4hpFflPpQW3n1kVpUIagIvkQRchQxDM5pnpuI= MIME-Version: 1.0 Received: by 10.181.61.2 with SMTP id o2mr610272bkk.101.1233358757141; Fri, 30 Jan 2009 15:39:17 -0800 (PST) In-Reply-To: <49835DB4.1040409@fifthhorseman.net> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> <498348F9.5030708@fifthhorseman.net> <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> <49835DB4.1040409@fifthhorseman.net> Date: Sat, 31 Jan 2009 00:39:17 +0100 Message-ID: <9ef756150901301539m64a6ef17p1d4e5e7f2d0fec72@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: IETF OpenPGP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 9:06 PM, Daniel Kahn Gillmor wrote: > I don't have an immediate example (i haven't used policy URIs on > self-sigs or anywhere else). But simply saying "these two policy-type > statements don't make sense" is different from saying "there could be no > possible policy statement that you would like to reference in a > self-signature." Uhm,... well I'm not sure what the others are thinking. Of course I see your point in preserving compatibility, but even if this semantical change would be introduced in a future version of the RFC it wouldn't probably hurt that much, would it? I mean policy URIs are quite rare and everybody could still interpret it as he wants ;-) > For example, here's a policy statement: "This identity is found on > official government documents in the legitimate possession of the keyholder" > > Say Margaret has two user IDs: > > "Margaret Kantor " > "Maggie Kantor " > > Since her gov't id doesn't have anything with "Maggie Kantor" on it (but > she's known by all of her friends as maggie) she might want to assert > the above policy for the former self-sig but not the latter. > > I'm not saying it's a great use case, but it would be really unfortunate > if she had done that and then later found that it meant that all > signatures issued by the Margaret Kantor uid (if she used a Signer's > User ID subpacket, for example) suddenly meant that she had verified > specific gov't-issued ID. Not sure if I understand what you mean. A goverment could simply just sign the first UID and specify perhaps the governmental policy that was used (but this is of course not on the self signature). Which information would you exactly put in the policy from the self-signature's Policy URI? (I actually believe that there might be reasonable cases, and just want to understand yours correctly :-) ) >> 1) Look at all policies whether they specify how to resolve conflicts. > this assumes that the policies are machine-parseable in a form that > includes conflict resolution, no? Why? All policies might have a human readable chapter "X. In case of policy conflicts", where they explain what should happen. > what form are you proposing? my > reading of the RFC is that there is no restriction on what can be > contained in the policy URI. I don't see that point why this would have to be machine-readable. > If we're ok with saying something like: "well-implemented clients should > be configured well enough to know to not make any conflicts", why not > just tell the well-implemented clients to embed the policy URI subpacket > in every signature they make, and not introduce this special case at > all? This is actually a good point and in principle you're right (and this could be done without changing the RFC at all). But my model would allow to implement a more mighty policy model imagine the following: The policy "in" the self-signature is used as I proposed above. It could contain information like the following: - How is the key secured (security building, fences, safes, guards) - What are the procedures in case of a security compromise - How are other key/UIDs certified (e.g. when is a 0x10, 0x11, 0x12 or 0x13 issued) All these are very general information. The policy of the non-self-signatures could contain additional information about just that single signed document (for example). > That seems simpler all around to me, and wouldn't require any > retroactive changes to the specification. Well that's a point. But the whole idea with the semantic addition/change to the policy URI was just an idea, that I wanted to be discussed by all these wonderful experts here. I don't claim that I have the proof that it makes sense or is the best and only solution ;-) > btw, please don't take my opposition to this particular idea as > opposition to you Oh and I was just about to add you to my deadly enemy list ;-) (just kidding) > proposing changes to the OpenPGP specification in > general. It's great to see this sort of discussion. Thanks for raising it! Thank you :-) ... but again I was inspired by some threads I've found on the gnupg-lists,... so I must thank Christoph Mitterer ;-) Cheers, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UMEhWH007810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 15:14:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UMEhB7007809; Fri, 30 Jan 2009 15:14:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UMEVlY007802 for ; Fri, 30 Jan 2009 15:14:42 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fk-out-0910.google.com with SMTP id 19so631093fkr.10 for ; Fri, 30 Jan 2009 14:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=ipr6EbCWnpoxJd6XFpV34kYHbnWyMYlAGN+BRgD2XFQ=; b=EPmdWGBLjVr1P0AHTqYpPNhJJIaSXULKpbxnKhbDTcGm9CtUTSavsRhiyYVtRLlR1G 3OLlhYeT1TANtwvByVoQIxhk0wi0vTWf37h/jP99wcYbHp+hWAEWv59Pu9w2Z85+R3K+ PG6zRR9bMYxAwi4+iXWk3ktd1KV7yKgxCk0bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WJpkMBsuCgvSuToEDIlc2Vqnry15CjuRxJuCXjosDggE837YVJgxgHSYqDZ+OI15iZ y/oFMoSHP3G/WAPP3QTO5hCNQOcQbjHlUKn3kawBdDVQpvL8eFAyhuRq7q6WUd4V1QNN mWLeZtdc45i4OnwoM9qoW16cgUIPTP0oe1JBM= MIME-Version: 1.0 Received: by 10.181.37.6 with SMTP id p6mr589956bkj.29.1233353671340; Fri, 30 Jan 2009 14:14:31 -0800 (PST) Date: Fri, 30 Jan 2009 23:14:31 +0100 Message-ID: <9ef756150901301414l791ff7c2p402a294d5967e549@mail.gmail.com> Subject: Series of minor questions about OpenPGP 6 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings. I've already threatened that I'd have more questions so here they are ;-) The following is about the correct interpretation of several signature subpackets on the different types of self-signatures. It would be great if you could tell me whether my interpretation of the CURRENT rfc and thus my interpretations of the semantical meanings are correct. I) General questions about the sematics: 1) signature creation time (2) Does the RFC imply, that a signature (of any type) is to be considered invalid, if the current time is not after the signature creation time? If so this would even mean that a key from the future is "unusable" if all self-signatures are invalid because of this, right? 2) signature expiration time (3) If the signature is expired it is to be considered invalid. It my thus have the same effect as key expiration time when all self-signatures are invalided because they're expired, right? 3) key expiration time (9) I've probably asked this before. But, what happens if different key expiration times are specified in the self-signatures? Is it left to the implementation to decide what to do? 4) exportable certification (4) Does this have a meaning on subkey binding signatures (0x18)? E.g. something like don't import the signature itself and neither the subkey? 5) Is it allowed that more than on subpackets of the same type exist in the same signature? E.g. Two policy URIs in on 0x13, or two preferred key servers. And what would it mean? I tried to create the following example and wonder whether my interpretation is always correct: Given is a public key, with several User IDs signed with 0x13s, a direct key signature 0x1F and several subkeys signed with an 0x18: (look closely as there are minor differences between the stuff below ;-) ) I) Subpackets on the 0x1F direct key signature (there should be only one of it): - signature creation/expiration time In principle it has only a meaning for the 0x1F itself, but it might also expire the key as described int I) 1 and I) 2 above. - key expiration time The expiration time of the WHOLE key with all UIDs, subkeys, etc. An implementation MAY decide when to use the key expiration from the 0x1F. Reasonable ways would be: * when no other self-sig specify one (thus it works globally for the key) * when the key was found/selected by the KeyID (this is questionable, isn't it?) * or it may even take priority in favor of all other key expiration times on other signatures, like 0x13's (but not 0x18s because subkeys have their own expiration time!!!!) - preferred symmetric/hash/compression algorithm An implementation MAY decide when to use these from the 0x1F. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when the key was found/selected by the Key ID (here I think this is NOT questionable as above) * or it may even take priority in favor of all other preferred algorithms on other signatures, like 0x13's and 0x18's - key server preferences / preferred key server / key flags / features An implementation MAY decide when to use these from the 0x1F. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when the key was found/selected by the Key ID (here I think this is NOT questionable as above) * or it may even take priority in favor of all other preferred algorithms on other signatures, like 0x13's and 0x18's II) Subpackets on any of the 0x10-0x13 certification signatures: - signature creation/expiration time In principle it has only a meaning for the 0x10-0x13 itself, but it might also expire the specific User ID (if there is no other valid self-signature on it). - key expiration time The expiration time of the WHOLE key with all UIDs, subkeys, etc. An implementation MAY decide when to use the key expiration from the 0x10-0x13. Reasonable ways would be: * when no other self-sig specify one (thus it works globally for the key) * when there is no global setting via a 0x1F self-signature * when the key was found/selected by the specific User ID (this is questionable, isn't it?), or it was specified as Signers User ID subpacket - preferred symmetric/hash/compression algorithm An implementation MAY decide when to use these from the 0x10-0x13. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature * when the key was found/selected by the specific User ID (here I think this is NOT questionable as above), or it was specified as Signers User ID subpacket - key server preferences / preferred key server / key flags / features An implementation MAY decide when to use these from the 0x10-0x13. Reasonable ways would be: * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature * when the key was found/selected by the specific User ID (here I think this is NOT questionable as above), or it was specified as Signers User ID subpacket III) Subpackets on the 0x18 subkey binding signature: - signature creation/expiration time In principle it has only a meaning for the 0x18 itself, but it might also expire the specific subkey (if there is no other valid self-signature on it). - key expiration time The expiration time ONLY of the specific subkey, not of any other subkey, any User ID or even the whole primary key. This only applies to the specifix subkey, so an implementation cannot choose anything (as with the key expiration times above) - preferred symmetric/hash/compression algorithm An implementation MAY decide when to use these from the 0x18. Reasonable ways would be: * when that specific subkey was used for encryption/signing/or selected somehow else and optionally (the above condition seems nearly mandatory): * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature - key server preferences / preferred key server / key flags / features An implementation MAY decide when to use these from the 0x18. Reasonable ways would be: * when that specific subkey was used for encryption/signing/or selected somehow else and optionally (the above condition seems nearly mandatory): * when no other self-sig specifies them (thus they work globally for the key) * when there is no global setting via a 0x1F self-signature Is this all correct / ok / within the borders of the CURRENT rfc? Ok that was a lot ^^ Lots of thanks in advance, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UK3Yfl002455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 13:03:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UK3YC1002454; Fri, 30 Jan 2009 13:03:34 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UK3XU5002447 for ; Fri, 30 Jan 2009 13:03:33 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 71211 invoked from network); 30 Jan 2009 20:03:32 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 30 Jan 2009 20:03:32 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49835DB4.1040409@fifthhorseman.net> Date: Fri, 30 Jan 2009 15:06:12 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Peter Thomas CC: IETF OpenPGP Working Group Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> <498348F9.5030708@fifthhorseman.net> <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> In-Reply-To: <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF87E6C5E2432703861AE0346" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF87E6C5E2432703861AE0346 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 02:38 PM, Peter Thomas wrote: > For policy-URIs on self-sigs: What would this mean at the moment: "The > policy under which I signed my own key", right? > Does this make any sense? I mean what could one tell in such a policy? > "I trust myself", "I checked my own identity"? > That was the idea why I suggested that idea, because I think otherwise > it does not make much sense at all. I don't have an immediate example (i haven't used policy URIs on self-sigs or anywhere else). But simply saying "these two policy-type statements don't make sense" is different from saying "there could be no possible policy statement that you would like to reference in a self-signature." For example, here's a policy statement: "This identity is found on official government documents in the legitimate possession of the keyhold= er" Say Margaret has two user IDs: "Margaret Kantor " "Maggie Kantor " Since her gov't id doesn't have anything with "Maggie Kantor" on it (but she's known by all of her friends as maggie) she might want to assert the above policy for the former self-sig but not the latter. I'm not saying it's a great use case, but it would be really unfortunate if she had done that and then later found that it meant that all signatures issued by the Margaret Kantor uid (if she used a Signer's User ID subpacket, for example) suddenly meant that she had verified specific gov't-issued ID. > 1) Look at all policies whether they specify how to resolve conflicts. this assumes that the policies are machine-parseable in a form that includes conflict resolution, no? what form are you proposing? my reading of the RFC is that there is no restriction on what can be contained in the policy URI. > 2) If the actual conflict remains, or if the conflict resolution > processes of the different policies are in conflict, the policies have > priority in the following order: > a) the policy specified in the signature of the signed data > b) the policy on the User ID self-signature,.. IF the signers user ID > was specified in the signature on the actual data > c) the policy on the (most recent) 0x1F signature > d) the policy on the 0x18 signature, from the key that was used to > create the signature on the actual data >=20 > Of course one would have to discuss which order fits best. Wow, that sounds like a lot of heavy, fairly arbitrary work and hassle to hash out the spec, let alone an implementation. If we're ok with saying something like: "well-implemented clients should be configured well enough to know to not make any conflicts", why not just tell the well-implemented clients to embed the policy URI subpacket in every signature they make, and not introduce this special case at all? That seems simpler all around to me, and wouldn't require any retroactive changes to the specification. btw, please don't take my opposition to this particular idea as opposition to you proposing changes to the OpenPGP specification in general. It's great to see this sort of discussion. Thanks for raising = it! --dkg --------------enigF87E6C5E2432703861AE0346 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYNduczS7ZTSFznpAQLEhw//dbQlFQoWdu7nRMrs5CIezc8l5Hmf+Xs8 gqIkviy82a2HKOegv8VACB8lgvYTppepRBeYU0J9TRn7zWJAj1OPgPK97nKgR2IR kAx7eb0/qyoIyTz9/4NWSsAvrtnAdoCFcHwKrieMguh8aIIao2ULhcJ5MC/308UF DyKSYSl0z9kJ+kpfRtplIYf1dO5SURDVFPFlDUBHb8RZKRUchRP3yr8IEKy5cC4O h3uokrcoWR+YBJ03sc6X8j1obykH5B5Lbk4aTIUp9ZO7RZg+mlj5Apt4ikfo+jHL RVh7Rkx8289ZO17sDMlNv/8uhHXnwYFgE+P2ZAP1aIdVFQSSV2bZNqRaREkGz/s6 NDn3I1rQgBSUFsGdvDm1PQs42+jpMUzkUk3E6uajVksVZUMMC+KUXQDmq1qdxrXk tUsHlkJtp6sVNSyS3nFyAToVLPE9hEKREwP4bD8HqH5soIVL2zU1IX1OM72p6Uq1 /lDVj38jsWWj2MhAcHzXCzCEcdeJgltKUtV6Qy+jIlT9tSkUuZlfO4XkV9Rh1Cem jw5CD5sLU2YE8XR9xI5RAUa+MLmAjm5qlBW60cTG9PP6VHMI/m4xhBqt0oXbRW2s 8H/dKop/CUfMjzZBa/4W8PdjKhBA5JKqJPeyz1tM5VAodmS4I6xuMZPO9dRiTT0L ZcGW+UodjuY= =+1xp -----END PGP SIGNATURE----- --------------enigF87E6C5E2432703861AE0346-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJxUmM002268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJxUKm002267; Fri, 30 Jan 2009 12:59:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJxI9U002259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 12:59:29 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0UJxHt1010375 for ; Fri, 30 Jan 2009 14:59:17 -0500 Date: Fri, 30 Jan 2009 14:59:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090130195917.GC19809@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 08:17:41PM +0100, Peter Thomas wrote: > > On Thu, Jan 29, 2009 at 11:30 PM, David Shaw wrote: > > It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F > > signature revokes (potentially) all of them that are a) from the same > > issuer (or from that issuer's designated revoker), and b) timestamped > > earlier than the revocation. It cannot revoke ones that come after > > it. > Uhm? Why this? I'd thought it would only revoke the specifically > revoked signature, as "the signature is computed over the same data as > the certificate that it revokes". > Am I missing something? Take this example: User ID 0x10 signature on that user ID (timestamp 1) 0x10 signature on that user ID (timestamp 2) 0x30 revocation (timestamp 3) Which signature is being revoked? Without a signature target, it's not clear. > > Even then there is the possibility of confusion of which signature you > > intend to revoke. In those cases, you can always specify a particular > > signature to revoke using the Signature Target subpacket in the > > revocation. Arguably, you could even revoke multiple signatures with > > one revocation by using multiple subpackets. > > > > Not, it should be pointed out, that many (any?) implementations > > support Signature Targets yet. But the semantics are there. > Uhm ok,.. so how does an implementation figure out which certificate > is revoked by a revocation signature? I can't speak to any other program, but GPG finds the latest (i.e. most recent) signature or revocation from the issuer. If that turns out to be a revocation, then there is effectively no signature. Note that using the example above (sig+sig+revoke), this would result in there being effectively no signature. That is intentional, not a bug: the second signature superseded the first signature, and then the revocation revoked the second. End result: no signature. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJc9VS001431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:38:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJc94G001430; Fri, 30 Jan 2009 12:38:09 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJc7LJ001424 for ; Fri, 30 Jan 2009 12:38:08 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so405190fxm.10 for ; Fri, 30 Jan 2009 11:38:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Wanj2eHOqRoq4IXM9p5rM+j0coyyKgBPsjDzxCAzDjM=; b=JgGJ4j0nHot+0KCcASgMbl9DPiPG7Qe55bkeSEGEYmEDCL0s/kJ7tUAnN91iKf6F4e pvdQh8nP+hKg6t36pKGkrptoSqvs4lvCtFiSgkqn0CgvSU68By4QUYpmhEGVwl5FKvdA Q1vo2xyIO49++d7/Yg6Y9hAKZ3HfeCzmpFtCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=JHJW5oKsq5EeE205CtuOkcqHJc69kWjw6ZKDmpKDW+tf/pH6BG/wNgzsphpKpiwnxV h3yPQObzGzWxSVBJgasiBwmyaoVuoZ615KYMIkxMbSZ23oIEtI6lpNeUBLCAmkDSxaSi C5BYKoQNGgHOBLb0+EHsfF9E8Ain7O2e7WcsM= MIME-Version: 1.0 Received: by 10.181.60.14 with SMTP id n14mr546741bkk.23.1233344286380; Fri, 30 Jan 2009 11:38:06 -0800 (PST) In-Reply-To: <498348F9.5030708@fifthhorseman.net> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> <498348F9.5030708@fifthhorseman.net> Date: Fri, 30 Jan 2009 20:38:06 +0100 Message-ID: <9ef756150901301138y10805210la3052440613c0ab0@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: IETF OpenPGP Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 7:37 PM, Daniel Kahn Gillmor wrote: > I'd disagree with such a change, if only because it seems to force a > semantic change on signatures that may already be in existence. It'd be > weird if i made a signature that i knew meant "foo", and then came back > later to find that according to the new RFC, i'd actually stated "bar". I'm not sure if I understand what you mean. Currently policy URI subpackets are allowed on any signature, right? Their meaning is "The policy under which that signature was maid", right? Ok for signatures on other keys or data I didn't propose a semantical change. For policy-URIs on self-sigs: What would this mean at the moment: "The policy under which I signed my own key", right? Does this make any sense? I mean what could one tell in such a policy? "I trust myself", "I checked my own identity"? That was the idea why I suggested that idea, because I think otherwise it does not make much sense at all. Or do you know anything I didn't think ok? :-) > And how would you interpret the following situation: > > Key A has a self-sig with policy X > > Key A signs B's key,uid pair and includes a with policy-URI Y. > > which policy governs the A's signature on B? why? This is actually a problem. Currently the Policy URI is only meaningful for the signature itself ("The Policy under which the signature was maid"). If my suggestions for policy URIs on self-signatures would be implemented, conflicts could arise, just as you showed in your example above. I think it would be actually worse, as one could have different self-signatures (0x13,0x1F,0x18) that might apply in addition to the signature on the data iself. While conflicts are possible they "should" be unlikely in practice as all these policies are under the control of the key holder (and hopefully he have set them up without conflicts). If not one could specify the following: In case of a conflict: 1) Look at all policies whether they specify how to resolve conflicts. 2) If the actual conflict remains, or if the conflict resolution processes of the different policies are in conflict, the policies have priority in the following order: a) the policy specified in the signature of the signed data b) the policy on the User ID self-signature,.. IF the signers user ID was specified in the signature on the actual data c) the policy on the (most recent) 0x1F signature d) the policy on the 0x18 signature, from the key that was used to create the signature on the actual data Of course one would have to discuss which order fits best. Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJHjpe000741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 12:17:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UJHjSq000740; Fri, 30 Jan 2009 12:17:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UJHgI1000726 for ; Fri, 30 Jan 2009 12:17:44 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by bwz5 with SMTP id 5so220177bwz.10 for ; Fri, 30 Jan 2009 11:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=B7v8e/GplcI9ofc0Y9PMidZ+yGRq86q+F2t+2V7tWUg=; b=WP+/doenbQkJNzBf6JNh37/TBFB28zvPI2PUW+/qh9Ge9XjjVSbsh3WTInasIIBv1o QRGiw8EXv58zDm3Kf6kUOlLXbbs8vWzSmLrNG0MSU93sZYm+WL/uLwPaj3rUHGbYUiUW UmOCSDQz0HfxbLHbu3J4KSO3Hw/aDFaKKQ3LQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=wPc++H6fvcCyWfUJwW36nVrkMgn1WRWzN48gtQS/AVjZdxUdqZOSEoz3K9R6504qIy OHxYPlY/Lewo2bJQ1HC+9Apv6t2rs/SPbSP0TH2ZgSt0oJeHtiVLiE30qsxnlCWspKNS dNsv7GGsqTpAZAsEkigmanE0TLspDi31sQLE4= MIME-Version: 1.0 Received: by 10.181.135.5 with SMTP id m5mr534320bkn.87.1233343061915; Fri, 30 Jan 2009 11:17:41 -0800 (PST) In-Reply-To: <20090129223044.GA16884@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> Date: Fri, 30 Jan 2009 20:17:41 +0100 Message-ID: <9ef756150901301117u167bef13jc3c734ead1708ace@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 11:30 PM, David Shaw wrote: > It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F > signature revokes (potentially) all of them that are a) from the same > issuer (or from that issuer's designated revoker), and b) timestamped > earlier than the revocation. It cannot revoke ones that come after > it. Uhm? Why this? I'd thought it would only revoke the specifically revoked signature, as "the signature is computed over the same data as the certificate that it revokes". Am I missing something? > Even then there is the possibility of confusion of which signature you > intend to revoke. In those cases, you can always specify a particular > signature to revoke using the Signature Target subpacket in the > revocation. Arguably, you could even revoke multiple signatures with > one revocation by using multiple subpackets. > > Not, it should be pointed out, that many (any?) implementations > support Signature Targets yet. But the semantics are there. Uhm ok,.. so how does an implementation figure out which certificate is revoked by a revocation signature? Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIZHwL098897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:35:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIZHES098896; Fri, 30 Jan 2009 11:35:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UIZ62o098887 for ; Fri, 30 Jan 2009 11:35:17 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 56019 invoked from network); 30 Jan 2009 18:35:05 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 30 Jan 2009 18:35:05 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <498348F9.5030708@fifthhorseman.net> Date: Fri, 30 Jan 2009 13:37:45 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Peter Thomas CC: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> In-Reply-To: <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig00D63C42AC6D682BB8B7BF9C" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig00D63C42AC6D682BB8B7BF9C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 01:15 PM, Peter Thomas wrote: > But by the way: This would be another thing that one could think of in > future revisions of the RFC. > Policy-URI on self-signatures: > 0x10-0x13: The policy that is used for signing, with the corresponding = UserID. > 0x1F: The global policy for the whole key, when signing anything > (especially other keys/UIDs) with that key > 0x18: The policy used when making signatures with this key >=20 > Policy-URI on other signatures: > The policy under which this signature was issued. (Just like it is > interpreted now) I'd disagree with such a change, if only because it seems to force a semantic change on signatures that may already be in existence. It'd be weird if i made a signature that i knew meant "foo", and then came back later to find that according to the new RFC, i'd actually stated "bar". If you want to propose a new subpacket with the above semantics (perhaps one that would be invalid on anything but a self-sig), i wouldn't be opposed, though i'm not sure how useful it would be. And how would you interpret the following situation: Key A has a self-sig with policy X Key A signs B's key,uid pair and includes a with policy-URI Y. which policy governs the A's signature on B? why? --dkg --------------enig00D63C42AC6D682BB8B7BF9C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYNI/szS7ZTSFznpAQJudw/9GTj28ll3kG2iNOhUG0JGizEVXycMxbBP AgSXNdAfeZow7AUCGFa7dVT9E1YHkzuW2xYWs9CWnP5ZbN/Nrez1/7VP+bDVsSyq Z5rkd5t0S3hfn0p9Wl8RnjaBWwrb6rrg93wWJyj1QFL+sGzp0iz8IoI5PQ7kuMzC 7ebmIHb461uuxvu873GUsiRTUv3bRKLMJfwGSi+R2Iizh45hdJhpg5X5F6WJfdCx pJVnbC7yhMTkyCFQHa+cYljAAwEyrfyxRRlMOpnmKcg7rqRyNAgOxarA2wzGBQWq xZ7lfrkN2tH6ID4O8yaUlKTGJOf/6uS7mxdqELn8S1r0Ks/XihVXCiXIqy+Kdn7A /LNLc/CfT7IsxptsWiNnw6DHM2s2AnQBYD6sx0jCPC3YviQiM2162I8xSLHwxbI/ ipqyc0SlGIaUgCM24ByR6HioMUCiB9k0bzKeXhshhmyGAbDMS2PzKyFQYtNoDDw+ DKWlPb5IokRbqVK+WzQtElc01e7QIDmhK8UCMvpqp0z73+xqQkgxgLOKFOCxvan7 8/NTOKDCvqpTu4ry4G9I8xAdePJr6+uYhN22KHCxGeey5/ky5fiYmH7UlD76DiNh iDR0RYrldAkwEki5lx9opbCDlI+JSnk7lJRfiQkMp08sAhZxoIbJza+N4TDdZWot p4/glC78op8= =F6Lb -----END PGP SIGNATURE----- --------------enig00D63C42AC6D682BB8B7BF9C-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIP1cP098404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:25:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIP163098403; Fri, 30 Jan 2009 11:25:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIOmwP098387 for ; Fri, 30 Jan 2009 11:24:59 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so365365fxm.10 for ; Fri, 30 Jan 2009 10:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=H5YTxjSH+ojIuxYFDQwRUf2co3UCdwuXKO+dqP04Iy4=; b=q5CvP7H8e5y61l9hqGIcdpOmUW+YDXL283mHEyESuz2vR8yoMKuDuKH30MjlrbZSlK vwTpHJ+Ifxv7UdS2F/TaaS+hMVTJxKMng8EKPBbtqKziZ51NxtUIPnGcPfv5MkcFgmFp fk7xJxSZXjFl6jxKR+NFCvfV0hxl9mAZMJW2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=r8K6wsOQhuu0M0mOKhwfhumtF3Dau00+S1qInZGdNjBVbESBzuIlcmPpNBuL88DQls sgd4ApVpSTzw4yJ5VmAblFYSMxQLoXvmC9IRIUNONnvmprI9+MnKYGKmIzgWFJhDjg7c fcAWR3TIcbYGATWB41KadA6l8C9nuvQpOyghw= MIME-Version: 1.0 Received: by 10.180.204.10 with SMTP id b10mr510432bkg.201.1233339887809; Fri, 30 Jan 2009 10:24:47 -0800 (PST) In-Reply-To: <20090129205321.GB16331@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> Date: Fri, 30 Jan 2009 19:24:47 +0100 Message-ID: <9ef756150901301024i3c62a79cuc1a357bef8685d4b@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 9:53 PM, David Shaw wrote: >> 0x1F: which one would I have to use for that? A 0x20 key revocation >> signature? Or would the completely revoke the whole key. > You revoke a 0x1F with a 0x30, same as you would use to revoke a > 0x10-0x13. 0x1F is a certification. Ooops XD >> Does the whole thing make sense anyway? I mean would it be a clean or >> at least working way to force ANY implementation to use only the most >> recent self-signatures? > I suspect it wouldn't hurt, but wouldn't help much either. For > example, given this: > > Signature === January 1 > Signature === January 3 > Signature === January 5 > > it is clear that the January 5 signature is the latest and the one to > use. Given this: > > Signature === January 1 > Revocation === January 2 > Signature === January 3 > Revocation === January 4 > Signature === January 5 > > It's still clear which signature is the right one. Yes, but it's not only clear. It is the ONLY way when following the RFC. But in the example from above (I've added some information to it): Signature using MD5 === January 1 Signature using MD5 === January 3 Signature using SHA256 === January 5 and implementation could say "oh I just understand MD5 and SHA1, but not SHA256... well the MD5 from 03.01. isn't the most recent, but at leas I understand it" > I suppose if you had an implementation that insisted on using the > first signature, regardless of the date, then the revocations would > force it to look at the last signature.. but then, an implementation > that did that may have other odd semantics elsewhere. Of course... > It may conclude > that there is no signature at all (after all, the one signature it was > looking at is revoked). Well,... even better than perhaps using the "dangerous" signature from January the 1st, isn't it? >> Would it work with the mayor implementations, PGP and GnuPG? > It would work in GnuPG. Hal, Jon, would it work with PGP? And would you experts here suggest to do the whole revoke-old-self-sigs-trick in order to prevent that kind of "downgrade attacks" (and possibly other evil things) I tried to describe above? Thanks for your advice, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIFjHs098072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:15:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UIFjw1098071; Fri, 30 Jan 2009 11:15:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-bw0-f12.google.com (mail-bw0-f12.google.com [209.85.218.12]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UIFXXH098058 for ; Fri, 30 Jan 2009 11:15:44 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by bwz5 with SMTP id 5so187282bwz.10 for ; Fri, 30 Jan 2009 10:15:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=C/4EXuZ3MJdJGF41ZdS3/YOT0SYHOmjdT/0IuX3d4Ug=; b=csDQyYZ+hVbDGcP9qp7IwVZs9F2oQ+KNiSmswUk3OPXts0VVyjq06UFQgi0y9U9WH+ NZElM8JGUQF1yq3MxjRvZH3DC61dug2/p6HfSWmKEiE/fvwCnSisvakXhSWksaqyPX0h xZq67V1BSn0YLePuo5htRCQ/uubZW+GhYeToQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cC4MmgrBmhpTcDSLgrDWiJt5QqW0GW5hrPYjfpFTTxhL9bsDefyP49/cjJSPF2ZePh /YNMQwsGpATSFpzJaVkNiH5rdgbM8LjU3YX4LtugZ/mbOOD995gG4ilpaV5zYm2bNQKI ydwm5y72eR3Cta/kMVzouHsXMBHLft/4n8ltg= MIME-Version: 1.0 Received: by 10.181.28.15 with SMTP id f15mr509295bkj.187.1233339332435; Fri, 30 Jan 2009 10:15:32 -0800 (PST) In-Reply-To: <20090129203809.GA16331@jabberwocky.com> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <20090129203809.GA16331@jabberwocky.com> Date: Fri, 30 Jan 2009 19:15:32 +0100 Message-ID: <9ef756150901301015m306d35faw19d9b2bcd16425b5@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 9:38 PM, David Shaw wrote: > That's basically the point of the critical bit. You can think of it > as a way to force a (quasi) compatibility break. The critical bit > means "This subpacket is so important to the signature that I'd rather > you treat the whole signature is invalid than you not understand this > subpacket". Yes :-) > For example, GPG sets the critical bit on signatures that have an > expiration date set. Thus, if the signature is read by an > implementation that doesn't understand expiring signatures, the whole > signature is invalid. This was deemed better than the alternative - a > "expired" signature being treated as still usable because the > recipient implementation didn't know to ignore it. Ok that's already great,.. what do you think about the other subpackets that I've suggested for being critical in my initial post? Would you for example change gpg, that for example it issues the critical bit with the signature creation time, key expiration and key usage, too? >> But this is the point. Which have clearly defined meanings? Hast the >> policy URI a meaning on 0x18s (e.g. as the policy for signatures made >> by that subkey)? > It is the policy under which the subkey itself was certified. The > Policy URI for signatures made by that subkey would be in those > signatures. Ah, you're right ^^ I'm always messing this up. But by the way: This would be another thing that one could think of in future revisions of the RFC. Policy-URI on self-signatures: 0x10-0x13: The policy that is used for signing, with the corresponding UserID. 0x1F: The global policy for the whole key, when signing anything (especially other keys/UIDs) with that key 0x18: The policy used when making signatures with this key Policy-URI on other signatures: The policy under which this signature was issued. (Just like it is interpreted now) > Section 5.2.3.3: > > An implementation that encounters multiple self-signatures on the > same object may resolve the ambiguity in any way it sees fit, but > it is RECOMMENDED that priority be given to the most recent self- > signature. > > I suspect that most software follows this recommendation. GPG does. Of course,.. and in principle this is fine,.. but I'd even go so far to change this recommendation to a MUST. > The problem here is that what one use case requires as security > critical may not be what another one does. The critical bit is a more > flexible way for an implementation to require which subpackets are > understood. Hm, ok you're the expert :-) I just thought that the subpackets from my initial posting would be critical in ANY case ^^ Best wishes, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UI5FA8097518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 11:05:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UI5F5Z097517; Fri, 30 Jan 2009 11:05:15 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UI530S097507 for ; Fri, 30 Jan 2009 11:05:14 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fk-out-0910.google.com with SMTP id 19so559934fkr.10 for ; Fri, 30 Jan 2009 10:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=J5To2d0GXmlw7Jc2/1fN10oraqlznP5KZoD+U+rdl8s=; b=QW7h/c0HSH1MME99xH6wrJTHGW0VntOLHx6n1HaJCv2MwZ86Xjtr4MjZLjo1oC8Kud EJ4cwQe0vE5b6CcTOkKkfRe7wgB8hqPsghojOC1jdHaK9mSnf4yUT6P+vFqiRQe4DRQl RBjuaEuAoCKzCvOVL5C0/bPqG6odnH1pDMfPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=k6OXNcllaNEMnqfid1AfaAiTjC3bY2rkbAdF6r/lud4aJxmzsDWTTA1OBaPuUVFAtW eWrXztTaXHiRjHFE7lVXKLlx7Zemxz23/JLj9HCEQOQff1CZ/9aYUEUc0Z3wEZNNeyVt 7gkomPm4PkHhMBJv3x3JOgq0AFiqSZCmBorsQ= MIME-Version: 1.0 Received: by 10.181.199.16 with SMTP id b16mr509791bkq.142.1233338702872; Fri, 30 Jan 2009 10:05:02 -0800 (PST) In-Reply-To: <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> Date: Fri, 30 Jan 2009 19:05:02 +0100 Message-ID: <9ef756150901301005h1886834ap61345ee302831bc8@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: OpenPGP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 8:37 PM, Jon Callas wrote: > On the contrary, I think you should start discussing things here and > start writing drafts. I don't believe I'm technically skilled enough for doing this. And I must admit that I've borrowed some (of course not all) ideas here from some threads I've found on the gnupg mailing lists. I've already contacted the author (Christoph Mitterer) of that threads and I hope he'll have a look at the currently ongoing discussion. >>> You >>> might also want to require the critical bit to be set on those >>> packets, >>> although that will impair interoperability. >> What do you mean with this? Require it by the RFC? > No, the critical bit means that you want an operation to be 100% > correct or to fail. If there is any doubt in anyone's mind, you want > the system to halt with an unrecoverable error. Would you guys here, I mean Hal/Jon from PGP and David from gnupg suggest, that I set critical bits on the subpackets I listed before? Would your implementations (PGP/GnuPG) support this? Would you (and of course the other list members) support the idea of having the security critical subpackets REQUIRED per default by a future RFC? > Hal points out that this will mar interoperability. We'll but that was the idea. An implementation that does not support e.g. signature expiration should better fail at all. >> What was the reason that the key expiration time was taken out of the >> key itself (I think it was there before?)? > Because in PGP 3, a number of attributes were moved to the self-sigs > with the thought that you might have a key with different user ids and > different features. For example, I might have a user id in which a > cipher is allowed, and one in which it is not. You might also want to > have different expirations on those user ids. Well my idea is the following: We have the key expiration time, we have the User ID self-signatures and we have signature expiration. - If a user wants to just expire the key with one specific User ID, he could either revoke the corresponding self-signature or set an signature expiration time on it. He could even re-set it later by creating a new self-signature. - If all self-signatures (0x10-0x13 and 0x1F) are expired or revoked it's basically the same as if the whole key expired/revoked. So I think the key expiration flags somehow doubles that functionality and to me it made more sense when it was part of the key itself and thus kind of a promise that could not be changed later (e.g. by issuing a new self-signature) >> Well this would be great,.. I mean the current MAIN implementations of >> OpenPGP are probably GnuPG and PGP. I think David and Werner who >> represent GnuPG are reading this list and you, are you still at PGP >> Corporation? > Yes. Great, so you can comment whether you'd support such changes as I propose for the criticality of signature subpackets. Cheers, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UHeAtt096105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 10:40:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UHeAvD096103; Fri, 30 Jan 2009 10:40:10 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UHdxgq096083 for ; Fri, 30 Jan 2009 10:40:10 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 4091 invoked from network); 30 Jan 2009 17:39:57 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 30 Jan 2009 17:39:57 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49833C0E.8010605@fifthhorseman.net> Date: Fri, 30 Jan 2009 12:42:38 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Ideas on new user attribute types and image formats References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> <20090130162347.GB19809@jabberwocky.com> In-Reply-To: <20090130162347.GB19809@jabberwocky.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CD7643A5DEA3431196DB021" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6CD7643A5DEA3431196DB021 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/30/2009 11:23 AM, David Shaw wrote: > We need (in the abstract) a way to store a picture in an OpenPGP user > ID, and we have that now. What does adding a second way to store that > picture buy us that we don't have already? hpng supports features that jpeg doesn't, including at least: * indexed colormaps * alpha-channel transparency Both of these are useful features in some not uncommon circumstances (e.g. logos and "hackergotchi"/floating-head images that discard background/non-identity information). I'm not suggesting that OpenPGP is worthless without PNG, of course. But it would be useful to support it. --dkg --------------enig6CD7643A5DEA3431196DB021 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYM8E8zS7ZTSFznpAQJCURAApmgXUi17aM5FTZqK8bh7GaSk1Inw0uu3 nM332UPCBnSLPtfUizWvI6/ntLC4QaulwUTLFDqCwS0Puo+w8SFzipVuPKeG2xEY r10cgU0e8cml5w24giYpv5hNvy/ilrJOLN8AT3i1O2Ouq+3T2WRn+6uIrcpaYIyp 3vceNwzdBqiUtnUgqQuH4qm43xqYvaUedkYf3w4oSUOo+17yaIYCIEBvW2anLVqu FwEs2KeK9SJcuf0ttKsAKo2kQOgSL6ESUHxy7YqDghFO3U1XQtCHbem6PZm1zorl mHuPHfH2TsReKyJmvgD1WdVWqpiZXhiTxvoYFwCWEC/XENq8QgQgLJ57LtBAAOq5 40mYy0tgyT5/PeGfLC8w4jJw+v8u9VMuJQi1S/8D7oTdtNiJirZgpyN+bc2MbDwv U6bI30+2/9Z22qyIenaJNE+MzMPdnm4r6P7jePpGJem1pk5f295JFI4duFXNsy5q WThofsI8yg56m8xvtSg6ilG00TXwSjtLV+uR52AkW5qFD9EgskesUoZLacTFLhOf A3W4KAHWqjAUbHDpBey/ZTaGxyBqJ3NYAU/m3ukepuwsK7r1v8SIm8xgEvxWDhv5 5UHEs6AkK09ZbUf04YNYM3GiRVMBAWjxuP4GXLiwf55wYucikGd5VziyoX3BjLdX skTcpBLYVwc= =lyhD -----END PGP SIGNATURE----- --------------enig6CD7643A5DEA3431196DB021-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGNnQr091609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UGNnEC091608; Fri, 30 Jan 2009 09:23:49 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UGNmad091602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 09:23:49 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0UGNlVf008723 for ; Fri, 30 Jan 2009 11:23:47 -0500 Date: Fri, 30 Jan 2009 11:23:47 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Ideas on new user attribute types and image formats Message-ID: <20090130162347.GB19809@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> <49831B83.7060704@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49831B83.7060704@fifthhorseman.net> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 10:23:47AM -0500, Daniel Kahn Gillmor wrote: > On 01/29/2009 01:23 PM, Peter Thomas wrote: > > 1) PNG (ISO 15948, RFC 2083) > > I fully agree that we should be supporting PNG here. That's long > overdue, and you don't have to do lossless compression in png, iiuc. We need (in the abstract) a way to store a picture in an OpenPGP user ID, and we have that now. What does adding a second way to store that picture buy us that we don't have already? I'm not really for or against PNG in OpenPGP, but I don't yet see the point here. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UG3feN090644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 09:03:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UG3fNt090643; Fri, 30 Jan 2009 09:03:41 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UG3UQ4090612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 30 Jan 2009 09:03:41 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0UG3TKk008614 for ; Fri, 30 Jan 2009 11:03:29 -0500 Date: Fri, 30 Jan 2009 11:03:29 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090130160329.GA19809@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49831D14.4030804@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49831D14.4030804@fifthhorseman.net> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jan 30, 2009 at 10:30:28AM -0500, Daniel Kahn Gillmor wrote: > On 01/29/2009 03:53 PM, David Shaw wrote: > > I suppose if you had an implementation that insisted on using the > > first signature, regardless of the date, then the revocations would > > force it to look at the last signature.. but then, an implementation > > that did that may have other odd semantics elsewhere. It may conclude > > that there is no signature at all (after all, the one signature it was > > looking at is revoked). > > This would be a particularly odd implementation because "the first > signature regardless of date" has no meaning in OpenPGP, iiuc. There's > nothing stopping a re-ordering of signature packets, and a certificate > that looks like this: Yes, it was particularly odd. I've seen it happen, but it's broken for all the reasons you say. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UFRjtx089091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 08:27:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UFRjgd089090; Fri, 30 Jan 2009 08:27:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UFRjZ7089084 for ; Fri, 30 Jan 2009 08:27:45 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 30412 invoked from network); 30 Jan 2009 15:27:44 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay02.pair.com with SMTP; 30 Jan 2009 15:27:44 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49831D14.4030804@fifthhorseman.net> Date: Fri, 30 Jan 2009 10:30:28 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> In-Reply-To: <20090129205321.GB16331@jabberwocky.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0E96254D1723DA3223AF8A1" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0E96254D1723DA3223AF8A1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/29/2009 03:53 PM, David Shaw wrote: > I suppose if you had an implementation that insisted on using the > first signature, regardless of the date, then the revocations would > force it to look at the last signature.. but then, an implementation > that did that may have other odd semantics elsewhere. It may conclude > that there is no signature at all (after all, the one signature it was > looking at is revoked). This would be a particularly odd implementation because "the first signature regardless of date" has no meaning in OpenPGP, iiuc. There's nothing stopping a re-ordering of signature packets, and a certificate that looks like this: primary_key \-uid +--sigX \--sigY Is semantically equivalent to this: primary_key \-uid +--sigY \--sigX And in fact, keyservers will often have to re-order signature packets if they gather data from disparate sources. --dkg --------------enigC0E96254D1723DA3223AF8A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYMdFczS7ZTSFznpAQJY4RAAq+1NvJRyCKh3HuExp47nB13oniWt5o/+ 7cIBUtqPEirrxU88WIwXQqoHrX2pNCzf1hky6iaE9vSWf0yjGvhevHDYvvBkr99j wvLRNwuBJkVpwIRZYU44wrCJTqjtWvLmPbn9VkbJ9B90HVWbDRBw21NkYxEJV+gQ t/7JjYs6v2jZuWOQMXt8FPM0CJ3LGT+0eYLGBKfo9vg7JAmnnhEMxj3DKsW1lnHH 8tgxKPtlbBk6+PrafFvvU8aiTzxYAfRD9R3xNgTzFL+kJxTjzfG6p6PFeXqkmXAZ qFxErsl1sHGib6A1dPKBwmlvEsedWeyAyqc7BQMWr/JycecgT1WhM8MpVTGnkzg9 Bnk6tsfgUPVIIEvCNUzdscI4dnjgMjqvFed/6cjyS507rLdBz4XkyFtrZu0Fa00m 03kAdE+ItsOWUxZPofe7PtUkSY5yqm8SaBGYBh8Rk6PeBT3mOBWqf08YjEvp1qEF tv9vH0qWV3Cb64vXKuqqas7zS3kz22L1ibIugfIJUJcBPBpLSB6fSMLHExKjSMxq /ZrNGvCv/B/0Zg1LeALE9VXJTaIS0HFLEn1k8Duz82IprWWmRPsx3yzuZK0M+yXr 9IuKTUxA2jnIv61Of7Q6fpi+qRCnLmtrS7lLZ8ZaNw19Ld7ymLXluj6eK08jXHmj c7pCdwq8Qcs= =Rvx9 -----END PGP SIGNATURE----- --------------enigC0E96254D1723DA3223AF8A1-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0UFLHG9088875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 08:21:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0UFLHoT088874; Fri, 30 Jan 2009 08:21:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n0UFL5jA088865 for ; Fri, 30 Jan 2009 08:21:16 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 27421 invoked from network); 30 Jan 2009 15:21:04 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay02.pair.com with SMTP; 30 Jan 2009 15:21:04 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <49831B83.7060704@fifthhorseman.net> Date: Fri, 30 Jan 2009 10:23:47 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Peter Thomas CC: ietf-openpgp@imc.org, Duane Groth Subject: Re: Ideas on new user attribute types and image formats References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> In-Reply-To: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig135E313878988A444AA8C823" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig135E313878988A444AA8C823 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/29/2009 01:23 PM, Peter Thomas wrote: > 1) PNG (ISO 15948, RFC 2083) I fully agree that we should be supporting PNG here. That's long overdue, and you don't have to do lossless compression in png, iiuc. > 2) JPEG 2000 (ISO/IEC 15444) Given how ill-specified and implemented this is, i suggest waiting on this until it is more mature. > 3) SVG SVG can potentially contain way more than images; it can contain javascript, for example, and other semi-executable nastiness. As much as i love svg, I think it might be a can of worms best left unopened until we're prepared to seriously think through the potential security consequences. > Second, ideas for user attributes: > This is more a: "Has anybody ideas how usage of user attributes could > be extended?" than a "I have this and that proposal.", so I'd really > love to see your ideas. Duane Groth has proposed making a new User Attribute type that just maps to the possible values of the X.509 subjectAltName specification: http://open-pgp.info/wiki/index.php?title=3DStandardisation_of_OpenPGP_Ke= ys_for_Server_Purposes#New_User_Attribute_Type_--_subjectAltNames What's nice about this proposal is that it doesn't require the creation of a new registry, implementors can potentially piggyback on existing ASN.1 parsers (they wouldn't need to write their own), and the specification can cover a range of ideas automatically. --dkg --------------enig135E313878988A444AA8C823 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSYMbhMzS7ZTSFznpAQKm5BAAhHAZKYCGzOOSLHVN/JVYARPjhpotEMc8 plPwErShrTfurhfxxjAxV75mJxWcenAqFDmbIEustjZwp+vqUMvEd+v3EH7A/UPQ tmLCfEUnPOwuJ24PVBBiz6GUyzBj4wLvIMjy4dF7MkWXtymKgenc7FS1qR7FOkkK yajrEwVyvV1fRO3mmk5bxwacKX0zcIwbQGE+g0zloHbWDhe4euyfHF6icxS5gPZo 5hriY8dA23qUfhKjP3OCjfXZ8JkYWN4Bu3BrFjNGmnxYkmpq34K7RYNMRAmgUrsX LzyLxrqrtNcxyIkd+5FntVHbdInUHy9jKs0dvnL6D/PPlxslXmjMDOm7l0WlhCb/ vg8WTv2QlwxzMW5W7DNwLo3akULVpKvMwPR5ObzkYUd0/7Io8ENbGzGwoOCqI2vY v3JJaA1Nbaxk6mXH0xF1xBobMD5w2h9MeCJI8LoSDezrL9ijc2Ug1ynLx5OPtC7N iHqNU/XWf2m2QYXMe/5IEVwYZFnSwN2bknL1Y9CVe7+cWWPrz5caiA8paK3RfTBM AUVdevi1haSscYMgbyEBGVmOJPKYwStwCeDaybI0rNgXM8kRYTbyQMnVeM/5Q0ts bkR+ZmrbEHTHJttYQkHqxnbYCfyoYIzU4PNccP2FOP4aHiJuOzkjcYsa6s21Q3GF CUi0G1wDMco= =u8Ze -----END PGP SIGNATURE----- --------------enig135E313878988A444AA8C823-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U02WbY047250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 17:02:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0U02Wk2047249; Thu, 29 Jan 2009 17:02:32 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0U02KAF047219 for ; Thu, 29 Jan 2009 17:02:31 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 68D3B11A17B for ; Fri, 30 Jan 2009 01:02:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 3CB0B598099 for ; Fri, 30 Jan 2009 02:01:38 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fkMPpPuQUncc for ; Fri, 30 Jan 2009 02:01:38 +0100 (CET) Received: from [10.0.0.164] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id E5FE0598092 for ; Fri, 30 Jan 2009 02:01:37 +0100 (CET) Message-ID: <49824380.3020501@epointsystem.org> Date: Fri, 30 Jan 2009 01:02:08 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> <20090129223044.GA16884@jabberwocky.com> In-Reply-To: <20090129223044.GA16884@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig8E1FEA9E4A3B02E8F099DA30" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E1FEA9E4A3B02E8F099DA30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Shaw wrote: > It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F > signature revokes (potentially) all of them that are a) from the same > issuer (or from that issuer's designated revoker), and b) timestamped > earlier than the revocation. It cannot revoke ones that come after > it. Of course. Sorry for the sloppy wording of my email. This is what I meant= =2E > Even then there is the possibility of confusion of which signature you > intend to revoke. In those cases, you can always specify a particular > signature to revoke using the Signature Target subpacket in the > revocation. Arguably, you could even revoke multiple signatures with > one revocation by using multiple subpackets. > > Not, it should be pointed out, that many (any?) implementations > support Signature Targets yet. But the semantics are there. Thank you, this answers my question. Haven't paid attention to Signature Targets, because I haven't seen a single one in the wild. But they are, i= ndeed, truly useful and as such worth implementing as soon as OpenPGP gets used = for serious legal purposes. I might do it myself. --=20 Daniel --------------enig8E1FEA9E4A3B02E8F099DA30 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmCQ4cACgkQi+vAY9cJzcIb3ACfYFJbJZ8vyTMzSO6I6gQz+GzN HzcAn1w9kTucoQU9+i7xkvSCQr0qKOV6 =3FRq -----END PGP SIGNATURE----- --------------enig8E1FEA9E4A3B02E8F099DA30-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMUlx9043711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 15:30:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TMUl0S043710; Thu, 29 Jan 2009 15:30:47 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TMUjY7043703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2009 15:30:46 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0TMUjxW025184 for ; Thu, 29 Jan 2009 17:30:45 -0500 Date: Thu, 29 Jan 2009 17:30:45 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090129223044.GA16884@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> <49822782.5090405@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49822782.5090405@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 11:02:42PM +0100, Daniel A. Nagy wrote: > David Shaw wrote: > > You revoke a 0x1F with a 0x30, same as you would use to revoke a > > 0x10-0x13. 0x1F is a certification. > > Hold on here. What you write here obviously follows from the text of > the RFC, so I do not question it, but it does raise a semantic > question. > > Obviously, one reason for attaching certifications directly to a key > rather than to particular user IDs is to make them stick even if any > particular user ID is revoked or expires (or even all of them). So, > if I want to make a statement about a certain person rather than a > user ID (concerning, e.g., his/her trustworthiness as a certifier), > I'd attach it directly to the key. There may be several > certifications by several people saying different things about the > person. > > The question: how does one revoke one of them? A 0x30 computed > directly on the key (as the RFC specifies) revokes all of them (for > which it is a designated revoker), doesn't it? Is there no way to > revoke just one? It doesn't actually revoke all of them. A 0x30 revocation on a 0x1F signature revokes (potentially) all of them that are a) from the same issuer (or from that issuer's designated revoker), and b) timestamped earlier than the revocation. It cannot revoke ones that come after it. Even then there is the possibility of confusion of which signature you intend to revoke. In those cases, you can always specify a particular signature to revoke using the Signature Target subpacket in the revocation. Arguably, you could even revoke multiple signatures with one revocation by using multiple subpackets. Not, it should be pointed out, that many (any?) implementations support Signature Targets yet. But the semantics are there. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TM315f042609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 15:03:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TM312k042608; Thu, 29 Jan 2009 15:03:01 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TM2oLU042595 for ; Thu, 29 Jan 2009 15:03:01 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 248C231A42B for ; Thu, 29 Jan 2009 23:02:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id 9129A59809B for ; Fri, 30 Jan 2009 00:02:08 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wRQhpcuMrQ41 for ; Fri, 30 Jan 2009 00:02:08 +0100 (CET) Received: from [157.181.227.130] (dhcp130.cs.elte.hu [157.181.227.130]) by mail.agileight.com (Postfix) with ESMTP id 48D9B598099 for ; Fri, 30 Jan 2009 00:02:08 +0100 (CET) Message-ID: <49822782.5090405@epointsystem.org> Date: Thu, 29 Jan 2009 23:02:42 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> <20090129205321.GB16331@jabberwocky.com> In-Reply-To: <20090129205321.GB16331@jabberwocky.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig919D7290F134DCBE799FC8AA" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig919D7290F134DCBE799FC8AA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable David Shaw wrote: > You revoke a 0x1F with a 0x30, same as you would use to revoke a > 0x10-0x13. 0x1F is a certification. Hold on here. What you write here obviously follows from the text of the = RFC, so I do not question it, but it does raise a semantic question. Obviously, one reason for attaching certifications directly to a key rath= er than to particular user IDs is to make them stick even if any particular user = ID is revoked or expires (or even all of them). So, if I want to make a stateme= nt about a certain person rather than a user ID (concerning, e.g., his/her trustworthiness as a certifier), I'd attach it directly to the key. There= may be several certifications by several people saying different things about th= e person. The question: how does one revoke one of them? A 0x30 computed directly o= n the key (as the RFC specifies) revokes all of them (for which it is a designa= ted revoker), doesn't it? Is there no way to revoke just one? --=20 Daniel --------------enig919D7290F134DCBE799FC8AA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkmCJ4YACgkQi+vAY9cJzcIMBwCeKNqR7RxsMKdvhcIsELBs7EDm tjcAnRMqwXYcnuNvBT8c2mhw4pIMC7St =n0lV -----END PGP SIGNATURE----- --------------enig919D7290F134DCBE799FC8AA-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKrNK7040178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 13:53:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TKrNUB040177; Thu, 29 Jan 2009 13:53:23 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKrL2I040170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2009 13:53:23 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0TKrLiO024475 for ; Thu, 29 Jan 2009 15:53:21 -0500 Date: Thu, 29 Jan 2009 15:53:21 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090129205321.GB16331@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 07:42:59PM +0100, Peter Thomas wrote: > What if I'd revoke the old self-signatures to mark them clearly as > superseded and to force ANY conforming OpenPGP implementation not to > use them. > 0x10-0x13 self-sigs could be revoked with a 0x30 certification > revocation signature > 0x18 self-sigs could be revoked with a 0x28 subkey revocation signautre > 0x1F: which one would I have to use for that? A 0x20 key revocation > signature? Or would the completely revoke the whole key. You revoke a 0x1F with a 0x30, same as you would use to revoke a 0x10-0x13. 0x1F is a certification. > Does the whole thing make sense anyway? I mean would it be a clean or > at least working way to force ANY implementation to use only the most > recent self-signatures? I suspect it wouldn't hurt, but wouldn't help much either. For example, given this: Signature === January 1 Signature === January 3 Signature === January 5 it is clear that the January 5 signature is the latest and the one to use. Given this: Signature === January 1 Revocation === January 2 Signature === January 3 Revocation === January 4 Signature === January 5 It's still clear which signature is the right one. I suppose if you had an implementation that insisted on using the first signature, regardless of the date, then the revocations would force it to look at the last signature.. but then, an implementation that did that may have other odd semantics elsewhere. It may conclude that there is no signature at all (after all, the one signature it was looking at is revoked). > Would it work with the mayor implementations, PGP and GnuPG? It would work in GnuPG. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKcLhs039719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 13:38:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TKcLjw039718; Thu, 29 Jan 2009 13:38:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TKcAna039707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jan 2009 13:38:21 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with SMTP id n0TKc92W024377 for ; Thu, 29 Jan 2009 15:38:09 -0500 Date: Thu, 29 Jan 2009 15:38:09 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Series of minor questions about OpenPGP 4 Message-ID: <20090129203809.GA16331@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.18 (2008-05-17) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 29, 2009 at 06:42:22PM +0100, Peter Thomas wrote: > > I would certainly encourage you to set the critical bit on these and > > other signature subpackets that you view as critical to the security. > Unfortunately I have no idea how to do this with gnupg (my used > implementation)... perhaps David can comment on this. But even if > would do modifications to set the critical bit on them I fear > compatibility issues with other implementations. That's basically the point of the critical bit. You can think of it as a way to force a (quasi) compatibility break. The critical bit means "This subpacket is so important to the signature that I'd rather you treat the whole signature is invalid than you not understand this subpacket". For example, GPG sets the critical bit on signatures that have an expiration date set. Thus, if the signature is read by an implementation that doesn't understand expiring signatures, the whole signature is invalid. This was deemed better than the alternative - a "expired" signature being treated as still usable because the recipient implementation didn't know to ignore it. > >> c) It's nowhere clearly specified if and what meaning these supackets > >> have on the subkey binding self-signature (0x18) > > You should probably not put subpackets into such signatures which do > > not have clearly defined meanings. > But this is the point. Which have clearly defined meanings? Hast the > policy URI a meaning on 0x18s (e.g. as the policy for signatures made > by that subkey)? It is the policy under which the subkey itself was certified. The Policy URI for signatures made by that subkey would be in those signatures. > >> 3) This is probably clear for everybody, but the part on revocation > >> signatures should perhaps highlight, that all subpackets in revoked > >> signatures MUST NOT be used, e.g. imagine the key expiration time is > >> only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets > >> revoked, the key has no longer an expiration time. > > I would recommend that your software follow this principle. > Oh my mistake,... an absent key expiration time means unlimited ;-) > Anyway I think the original problem remains,.. what is the semantical > meaning e.g. when there are different key expiration time values on > (perhaps even multiple) 0x13s and a 0x1F? Section 5.2.3.3: An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self- signature. I suspect that most software follows this recommendation. GPG does. > For example I'd like to see those possible (at leas in my opinion) > security critical subpackets to be REQUIRED by an future RFC. Of > course no one can force an implementation to really adhere to the > standard, but that's always the case. The problem here is that what one use case requires as security critical may not be what another one does. The critical bit is a more flexible way for an implementation to require which subpackets are understood. David Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJbVbH037068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 12:37:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TJbV2x037067; Thu, 29 Jan 2009 12:37:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJbUlR037060 for ; Thu, 29 Jan 2009 12:37:30 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 603952E13E for ; Thu, 29 Jan 2009 11:38:21 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 46812-09 for ; Thu, 29 Jan 2009 11:38:18 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 2037E2E15B for ; Thu, 29 Jan 2009 11:38:18 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Thu, 29 Jan 2009 10:38:28 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 29 Jan 2009 10:38:28 -0800 Message-Id: <0ABC8B60-8DF3-4953-A7D9-DF33ECBD971A@callas.org> From: Jon Callas To: OpenPGP In-Reply-To: <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Series of minor questions about OpenPGP 4 Date: Thu, 29 Jan 2009 11:37:25 -0800 References: <20090128184824.E28D614F6E1@finney.org> <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > You still can say shut up and go away ;-) On the contrary, I think you should start discussing things here and start writing drafts. >> You >> might also want to require the critical bit to be set on those >> packets, >> although that will impair interoperability. > What do you mean with this? Require it by the RFC? No, the critical bit means that you want an operation to be 100% correct or to fail. If there is any doubt in anyone's mind, you want the system to halt with an unrecoverable error. Hal points out that this will mar interoperability. >>> 4) In chapter 5.2.3.3 it is explicitly allowed that the key >>> expiration >>> time is reset by a user (of course this cannot be prevented as the >>> key >>> expiration time is no longer part of the key itself). Isn't this >>> possibility comparable to revoke a revocation? >>> I mean the creators states: "This key SHOULD NOT be used after >> expiration>." for example because he thinks an RSA786 key SHOULD no >>> longer be used in 10 years. An attacker might simply revoke this >>> (implicit) revocation by issuing a new self-signature with an >>> updated >>> date. >> If the attacker got the private key. > What was the reason that the key expiration time was taken out of the > key itself (I think it was there before?)? Because in PGP 3, a number of attributes were moved to the self-sigs with the thought that you might have a key with different user ids and different features. For example, I might have a user id in which a cipher is allowed, and one in which it is not. You might also want to have different expirations on those user ids. >> > Well this would be great,.. I mean the current MAIN implementations of > OpenPGP are probably GnuPG and PGP. I think David and Werner who > represent GnuPG are reading this list and you, are you still at PGP > Corporation? Yes. > > Best wishes, > Peter > To you too! It's nice to see enthusiastic new blood. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJgfeksTedWZOD3gYRAmLQAKChmG6pgdkCdkZDIslxMEUupmLCQACgxAQj H8YuyCyhFF697rSGw40BBBQ= =+IVy -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJTB8h036547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 12:29:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TJTB9S036546; Thu, 29 Jan 2009 12:29:11 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TJSxA5036536 for ; Thu, 29 Jan 2009 12:29:10 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id F2FD22E1D6 for ; Thu, 29 Jan 2009 11:29:49 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 46802-01 for ; Thu, 29 Jan 2009 11:29:47 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 135E02E13E for ; Thu, 29 Jan 2009 11:29:47 -0800 (PST) Received: from rochoa-x300.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Thu, 29 Jan 2009 10:29:57 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 29 Jan 2009 10:29:57 -0800 Cc: ietf-openpgp@imc.org Message-Id: <7B27ABCD-D17C-4651-B7DE-9AFDC2D61AFD@callas.org> From: Jon Callas To: Peter Thomas In-Reply-To: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: Ideas on new user attribute types and image formats Date: Thu, 29 Jan 2009 11:28:53 -0800 References: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 29, 2009, at 10:23 AM, Peter Thomas wrote: > > Hi list. > > This is not an official proposal or request. I haven't read RFC2434 > yet ;-) > > Just wanted to ask about opinions and ideas for new user attribute > types and image formats. I think you understand the pros and cons well enough. My personal opinion is that there's an argument for PNG, but not much else. And so far as I know, JPEG is not encumbered by patents at all, but there are people who would like it to be, especially if it's their patent. I have no idea why you'd want to do SVG, and you seem to know anything I could say as to why not. So I'll just say that anything you put in would be a MAY, and if you put in something that no one's going to implement, you are arguably wasting your time. However: Write it up! Especially your thoughts about structured user information. The Jabber one is also good, since Jabber directly supports OpenPGP. Do it informally here first, but also start looking at how to edit up an Internet Draft. The XML tools make it a lot easier than it used to be. Oh, and you can't do birthday as a time_t. As shocking as it may sound, there are still living people who were born before 1-Jan-1970. Some of them even use computers. Jon > > > > > First perhaps the image formats as these are easier to discuss: > Of course JPEG is in principle enough and it's probably a very bad > idea to include any image type GIMP can open ;-) but I think the > following might be worth thinking about: > 1) PNG (ISO 15948, RFC 2083) > Advantages: > - just as JPEG, nearly everybody can open these image format in the > meantime (even MS IE as far as I know) > - well standardized (ISO/IETF RFC) > - "We" call our "product" OpenPGP but JPEPG is - as far as I know - > patent encumbered, but PGP is fully free. > - Is providing an alpha-channel an argument?! ;-) > - lossless compression > > Disadvantages: > - lossless compression leading to much bigger packets than with JPEG > > 2) JPEG 2000 (ISO/IEC 15444) > Advantages: > - well standardized (ISO) ... ok one could question that ^^ > - provides even better/smaller quality/image sizes than JPEG > (And I think to keep image-packets small was the main reason for > choosing JPEG) > > Disadvantages: > - no widespread support > - standard is still incomplete (at least some additional parts, but > that wouldn't hurt "us" anyway) > > 3) SVG > Probably my most adventurous suggestion ^^ > RFC 4880 say in chapter 5.12.1 that the image is not necessarily that > of the key owner. > I'm not fully sure what this means, but could it mean that an image > attribute subpacket is used to store for example an heraldic device > ("I'm the king of Belgium and I'd like to include my emblem in my key" > *G*)? > If so, SVG would be useful file format (see Wikipedia for dozens of > heraldic devices in hight quality). > > > > > Second, ideas for user attributes: > This is more a: "Has anybody ideas how usage of user attributes could > be extended?" than a "I have this and that proposal.", so I'd really > love to see your ideas. > > I personally think of the user ID packet (not the user attribute > packet) as kind of primary key (in the sense of databases). > The RFC says in chapter 5.11. that it is "intended to represent the > name and email address of the keyholder"; it doesn't say it must > (which is good in my opinion). > That way some organization, a company or university could use the User > ID like primary keys and set them to some staff or student number. > > Most people surely follow the recommendation to use name/email with > RFC 2822 style. > This also fit's with my thinking of user IDs as some kind of primary > key as the email address makes the whole thing unique. > > The user attribute packet introduced ways to better represent > properties of the key-holder. > Take my name "Peter Thomas" from just the user ID "Peter Thomas" > you cannot definitely say whether "Peter" > or "Thomas" is the first- or family-name. The naming schemes in other > cultures might be even "worse", just consider Arabic names > (http://en.wikipedia.org/wiki/Arabic_name). > Having attributes like: > - common name > - family names > - given names > - Kunya (Arabic) > - Nasab (Arabic) > may be something worth to implement. > > Consider the following two example: My full name would be "Peter > Marvolo Thomas" > a) My User ID only has "Peter Thomas" and my passport has the full > name "Peter Marvolo Thomas" > When another person validates my identity he can either sign it and > accept that it's missing part of my official name, or he can decline > to do so. > With the above user attributes, he could decide to just sign the > family name, but not the given names filed. > b) The example above vice versa, with full name in the user id, but > not in the passport. > > Think of similar examples with Arabic names where it is much clearer > that this would be an advantage (as for example most western > government documents simply drop parts of Arabic names). > > Other attributes that might be worth to implement: > -birthday (perhaps as UNIX time code ^^) > -birthplace/country/etc. > -other fixed body attributes like natural color of eyes and hairs > > One could even think of stuff like: > - Jabber ID > - etc. > > When you comment on this please remember that these are just ideas and > not proposals that I've thought about hours ;-) > > > Looking forward to see your comments, > Peter > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJgfWlsTedWZOD3gYRAvplAJ0UwXyEhqJzoXrnbZiCdKkqoMU6EACfbWqg Scf7WNYhYlH5TSStmsAcnho= =oBkh -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TIhCD1034458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 11:43:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TIhCOi034457; Thu, 29 Jan 2009 11:43:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TIh0Ln034446 for ; Thu, 29 Jan 2009 11:43:11 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fg-out-1718.google.com with SMTP id e12so40499fga.26 for ; Thu, 29 Jan 2009 10:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z8fPO7O1oL9o+6BcSkCYDZgeEmMFDVGsXwJKOP0ZVys=; b=QDv8L0fb9+KJT0u9JB2yfvLJX7kphS8ULU0kem1sa09QAYUAu39JCiGGwVR3PEgZS7 s2QrJMZJBTLpGxYd3USGvWJ4j4os0eKiJ+XsA33gAZk5waeRaPNumV8uk7M8U52IkLXG U+oksQSrHX2zs7d4Kz4Lc8uEXFSuO5RpDCK6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xVjpjUWRwd3NJ1QzOD79jJ93fbQqaGf2S9Feqlpgv3ZR/YA11+s84l7bOO78IYMA1m LZ47T+91px5ldKl5kT0AyLoZEuaG3vfyc/5i2BBAzrbWiplKz/W8SGNb3TeO9cdsogVo PV69CKdB5SgfYbYuae6a4NJLSN7mCTXZ9jg3I= MIME-Version: 1.0 Received: by 10.181.158.16 with SMTP id k16mr105919bko.208.1233254579308; Thu, 29 Jan 2009 10:42:59 -0800 (PST) In-Reply-To: <20090128184824.E28D614F6E1@finney.org> References: <20090128184824.E28D614F6E1@finney.org> Date: Thu, 29 Jan 2009 19:42:59 +0100 Message-ID: <9ef756150901291042q4df30e9bifa0a7c95cc475a4d@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: Hal Finney , David Shaw Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One probably stupid idea on this *G* On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" wrote: >> 5) Chapter 5.2.3.3. also says what should happen when multiple >> self-signatures are encountered by an implementation. >> Wouldn't it be more secure to require that ONLY the most recent self >> signature of a given type (per primary key in the case of 0x1F, per >> User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) >> may be used and if that one could not be parsed (e.g. because of >> unknown subpackets with the critical bit set) no self-signature MUST >> be considered as valid? > I would encourage you to consider this design concept in your software. I thought about how this "issue" could be solved with the current means of the standard. I mean how can I secure that only the most recent self-signature (no matter whether 0x10-0x13, 0x1F or 0x18) is used by ANY conforming implementation. Perhaps this is really stupid, so better sit down ;-) What if I'd revoke the old self-signatures to mark them clearly as superseded and to force ANY conforming OpenPGP implementation not to use them. 0x10-0x13 self-sigs could be revoked with a 0x30 certification revocation signature 0x18 self-sigs could be revoked with a 0x28 subkey revocation signautre 0x1F: which one would I have to use for that? A 0x20 key revocation signature? Or would the completely revoke the whole key. What would be the most fitting reasons for revocation? For 0x10-0x13 probably 32 (user id information no longer valid), but for the others? Or should one use 0 (no reason specified). Does the whole thing make sense anyway? I mean would it be a clean or at least working way to force ANY implementation to use only the most recent self-signatures? Would it work with the mayor implementations, PGP and GnuPG? Lots of thanks for your comments and ideas, Peter :-) *who is now going home* Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TINH0Y033137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 11:23:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0TINHU2033136; Thu, 29 Jan 2009 11:23:17 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0TIN5uS033128 for ; Thu, 29 Jan 2009 11:23:16 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fg-out-1718.google.com with SMTP id e12so34945fga.26 for ; Thu, 29 Jan 2009 10:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=HsNbnf3/ZWPC7iS5U40PHXSjDTCokMiw43gK0piomhA=; b=HC9T6zBLGgRPCDyqLcda4o9XeVTKIe2dECyksxbFGRfdhUUga6A8EfmP9aFvNChp4b GxWPE98XttNhe49LlGCKwgFirS2BGqIImRRiU2Q1mrCgVTjx7l6fyW1EOHtNaBHyDdD8 6HX4FLGSCh87c8MTizJrdVNYOaruK2G/7zxmk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=EXW2PmUveNAvAHF2SC6Hrei3sjA0nwC7r0tNkr/zcRmm4pCRn6sMkc7i5sAYR14GRJ t4EIenwQBhTuDIxpNIXWzTsgJ66OHtIuko7RlSQRICDs+ZP7ZTPWa2myJk5ZjDWsBaWt uKNTef/+o+z3wmqJOB2tjMK2QpOC5jjBW7iAg= MIME-Version: 1.0 Received: by 10.181.28.15 with SMTP id f15mr111264bkj.75.1233253384691; Thu, 29 Jan 2009 10:23:04 -0800 (PST) Date: Thu, 29 Jan 2009 19:23:04 +0100 Message-ID: <9ef756150901291023u6ea04839iaad8a85060a4b8ce@mail.gmail.com> Subject: Ideas on new user attribute types and image formats From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi list. This is not an official proposal or request. I haven't read RFC2434 yet ;-) Just wanted to ask about opinions and ideas for new user attribute types and image formats. First perhaps the image formats as these are easier to discuss: Of course JPEG is in principle enough and it's probably a very bad idea to include any image type GIMP can open ;-) but I think the following might be worth thinking about: 1) PNG (ISO 15948, RFC 2083) Advantages: - just as JPEG, nearly everybody can open these image format in the meantime (even MS IE as far as I know) - well standardized (ISO/IETF RFC) - "We" call our "product" OpenPGP but JPEPG is - as far as I know - patent encumbered, but PGP is fully free. - Is providing an alpha-channel an argument?! ;-) - lossless compression Disadvantages: - lossless compression leading to much bigger packets than with JPEG 2) JPEG 2000 (ISO/IEC 15444) Advantages: - well standardized (ISO) ... ok one could question that ^^ - provides even better/smaller quality/image sizes than JPEG (And I think to keep image-packets small was the main reason for choosing JPEG) Disadvantages: - no widespread support - standard is still incomplete (at least some additional parts, but that wouldn't hurt "us" anyway) 3) SVG Probably my most adventurous suggestion ^^ RFC 4880 say in chapter 5.12.1 that the image is not necessarily that of the key owner. I'm not fully sure what this means, but could it mean that an image attribute subpacket is used to store for example an heraldic device ("I'm the king of Belgium and I'd like to include my emblem in my key" *G*)? If so, SVG would be useful file format (see Wikipedia for dozens of heraldic devices in hight quality). Second, ideas for user attributes: This is more a: "Has anybody ideas how usage of user attributes could be extended?" than a "I have this and that proposal.", so I'd really love to see your ideas. I personally think of the user ID packet (not the user attribute packet) as kind of primary key (in the sense of databases). The RFC says in chapter 5.11. that it is "intended to represent the name and email address of the keyholder"; it doesn't say it must (which is good in my opinion). That way some organization, a company or university could use the User ID like primary keys and set them to some staff or student number. Most people surely follow the recommendation to use name/email with RFC 2822 style. This also fit's with my thinking of user IDs as some kind of primary key as the email address makes the whole thing unique. The user attribute packet introduced ways to better represent properties of the key-holder. Take my name "Peter Thomas" from just the user ID "Peter Thomas" you cannot definitely say whether "Peter" or "Thomas" is the first- or family-name. The naming schemes in other cultures might be even "worse", just consider Arabic names (http://en.wikipedia.org/wiki/Arabic_name). Having attributes like: - common name - family names - given names - Kunya (Arabic) - Nasab (Arabic) may be something worth to implement. Consider the following two example: My full name would be "Peter Marvolo Thomas" a) My User ID only has "Peter Thomas" and my passport has the full name "Peter Marvolo Thomas" When another person validates my identity he can either sign it and accept that it's missing part of my official name, or he can decline to do so. With the above user attributes, he could decide to just sign the family name, but not the given names filed. b) The example above vice versa, with full name in the user id, but not in the passport. Think of similar examples with Arabic names where it is much clearer that this would be an advantage (as for example most western government documents simply drop parts of Arabic names). Other attributes that might be worth to implement: -birthday (perhaps as UNIX time code ^^) -birthplace/country/etc. -other fixed body attributes like natural color of eyes and hairs One could even think of stuff like: - Jabber ID - etc. When you comment on this please remember that these are just ideas and not proposals that I've thought about hours ;-) Looking forward to see your comments, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0THgaIk031182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 10:42:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0THgal6031181; Thu, 29 Jan 2009 10:42:36 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0THgNnS031166 for ; Thu, 29 Jan 2009 10:42:35 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by mu-out-0910.google.com with SMTP id w9so22497mue.4 for ; Thu, 29 Jan 2009 09:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/MauQVHKGqZwAiJyA/77g6Jvg4TeUY/x97vxH7p2Lfg=; b=jcbb0kMWrWvPlL+CpiOCrS6A49U8RYUHD+fvxQff5AtYSbq96M2OiSaBt24YB6rJRL Y00wnvI1Is1p2x//aa362ChegH8Hqv70Zt57LMr/MX1+nvCZDOztOitvPIPPmmXThJCV yawej7raOdZXX1cTepLz2YVTW3I/NXXHWyl8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d8ew50WoTxp8UWDQAqKrdRPEW6NMo4YxWIcgVzPXMwDnBBlmy50GN5nQckrAgZi+IX T2tmMY/gGM3mKCNYw5VVZdhbOlRquFHaY+6EQ4G0zR+BPCAILeD3tjkyrLZIvgnRga6Z 4crFGvwWCKcLZrUnoYsKtjnaUfu+nAF+dncus= MIME-Version: 1.0 Received: by 10.181.209.1 with SMTP id l1mr95381bkq.113.1233250942921; Thu, 29 Jan 2009 09:42:22 -0800 (PST) In-Reply-To: <20090128184824.E28D614F6E1@finney.org> References: <20090128184824.E28D614F6E1@finney.org> Date: Thu, 29 Jan 2009 18:42:22 +0100 Message-ID: <9ef756150901290942h65537fd9ic4eb2f067558a80b@mail.gmail.com> Subject: Re: Series of minor questions about OpenPGP 4 From: Peter Thomas To: Hal Finney Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi Hal. On Wed, Jan 28, 2009 at 7:48 PM, "Hal Finney" wrote: > I will answer your questions on the assumption that you are writing > OpenPGP compliant software. You are therefore asking about how you should > implement your software. Yes and no. I'm actually thinking about writing an OpenPGP key editor (perhaps using parts of gnupg as backend) which can do nearly everything that the RFC allows to give geeks and freaks the opportunity to try out everything which shouldn't be possible for the average user (that said I fully like the way gnupg - and probably other implementations - "guide" the user). But my discussion here is more about how could the RFC be improved. Please don't get me wrong, I don't wanna say the RFC is crap or anyone here did make wrong things or so and I'm fully aware that I'm really a newbie here. But what I see is that X.509 based PKIs which are based on a strict hierarchical trust model are spread more and more. And personally I dislike it and consider hierarchical trust models inferior to what OpenPGP allows. Most governments fully set on X.509 based PKIs and don't consider or even support OpenPGP and even most technical standards or applications are only X.509 aware (see SSL/TLS, although we have RFC 5081). What it all comes down to is: I think there are places where the RFC and thus OpenPGP could be improved maybe I'm wrong but nevertheless I'll tell this list my ideas. Of course some of them would be difficult to implement or even break compatibility. I'm aware of the time that was needed for this RFC and fully respect the effort the WG put in it and I'm also aware that a new RFC won't come up tomorrow, but anyway I'd like to tell you what I think. You still can say shut up and go away ;-) > I would certainly encourage you to set the critical bit on these and > other signature subpackets that you view as critical to the security. Unfortunately I have no idea how to do this with gnupg (my used implementation)... perhaps David can comment on this. But even if would do modifications to set the critical bit on them I fear compatibility issues with other implementations. > You > might also want to require the critical bit to be set on those packets, > although that will impair interoperability. What do you mean with this? Require it by the RFC? >> c) It's nowhere clearly specified if and what meaning these supackets >> have on the subkey binding self-signature (0x18) > You should probably not put subpackets into such signatures which do > not have clearly defined meanings. But this is the point. Which have clearly defined meanings? Hast the policy URI a meaning on 0x18s (e.g. as the policy for signatures made by that subkey)? >> 3) This is probably clear for everybody, but the part on revocation >> signatures should perhaps highlight, that all subpackets in revoked >> signatures MUST NOT be used, e.g. imagine the key expiration time is >> only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets >> revoked, the key has no longer an expiration time. > I would recommend that your software follow this principle. Oh my mistake,... an absent key expiration time means unlimited ;-) Anyway I think the original problem remains,.. what is the semantical meaning e.g. when there are different key expiration time values on (perhaps even multiple) 0x13s and a 0x1F? >> 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration >> time is reset by a user (of course this cannot be prevented as the key >> expiration time is no longer part of the key itself). Isn't this >> possibility comparable to revoke a revocation? >> I mean the creators states: "This key SHOULD NOT be used after > expiration>." for example because he thinks an RSA786 key SHOULD no >> longer be used in 10 years. An attacker might simply revoke this >> (implicit) revocation by issuing a new self-signature with an updated >> date. > If the attacker got the private key. What was the reason that the key expiration time was taken out of the key itself (I think it was there before?)? > Again, there will be no new RFC, not for many years at least. You must > solve them in your software using the current RFC. If you want to ask > more specific and practically oriented questions, like, what should I > do when I see this kind of key, we can try to give you more specific > advice. Thanks again for your advices. But if you're interested in and find the time I'd like to see your comments and ideas about the "issues" themselves. Of course it's possible to find and implement a reasonable solution, which is what you suggested me in most of your comments :-) At some point the RFC says that it's a little bit "vague". In my opinion (and I really don't want to offend anybody) this is bad for a cryptologic. Everything should be exactly defined. For example I'd like to see those possible (at leas in my opinion) security critical subpackets to be REQUIRED by an future RFC. Of course no one can force an implementation to really adhere to the standard, but that's always the case. Would be nice if you and perhaps even the other authors of the RFC (David for example has give me already some very deep insight) could comment on the "issues" themselves. I promise that I don't request you to write a new RFC immediately ;-) > Maybe you can persuade David or someone else to change > his software to be more to your liking, or failing that you can write > your own to address your concerns. Well this would be great,.. I mean the current MAIN implementations of OpenPGP are probably GnuPG and PGP. I think David and Werner who represent GnuPG are reading this list and you, are you still at PGP Corporation? If some or all of you find suggestions that I made or will make worth to implement (e.g. that critical bit issues) we could put this in practice even before having (perhaps at some day) a new RFC. Thanks for allowing me to ask additional questions, I have "plenty" left ;-) But I'll start new threads for them. Best wishes, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJP3g8064984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 12:25:04 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0SJP3B8064983; Wed, 28 Jan 2009 12:25:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0SJOphU064964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Jan 2009 12:25:02 -0700 (MST) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id E28D614F6E1; Wed, 28 Jan 2009 10:48:24 -0800 (PST) To: ietf-openpgp@imc.org, p4.thomas@googlemail.com Subject: Re: Series of minor questions about OpenPGP 4 Message-Id: <20090128184824.E28D614F6E1@finney.org> Date: Wed, 28 Jan 2009 10:48:24 -0800 (PST) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello Peter - I will answer your questions on the assumption that you are writing OpenPGP compliant software. You are therefore asking about how you should implement your software. > 1) gnupg (and as far as I can see other implementations, too) don't > set the critical bit on much signature subpackets by default. The RFC > (AFAIK) doesn't demand any subpacket to be understood by applications. > Unknown subpackets should be ignored, except the critical bit is set. > Correct so far? > Now when I go through the currently defined signature subpackets, I > see several which are or at least could be critical for security and > for the correct evaluation of signatures: > 2, 3: a signature might not be valid yet, or might be expired already > 7: an attacker might manage to revoke an irrevocable signature > 9: they key is expired and the owner does not want it to be used any > longer (maybe also due to security reasons) > 12: if an implementation doesn't understand this, it might not notice, > that a key/UID is already revoked > 26: the policy may contain critical information for security (e.g. > "this key signs any applicant without validating his personal data) > 27: it might be a security issue, if a key that was marked for > certification-only (0x01) has signed some casual data > 31: required for revocation signatures and thus possibly security critical > 32: required for the signing subkey backsigs (0x19) > > I'd even consider the following as critical: > 28: the signer might want to express that a specific role/UID made the > signature, and this might be security critical depending on the policy > > Of course no one can force the user to actually read and follow these > subpackets (the policy (26) is the best example for this ^^), but > wouldn't it make sense that the RFC _REQUIRES_ these subpackets to be > understood by conforming implementations? > Just an idea, though :-) I would certainly encourage you to set the critical bit on these and other signature subpackets that you view as critical to the security. You might also want to require the critical bit to be set on those packets, although that will impair interoperability. > 2) Selfsignatures and possible ambiguities: > In an email before David told me that it's fully ok that some > signature subpackets are on 0x13 and/or 0x1F self signatures. I said > I'll come back to this; here it is. > The RFC is very clear (5.2.3.3) about which signature types may be > self-signatures, namely 0x10-0x13, 0x1F and 0x18 (I assume 0x19 is let > out, as it's made by the subkey, right?). > This chapter also says that an implementation should interpret it as > narrowly as possible. > a) That's by the way the first "problem" which _could_ lead to > secrutiy issues, as the standard doesn't define for every case what > "as narrowly as possible" mean. Of course everyone could say "just > follow the common human sense" but this is always problematic, isn't > it? ;-) In your software, you should make your own judgements about this. > b) What for example, if a 0x13 and a 0x1F have conflicting key > expiration times? Should an implementation use the time in the most > recent of the two? Should it use the information from the 0x1F, as key > expiration time is "clearly" related to the key, and not the the User > ID? Should it just use the smallest value of the two? Should it use > the value accordingly by which the key was found (if by Key ID -> use > 0x1F, if by User ID -> use 0x13). I would encourage you to make sure your software does not create keys which have this problem. If you do receive keys with this kind of inconsistency, you should decide for yourself how to interpret it. There is no one right answer for what to do with keys with this problem. > One can easily think of similar examples for other subpacket types, > and its easy to think of examples where this could lead to security > problems (Imagine a user resets the expiration time of his key to > denote that it should not longer be used. His implementation updates > only the 0x13 self-signature but not the "unlimited" in the 0x1F, made > by some other implementation. A third implementation may now choose > the "right one" or not.) I hope you will write your software not to make this mistake. > c) It's nowhere clearly specified if and what meaning these supackets > have on the subkey binding self-signature (0x18) You should probably not put subpackets into such signatures which do not have clearly defined meanings. > A solution would be, that the RFC clearly specifies which subpackets > MAY go to which self-signature, which one takes priority, and for > which the implementation is allowed to choose itself (e.g. according > to the way the key was found). That is probably not going to happen. It took us many years to come up with the latest RFC. I doubt that we would see another revision before 2012 at the earliest. > btw: The example on page 27 "If the key is located via Key ID => use > the subpacket from the primary User ID self-signature also shows the > conflict with 0x1F signatures that could arise in that case. > > 3) This is probably clear for everybody, but the part on revocation > signatures should perhaps highlight, that all subpackets in revoked > signatures MUST NOT be used, e.g. imagine the key expiration time is > only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets > revoked, the key has no longer an expiration time. I would recommend that your software follow this principle. > btw: Is it specified what happens when possibly security critical > subpackets like the expiration time or key usage are absent? > > 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration > time is reset by a user (of course this cannot be prevented as the key > expiration time is no longer part of the key itself). Isn't this > possibility comparable to revoke a revocation? > I mean the creators states: "This key SHOULD NOT be used after expiration>." for example because he thinks an RSA786 key SHOULD no > longer be used in 10 years. An attacker might simply revoke this > (implicit) revocation by issuing a new self-signature with an updated > date. If the attacker got the private key. > 5) Chapter 5.2.3.3. also says what should happen when multiple > self-signatures are encountered by an implementation. > Wouldn't it be more secure to require that ONLY the most recent self > signature of a given type (per primary key in the case of 0x1F, per > User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) > may be used and if that one could not be parsed (e.g. because of > unknown subpackets with the critical bit set) no self-signature MUST > be considered as valid? I would encourage you to consider this design concept in your software. > My idea is about this: > Imagine a very old self-signature that still uses MD5 (which is now > broken, isn't it?) and a newer (in the sense of it's signature > creation time) self-signature which uses say SHA512. Both > self-signatures specify a designated revoker (subpacket 12). > Now an implementation doesn't understand SHA512 signatures and thus > uses the older one with MD5 (as far as I understand the RFC allows to > do so). But than one is probably a forged one by an attacker which > doesn't contain the subpacket 12. > See what I mean? I think it's quite easy to create similar examples > with other subpackets involved. > > So a solution would be that the RFC requires, that always and only the > most recent self-signature is used. Again, there will be no new RFC, not for many years at least. You must solve them in your software using the current RFC. If you want to ask more specific and practically oriented questions, like, what should I do when I see this kind of key, we can try to give you more specific advice. > Ok,.. enough for now,.. but I fear that I'm still not finished :-( > Is it possible to donate a few bugs to gnupg in order to compensate > the time you spend for answering my questions? Feel free to ask more, but I think on this list, for me at least the information I can give you is limited to advice along the lines I have outlined above. Maybe you can persuade David or someone else to change his software to be more to your liking, or failing that you can write your own to address your concerns. Hal Finney Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RLsMY1003991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jan 2009 14:54:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0RLsM4g003990; Tue, 27 Jan 2009 14:54:22 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0RLsATv003980 for ; Tue, 27 Jan 2009 14:54:21 -0700 (MST) (envelope-from p4.thomas@googlemail.com) Received: by fxm13 with SMTP id 13so1830868fxm.10 for ; Tue, 27 Jan 2009 13:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=uwJBG5PYdKcSt2bwmfl4G/PIGYdYf+Xv6gWs7xeCI2k=; b=XCvMmOnpnL2y5drf+hQM3vw5ZKhemvi5RAYQM48G/v3uL+RTdh3xsC+Tpsusg/dZNO gOLJ6NCogwZjxXmVu6zUCP67S0lqb04hzJ1y3racaZKbe0qdZ+KnxFfCAoyI4JZSldCM ifF1AxEDDR1qL536USO34CQSkfye1hJ3vShes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZMn6UsThggh+K3wLkIBAPCkvQq1PDW3uRjPY5+7ri9mR+zi5Jqvar71iSWcF38X+uy TCxKbbicVvKdB0pS/gIPQbsFAldTT6zjJxaYmGO3FTKS6r+4yOC0F2CHaCR7WBarqDDe y1kPrnJ29tYD5M6SqYnhClVn17LQPlO+/47RM= MIME-Version: 1.0 Received: by 10.181.4.1 with SMTP id g1mr1708453bki.100.1233093249429; Tue, 27 Jan 2009 13:54:09 -0800 (PST) Date: Tue, 27 Jan 2009 22:54:09 +0100 Message-ID: <9ef756150901271354r48975a90qe93051006346dd07@mail.gmail.com> Subject: Series of minor questions about OpenPGP 4 From: Peter Thomas To: ietf-openpgp@imc.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello list. As you can see from the subject this is already the 4th email in a series of questions about OpenPGP (and in some cases gnupg). After the first three David Shaw, who perfectly answered my questions so far (lots of thanks again), asked me to move here, as it became more and more OpenPGP specific. For those who are interested (the previous ones also contained questions about OpenPGP itself, and some very great answers) you can find the other ones here: http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035445.html http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035458.html http://lists.gnupg.org/pipermail/gnupg-users/2009-January/035467.html This time it's all about signature subpackets: Sorry that this got longer, but I think these points are all somehow connected. So feel free to split up as you like :-) I know that these questions are more about OpenPGP itself than gnupg, but perhaps you, David, can have a look at them here, before I post it on their mailing list (don't want to look stupid there ^^ and I'm still quite new in OpenPGP's standard). 1) gnupg (and as far as I can see other implementations, too) don't set the critical bit on much signature subpackets by default. The RFC (AFAIK) doesn't demand any subpacket to be understood by applications. Unknown subpackets should be ignored, except the critical bit is set. Correct so far? Now when I go through the currently defined signature subpackets, I see several which are or at least could be critical for security and for the correct evaluation of signatures: 2, 3: a signature might not be valid yet, or might be expired already 7: an attacker might manage to revoke an irrevocable signature 9: they key is expired and the owner does not want it to be used any longer (maybe also due to security reasons) 12: if an implementation doesn't understand this, it might not notice, that a key/UID is already revoked 26: the policy may contain critical information for security (e.g. "this key signs any applicant without validating his personal data) 27: it might be a security issue, if a key that was marked for certification-only (0x01) has signed some casual data 31: required for revocation signatures and thus possibly security critical 32: required for the signing subkey backsigs (0x19) I'd even consider the following as critical: 28: the signer might want to express that a specific role/UID made the signature, and this might be security critical depending on the policy Of course no one can force the user to actually read and follow these subpackets (the policy (26) is the best example for this ^^), but wouldn't it make sense that the RFC _REQUIRES_ these subpackets to be understood by conforming implementations? Just an idea, though :-) 2) Selfsignatures and possible ambiguities: In an email before David told me that it's fully ok that some signature subpackets are on 0x13 and/or 0x1F self signatures. I said I'll come back to this; here it is. The RFC is very clear (5.2.3.3) about which signature types may be self-signatures, namely 0x10-0x13, 0x1F and 0x18 (I assume 0x19 is let out, as it's made by the subkey, right?). This chapter also says that an implementation should interpret it as narrowly as possible. a) That's by the way the first "problem" which _could_ lead to secrutiy issues, as the standard doesn't define for every case what "as narrowly as possible" mean. Of course everyone could say "just follow the common human sense" but this is always problematic, isn't it? ;-) b) What for example, if a 0x13 and a 0x1F have conflicting key expiration times? Should an implementation use the time in the most recent of the two? Should it use the information from the 0x1F, as key expiration time is "clearly" related to the key, and not the the User ID? Should it just use the smallest value of the two? Should it use the value accordingly by which the key was found (if by Key ID -> use 0x1F, if by User ID -> use 0x13). One can easily think of similar examples for other subpacket types, and its easy to think of examples where this could lead to security problems (Imagine a user resets the expiration time of his key to denote that it should not longer be used. His implementation updates only the 0x13 self-signature but not the "unlimited" in the 0x1F, made by some other implementation. A third implementation may now choose the "right one" or not.) c) It's nowhere clearly specified if and what meaning these supackets have on the subkey binding self-signature (0x18) A solution would be, that the RFC clearly specifies which subpackets MAY go to which self-signature, which one takes priority, and for which the implementation is allowed to choose itself (e.g. according to the way the key was found). btw: The example on page 27 "If the key is located via Key ID => use the subpacket from the primary User ID self-signature also shows the conflict with 0x1F signatures that could arise in that case. 3) This is probably clear for everybody, but the part on revocation signatures should perhaps highlight, that all subpackets in revoked signatures MUST NOT be used, e.g. imagine the key expiration time is only stored in an 0x1F and not in any 0x10-0x13. If that 0x1F gets revoked, the key has no longer an expiration time. btw: Is it specified what happens when possibly security critical subpackets like the expiration time or key usage are absent? 4) In chapter 5.2.3.3 it is explicitly allowed that the key expiration time is reset by a user (of course this cannot be prevented as the key expiration time is no longer part of the key itself). Isn't this possibility comparable to revoke a revocation? I mean the creators states: "This key SHOULD NOT be used after ." for example because he thinks an RSA786 key SHOULD no longer be used in 10 years. An attacker might simply revoke this (implicit) revocation by issuing a new self-signature with an updated date. 5) Chapter 5.2.3.3. also says what should happen when multiple self-signatures are encountered by an implementation. Wouldn't it be more secure to require that ONLY the most recent self signature of a given type (per primary key in the case of 0x1F, per User ID in the case of 0x10-0x13 and per subkey in the case of 0x18) may be used and if that one could not be parsed (e.g. because of unknown subpackets with the critical bit set) no self-signature MUST be considered as valid? My idea is about this: Imagine a very old self-signature that still uses MD5 (which is now broken, isn't it?) and a newer (in the sense of it's signature creation time) self-signature which uses say SHA512. Both self-signatures specify a designated revoker (subpacket 12). Now an implementation doesn't understand SHA512 signatures and thus uses the older one with MD5 (as far as I understand the RFC allows to do so). But than one is probably a forged one by an attacker which doesn't contain the subpacket 12. See what I mean? I think it's quite easy to create similar examples with other subpackets involved. So a solution would be that the RFC requires, that always and only the most recent self-signature is used. Ok,.. enough for now,.. but I fear that I'm still not finished :-( Is it possible to donate a few bugs to gnupg in order to compensate the time you spend for answering my questions? Cheerio, Peter Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DBUiTb081619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2009 04:30:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0DBUinV081618; Tue, 13 Jan 2009 04:30:44 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0DBUUYT081607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2009 04:30:42 -0700 (MST) (envelope-from ben@links.org) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AD45C33C21; Tue, 13 Jan 2009 11:32:02 +0000 (GMT) Message-ID: <496C7B5D.7010908@links.org> Date: Tue, 13 Jan 2009 11:30:37 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Jon Callas CC: Daniel Kahn Gillmor , IETF OpenPGP Working Group , Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> <4967E8D7.6000505@links.org> <40B5334D-6A89-4121-98AA-04654DE91C86@callas.org> In-Reply-To: <40B5334D-6A89-4121-98AA-04654DE91C86@callas.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote: > >> Jon Callas wrote: >>> (Let me put on my hash-designer's hat for a moment. In Skein, we >>> created a one-pass MAC construction that can replace HMAC. It also >>> has >>> a proof of security. >> I wish people would stop saying that things have "a proof of >> security". >> Rot13 has a proof of security, but I don't want to use it. You need to >> state what security properties you have proved. > > If we're going to get picky, Rot-13 is not a cipher, it's a code. So what? > It > has similar security properies to ASCII, which is a related code. But > you're right -- on another list I'm on, there was someone who made the > comment that there's no theoretically perfect cryptography. I almost > replied that the Caesar cipher (which is ROT-N) has perfect security, > just an inadequate key space. > > Nonetheless, you're right. Many people including me sneer at security > proofs. Then why mention them? > The list of things that have had proofs of security and then > fallen over is large. There are plenty of proofs of security that have > some people raise an eyebrow. For example, we say that HMAC is secure > on today's slightly dodgy hash functions because of a proof of > security, but that proof relies on properties of the hash function > we're not sure they have. (Niels Ferguson was the first person I know > to bring this up, and for the most part, we all whistle as we walk by > his observations.) > > I think that security proofs are fundamentally lacking in basic > foundations. There's a sense in which you can start with the Peano > postulates for arithmetic and end up with double entry bookkeeping. We > can't do anything like that in security, and it's a huge lack. > > Nonetheless, it's better to have a proof than not to have one. If the proof proves something useful, then indeed it is better. But once more, saying "it has a security proof" provides no useful information. > And I > didn't want to turn this into a Skein discussion, I was making the > aside that there are people looking at verification constructions that > have properties programmers like, and I know this because I've worked > on one. > > Go read the Skein paper. It's at . I think > we've addressed your comments, because we feel the same way. I have read the Skein paper. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0D6oT9t064670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 23:50:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0D6oTkF064669; Mon, 12 Jan 2009 23:50:29 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0D6oIM0064659 for ; Mon, 12 Jan 2009 23:50:29 -0700 (MST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 12BBF19A6C for ; Tue, 13 Jan 2009 19:50:17 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqwP3V-CJ321 for ; Tue, 13 Jan 2009 19:50:16 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 0039219AB3 for ; Tue, 13 Jan 2009 19:50:11 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 801AA1AE4003 for ; Tue, 13 Jan 2009 19:50:10 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1LMd6I-0007Fr-CP for ietf-openpgp@imc.org; Tue, 13 Jan 2009 19:50:10 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org Subject: Re: A review of hash function brittleness in OpenPGP Message-Id: Date: Tue, 13 Jan 2009 19:50:10 +1300 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie writes: >Jon Callas wrote: >> (Let me put on my hash-designer's hat for a moment. In Skein, we >> created a one-pass MAC construction that can replace HMAC. It also has >> a proof of security. > >I wish people would stop saying that things have "a proof of security". Rot13 >has a proof of security, but I don't want to use it. You need to state what >security properties you have proved. On the subject of provable security, I've just been reading a paper that provides a rigorous proof that a particular security mechanism is secure (under appropriate assumptions regarding the cryptographic functions used). Unfortunately this is a mechanism that's a slight variant of "click-OK-to- continue", which means that it's close to worthless in practice (this result both anecdotally and from a number of HCI papers that have evaluated it). So this would be a prime example of a rigorous provably-secure crypto mechanism that thirty seconds of googling or a beer's worth of analysis would show doesn't actually work. (I haven't mentioned the paper name because I'm not trying to attack the author, just using it as a nice example of a provably secure but practically insecure mechanism, I can provide details in private email if anyone really wants to know). Peter. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BH4J4L056382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Jan 2009 10:04:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0BH4Jwn056381; Sun, 11 Jan 2009 10:04:19 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0BH45Gk056368 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sun, 11 Jan 2009 10:04:18 -0700 (MST) (envelope-from fw@deneb.enyo.de) Received: from deneb.vpn.enyo.de ([212.9.189.177] helo=deneb.enyo.de) by mail.enyo.de with esmtp id 1LM3jH-0007yw-D5; Sun, 11 Jan 2009 18:04:03 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.69) (envelope-from ) id 1LM3jG-0006vJ-R0; Sun, 11 Jan 2009 18:04:02 +0100 From: Florian Weimer To: Daniel Kahn Gillmor Cc: IETF OpenPGP Working Group Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> Date: Sun, 11 Jan 2009 18:04:02 +0100 In-Reply-To: <49664D21.50403@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 08 Jan 2009 13:59:45 -0500") Message-ID: <87sknp22rh.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Daniel Kahn Gillmor: > Also, it's quite likely that i've missed things in my reading of the > spec. If anyone sees any other problematic areas, it would be great to > air them as soon as possible. There's the issue of V3 keys. If packet formats are changed once again, it could make sense to incorporate random blobs near the start of the packets, so that an attacker cannot predict the internal state of the hash function when a signature is created. OpenPGP does not need the convergent property of hash functions. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ALujgG007107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jan 2009 14:56:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0ALuj2F007106; Sat, 10 Jan 2009 14:56:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ALuXnD007094 for ; Sat, 10 Jan 2009 14:56:43 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id 619DE2E215 for ; Sat, 10 Jan 2009 13:57:00 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 48622-06 for ; Sat, 10 Jan 2009 13:56:55 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 6194E2E0D5 for ; Sat, 10 Jan 2009 13:56:55 -0800 (PST) Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Sat, 10 Jan 2009 12:57:28 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Sat, 10 Jan 2009 12:57:28 -0800 Cc: Daniel Kahn Gillmor , IETF OpenPGP Working Group , Monkeysphere Developers Message-Id: <40B5334D-6A89-4121-98AA-04654DE91C86@callas.org> From: Jon Callas To: Ben Laurie In-Reply-To: <4967E8D7.6000505@links.org> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: A review of hash function brittleness in OpenPGP Date: Sat, 10 Jan 2009 13:56:24 -0800 References: <49664D21.50403@fifthhorseman.net> <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> <4967E8D7.6000505@links.org> X-Mailer: Apple Mail (2.929.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 9, 2009, at 4:16 PM, Ben Laurie wrote: > > Jon Callas wrote: >> (Let me put on my hash-designer's hat for a moment. In Skein, we >> created a one-pass MAC construction that can replace HMAC. It also >> has >> a proof of security. > > I wish people would stop saying that things have "a proof of > security". > Rot13 has a proof of security, but I don't want to use it. You need to > state what security properties you have proved. If we're going to get picky, Rot-13 is not a cipher, it's a code. It has similar security properies to ASCII, which is a related code. But you're right -- on another list I'm on, there was someone who made the comment that there's no theoretically perfect cryptography. I almost replied that the Caesar cipher (which is ROT-N) has perfect security, just an inadequate key space. Nonetheless, you're right. Many people including me sneer at security proofs. The list of things that have had proofs of security and then fallen over is large. There are plenty of proofs of security that have some people raise an eyebrow. For example, we say that HMAC is secure on today's slightly dodgy hash functions because of a proof of security, but that proof relies on properties of the hash function we're not sure they have. (Niels Ferguson was the first person I know to bring this up, and for the most part, we all whistle as we walk by his observations.) I think that security proofs are fundamentally lacking in basic foundations. There's a sense in which you can start with the Peano postulates for arithmetic and end up with double entry bookkeeping. We can't do anything like that in security, and it's a huge lack. Nonetheless, it's better to have a proof than not to have one. And I didn't want to turn this into a Skein discussion, I was making the aside that there are people looking at verification constructions that have properties programmers like, and I know this because I've worked on one. Go read the Skein paper. It's at . I think we've addressed your comments, because we feel the same way. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJaQu4sTedWZOD3gYRAik5AKDB0wYRnOll/Wpj0FJF9AhFMN1rfwCgkyfP 5AMtf+fg4q4y1m0Iu+h/7WA= =REWI -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0A0GVvn051307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 17:16:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0A0GVbo051306; Fri, 9 Jan 2009 17:16:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0A0GJR8051296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2009 17:16:31 -0700 (MST) (envelope-from ben@links.org) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 820F733C1E; Sat, 10 Jan 2009 00:17:52 +0000 (GMT) Message-ID: <4967E8D7.6000505@links.org> Date: Sat, 10 Jan 2009 00:16:23 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Jon Callas CC: Daniel Kahn Gillmor , IETF OpenPGP Working Group , Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> In-Reply-To: <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > (Let me put on my hash-designer's hat for a moment. In Skein, we > created a one-pass MAC construction that can replace HMAC. It also has > a proof of security. I wish people would stop saying that things have "a proof of security". Rot13 has a proof of security, but I don't want to use it. You need to state what security properties you have proved. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09NSQbV048916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 16:28:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09NSQKS048915; Fri, 9 Jan 2009 16:28:26 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09NSEAe048909 for ; Fri, 9 Jan 2009 16:28:24 -0700 (MST) (envelope-from jon@callas.org) Received: from localhost (localhost [127.0.0.1]) by merrymeet.com (Postfix) with ESMTP id D02832E0DF for ; Fri, 9 Jan 2009 15:28:40 -0800 (PST) Received: from merrymeet.com ([127.0.0.1]) by localhost (host.domain.tld [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 13602-08 for ; Fri, 9 Jan 2009 15:28:33 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTPA id 868952E0C9 for ; Fri, 9 Jan 2009 15:28:33 -0800 (PST) Received: from [192.168.2.91] ([64.1.215.244]) by keys.merrymeet.com (PGP Universal service); Fri, 09 Jan 2009 14:29:07 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 09 Jan 2009 14:29:07 -0800 Cc: IETF OpenPGP Working Group , Monkeysphere Developers Message-Id: <1DE80143-9BD3-4369-BFD4-69AE591FD25C@callas.org> From: Jon Callas To: Daniel Kahn Gillmor In-Reply-To: <49664D21.50403@fifthhorseman.net> Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: A review of hash function brittleness in OpenPGP Date: Fri, 9 Jan 2009 15:28:03 -0800 References: <49664D21.50403@fifthhorseman.net> X-Mailer: Apple Mail (2.929.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Virus-Scanned: Maia Mailguard Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 8, 2009, at 10:59 AM, Daniel Kahn Gillmor wrote: > * PGP Signed by an unknown key > > Hey folks-- > > I've been trying to evaluate RFC 4880's resistance to a hash function > compromise in light of the recent activity exploiting weaknesses > MD-5 in > That Other PKI [0]. > > I'm quite pleased with the bulk of what i've found. OpenPGP's use of > message digests is almost entirely parameterized, leaving the door > open > to forward-looking adoption of new hash algorithms and the smooth > deprecation as older ones are demonstrated to be weak. Great comments. > > > So I've been looking for places in the spec where the choice of digest > function is not parameterized. In particular, explicit and hardcoded > reliance on SHA-1 could become problematic as it is already being > deprecated. For example, reliance on SHA-1 must be eliminated in > all US > Gov't federal agencies by the end of 2010 [1]. > > Here are the concerns i've found so far: > > MDC > --- > > The modification detection packets (sections 5.13 and 5.14) explicitly > specify SHA-1, and basically acknowledge that this choice may need > to be > made more flexible in the future. Yes. Let me add an historic note. The MDC occupies an odd position. There is an obvious, easy, supported way to create an integrity- protected message: you sign it. The problem is that an unsigned message is pretty vulnerable to many problems from cut-and-paste attacks on. A number of people wanted to do something about that problem -- you want an unsigned message that has a reasonable guarantee that it arrived whole. Most people didn't see the threat. Outside this working group, almost no one did. Even inside the working group we were ambivalent about it. The solution as you see it was a compromise among us, and as a compromise it means we're all a bit ambivalent about it. In retrospect, an MAC would have been a better solution, but brought up a new set of issues like what key to use. HMACs were developed *during* the MDC discussions, and the proof of security for HMAC was done *after* we all agreed. The implementors didn't want to do an HMAC for performance reasons, especially for streaming, and again -- there was no proof of security. HMAC was this new thing that Hugo and Shai did. Since then, there are also obvious answers for KDFs as well. Despite this, it's a fine construction. It does what it was intended to do, and the known weaknesses of SHA-1 do not affect it at all. We are not relying on collision-resistance, we are relying on one- wayness. Remember, this is an *unauthenticated*, but whole message. If you want to authenticate the message, we have some nice digital signatures to offer you. Since then, there have been several attacks against the OpenPGP formats that are thwarted by the MDC. If we want to upgrade the MDC, we know how to do it, that's outlined in 4880. (Let me put on my hash-designer's hat for a moment. In Skein, we created a one-pass MAC construction that can replace HMAC. It also has a proof of security. I think it would be best to wait a while longer to see what comes out of the SHA3 competition, because it's likely that it will yield KDFs and hash-based MACs that answer all of the concerns that lead us to the present MDC compromise. They'll be fast, easy, and one-pass.) > > > Fingerprints > ------------ > > Fingerprints (section 12.2) are specified as an SHA-1 computation. > While this isn't an explicit reliance on SHA-1 for cryptographic > security (and the RFC makes it clear that there is a non-zero chance > of > fingerprint collisions), the real-world use of fingerprints as unique > identifiers for keys poses a serious risk to OpenPGP infrastructure > should SHA-1 become further compromised. There's a proposal for a new way to do fingerprints. I will do it the injustice of summarizing it: You express a fingerprint as the algorithm number, a colon, and then the hexadecimal. Truncations are handled in some obvious manner. Presently, for better or worse, a key id is the low-order 64 bits of a fingerprint, so we probably have to stick with that, despite the gnashing of teeth many of us will have. Under that proposal, one of my fingerprints (DFA7 517E 2BF4 6834 6C15 C029 B137 9D59 9383 DE06) could also be expressed as (2:DFA7 517E 2BF4 6834 6C15 C029 B137 9D59 9383 DE06) because SHA-1 has the algorithm number of 2. All we need is someone to write this up as an I-D -- or code it up preemptively. > > > Revocation keys > --------------- > > Section 5.2.3.15 defines a way that key A can allow key B to > authoritatively issue revocation signatures on A's behalf, including > key > revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and > certification revocation (sigtype 0x30). However, this mechanism > relies > on the fingerprint of B being unique. Since the fingerprint itself is > bound to SHA-1, this presents a risk to users of this feature of the > specification should SHA-1 become further compromised. > Solved by upgrading fingerprints and three more paragraphs of text. > > > As the IETF working group for OpenPGP, we probably should start > actively > working to resolve these issues so we can have infrastructure in place > well before SHA-1 is similarly compromised. Any suggestions? I'm new > to the WG, so i don't have any experience addressing concerns like > this. > > I'm particularly concerned about fingerprints, since they is used > widely > in the real world (e.g. i have my fingerprint on my business card). I > can imagine relatively straightforward technical measures to resolve > the > other concerns. > > Also, it's quite likely that i've missed things in my reading of the > spec. If anyone sees any other problematic areas, it would be great > to > air them as soon as possible. Are you volunteering to write a document? > > > Regards, > > --dkg > > [0] http://www.phreedom.org/research/rogue-ca/ > [1] http://csrc.nist.gov/groups/ST/hash/statement.html > > > * Unknown Key > * 0xD21739E9 -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFJZ8+zsTedWZOD3gYRAkutAJ0Wo0iRVUNDaF1KAw//GocHyI+PbwCgzdZ8 pWhsc6izhtYXW5MYUnkiwVA= =6Xt5 -----END PGP SIGNATURE----- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09EpLTZ020162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 07:51:21 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09EpKYM020161; Fri, 9 Jan 2009 07:51:20 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09Ep7rs020150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Jan 2009 07:51:20 -0700 (MST) (envelope-from ben@links.org) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 5669933C1F; Fri, 9 Jan 2009 14:52:40 +0000 (GMT) Message-ID: <4967645F.5090206@links.org> Date: Fri, 09 Jan 2009 14:51:11 +0000 From: Ben Laurie User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Cryptography , OpenPGP Subject: OpenPGP:SDK v0.9 released X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I thought people might be interested in this now somewhat-complete, BSD-licensed OpenPGP library... http://openpgp.nominet.org.uk/cgi-bin/trac.cgi/wiki/V0.9 -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n09047I3081015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 17:04:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n09047KT081014; Thu, 8 Jan 2009 17:04:07 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from b.relay.invitel.net (b.relay.invitel.net [62.77.203.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0903trO081002 for ; Thu, 8 Jan 2009 17:04:06 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by b.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 536F831A304; Fri, 9 Jan 2009 01:03:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id E6B00598099; Fri, 9 Jan 2009 01:03:53 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nD6e8urDQxDl; Fri, 9 Jan 2009 01:03:53 +0100 (CET) Received: from [10.0.0.164] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id A8ECA598092; Fri, 9 Jan 2009 01:03:53 +0100 (CET) Message-ID: <49669464.3030100@epointsystem.org> Date: Fri, 09 Jan 2009 01:03:48 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> <49668A41.1030402@fifthhorseman.net> In-Reply-To: <49668A41.1030402@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig38FEE6AF3B222376763F7771" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig38FEE6AF3B222376763F7771 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > The X.509 community was able to respond by further deprecating MD5 > because there was a parameterized method in place to switch to another > hash function. OpenPGP currently has this in place almost everywhere a= > hash function is used. That's good! As far as I can judge, X.509 PKI is still in the state of catastrophic fa= ilure with no obvious way out. Right now, if my browser (or yours, or anybody else's) tells me that the = site I am browsing presented a certificate issued to it by a legitimate CA, I ca= nnot be sure that this assertion is true. Rejecting all certificates with MD5 in = their signatures is not a solution (there are too many out there and replacing = them requires non-trivial cooperation between different parties; no-one can do= it acting alone). Not issuing any more MD5-based certificates is not a solut= ion (who knows how many rogue CAs are already out there?). In fact, I do not = see an easy and cheap solution out of this mess. It is a good thought-experiment to assess the consequences of an existent= ial collision attack on SHA1 such as the one we have for MD5 on OpenPGP secur= ity, considering all the places where SHA1 is wired in. I haven't checked ever= y corner of RFC4880, but I can see no catastrophic failure akin to what hap= pened to X.509 PKI. --=20 Daniel --------------enig38FEE6AF3B222376763F7771 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAklmlGkACgkQi+vAY9cJzcKt9gCgmsVFjhMTIeBEzsnHAWq1DyJN ChUAnA/j8B1AlHDeYcxBs6Qd52KZ0w6C =9C8G -----END PGP SIGNATURE----- --------------enig38FEE6AF3B222376763F7771-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08NIbk4078835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 16:18:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08NIbSs078834; Thu, 8 Jan 2009 16:18:37 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n08NIQEg078820 for ; Thu, 8 Jan 2009 16:18:36 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 60353 invoked from network); 8 Jan 2009 23:18:24 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay03.pair.com with SMTP; 8 Jan 2009 23:18:24 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49668A41.1030402@fifthhorseman.net> Date: Thu, 08 Jan 2009 18:20:33 -0500 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> In-Reply-To: <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2424D1A17CE941F82629DA06" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2424D1A17CE941F82629DA06 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 01/08/2009 05:34 PM, tz wrote: > To analyze the RFC, the internal structure of the key certificates > which are signed need to be analyzed (first there has to be a current > source for new things with MD5 anyway, I'd have to come up with two > things to be signed, a real one which will be signed and the rogue one > that has the same MD5 hash). =20 I suppose i should have been more explicit: i'm not concerned about this specific attack working against OpenPGP. It just got me to thinking about various ways that an abused hash function could cause a PKI failure, and how the community around that PKI could respond to such an attack. The X.509 community was able to respond by further deprecating MD5 because there was a parameterized method in place to switch to another hash function. OpenPGP currently has this in place almost everywhere a hash function is used. That's good! However, there are a few places where we don't have that agility, which is what i was trying to highlight. Actually doing the switch from one hash algorithm to another within a well-defined parameterized structure is a chore, but it's doable. My concern is that there are places in OpenPGP (fingerprints being the most worrisome place) where we would be unable to actually make such a transition should there be a cryptographic result rendering that hash function unusable. > I don't think there are many such things in place, but I would look if > there are any legacy signers (including prominent people with older > keys or implementations). I think after PGP5 it would be very > unlikely, but I would look for something that allowed, requested, or > forced "backward compatibility", i.e. if there are bits or something > else I can cause the hash algorithm to be MD5. Doing a test of common implementations of OpenPGP to see if they give adequate warnings based on use of deprecated algorithms would be good, though this was not intended to be the point of my initial message. For example, the following series of commands generates warnings on signature creation, but not on signature verification, afaict: echo test > test gpg --digest-algo MD5 --clearsign test gpg --verify test.asc Is this the desired behavior? Or should there be a warning during verification that the signature was based on a deprecated hash? What about during certification verification or web of trust calculations? How do other implementations approach this scenario? --dkg --------------enig2424D1A17CE941F82629DA06 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSWaKQszS7ZTSFznpAQIeow//R2qa8VORXDGsv7GqYVM6M+2/COFxo5iP YYNpybG5JVGFzQVXOX6/WXU5W+Z7B3MaHbT79aLduUFm9brQK2dU969y3Slgtq/C H5Y2ByzExGnX0ijfW3yNSaTVUTImlaTLcsMpVuJpDIX2Ho6jRLhlfe31NrXbcN2r lFpjQDWDY90FQVv8nFHszXhdVwhi9G0/SvLO/NoGa5+eDHthwxJEiLLqG3jG/w46 94A5JfWsVgL9IuYTT60/pO6/EmS+/+szRvzLGcjyxI1cTO0Wj7YzbFNb4fZmQiVg 09zPseaGKdz5CWK1mpXgTsE6lm7zbvqiOFUDJe9kFj/LPqzdSd7nUD1slyr7lYxm +ZHTfO8dvF38DtWXdFLUwak+BhqdiSGq2zV0vCC9vPJPT2bXCMGWORw3j99vi0pW TsSnlgVpehVWan38jjG9yJhCiSkQvOkotTxqcxG4t86nz1qsqxdkOgJNnk9ahLbi Jk9B8iusTI+crw8rAMP6YqVB5wFFFOKLEdzo0y3AgmgClveejA2BjJSIhzUki0Dp Xsqd5oRI8p+2n4AdfFosbPa+oasIyTSgjkWy8aKoixNfBH7ENnq8UgPGKAhIwoRl 8Wu0/l9k1J5ts0mwSJ/a+UacPnVBj/6dDi7mDm4JKvPiOE4Mqcwp20HXWu3BTnQv aJGeXCJ+fMw= =26t4 -----END PGP SIGNATURE----- --------------enig2424D1A17CE941F82629DA06-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08N4pv8078211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 16:04:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08N4puY078210; Thu, 8 Jan 2009 16:04:51 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from a.relay.invitel.net (a.relay.invitel.net [62.77.203.3]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08N4cjc078193 for ; Thu, 8 Jan 2009 16:04:49 -0700 (MST) (envelope-from nagydani@epointsystem.org) Received: from mail.agileight.com (62-77-229-117.static.invitel.hu [62.77.229.117]) by a.relay.invitel.net (Invitel Core SMTP Transmitter) with ESMTP id 24D7E11A65C; Fri, 9 Jan 2009 00:04:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.agileight.com (Postfix) with ESMTP id AE425598099; Fri, 9 Jan 2009 00:04:35 +0100 (CET) X-Virus-Scanned: amavisd-new at mail.agileight.com Received: from mail.agileight.com ([127.0.0.1]) by localhost (www.agileight.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9eeKjzCCRkrV; Fri, 9 Jan 2009 00:04:35 +0100 (CET) Received: from [10.0.0.164] (78-131-55-134.static.hdsnet.hu [78.131.55.134]) by mail.agileight.com (Postfix) with ESMTP id 5882F598092; Fri, 9 Jan 2009 00:04:35 +0100 (CET) Message-ID: <49668683.4070601@epointsystem.org> Date: Fri, 09 Jan 2009 00:04:35 +0100 From: "Daniel A. Nagy" User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Daniel Kahn Gillmor CC: IETF OpenPGP Working Group , Monkeysphere Developers Subject: Re: A review of hash function brittleness in OpenPGP References: <49664D21.50403@fifthhorseman.net> In-Reply-To: <49664D21.50403@fifthhorseman.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD37C0D29BCC3DA75DB8EEFFA" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD37C0D29BCC3DA75DB8EEFFA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, First off, thank you for such a swift reaction to one of the most serious= cryptographic vulnerabilities discovered in recent times. Let me just com= ment on your comments. Daniel Kahn Gillmor wrote: > MDC > --- >=20 > The modification detection packets (sections 5.13 and 5.14) explicitly > specify SHA-1, and basically acknowledge that this choice may need to b= e > made more flexible in the future. We should be very careful here. By being more flexible on MDCs, one makes= the system less secure. After all, it is sufficient to forge ONE of the valid= MDC functions for the MDC-protected packet to check. There is a reason (with = a good discussion in the archives of this list, if I am not mistaken) why there = is no algorithm agility in OpenPGP MDC. Also, MDC needs to be secure against second pre-images, not against colli= sions. Collision-resistance is not a requirement for MDCs. > Fingerprints > ------------ >=20 > Fingerprints (section 12.2) are specified as an SHA-1 computation. > While this isn't an explicit reliance on SHA-1 for cryptographic > security (and the RFC makes it clear that there is a non-zero chance of= > fingerprint collisions), the real-world use of fingerprints as unique > identifiers for keys poses a serious risk to OpenPGP infrastructure > should SHA-1 become further compromised. There are many more problems with current OpenPGP key IDs and fingerprint= s. I think that these are in need of a major overhaul. Here are two other prob= lems with fingerprints and keyIDs: Creation date is hashed in the fingerprint, thereby allowing the same key= with different fingerprints of which 31 bits are of the attacker's choosing, effectively shaving off 31 bits off the attacker's task (in other words, = making it 2 billion times easier on average). Also, fingerprints and key IDs are hexadecimal, which makes them super-inconvenient with mobile phones with numeric keypads. > Revocation keys > --------------- >=20 > Section 5.2.3.15 defines a way that key A can allow key B to > authoritatively issue revocation signatures on A's behalf, including ke= y > revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and > certification revocation (sigtype 0x30). However, this mechanism relie= s > on the fingerprint of B being unique. Since the fingerprint itself is > bound to SHA-1, this presents a risk to users of this feature of the > specification should SHA-1 become further compromised. Again, collisions don't seem to be a problem here. > As the IETF working group for OpenPGP, we probably should start activel= y > working to resolve these issues so we can have infrastructure in place > well before SHA-1 is similarly compromised. Any suggestions? I'm new > to the WG, so i don't have any experience addressing concerns like this= =2E >=20 > I'm particularly concerned about fingerprints, since they is used widel= y > in the real world (e.g. i have my fingerprint on my business card). I > can imagine relatively straightforward technical measures to resolve th= e > other concerns. I think, fingerprints should be dealt with as part of the shift to v5 key= s. However, formulating reasonable requirements for fingerprints sounds like= a good way to kick off the design process of v5 key format specification. I will= write up a few ideas soon. Regards, --=20 Daniel --------------enigD37C0D29BCC3DA75DB8EEFFA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAklmhoMACgkQi+vAY9cJzcIhRACdHfMgggT758vw286TCaPTVBya eHQAoKA9yY2f9E9rq7rdtZFB9Df18qfa =yOQD -----END PGP SIGNATURE----- --------------enigD37C0D29BCC3DA75DB8EEFFA-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08MYdo2077131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 15:34:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08MYd1T077130; Thu, 8 Jan 2009 15:34:39 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.153]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08MYRdZ077113 for ; Thu, 8 Jan 2009 15:34:37 -0700 (MST) (envelope-from tz2026@gmail.com) Received: by yw-out-1718.google.com with SMTP id 5so4319672ywr.4 for ; Thu, 08 Jan 2009 14:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=BlFUTgdejZ7cDfV+um7+KwJycPa2BSNo4VuMo0p9Ew4=; b=T2djD9o3QRYcC9cW3A/O/NIxQn9/nNjd5nRmMMY4HQHxp8iLu8V7YLOzeNC5bbvWdQ Z7G8EDjooee/HC0YNtdx5NKN4BZ+vMAeg/qBjt35kcF6+npMzonrbxjGyxsJhzH2yVqL hmBrMrFwYirhZvCvfhxtEvU3kVC6jMqnoC71s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=fUSOxgiq+Dk+nZMUiQ3Zh5dmLMDnHC279Gdp+MhZa0Dwoy4eRHPTgKWb10D6adVLv9 9yXUEbmqUl0l3v5tlJ+HHEbgevw7nACp45hVapqmBVTan0/x6b2M5t8D2WS5v3rRr3Z9 RZHqRdPrzYJN/EnbxZyBRlbYaWnyw9XoZDwpk= Received: by 10.100.105.15 with SMTP id d15mr13477706anc.69.1231454065991; Thu, 08 Jan 2009 14:34:25 -0800 (PST) Received: by 10.100.194.8 with HTTP; Thu, 8 Jan 2009 14:34:25 -0800 (PST) Message-ID: <80b274790901081434t46718ad5vdc215590d000c26a@mail.gmail.com> Date: Thu, 8 Jan 2009 16:34:25 -0600 From: tz To: "Daniel Kahn Gillmor" Subject: Re: A review of hash function brittleness in OpenPGP Cc: "IETF OpenPGP Working Group" , "Monkeysphere Developers" In-Reply-To: <49664D21.50403@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49664D21.50403@fifthhorseman.net> X-Google-Sender-Auth: 6ff59723ce354869 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The other exploit was also complex and required finding collisions which was not trivial but possible with MD5. The key seemed to be that the separate bits of the certificate were in places which made the exploit easy, e.g. the top half was either static or predictable, but there was a comment field (which could be stuffed with the bits to generate the collision), then the big prime product. To analyze the RFC, the internal structure of the key certificates which are signed need to be analyzed (first there has to be a current source for new things with MD5 anyway, I'd have to come up with two things to be signed, a real one which will be signed and the rogue one that has the same MD5 hash). I think the simplicity of the certificates might make it more difficult, but that is where I would look. I don't think there are many such things in place, but I would look if there are any legacy signers (including prominent people with older keys or implementations). I think after PGP5 it would be very unlikely, but I would look for something that allowed, requested, or forced "backward compatibility", i.e. if there are bits or something else I can cause the hash algorithm to be MD5. On Thu, Jan 8, 2009 at 12:59 PM, Daniel Kahn Gillmor wrote: > Hey folks-- > > I've been trying to evaluate RFC 4880's resistance to a hash function > compromise in light of the recent activity exploiting weaknesses MD-5 in > That Other PKI [0]. > > I'm quite pleased with the bulk of what i've found. OpenPGP's use of > message digests is almost entirely parameterized, leaving the door open > to forward-looking adoption of new hash algorithms and the smooth > deprecation as older ones are demonstrated to be weak. > > So I've been looking for places in the spec where the choice of digest > function is not parameterized. In particular, explicit and hardcoded > reliance on SHA-1 could become problematic as it is already being > deprecated. For example, reliance on SHA-1 must be eliminated in all US > Gov't federal agencies by the end of 2010 [1]. > > Here are the concerns i've found so far: > > MDC > --- > > The modification detection packets (sections 5.13 and 5.14) explicitly > specify SHA-1, and basically acknowledge that this choice may need to be > made more flexible in the future. > > Fingerprints > ------------ > > Fingerprints (section 12.2) are specified as an SHA-1 computation. > While this isn't an explicit reliance on SHA-1 for cryptographic > security (and the RFC makes it clear that there is a non-zero chance of > fingerprint collisions), the real-world use of fingerprints as unique > identifiers for keys poses a serious risk to OpenPGP infrastructure > should SHA-1 become further compromised. > > Revocation keys > --------------- > > Section 5.2.3.15 defines a way that key A can allow key B to > authoritatively issue revocation signatures on A's behalf, including key > revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and > certification revocation (sigtype 0x30). However, this mechanism relies > on the fingerprint of B being unique. Since the fingerprint itself is > bound to SHA-1, this presents a risk to users of this feature of the > specification should SHA-1 become further compromised. > > > > As the IETF working group for OpenPGP, we probably should start actively > working to resolve these issues so we can have infrastructure in place > well before SHA-1 is similarly compromised. Any suggestions? I'm new > to the WG, so i don't have any experience addressing concerns like this. > > I'm particularly concerned about fingerprints, since they is used widely > in the real world (e.g. i have my fingerprint on my business card). I > can imagine relatively straightforward technical measures to resolve the > other concerns. > > Also, it's quite likely that i've missed things in my reading of the > spec. If anyone sees any other problematic areas, it would be great to > air them as soon as possible. > > Regards, > > --dkg > > [0] http://www.phreedom.org/research/rogue-ca/ > [1] http://csrc.nist.gov/groups/ST/hash/statement.html > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08Ivslb066583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:57:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n08IvsHM066582; Thu, 8 Jan 2009 11:57:54 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n08Ivg9K066569 for ; Thu, 8 Jan 2009 11:57:53 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 36098 invoked from network); 8 Jan 2009 18:57:41 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 8 Jan 2009 18:57:41 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <49664D21.50403@fifthhorseman.net> Date: Thu, 08 Jan 2009 13:59:45 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018) MIME-Version: 1.0 To: IETF OpenPGP Working Group CC: Monkeysphere Developers Subject: A review of hash function brittleness in OpenPGP X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B8AC4F50DA64063949DE949" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B8AC4F50DA64063949DE949 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey folks-- I've been trying to evaluate RFC 4880's resistance to a hash function compromise in light of the recent activity exploiting weaknesses MD-5 in That Other PKI [0]. I'm quite pleased with the bulk of what i've found. OpenPGP's use of message digests is almost entirely parameterized, leaving the door open to forward-looking adoption of new hash algorithms and the smooth deprecation as older ones are demonstrated to be weak. So I've been looking for places in the spec where the choice of digest function is not parameterized. In particular, explicit and hardcoded reliance on SHA-1 could become problematic as it is already being deprecated. For example, reliance on SHA-1 must be eliminated in all US Gov't federal agencies by the end of 2010 [1]. Here are the concerns i've found so far: MDC --- The modification detection packets (sections 5.13 and 5.14) explicitly specify SHA-1, and basically acknowledge that this choice may need to be made more flexible in the future. Fingerprints ------------ Fingerprints (section 12.2) are specified as an SHA-1 computation. While this isn't an explicit reliance on SHA-1 for cryptographic security (and the RFC makes it clear that there is a non-zero chance of fingerprint collisions), the real-world use of fingerprints as unique identifiers for keys poses a serious risk to OpenPGP infrastructure should SHA-1 become further compromised. Revocation keys --------------- Section 5.2.3.15 defines a way that key A can allow key B to authoritatively issue revocation signatures on A's behalf, including key revocation (sigtype 0x20), subkey revocation (sigtype 0x28), and certification revocation (sigtype 0x30). However, this mechanism relies on the fingerprint of B being unique. Since the fingerprint itself is bound to SHA-1, this presents a risk to users of this feature of the specification should SHA-1 become further compromised. As the IETF working group for OpenPGP, we probably should start actively working to resolve these issues so we can have infrastructure in place well before SHA-1 is similarly compromised. Any suggestions? I'm new to the WG, so i don't have any experience addressing concerns like this. I'm particularly concerned about fingerprints, since they is used widely in the real world (e.g. i have my fingerprint on my business card). I can imagine relatively straightforward technical measures to resolve the other concerns. Also, it's quite likely that i've missed things in my reading of the spec. If anyone sees any other problematic areas, it would be great to air them as soon as possible. Regards, --dkg [0] http://www.phreedom.org/research/rogue-ca/ [1] http://csrc.nist.gov/groups/ST/hash/statement.html --------------enig7B8AC4F50DA64063949DE949 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSWZNJszS7ZTSFznpAQIwog//b705lnuUoYzz1Tp6OHBbTmKtThS2myCX Cp8sgmkH9p/GtP4MEBKmR3TFkw0JxwyhRAPsRsDVp/JpDkv08oxdW3+Mqi8xgBIF x9zyBb+XmV3WNwYTTjkcNQ+WYVqqLzvWGDS2wZ3/BjQiezgV60C42vNBM05ZTp93 WS0cnh/txJ5Lex+rxqE+qiZOWaAubyxX4AmZ4e68uoXM3faSFT8TesZUzZRbd9zN SDBIxjb1FYgDLboaotlEHk5Zeq+Uy0nM3hQ3jqXZnmNk7bjajCkCl5zm/xUcUXVZ yDb/nSpDTrYfdfdhCrtqBoHzxlw+tzs5mu77Fc7wR2GNNJo6/xq8uRbabYDsyaaL cTlpNdvaz3Cj4Ncq5Ztqpjgpgw/NfG0Msp9B2Qw2sz1yDr8ZyH5WaB9QJCuDH8Zf DJapjUFqgqgtUQRZIU+DSpW0KtiAYa+3Bg8heQmfoJd9DnS9J+OILCZg/RNArt/5 5Gqe5GjvioWG6g09hmr9Uo8WAMVNDTk8YaWiMfQYvvi2Qa48ZzS09CYDMF1GR0ld K11czwkHqrNAXuWF/YBDkecv4jtmAj+Mu4ddVjHtuz59+AelCh/gy5FHyOtSWrvH KbYF4AQIUYwMdTTJiZ4RTG8PQtUxyy6H9sDGfrdpih9aBanseCQ+IEjFB02yqCbN VL0EXYVBOhM= =kw/q -----END PGP SIGNATURE----- --------------enig7B8AC4F50DA64063949DE949--