From owner-ietf-openpgp@mail.imc.org Thu May 1 15:05:28 2008 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 76A6B3A67EC for ; Thu, 1 May 2008 15:05:28 -0700 (PDT) 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 J7FIWnukpn90 for ; Thu, 1 May 2008 15:05:27 -0700 (PDT) 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 DBF543A6BC9 for ; Thu, 1 May 2008 15:04:03 -0700 (PDT) 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 m41Liwuv039262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2008 14:44:58 -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 m41LivSi039247; Thu, 1 May 2008 14:44:57 -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.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m41LisxM039169 for ; Thu, 1 May 2008 14:44:56 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so843729fkq.10 for ; Thu, 01 May 2008 14:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l1yGG210vj7emrzTm9GEJjriv+dHsE9kQvAC43aqM7k=; b=F/06nEnjYJm9dxwIvRiA0WCaRjQGX3M8M2WgV49OHBTHfalAqeu7GabXUBxZMWGX1NOTm2+DOayoJbQXkMGBa/4cqih2PY/T9bEEeTVi6DvrsOvmW+uDF4cAX/5XLz6vLlTH6AZBRxAMp9loNGx+UHyV/0+cxAlSPB0pUSszHeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vKENrmTAhqYEndez+vvgRMBpzdVpndSIDW9ESvSVEiR90Nbat5EjwdvTDU9E9t+suWwmlXYT9oYeOXUOo78jSyriA3i17w57tzA9iN6kTIqRPFQptiIyZV/xse7NpZTrUJmtR1d5nKF68ENd733jphzmMwXF0ddyd2X6qgRz+F4= Received: by 10.78.120.15 with SMTP id s15mr735692huc.108.1209678293785; Thu, 01 May 2008 14:44:53 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Thu, 1 May 2008 14:44:53 -0700 (PDT) Message-ID: <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> Date: Thu, 1 May 2008 22:44:53 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Cc: OpenPGP In-Reply-To: <481815F0.8090401@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481815F0.8090401@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The discussions we had on pre-submission version of the specification can > continue with the draft. The submitted version doesn't (yet) have mention of the proposed (and generally, it seems, well-received notion of) a StrictSuiteB flag / flags. Discussions tailed off on this, but we (still) need(ed) to give the whole interoperability thing a long hard look, as per your last message on this topic. Some comments from me on the (latest) submitted draft: | While TripleDES ensures interoperability between applications | complaint with OpenPGP and ECC specifications, it doesn't help | interoperability with Suite-B profile. Suppose TripleDES is the | only shared algorithm within a set of recipients. If Suite-B | compliant recipient is added to the mentioned recipient set, the | sender SHALL NOT send out a message. shouldn't this be MUST NOT? (continuing to quote section so people can see the context) | This is because TripleDES is | excluded from Suite-B and sending out two copies of the same | message, one encrypted with TripleDES and another with AES-128 or | AES-256, would mean that the same information that must have been | protected with Suite-B compliant algorithm was protected instead | with non-compliant TripleDES. This restriction covers other cases | in which none of recipients' shared algorithms are allowed by | Suite-B. One of available methods to a recipient to help ensure | interoperability with Suite-B is to include one of two Suite-B | symmetric algorithms, AES-128 or AES-256, or both, in the set of | preferred algorithms. (end of that section). But how *on earth* are you going to "enforce" people NOT sending two copies of the same message under different ciphers??! Meanwhile, this new bit: | While some statements in this specification refer to TripleDES | algorithm, this is only done to help interoperability with existing | application and already generated keys; AES-256 is the recommended | alternative to TripleDES in all circumstances when AES-256 is | available. I (really) like, but probably needs to have added onto the end of it: Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC, and may be preferred in more constrained environments. However, AES-128 is not allowable when the larger Suite-B profiles are required, so AES-256 may still need to be implemented for this interoperability. (But, as I stated at the start of this email, this whole topic still needs further thought.) From owner-ietf-openpgp@mail.imc.org Fri May 2 06:50:15 2008 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 998463A6A77 for ; Fri, 2 May 2008 06:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 LkynC5AArDz1 for ; Fri, 2 May 2008 06:50:14 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8E0A428C137 for ; Fri, 2 May 2008 06:49:36 -0700 (PDT) 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 m42DWxOC067438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 06:32:59 -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 m42DWxbC067437; Fri, 2 May 2008 06:32:59 -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.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42DWwfZ067403 for ; Fri, 2 May 2008 06:32:58 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (PGPDEV.IHTFP.ORG [204.107.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 4538ABD8464; Fri, 2 May 2008 09:32:57 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m42DWpGj008399; Fri, 2 May 2008 09:32:51 -0400 To: "David Crick" Cc: "Andrey Jivsov" , OpenPGP Subject: Re: ECC in OpenPGP -00.txt is posted as a draft References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> From: Derek Atkins Date: Fri, 02 May 2008 09:32:51 -0400 In-Reply-To: <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> (David Crick's message of "Thu\, 1 May 2008 22\:44\:53 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) 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: David, "David Crick" writes: >> The discussions we had on pre-submission version of the specification can >> continue with the draft. > > The submitted version doesn't (yet) have mention of the > proposed (and generally, it seems, well-received notion of) > a StrictSuiteB flag / flags. Discussions tailed off on this, but we > (still) need(ed) to give the whole interoperability thing a long > hard look, as per your last message on this topic. Actually, it was not well received. The "OpenPGP way" of doing this is an application putting in the "accepted ciphers" into the public key notation. This document doesn't need to describe that because it's already well documented in RFC 4880. Using the notation packet also allows us to support different "Strict Suites".. If some other country wants their own stuff in there we don't need to extend anything; applications just set the appropriate supported cipher list. Et Voila, you've got your "flag". -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Fri May 2 07:18:23 2008 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 751173A6A04 for ; Fri, 2 May 2008 07:18:23 -0700 (PDT) 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 S4isNNtNEHkN for ; Fri, 2 May 2008 07:18:22 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9C34E3A6A15 for ; Fri, 2 May 2008 07:18:21 -0700 (PDT) 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 m42E21HA080692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 07:02: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 m42E21XJ080691; Fri, 2 May 2008 07:02: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42E1xDd080662 for ; Fri, 2 May 2008 07:02:00 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by nf-out-0910.google.com with SMTP id 30so676517nfu.24 for ; Fri, 02 May 2008 07:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=D0px8lu2/9y3me43AtnhVKEyjlDOqnQIQzmdudWtOm0=; b=LFXxzl8SzPopaMdJp93Hf1N+EHWUy22Vmb3spWVMKUpmZE9JPAtJDqgx/nWQ8lacoAI9NUY5sgWYbZ4xBo+61UdTbw6Yi6+oy+pgBlT2zejC/Xe99lgK/bfLIJJSTjauaYEkf9Wn8WMyEuoPzA1A2T5mTJNR6J+BJbZybUZIoWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sSmeCzec0e1wVotKx2kuppmnwnG6R+qeOvJnTxUWj8OmeWNZqKmNX6k0VHLC65DTwWZbDWFAa1u3t//yiLf4mrcU9iYmixMZJGsYE7tTcNpiW8TEU7H7PrUMh8/UWzSw51fucfWrngK7ir+QqvbDTjuSUEW6EVLsFj3vlQn9g78= Received: by 10.78.20.13 with SMTP id 13mr912394hut.47.1209736916201; Fri, 02 May 2008 07:01:56 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Fri, 2 May 2008 07:01:56 -0700 (PDT) Message-ID: <117bad160805020701k5a24906cs565e43a184bbeed9@mail.gmail.com> Date: Fri, 2 May 2008 15:01:56 +0100 From: "David Crick" To: "Derek Atkins" Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Cc: "Andrey Jivsov" , OpenPGP In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, May 2, 2008 at 2:32 PM, Derek Atkins wrote: > David, > > > The submitted version doesn't (yet) have mention of the > > proposed (and generally, it seems, well-received notion of) > > a StrictSuiteB flag / flags. > > Actually, it was not well received. oh. I counted at least (quick search of the archive): Jon Callas: I don't think this is a bad idea at all ... * I like David Crick's suggestion of a preference that says, "I'm going to be strict about Suite B." This is a legislative solution, and it would work well, it's simple, and elegant. End of story. Werner Koch (quoting the "i like David Crick's" paragraph above): I support this. Further, Andrey Jivsov continued the discussion: One additional issue I realized that we didn't address is the mixing of keys for two levels of Suite-B profile. It is similar to the issue of mixing non-Suite-B and Suite-B keys. TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We cannot make TOP SECRET keys use AES-128, yet this is what happens with implicit AES-128. Making AES-256 implicit will not work either, because now SECRET keys will be picked as compatible with TOP SECRET keys. Finally, having no implicit preferences disallows TOP SECRET keys to receive SECRET information. Do we now need two Suite-B flags? (end quoting Andrey) so I thought this had some momentum behind it? > The "OpenPGP way" of doing this > is an application putting in the "accepted ciphers" into the public > key notation. This document doesn't need to describe that because > it's already well documented in RFC 4880. but the problem was that a recipient currently has no way of saying "strict suite B" beyond setting one/both of the AESes as higher up in their preference list and then *hoping* all of the implementations that ever send messages use this "advisory" information rather than (legitimately) taking some other arbitrary intersection of recipient preferences and choosing something other than the AES of the correct length. > Using the notation packet also allows us to support different "Strict > Suites".. If some other country wants their own stuff in there we don't > need to extend anything; applications just set the appropriate > supported cipher list. Et Voila, you've got your "flag". perhaps I'm not using correct terminology here? My "flag" (or "flags," if we decide we need one for each of the Suite B profiles, as per Andrey's last message, quoted above) was intended to be "something" on the key that the user can set to say "Strict Suite-B." Is my "flag"/key "something" the same as what you are calling a "notation packet" ? I don't think it is? But I emphasis again that the key cipher preference list *cannot* be guaranteed to make us Suite-B compliant, as implementations can choose their own intersections. So we need something "more." > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > From owner-ietf-openpgp@mail.imc.org Fri May 2 10:47:49 2008 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 110D13A6CA5 for ; Fri, 2 May 2008 10:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.509, 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 qPpXvW6Rdn8R for ; Fri, 2 May 2008 10:47:47 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 371A03A6ACD for ; Fri, 2 May 2008 10:47:47 -0700 (PDT) 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 m42HU7lU072486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 10:30: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 m42HU7NK072485; Fri, 2 May 2008 10:30: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 mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42HU5Ua072465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 2 May 2008 10:30:06 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m42HXt55009507; Fri, 2 May 2008 13:33:56 -0400 Message-ID: <481B4F95.7040705@brainhub.org> Date: Fri, 02 May 2008 10:29:57 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: David Crick CC: OpenPGP Subject: Re: ECC in OpenPGP -00.txt is posted as a draft References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> In-Reply-To: <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: >> The discussions we had on pre-submission version of the specification can >> continue with the draft. > > The submitted version doesn't (yet) have mention of the > proposed (and generally, it seems, well-received notion of) > a StrictSuiteB flag / flags. Discussions tailed off on this, but we > (still) need(ed) to give the whole interoperability thing a long > hard look, as per your last message on this topic. > Given later comments by Derek and your subsequent replies, I think we may need separate discussion on this. Without assumption that additional key properties is the way to go and where this description should be, I thought it will be helpful to submit more detailed proposal on how this could be done and what are the issues we need to worry about. I will do this before coming Monday. We can then have some sort of vote on this subject. > > Some comments from me on the (latest) submitted draft: > > | While TripleDES ensures interoperability between applications > | complaint with OpenPGP and ECC specifications, it doesn't help > | interoperability with Suite-B profile. Suppose TripleDES is the > | only shared algorithm within a set of recipients. If Suite-B > | compliant recipient is added to the mentioned recipient set, the > | sender SHALL NOT send out a message. > > shouldn't this be MUST NOT? Will do. > > (continuing to quote section so people can see the context) > | This is because TripleDES is > | excluded from Suite-B and sending out two copies of the same > | message, one encrypted with TripleDES and another with AES-128 or > | AES-256, would mean that the same information that must have been > | protected with Suite-B compliant algorithm was protected instead > | with non-compliant TripleDES. This restriction covers other cases > | in which none of recipients' shared algorithms are allowed by > | Suite-B. One of available methods to a recipient to help ensure > | interoperability with Suite-B is to include one of two Suite-B > | symmetric algorithms, AES-128 or AES-256, or both, in the set of > | preferred algorithms. > (end of that section). > > But how *on earth* are you going to "enforce" people NOT sending > two copies of the same message under different ciphers??! I meant to provide a warning to implementors that once crypto/messaging layer detects sending conflict to a group of recipients, the conflict cannot be resolved by sending two separate messages. While each of two messages with appropriate subset of recipients can satisfy constrains of crypto/messaging layer, this is not the right thing to do from the point of view of information protection. For example, I thought that the following message misses this point: Len Sassaman wrote this in Mar 2008: > Breaking compatibility on the protocol level doesn't mean breaking it on > the actually application level. In a different thread, there as discussion > of people using "regular" DSA/EG keys and then adding a recipient who uses > ECC. So what? The application can encrypt twice, and send the properly > encrypted messages to the appropriate people. > > > Meanwhile, this new bit: > > | While some statements in this specification refer to TripleDES > | algorithm, this is only done to help interoperability with existing > | application and already generated keys; AES-256 is the recommended > | alternative to TripleDES in all circumstances when AES-256 is > | available. > > I (really) like, but probably needs to have added onto the end of it: > > Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC, > and may be preferred in more constrained environments. However, > AES-128 is not allowable when the larger Suite-B profiles are required, > so AES-256 may still need to be implemented for this interoperability. > > (But, as I stated at the start of this email, this whole topic still needs > further thought.) I would say that, overall, AES-128 should remains the lowest common denominator in this specification. It is needed to cover the mix of recipients with smartcards, cellphones, etc. Hopefully, "TOP SECRET Suite-B profile keys" will not be issued on constrained smartcards. Another point, when TOP SECRET keys receive TOP SECRET information, this is when AES-256 must be used, only TOP SECRET keys can be in the list of recipients. AES-256 SHOULD be in the set of preferred algorithms on each key in this case. From owner-ietf-openpgp@mail.imc.org Fri May 2 11:25:30 2008 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 D6C8928C44A for ; Fri, 2 May 2008 11:25:30 -0700 (PDT) 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 JonXYcd3AMrK for ; Fri, 2 May 2008 11:25:26 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EA7FB3A6E45 for ; Fri, 2 May 2008 11:25:13 -0700 (PDT) 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 m42I0Rxx086709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 11:00:27 -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 m42I0Rcs086708; Fri, 2 May 2008 11:00:27 -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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42I0QB7086689 for ; Fri, 2 May 2008 11:00:26 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by nf-out-0910.google.com with SMTP id 30so747031nfu.24 for ; Fri, 02 May 2008 11:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2ewe6UKe9ZLe4P35erT2+TmoqEVsJpUZGd9lLQX0v4w=; b=sGngVnHqN6PYfH0Q2Ye6wAURt4KqO5Fs2+dAOtlR3HttfJDCI9E6MUXT1rBvOQVKiQGYwHCMrK7mV9PU+JYbAMkZ96PMVCkfuTbFtb9Uh3+oeL7/GMoxJM/57OV1NaUSZ+1c496+x/ELEiuSvnIW1+wXeC2UW+cTMXfAaFMw7aM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mHEN+thA5xdJ3gLjW/InRbUxn35kwVs40SjEfUsVbT95mol1RpSJS6TKuLdHI99mGc86uYXgf8maWVBvkqBh3aJKwumRO7rfA4oBGL6iw5OvSuCFaUtkMspNsf25ulUDjSks3mOOyDw0V+VTyBBaBoRJZ73qBpqxE5d62ppIm/o= Received: by 10.78.146.13 with SMTP id t13mr948553hud.101.1209751224486; Fri, 02 May 2008 11:00:24 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Fri, 2 May 2008 11:00:24 -0700 (PDT) Message-ID: <117bad160805021100v709e8515u3b049fec5a09ae78@mail.gmail.com> Date: Fri, 2 May 2008 19:00:24 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Cc: OpenPGP In-Reply-To: <481B4F95.7040705@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> <481B4F95.7040705@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, May 2, 2008 at 6:29 PM, Andrey Jivsov wrote: > David Crick wrote: > > > The submitted version doesn't (yet) have mention of the ... > > StrictSuiteB flag / flags. > Given later comments by Derek and your subsequent replies, I think we may > need separate discussion on this. An alternative that I've just thought of is to do some sort of "layering": rfc4880 (base) -> OpenPGP ECC ("anything goes") -> Suite-B, and other (e.g. national) "profiles" So the current "OpenPGP ECC" doc could be completely re-written, stripping out references to Suite-B (but still retaining a "relative strengths" section). This would also simplify the specification. *Then* we could write a standalone Suite-B doc, which would specify a constrained sub-set of OpenPGP ECC. Note, we'd *still* have the "how to make Suite-B strict" problem, so *still* might require some sort of kludge. And/*or* we could even just "avoid" the Strict Suite B issue altogether, and leave it for the implementers! Since Suite-B users will (by definition) only want to communicate with other Suite-B users, then they will be a self-contained userbase, and so can simply not implement 3DES [and other ciphers]. Meanwhile the rest of us just set AES-256 and AES-128 at the head of our cipher preferences and put up with the fact that someone may send us 3DES messages (or using any other cipher for that matter, if they over-ride using [e.g., in gnupg] --cipher-algo and disregard the warning). From owner-ietf-openpgp@mail.imc.org Fri May 2 15:22:36 2008 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 1D6303A6A80 for ; Fri, 2 May 2008 15:22:36 -0700 (PDT) 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 3PYmTJ1peCRm for ; Fri, 2 May 2008 15:22:35 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AD8003A6A1E for ; Fri, 2 May 2008 15:22:34 -0700 (PDT) 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 m42M8oBn097554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:08:50 -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 m42M8omc097551; Fri, 2 May 2008 15:08:50 -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 m42M8mr2097527 for ; Fri, 2 May 2008 15:08:48 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 70F81F0D730 for ; Fri, 2 May 2008 15:08:47 -0700 (PDT) Received: from bgillson-d620.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 02 May 2008 15:08:48 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 02 May 2008 15:08:48 -0700 Cc: "Derek Atkins" , "Andrey Jivsov" , OpenPGP Message-Id: From: Jon Callas To: David Crick In-Reply-To: <117bad160805020701k5a24906cs565e43a184bbeed9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Date: Fri, 2 May 2008 15:08:44 -0700 References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> <117bad160805020701k5a24906cs565e43a184bbeed9@mail.gmail.com> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 2, 2008, at 7:01 AM, David Crick wrote: > > On Fri, May 2, 2008 at 2:32 PM, Derek Atkins wrote: >> David, >> >>> The submitted version doesn't (yet) have mention of the >>> proposed (and generally, it seems, well-received notion of) >>> a StrictSuiteB flag / flags. >> >> Actually, it was not well received. > > oh. I counted at least (quick search of the archive): > > Jon Callas: > I don't think this is a bad idea at all Since I'm being invoked, I must clarify. I don't think it's a bad idea at all. But I think in the interests of minimalism, nothing is better than something. In other words, leaving as much to the implementation as possible is good. But that also includes some flag that says the implementation does SuiteB strictly. It's good to have it, but I'm not sure much more needs to be said. It isn't our job to go into the gory details of what that means. > > ... > * I like David Crick's suggestion of a preference that says, "I'm > going to be strict about Suite B." This is a legislative solution, and > it would work well, it's simple, and elegant. End of story. > > Werner Koch (quoting the "i like David Crick's" paragraph above): > I support this. > > > Further, Andrey Jivsov continued the discussion: > One additional issue I realized that we didn't address is the mixing > of keys for two levels of Suite-B profile. It is similar to the issue > of mixing non-Suite-B and Suite-B keys. > > TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We > cannot make TOP SECRET keys use AES-128, yet this is what happens with > implicit AES-128. Making AES-256 implicit will not work either, > because now SECRET keys will be picked as compatible with TOP SECRET > keys. Finally, having no implicit preferences disallows TOP SECRET > keys to receive SECRET information. > > Do we now need two Suite-B flags? > (end quoting Andrey) > > > so I thought this had some momentum behind it? > >> The "OpenPGP way" of doing this >> is an application putting in the "accepted ciphers" into the public >> key notation. This document doesn't need to describe that because >> it's already well documented in RFC 4880. > > but the problem was that a recipient currently has no > way of saying "strict suite B" beyond setting one/both > of the AESes as higher up in their preference list and > then *hoping* all of the implementations that ever > send messages use this "advisory" information rather > than (legitimately) taking some other arbitrary intersection > of recipient preferences and choosing something other > than the AES of the correct length. > >> Using the notation packet also allows us to support different "Strict >> Suites".. If some other country wants their own stuff in there we >> don't >> need to extend anything; applications just set the appropriate >> supported cipher list. Et Voila, you've got your "flag". > > perhaps I'm not using correct terminology here? My "flag" > (or "flags," if we decide we need one for each of the Suite > B profiles, as per Andrey's last message, quoted above) > was intended to be "something" on the key that the user > can set to say "Strict Suite-B." Is my "flag"/key "something" > the same as what you are calling a "notation packet" ? > > I don't think it is? > > But I emphasis again that the key cipher preference list > *cannot* be guaranteed to make us Suite-B compliant, > as implementations can choose their own intersections. > > So we need something "more." > >> -derek >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIG5DwsTedWZOD3gYRApUbAKDNKq2ouFglE2+0ckWGtsvjJ8LBCgCfULUi XXedj8ZUuZUf4SHJMMpMM98= =F+Yn -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat May 3 14:24:56 2008 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 D6DDE3A6ACC for ; Sat, 3 May 2008 14:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, J_CHICKENPOX_18=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 5EtbHpwgApno for ; Sat, 3 May 2008 14:24:56 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 686353A6B31 for ; Sat, 3 May 2008 14:24:55 -0700 (PDT) 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 m43LBCsW022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 14:11: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 m43LBCw0022687; Sat, 3 May 2008 14:11: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 mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43LBAF9022664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 3 May 2008 14:11:11 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m43LFQ55031517 for ; Sat, 3 May 2008 17:15:27 -0400 Message-ID: <481CD4EB.2020309@brainhub.org> Date: Sat, 03 May 2008 14:11:07 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: OpenPGP Subject: OpenPGP keys and Suite-B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires that TOP SECRET must use AES-256 SECRET must use AES-128 or AES-256 Labeled security is usually required with these standards. Information is labeled with certain classification, which assures that the processing of this information will match the label as data travels through the system. This results in: TOP SECRET keys can receive TOP SECRET and SECRET information SECRET keys can only receive SECRET information Information | | level | Keys | "Send to" action -------------------------------------------- [TS] | [TS],[S] | fail [S] | [TS],[S] | allow with AES-256 [TS] | [S] | fail [S] | [TS] | allow with AES-256 [TS] | [TS] | allow with AES-256 [S] | [S] | allow with AES-256/128 Note that two first rows represent the same mix of keys but result in different behavior. This aspect is orthogonal to OpenPGP. For completeness, Key level | Key preferences -------------------------------------------- [TS] | {AES-256} [S] | {AES-256, AES-128} I see three approaches. =================================================================== A. Use key notations "suite-b-key@pgp.com" with values "top secret" and "secret". =================================================================== Leave the interpretation of these values to applications. The rationale is that we don't recite government documents in the document like "ECC in OpenPGP". There are other requirements that must be satisfied beyond the scope of the "ECC in OpenPGP" document, such as authentication and how the private keys are unlocked. For example, we cannot enforce the use of PIN pad devices. (If all we have to say is the sentence under A, I would say we keep it out of the document.) =================================================================== B. Use feature bits of a key 0x02, 0x4 of "5.2.3.24. Features" as follows: 0x02: The default symmetric alg. of the key is AES-128 0x04: The default symmetric alg. of the key is AES-256 These bits can be combined (i.e. they are not mutually exclusive). =================================================================== TOP SECRET (TS) must have 0x02 SECRET must have 0x02|0x04=0x06 The existence of 0x02 or 0x04 tells that the implicit default algorithm TripleDES is replaced by (either of) corresponding AES algorithm(s). This specification may appeal to these who don't want to see Suite-B mentioned in the "protocol/format" document. It also specifies narrow feature using the concepts compatible with the scope of RFC 4880. The Suite-B meaning need to be layered on top of these bits. Yet, the proposals A and B lack following details: * It is not sufficient to rely on key holder to tell which information level it is eligible to receive. Everyone wants TOP SECRET. This statement must come from a trusted source, like a certification by a trusted key or looked up online. The above proposals A and B put data into a self-signature. OpenPGP "0x50: Third-Party Confirmation signature" may be needed. It is "may" because in some cases keys are managed, making this notary signatures unnecessary, or keys may be looked up in some online directory. * Furthermore, what a sender does with the information and how it interprets the flags on a key is not enforceable by a recipient. This must be enforced by higher levels. * I thought about how a [TS] information might be encrypted to a Suite-B recipient with hypothetical command line tool. For example, like this: openpgpcmd --suite-B-information=secret --trusted-certifier-top-secret=XXX -trusted-certifier-secret=YYY recipients v.s. openpgpcmd --suite-B-information=secret --trusted-certifier=ZZZ recipients In one case the type of certifier ([TS]/[S]) is determined from key properties, in another case the types of certifiers are passed explicitly. The commands look similar, especially if there are two trusted certifiers in each case. Finally: =================================================================== C. Higher layers of application will govern compliance with Suite B. "ECC in OpenPGP" document will define reasonable superset of features required for Suite-B or similar government documents, but exact specification of the policies to use ECC in OpenPGP is out of scope. =================================================================== In other words, A and B are really C+policies. Regardless of which route we take, we will need "protocol/format" document. This is what implementors need first. This is what is needed to establish interoperability base. This is what will make messages flow. This layer alone may get incorrectly encrypted [TS] information with TripleDES, so higher layer will be needed. However, as an implementor I see value in splitting a Suite-B cloud into layers that we can implement and test independently. Here is promised ballot. "x" for "yes". As an editor I think that voting C will result in faster progress of the document. Andrey: A: B: C: x From owner-ietf-openpgp@mail.imc.org Sat May 3 14:42:30 2008 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 157393A6D7C for ; Sat, 3 May 2008 14:42:30 -0700 (PDT) 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 W6zl3nfWWB3P for ; Sat, 3 May 2008 14:42:29 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E0F313A6BF2 for ; Sat, 3 May 2008 14:42:28 -0700 (PDT) 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 m43LQOQ1030320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 14:26:24 -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 m43LQOXZ030319; Sat, 3 May 2008 14:26: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 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 m43LQMgp030294 for ; Sat, 3 May 2008 14:26:23 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so263332fkq.10 for ; Sat, 03 May 2008 14:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sXiN/ZpzGd/JUXb5f83v+IPlm7zz4dNcOgmY0MS5BEI=; b=dCHI+dOc0CsNW9lwITo2Auy3SQiQrlMaTb4adtNr+A2hE1H8K9sIBN5JPNHqMv1zB0pGEDLpxs595RQH0ZnS97wY7P+HGPII2PihbRnIwjJbrAqRKq6nsAf96UrFdVw7iE41Bd4HtD3R03mjyWTLWt3bOMU0UILHqcl9q8r3vu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o/c+dHg2Y5GaRUdtDi9Onqi3jjS1vSZq7j0EMGaN/YVBNBXsWUjcV+zG8HxCOMoCqNI4lWoYEy65OissK50ewmbMV53mn8NLzPVACxBPooLsdwTYhbnNdIV3xOSZsLNNjCWpSO5waiHgozxupb+W3EttbGQLnbplF4TDeGAyM3I= Received: by 10.78.133.2 with SMTP id g2mr1204430hud.92.1209849981210; Sat, 03 May 2008 14:26:21 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sat, 3 May 2008 14:26:21 -0700 (PDT) Message-ID: <117bad160805031426x3898f2dcu4ad9129122fc7de1@mail.gmail.com> Date: Sat, 3 May 2008 22:26:21 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Here is promised ballot. "x" for "yes". > A: > B: > C: can we mark more than one box...? From owner-ietf-openpgp@mail.imc.org Sat May 3 15:55:13 2008 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 3A5193A6976 for ; Sat, 3 May 2008 15:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.406, 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 dnUl5SOPDHLC for ; Sat, 3 May 2008 15:55:01 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0CDA43A6808 for ; Sat, 3 May 2008 15:55:00 -0700 (PDT) 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 m43Mdihv061699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 15:39: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 m43MdiZn061698; Sat, 3 May 2008 15:39: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.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43MdYWc061625 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 3 May 2008 15:39:43 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m43Mge55010912 for ; Sat, 3 May 2008 18:43:37 -0400 Message-ID: <481CE944.7030004@brainhub.org> Date: Sat, 03 May 2008 15:37:56 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: OpenPGP Subject: Re: OpenPGP keys and Suite-B X-Priority: 5 (Lowest) References: <481CD4EB.2020309@brainhub.org> <117bad160805031426x3898f2dcu4ad9129122fc7de1@mail.gmail.com> In-Reply-To: <117bad160805031426x3898f2dcu4ad9129122fc7de1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: >> Here is promised ballot. "x" for "yes". > >> A: >> B: >> C: > > can we mark more than one box...? I suppose prioritized list will convey some information, as long as the best choice is obvious. I also don't mean to suppress offer alternative proposals, but before we go there it would be interesting to see where we stand with this list. From owner-ietf-openpgp@mail.imc.org Sun May 4 08:11:21 2008 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 1B61A28C2F8 for ; Sun, 4 May 2008 08:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_18=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 f-IzyVwh94Xa for ; Sun, 4 May 2008 08:11:16 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id D7AEA3A6DAB for ; Sun, 4 May 2008 08:11:15 -0700 (PDT) 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 m44EuANl087521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 07:56: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 m44EuAGm087520; Sun, 4 May 2008 07:56: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 fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44Eu8AL087496 for ; Sun, 4 May 2008 07:56:09 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so502255fkq.10 for ; Sun, 04 May 2008 07:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YnI1/+3DPzBdcHS6xAetyScvAPhPjr818LDxS1tqif4=; b=kLpm9u8h0zNUsSUpboAArR2YI1f1O+g97M7T7sWAy4avDUksvyfXlgyg4bLRrJHDkG6j51O1jI7UMpnHlEnCBfFcIAljUo2jEFVeStYq9tybXIjLiyUu3FrBbBOLF+WRiZBZr7Ese1zM/Hd1xsbUzyvibY33ah6V7bo8yBaKVVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XSe8dyGpF5K6298MMFrTutfryxVShLUiZqB1FxAq/8EvO7tegHf7b7szg5fe4Ow35V7ric59ekDw1K1QE6iyoYS7CzAVC6iJB/HNFxcvHeCMF948grcI8RAnNkkSIub9JIEjsqk9RuJ5cdHdsimH0O+Rtsw7MfA1M6H93BbeoOw= Received: by 10.78.135.20 with SMTP id i20mr1381550hud.18.1209912967717; Sun, 04 May 2008 07:56:07 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sun, 4 May 2008 07:56:07 -0700 (PDT) Message-ID: <117bad160805040756v1938d69ej47a5a412942e9f64@mail.gmail.com> Date: Sun, 4 May 2008 15:56:07 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, May 3, 2008 at 10:11 PM, Andrey Jivsov wrote: > > Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires > that > > TOP SECRET must use AES-256 > SECRET must use AES-128 or AES-256 > > Labeled security is usually required with these standards. Information is > labeled with certain classification, which assures that the processing of > this information will match the label as data travels through the system. > This results in: > > TOP SECRET keys can receive TOP SECRET and SECRET information > SECRET keys can only receive SECRET information > > Information | | > level | Keys | "Send to" action > -------------------------------------------- > [TS] | [TS],[S] | fail > [S] | [TS],[S] | allow with AES-256 > [TS] | [S] | fail > [S] | [TS] | allow with AES-256 > [TS] | [TS] | allow with AES-256 > [S] | [S] | allow with AES-256/128 > > Note that two first rows represent the same mix of keys but result in > different behavior. This aspect is orthogonal to OpenPGP. Andrey, I really appreciate you putting the effort in to flesh this out. > For completeness, > > Key level | Key preferences > -------------------------------------------- > [TS] | {AES-256} > [S] | {AES-256, AES-128} Note, however, that the [TS]/[S] suites restrict not only the symmetrical cipher but also the public key size and the size of the SHA2 hash used too. Your "key level" implicitly includes these further restrictions, but it needs to be stated explicitly as well, and there would be similar "fails" if the public key size was too small or (say) you were doing conventional encryption and the hash used for the passphrase was too small. The current discussion has sprung from the "inheriting" of 3DES from 4880, however, so that was why the focus has (so far) been on the fact that OpenPGP ECC COULD encrypt using 3DES unless we provide some sort of mechanism or policy to prevent this (and hence this particular document). > I see three approaches. > > A. Use key notations "suite-b-key@pgp.com" > Leave the interpretation of these values to applications. > (If all we have to say is the sentence under A, I would say we keep it out > of the document.) I agree. In fact I would go further and say if A is the way forward chosen then we should remove *all* mention of Suite-B from the OpenPGP ECC proposal, except for perhaps a paragraph noting that a subset of OpenPGP ECC may be used as the basis for Suite B implementations. =================================================================== > B. Use feature bits of a key 0x02, 0x4 of > "5.2.3.24. Features" as follows: > 0x02: The default symmetric alg. of the key is AES-128 > 0x04: The default symmetric alg. of the key is AES-256 > These bits can be combined (i.e. they are not mutually > exclusive). > =================================================================== > > TOP SECRET (TS) must have 0x02 > SECRET must have 0x02|0x04=0x06 > > The existence of 0x02 or 0x04 tells that the implicit default algorithm > TripleDES is replaced by (either of) corresponding AES algorithm(s). this is all good. > This specification may appeal to these who don't want to see Suite-B > mentioned in the "protocol/format" document. It also specifies narrow > feature using the concepts compatible with the scope of RFC 4880. > > The Suite-B meaning need to be layered on top of these bits. interesting - I would say this was "a little bit less" than I was originally intending, i.e. you've made it "profile" (e.g. Suite-B) independent. I'm fine with that as a half-measure; it will help us "remove" 3DES. > Yet, the proposals A and B lack following details: > > * It is not sufficient to rely on key holder to tell which information > level it is eligible to receive. Everyone wants TOP SECRET. This statement > must come from a trusted source, like a certification by a trusted key or > looked up online. The above proposals A and B put data into a > self-signature. OpenPGP "0x50: Third-Party Confirmation signature" may be > needed. It is "may" because in some cases keys are managed, making this > notary signatures unnecessary, or keys may be looked up in some online > directory. > * Furthermore, what a sender does with the information and how it > interprets the flags on a key is not enforceable by a recipient. This must > be enforced by higher levels. right, so this is where my original proposal was "stronger." My original proposal was "strict suite-B flag[s] mean a sender's implementation MUST NOT use anything other than the appropriate ciphers [and hashes/public key sizes] on the recipient[s]' key" If you wish to add this as a further option to the ballot then that's up to you. > Finally: > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. Hmmm, your C reads very much like your A. In fact now having looked at your C in more detail I actually don't see any value in A - it's almost a "hint from the receiver" that needs the human user on the sending side to see it as such. At least C means something to an implementer. > In other words, A and B are really C+policies. Regardless of which route we > take, we will need "protocol/format" document. This is what implementors > need first. This is what is needed to establish interoperability base. This > is what will make messages flow. This layer alone may get incorrectly > encrypted [TS] information with TripleDES, so higher layer will be needed. This layer doesn't even care whether it's 3DES; it's not "incorrect" at all for this layer. Anyway, as with your "A" option, I see that if "C" is chosen then (almost) all mention of Suite-B should be removed from the OpenPGP ECC specification, aside from as I've mentioned above ("a subset of OpenPGP ECC may be") > However, as an implementor I see value in splitting a Suite-B cloud into > layers that we can implement and test independently. Well your original document was an AES strength ECC with Suite-B capability along with it. What's come out of it was that we either need to deal fully/properly (i.e. we need to enforce ciphers somehow), *or*, we junk all notion of Suite-B in OpenPGP ECC. If we don't "do" Suite-B "properly" then we're not actually doing it at all (it either supports Suite-B or it doesn't, i.e. there is scope for it to wrongly-encrypt with 3DES, or there isn't). > Here is promised ballot. "x" for "yes". > > As an editor I think that voting C will result in faster progress of the > document. Possibly, although the removal of Suite-B from the text will probably take just as long (longer?) than adding the "features bit" (or the "stronger" SSB bit) to the text! So, my vote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Crick: A: [_] (meaningless for an implementation spec) B: [x] (ideally as a strict suite B MUST respect / MUST NOT deviate) C: [_] (may as well just remove notion of Suite-B) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iF4EAREIAAYFAkgdy1UACgkQNTbKPm/1JkC8VwD+ILAxlVcej7QfV4YVwyk+i4h4 4Fo5XnMoSPghxJtt7DwA/jVQuwzAwF5wow1k99+5+gE/qy0enRZP7C/V2EnLyVIA =UEJU -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun May 4 08:52:59 2008 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 82B0D3A6D6C for ; Sun, 4 May 2008 08:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 HQJubY9HizZH for ; Sun, 4 May 2008 08:52:55 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 75BBE3A6B23 for ; Sun, 4 May 2008 08:52:55 -0700 (PDT) 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 m44FfV8X005172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 08:41: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 m44FfVWm005171; Sun, 4 May 2008 08:41: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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44FfUHH005151 for ; Sun, 4 May 2008 08:41:30 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44FfTk26860 for ; Sun, 4 May 2008 11:41:29 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44FfO9Z007130 for ; Sun, 4 May 2008 11:41:24 -0400 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 11:41:24 -0400 References: <481CD4EB.2020309@brainhub.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote: > =================================================================== > B. Use feature bits of a key 0x02, 0x4 of > "5.2.3.24. Features" as follows: > 0x02: The default symmetric alg. of the key is AES-128 > 0x04: The default symmetric alg. of the key is AES-256 > These bits can be combined (i.e. they are not mutually > exclusive). > =================================================================== > > TOP SECRET (TS) must have 0x02 > SECRET must have 0x02|0x04=0x06 > > The existence of 0x02 or 0x04 tells that the implicit default > algorithm TripleDES is replaced by (either of) corresponding AES > algorithm(s). > > This specification may appeal to these who don't want to see Suite-B > mentioned in the "protocol/format" document. It also specifies > narrow feature using the concepts compatible with the scope of RFC > 4880. I'm not sure that option (B) is really selectable here. Or put another way, I think option (B) already exists as part of the current cipher preferences system. For example, take the entire installed user base of OpenPGP programs to date. That's a non-trivial amount of code in active use. Those programs will not know about the new feature flags, and will thus ignore them (meaning they will use 3DES as the default algorithm). Now take the case of an old key (default is 3DES) and a new key (default is AES) as recipients to a message. Let's assume that there is no agreement on ciphers, so the cipher of last resort must be used. A sender using the 4880-compliant program will (correctly) use 3DES, as it knows nothing about the feature flag telling it do behave otherwise. A new OpenPGP program might not have 3DES (why bother since AES is the new default), so one of the recipients won't be able to read the message. Okay, so we can fix that: we can enhance (B) with a rule saying that 3DES is still a MUST-implement cipher, to cover that case. Now take the reverse case: the same two recipient keys, but the sender is a new OpenPGP program that believes AES to be the default. In the case above, the message will *still* be 3DES, as the older key does not have the necessary feature flag, so the new program can't use this new feature across the entire recipient set. So given that new programs will need to have 3DES anyway to cover the transition case, and given that messages sent to a mixture of old and new keys that are forced to use the cipher of last resort will end up as 3DES.... how is (B) different than the current cipher preference system with AES listed before 3DES? David From owner-ietf-openpgp@mail.imc.org Sun May 4 09:25:10 2008 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 6B91C3A68C9 for ; Sun, 4 May 2008 09:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 YVrhe4JoAF0y for ; Sun, 4 May 2008 09:25:09 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 8310F3A67B5 for ; Sun, 4 May 2008 09:25:09 -0700 (PDT) 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 m44GDbaV018570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 09:13: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 m44GDbfd018569; Sun, 4 May 2008 09:13: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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44GDYI7018542 for ; Sun, 4 May 2008 09:13:37 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44GDXk27042 for ; Sun, 4 May 2008 12:13:33 -0400 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m44GDSBC007280 for ; Sun, 4 May 2008 12:13:28 -0400 Date: Sun, 4 May 2008 12:13:27 -0400 From: David Shaw To: OpenPGP Subject: Re: OpenPGP keys and Suite-B Message-ID: <20080504161327.GA60504@jabberwocky.com> Mail-Followup-To: OpenPGP References: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481CD4EB.2020309@brainhub.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote: > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== I vote for C. Keep the policies out of the standard and leave it up to the implementers. I'm not against having policies specified, but I'd rather see them in a different document for use by those people who need them. There is precedence here: OpenPGP specifies DSA and not DSS. David From owner-ietf-openpgp@mail.imc.org Sun May 4 09:36:00 2008 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 DF7B23A69C7 for ; Sun, 4 May 2008 09:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 zxueuIU7srms for ; Sun, 4 May 2008 09:36:00 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0E43E3A6C3C for ; Sun, 4 May 2008 09:36:00 -0700 (PDT) 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 m44GP9HO024425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 09:25: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 m44GP9ir024424; Sun, 4 May 2008 09:25: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 mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44GP7th024399 for ; Sun, 4 May 2008 09:25:08 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so851388mue.4 for ; Sun, 04 May 2008 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=mM1mqKl3h6DtR0GKu2fSWBXrObHIBqkWp8Pe32F1Hs0=; b=SOshjU6WDj0ebPHrfFxD5M4BsqRAZpSr/j3JSsTBZNQvXD0NjepS+mYtHEy2N0KofGmnmhqIcp56rQKFxJMVO83UOlGnSMEfTMEyE1kVmeWtgu4LcqHRQQZI2B7/0KzMsGRgXbX4USXFYNUPEx3OhrKnlbORny/+5ccoZNNz71I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lfkGurgdgWIFcxqwq6EAKX/b8S7iU23igdn4csTidvLd4nJEUCHvz0CbdW2SO6AwdOZ4fE9+j7aqExjRaJJ9iLLy9TlZHX3gHqfSpRLAeZ/PaE4EW+K0rOEtFfaemORVfw7zO93gyyFUVoVjGinGIOH2AsHlCKZZR3wJMTNDNCY= Received: by 10.78.147.6 with SMTP id u6mr1386907hud.39.1209918306278; Sun, 04 May 2008 09:25:06 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sun, 4 May 2008 09:25:06 -0700 (PDT) Message-ID: <117bad160805040925p2025e620l504b8be6c5f43af@mail.gmail.com> Date: Sun, 4 May 2008 17:25:06 +0100 From: "David Crick" To: "David Shaw" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP , "Andrey Jivsov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So given that new programs will need to have 3DES anyway to cover the > transition case, and given that messages sent to a mixture of old and new > keys that are forced to use the cipher of last resort will end up as 3DES.... This is (mainly) about ECC keys, and specifically about the implementations' [ability to enforce] Suite-B compliance. As old applications won't be able to understand ECC keys *at all*, we've "almost" got a clean sheet with what we do with ECC keys. "Almost," because at present ECC keys inherit 3DES as the default cipher from 4880. > how is (B) different than the current cipher preference system with > AES listed before 3DES? right - which is why my original proposal was for a stronger suite B flag, which says implementations MUST NOT process messages that fall outside of the Suite-B restrictions (that aside, Andrey has written in "OpenPGP technical/documentation terms" what I was originally trying to get across with my perhaps wrong terminology of a Strict Suite-B "flag"). (And to directly answer your question, Andrey's B is slightly different, in that while the preference system *is* ordered, implementations currently have free rein at how they use the intersection of recipient preferences; Andrey's B says that AES should be used in place of 3DES - but as you've (now) pointed out, for non-ECC keys this may mean some people receiving AES messages when in fact they can e.g. only process 3DES ones). From owner-ietf-openpgp@mail.imc.org Sun May 4 09:45:07 2008 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 973B128C2F5 for ; Sun, 4 May 2008 09:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 CdZdZLgDyEMe for ; Sun, 4 May 2008 09:45:06 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id EC8183A6B86 for ; Sun, 4 May 2008 09:45:05 -0700 (PDT) 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 m44GYRnC028937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 09:34:27 -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 m44GYRLq028936; Sun, 4 May 2008 09:34:27 -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.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44GYPI6028916 for ; Sun, 4 May 2008 09:34:26 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so532324fkq.10 for ; Sun, 04 May 2008 09:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VckS+vlqCbaUI4ccZtS61z08+rg7FmKPOnKPSRvM5tY=; b=tsDIlN8Mpu1RaXaXZ5c7z0rRh4jtfCXH6bIVvGUN5woKqvRqjsc3oyn193dUGZZ1zUEwG28FW+rSEWY1OeIIiI7J0dpa0MAiAlEg9joT2IMy7yReZ1UyeBOMhtTriMoZO/53ism8e+vXmGK2Ab70RpbKQRSBXIxru8z9EzyJnMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YdsTyhndQEmtrZgoy5HpL788AmC2or0VJAMa1w6lCGKEAKHn/vw0AJQCbQpbQGLrI8l6/d+3kK8ow5TN7f+++1WpSslMb7uScsBmTLgXmRodvD3dw9o5VEU76iSb4Nx7qQRSHNpmlyjlXWXJiBChIDRBmPDyEcza4qo7nYG/Olc= Received: by 10.78.129.16 with SMTP id b16mr1352300hud.116.1209918864146; Sun, 04 May 2008 09:34:24 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sun, 4 May 2008 09:34:24 -0700 (PDT) Message-ID: <117bad160805040934s76a499fheaf977b2d4f5d53e@mail.gmail.com> Date: Sun, 4 May 2008 17:34:24 +0100 From: "David Crick" To: OpenPGP Subject: Re: OpenPGP keys and Suite-B Cc: "David Shaw" In-Reply-To: <20080504161327.GA60504@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> <20080504161327.GA60504@jabberwocky.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, May 4, 2008 at 5:13 PM, David Shaw wrote: > > On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote: > > > =================================================================== > > C. Higher layers of application will govern compliance > > with Suite B. "ECC in OpenPGP" document will define > > reasonable superset of features required for Suite-B > > or similar government documents, but exact > > specification of the policies to use ECC in OpenPGP > > is out of scope. > > =================================================================== > > I vote for C. Keep the policies out of the standard and leave it up > to the implementers. I'm not against having policies specified, but > I'd rather see them in a different document for use by those people > who need them. There is precedence here: OpenPGP specifies DSA and > not DSS. > > David 4880 13.6 starts with: 13.6. DSA An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. It MUST NOT implement a DSA key with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. and ends with: Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. which I would say would be "on using DSA in OpenPGP." But then in the middle of those two bits has all of this: The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. which by your argument "shouldn't be in" OpenPGP. We've got the same thing with Suite-B, only the fact that it's not just a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is of 4880), but that there's a conflict between the 4880 spec and Suite-B (i.e. (at least) the issue of 3DES). From owner-ietf-openpgp@mail.imc.org Sun May 4 13:24:57 2008 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 EA4E63A6F1F for ; Sun, 4 May 2008 13:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] 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 zmqbX8ZF4QgC for ; Sun, 4 May 2008 13:24:53 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B46DE3A6F3F for ; Sun, 4 May 2008 13:22:45 -0700 (PDT) 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 m44KA2aA024671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 13:10: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 m44KA2GQ024670; Sun, 4 May 2008 13:10: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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44KA0VS024642 for ; Sun, 4 May 2008 13:10:01 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44K9xk28044 for ; Sun, 4 May 2008 16:09:59 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44K9sqZ008196 for ; Sun, 4 May 2008 16:09:54 -0400 Message-Id: <00A8C9D4-E391-4B1E-BF65-2CAD941326D1@jabberwocky.com> From: David Shaw To: OpenPGP In-Reply-To: <117bad160805040934s76a499fheaf977b2d4f5d53e@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 v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 16:09:54 -0400 References: <481CD4EB.2020309@brainhub.org> <20080504161327.GA60504@jabberwocky.com> <117bad160805040934s76a499fheaf977b2d4f5d53e@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2008, at 12:34 PM, David Crick wrote: > > On Sun, May 4, 2008 at 5:13 PM, David Shaw > wrote: >> >> On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote: >> >>> =================================================================== >>> C. Higher layers of application will govern compliance >>> with Suite B. "ECC in OpenPGP" document will define >>> reasonable superset of features required for Suite-B >>> or similar government documents, but exact >>> specification of the policies to use ECC in OpenPGP >>> is out of scope. >>> =================================================================== >> >> I vote for C. Keep the policies out of the standard and leave it up >> to the implementers. I'm not against having policies specified, but >> I'd rather see them in a different document for use by those people >> who need them. There is precedence here: OpenPGP specifies DSA and >> not DSS. >> >> David > > 4880 13.6 starts with: > > 13.6. DSA > > An implementation SHOULD NOT implement DSA keys of size less than > 1024 bits. It MUST NOT implement a DSA key with a q size of less > than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the > q size MUST be a multiple of 8 bits. > > and ends with: > > Note that earlier versions of this standard only allowed a 160-bit q > with no truncation allowed, so earlier implementations may not be > able to handle signatures with a different q size or a truncated > hash. > > which I would say would be "on using DSA in OpenPGP." But then in > the middle of those two bits has all of this: > > The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be > used in one of the following ways: > > * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or > SHA-512 hash > > * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 > hash > > * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash > > * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash > > The above key and q size pairs were chosen to best balance the > strength of the key with the strength of the hash. Implementations > SHOULD use one of the above key and q size pairs when generating DSA > keys. If DSS compliance is desired, one of the specified SHA hashes > must be used as well. [FIPS186] is the ultimate authority on DSS, > and should be consulted for all questions of DSS compliance. > > > which by your argument "shouldn't be in" OpenPGP. Not at all. There is a very substantial difference between mentioning in passing the difference between the specification and a popular standard and the addition of new semantics to enforce a difference between the specification and a popular standard. Notice we don't have a "Strict DSS" flag or anything like that. If someone wants to enforce it and draw a distinction, that's fine. OpenPGP gives people a lot of crypto parts they can put together in different ways. > We've got the same thing with Suite-B, only the fact that it's not > just > a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is > of 4880), but that there's a conflict between the 4880 spec and > Suite-B > (i.e. (at least) the issue of 3DES). Then publish an additional RFC giving whatever semantics are desired. I wouldn't want to load down the basic "ECC in OpenPGP" spec with it, any more than I'd want to see the traditional PGP trust model specified in 4880. David From owner-ietf-openpgp@mail.imc.org Sun May 4 13:46:56 2008 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 759623A6C41 for ; Sun, 4 May 2008 13:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.553 X-Spam-Level: X-Spam-Status: No, score=0.553 tagged_above=-999 required=5 tests=[HELO_MISMATCH_COM=0.553] 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 txhb1kyrO9dm for ; Sun, 4 May 2008 13:46:55 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B46FE3A6B9E for ; Sun, 4 May 2008 13:46:55 -0700 (PDT) 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 m44KZHqA035973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 13: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 m44KZGak035972; Sun, 4 May 2008 13:35:16 -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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44KZFmb035955 for ; Sun, 4 May 2008 13:35:16 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44KZEk28155 for ; Sun, 4 May 2008 16:35:14 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44KZ9bs008266 for ; Sun, 4 May 2008 16:35:09 -0400 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <117bad160805040925p2025e620l504b8be6c5f43af@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 v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 16:35:09 -0400 References: <481CD4EB.2020309@brainhub.org> <117bad160805040925p2025e620l504b8be6c5f43af@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2008, at 12:25 PM, David Crick wrote: >> So given that new programs will need to have 3DES anyway to cover the >> transition case, and given that messages sent to a mixture of old >> and new >> keys that are forced to use the cipher of last resort will end up >> as 3DES.... > > This is (mainly) about ECC keys, and specifically about the > implementations' [ability to enforce] Suite-B compliance. > > As old applications won't be able to understand ECC keys *at > all*, we've "almost" got a clean sheet with what we do with > ECC keys. "Almost," because at present ECC keys inherit > 3DES as the default cipher from 4880. I understand that this is intended to be about ECC keys, but the slate isn't even "almost" clean so long as as we're playing alongside 4880. There are a bunch of messy cross cases that make this highly resistant to cleanliness. >> how is (B) different than the current cipher preference system with >> AES listed before 3DES? > > right - which is why my original proposal was for a stronger > suite B flag, which says implementations MUST NOT process > messages that fall outside of the Suite-B restrictions (that aside, > Andrey has written in "OpenPGP technical/documentation terms" > what I was originally trying to get across with my perhaps wrong > terminology of a Strict Suite-B "flag"). This sort of thing risks putting restrictions in places that can't always handle those restrictions. Take the restriction where the implementation, in its Suite-B mode, must not allow the sending of messages to keys that can't handle Suite-B: so much so that it's even verboten to send two messages. Now take real-world examples like that of Enigmail, which uses GPG as its crypto engine. How on earth is GPG, the "OpenPGP implementation" in that system, supposed to stop Enigmail from doing that? Forget GPG even - outside of a locked down environment, how is any implementation supposed to stop the user from doing that? I'm okay with some magic flag that says "I do Suite-B", if we leave the implementation alone to deal with it (within the bounds of interoperability). I'm even more in favor of combining that with a "OpenPGP Suite-B" document that lays out all the rules, whether they pertain to the OpenPGP message format, or how a mail program is allowed to send mail. A separate document, where those who need those semantics can have them all specified in detail, but those who don't need those semantics are not encumbered with by them. David From owner-ietf-openpgp@mail.imc.org Sun May 4 13:59:51 2008 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 643C53A6F21 for ; Sun, 4 May 2008 13:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[AWL=-0.300, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_18=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 IzDrde-ZD+Mj for ; Sun, 4 May 2008 13:59:50 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 33E3C3A6F4A for ; Sun, 4 May 2008 13:56:59 -0700 (PDT) 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 m44KlXX6041234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 13:47:33 -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 m44KlXYm041232; Sun, 4 May 2008 13:47:33 -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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44KlVEJ041203 for ; Sun, 4 May 2008 13:47:31 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44KlUk28204 for ; Sun, 4 May 2008 16:47:30 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44KlPdA008315 for ; Sun, 4 May 2008 16:47:25 -0400 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 16:47:25 -0400 References: <481CD4EB.2020309@brainhub.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote: > > =================================================================== > A. Use key notations "suite-b-key@pgp.com" > with values "top secret" and "secret". > =================================================================== > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== > In other words, A and B are really C+policies. Unless I misunderstand, isn't A really the same as C (or to be very accurate, isn't A a possible implementation of C?) David From owner-ietf-openpgp@mail.imc.org Mon May 5 03:02:20 2008 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 EE60C28C145 for ; Mon, 5 May 2008 03:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 KOs4AoIvIcK2 for ; Mon, 5 May 2008 03:02:16 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id AEF1E3A67AE for ; Mon, 5 May 2008 03:02:15 -0700 (PDT) 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 m459km3N055627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 02:46:48 -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 m459kmQX055622; Mon, 5 May 2008 02:46:48 -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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m459kGFE055460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 5 May 2008 02:46:17 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JsxP3-0001zd-Ls for ; Mon, 05 May 2008 11:54:37 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JsxCw-0006nY-G7; Mon, 05 May 2008 11:42:06 +0200 From: Werner Koch To: Andrey Jivsov Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 05 May 2008 11:42:06 +0200 In-Reply-To: <481CD4EB.2020309@brainhub.org> (Andrey Jivsov's message of "Sat, 03 May 2008 14:11:07 -0700") Message-ID: <87lk2pjde9.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) 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: On Sat, 3 May 2008 23:11, openpgp@brainhub.org said: > =================================================================== > A. Use key notations "suite-b-key@pgp.com" > with values "top secret" and "secret". > =================================================================== Fine with me, but I see no need to mention it in the standard. > =================================================================== > B. Use feature bits of a key 0x02, 0x4 of > "5.2.3.24. Features" as follows: > 0x02: The default symmetric alg. of the key is AES-128 > 0x04: The default symmetric alg. of the key is AES-256 > These bits can be combined (i.e. they are not mutually > exclusive). > =================================================================== Too complicated. > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== Okay. Werner: A: B: C: x Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From owner-ietf-openpgp@mail.imc.org Mon May 5 03:15:33 2008 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 C840D3A6B28 for ; Mon, 5 May 2008 03:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 O-ew41EQlWz8 for ; Mon, 5 May 2008 03:15:32 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 827C83A695E for ; Mon, 5 May 2008 03:15:32 -0700 (PDT) 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 m459tnZQ059152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 02:55: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 m459tnTq059151; Mon, 5 May 2008 02:55: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 skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m459tT5E058996 for ; Mon, 5 May 2008 02:55:34 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 5EE895D23; Mon, 5 May 2008 10:55:17 +0100 (GMT/BST) Message-ID: <481ED98A.8040308@systemics.com> Date: Mon, 05 May 2008 11:55:22 +0200 From: Ian G User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: David Shaw Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805040925p2025e620l504b8be6c5f43af@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: >>> how is (B) different than the current cipher preference system with >>> AES listed before 3DES? >> >> right - which is why my original proposal was for a stronger >> suite B flag, which says implementations MUST NOT process >> messages that fall outside of the Suite-B restrictions (that aside, >> Andrey has written in "OpenPGP technical/documentation terms" >> what I was originally trying to get across with my perhaps wrong >> terminology of a Strict Suite-B "flag"). > > This sort of thing risks putting restrictions in places that can't > always handle those restrictions. Take the restriction where the > implementation, in its Suite-B mode, must not allow the sending of > messages to keys that can't handle Suite-B: so much so that it's even > verboten to send two messages. Now take real-world examples like that > of Enigmail, which uses GPG as its crypto engine. How on earth is GPG, > the "OpenPGP implementation" in that system, supposed to stop Enigmail > from doing that? Forget GPG even - outside of a locked down > environment, how is any implementation supposed to stop the user from > doing that? Good example. I don't believe it is possible to assert compliance with Suite-B, simply because we (whoever we are) are not the authorities on it. Others are, NIST, I assume. In such a situation, likely the best we can do is lay the framework for Suite-B *compatible* messages. Get some formats out, get some code written. And Enigmail will become (if it so desires) a Suite-B compatible client. Then, others, perhaps PGP Inc's client, will become certified to do Suite-B by jumping through all the hoops. This will create a different messaging profile, perhaps compatible with the earlier, or perhaps not. Suite-B public compatible profile, versus, Suite-B certified profile. We'll likely end up with a schitzophrenic marketplace. The first thing that will happen is that clients distribute compatible messages, to bootstrap the usage. Then, someone will create a certification profile and get it certified. Then, there will be some tiny proportion of sales for the certification profile, and the vast mass will work to the compatible modes. This is ok, as long as we end up with a large marketplace where the majority of clients speak a compatible mode. The challenge is then only for the official certified version ... how does it switch between "compatible" and "certified" messages? However, that challenge properly belongs to the commercial company that tries to take it through the certification process. (I think I am now agreeing with Jon. The best solution is to do nothing, state nothing in the document. And leave it to the company that takes it through the certification process. And let them create a new convention. And they can share that profile with other *certified* implementations under the NIST process, or with the world, as they see fit.) > I'm okay with some magic flag that says "I do Suite-B", if we leave the > implementation alone to deal with it (within the bounds of > interoperability). I'm even more in favor of combining that with a > "OpenPGP Suite-B" document that lays out all the rules, whether they > pertain to the OpenPGP message format, or how a mail program is allowed > to send mail. A separate document, where those who need those semantics > can have them all specified in detail, but those who don't need those > semantics are not encumbered with by them. I'm ok with that. I now see that it may have been just too complicated to do both ECC and Suite-B in the same document. iang From owner-ietf-openpgp@mail.imc.org Mon May 5 03:31:39 2008 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 BBC2C28C28C for ; Mon, 5 May 2008 03:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 gRYUysLklEtm for ; Mon, 5 May 2008 03:30:53 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 939D128C390 for ; Mon, 5 May 2008 03:29:33 -0700 (PDT) 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 m45ABKcn065893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 03:11: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 m45ABKqg065891; Mon, 5 May 2008 03:11: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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45ABFpA065863 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 5 May 2008 03:11:17 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JsxnF-0002Cb-Pn for ; Mon, 05 May 2008 12:19:37 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JsxaK-0006ow-BP; Mon, 05 May 2008 12:06:16 +0200 From: Werner Koch To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> <87r6d4eu4g.fsf@wheatstone.g10code.de> <4808ECD9.8050204@brainhub.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 05 May 2008 12:06:15 +0200 In-Reply-To: <4808ECD9.8050204@brainhub.org> (Andrey Jivsov's message of "Fri, 18 Apr 2008 11:47:53 -0700") Message-ID: <87hcddjca0.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) 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: On Fri, 18 Apr 2008 20:47, openpgp@brainhub.org said: > Pros for OpenPGP IDs. > > 1) Vote of confidence for a particular curve. If it is included, > potential implementers have agreed on it. It will be more likely > widely supported. For example this is useful for hardware folks who > plan far ahead, plays in the decisions about which curve to use in key > self-signatures, and gives priorities to performance optimizations. The same can be said of OIDs. > 2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()). Well, okay. > 3) consistency with the way OpenPGP references other algorithms. Only if we agree that a curveID describes an OpenPGP algorithm. In my view this is a parameter of the algorithm, much like p, q and g in DSA or even the key size of all aglgorithms. For sure I do not want to convey all ECC curve parameters, thus using a way to describe the curve is important. > 4) Named curves can be introduced as an extension. The core set of > curves will be encoded as integers, others as named curves. I thought of that and was about to propose a format using an ID of 0 to identify a named curve. However the specification as well as the code will be more complicated - even in the case that named curves are not supported by the implementation. > Do you see any value in having some approval process for new curves? > Does it bother you that I can use some questionable curve and it will > carry equal status per the spec to the three curves we discussed so > far (will we have a method to distinguish "next good" curve past P-521 > from an experimental curve) ? No. We also don't approve implementations and have no real limits on key sizes. It is easy to get things wrong. Using a good curve is as important as to use sound parameters for RSA. > Can we reach an agreement if the document also defined a method to > list named curves, along the lines of Werner's proposal? If there is no other way to allow for arbitrary curves, I would agree to it. However, I still believe that an OID with a memcmp in the code is easier to implement than a numeric ID with a switch and a mechnism to cope withe the optional OID named curve. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From owner-ietf-openpgp@mail.imc.org Mon May 5 03:55:51 2008 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 D2F5D28C332 for ; Mon, 5 May 2008 03:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 DWm6PSfOd9Vb for ; Mon, 5 May 2008 03:55:50 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7CA4628C2DC for ; Mon, 5 May 2008 03:55:50 -0700 (PDT) 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 m45Ai05f079005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 03:44: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 m45Ai0vo079004; Mon, 5 May 2008 03:44: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 skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45AhwlE078984 for ; Mon, 5 May 2008 03:43:59 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 4AB655D23; Mon, 5 May 2008 11:43:51 +0100 (GMT/BST) Message-ID: <481EE4ED.8060503@systemics.com> Date: Mon, 05 May 2008 12:43:57 +0200 From: Ian G User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Andrey Jivsov Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> In-Reply-To: <481CD4EB.2020309@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== Iang: A: B: C: x. iang PS: the rest of the original post looks great for an intro to a document describing a potential Suite-B compatible profile. From owner-ietf-openpgp@mail.imc.org Mon May 5 07:04:36 2008 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 DD3563A6B65 for ; Mon, 5 May 2008 07:04:36 -0700 (PDT) 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 y0tcrq04k1lC for ; Mon, 5 May 2008 07:04:36 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BFD093A68D5 for ; Mon, 5 May 2008 07:04:35 -0700 (PDT) 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 m45Dq8HD050223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 06:52:08 -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 m45Dq8JY050222; Mon, 5 May 2008 06:52:08 -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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45Dq6q0050214 for ; Mon, 5 May 2008 06:52:07 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by nf-out-0910.google.com with SMTP id 30so1132904nfu.24 for ; Mon, 05 May 2008 06:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=c7xMncbiuGKl1Poe9MOm8BZ+K6T66MqY1CRCegl8dFs=; b=B14D/mLHzxvLHvpe0wVkWUOOJ64vTCv3AzIt5940On3ko5DMIA+L5gKGw4RoocIKnqwwhqozoB/QVH8BPfWzmoRINBMTO2h7Tv3IpHfKtX0t7OQIbMXKYj8t0gn7gj2zLumDPIvGL2jwYxxKFKAvE2uJJKHjUFQF+8tr9KR8zLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rksLi9aImkSjE3vWcMWkr/UyIYJRYTYlcQeQGB1k0+Ydz2lw/eoepYB/vbRCHNxaAAr5OWq3PWxYN1BmlARdwelhMpSkedcGPGIMyRUwTouU+d5krc+LsE+T7PSEXKu+L850JCzT6DoLNWt+ddZnZCbNNSYwxg495LQHATmiIgA= Received: by 10.78.21.7 with SMTP id 7mr1619943huu.69.1209995525322; Mon, 05 May 2008 06:52:05 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Mon, 5 May 2008 06:52:05 -0700 (PDT) Message-ID: <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> Date: Mon, 5 May 2008 14:52:05 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Here is promised ballot. "x" for "yes". Well unless there is some Microsoft-style vote-stuffing / strange consensus counting, it looks like Andrey's C has carried. I'm happy with that - I'd rather see Suite-B left out than "put in with problems." Andrey - do you want to start a re-write of the submitted document "without" Suite-B? I will be more than happy to (then) do my long-promised clarity review - although I'm sure removing Suite-B will just by itself reduce a lot of the current complexity and verbiage. From owner-ietf-openpgp@mail.imc.org Mon May 5 14:57:49 2008 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 A472D28C363 for ; Mon, 5 May 2008 14:57:49 -0700 (PDT) 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 yzVM0eRL2xQO for ; Mon, 5 May 2008 14:57:48 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 813CC28C35E for ; Mon, 5 May 2008 14:57:48 -0700 (PDT) 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 m45LlT3q041398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:47: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 m45LlT4N041397; Mon, 5 May 2008 14:47: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 merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45LlSkW041387 for ; Mon, 5 May 2008 14:47:29 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 1FFA2F1FED5 for ; Mon, 5 May 2008 14:47:27 -0700 (PDT) Received: from bgillson-d620.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 05 May 2008 14:47:28 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 05 May 2008 14:47:28 -0700 Message-Id: <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> From: Jon Callas To: OpenPGP In-Reply-To: <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Mon, 5 May 2008 14:47:26 -0700 References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 5, 2008, at 6:52 AM, David Crick wrote: > >> Here is promised ballot. "x" for "yes". > > Well unless there is some Microsoft-style vote-stuffing > / strange consensus counting, it looks like Andrey's C > has carried. Excuse me, but we operate by rough consensus, not voting. While it's appropriate to have a straw poll to get the feeling of what the consensus is, things do not "carry" -- and certainly ending a straw poll on Monday afternoon that went out on Saturday might look a lot like vote-stuffing to someone who worried about such things. Having said that, I also like C. Rough consensus seems to be going that way, but we'd want to give people a week or so. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIH4BwsTedWZOD3gYRAjslAKCorzXVHcfv7J0yLgpGKOEDpTZClQCfewPM Pwx+fkHBEPCkLNGiuYiB1Os= =s/Zs -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue May 6 13:31:24 2008 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 DC8FE3A67D0 for ; Tue, 6 May 2008 13:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 xBXPBzPVf7nO for ; Tue, 6 May 2008 13:31:24 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 62C323A67A8 for ; Tue, 6 May 2008 13:31:23 -0700 (PDT) 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 m46K4AcA002704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 13:04: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 m46K4ADS002703; Tue, 6 May 2008 13:04: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 brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46K485F002693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 May 2008 13:04:09 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [10.214.201.192] ([64.1.215.241]) by brainhub.org (8.14.2/8.14.1) with ESMTP id m46K48uE005699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 May 2008 13:04:08 -0700 Message-ID: <4820B9B2.1010500@brainhub.org> Date: Tue, 06 May 2008 13:04:02 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> In-Reply-To: <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I sent it out incorrectly, re-sending] A few comments to David Crick: > I agree. In fact I would go further and say if A is the way forward > chosen then we should remove *all* mention of Suite-B from the > OpenPGP ECC proposal, except for perhaps a paragraph noting that a > subset of OpenPGP ECC may be used as the basis for Suite B > implementations. I agree that there is inconsistency in that if we go with "C", i.e. we anticipate another separate document (standard or just a best practices write-up), then Suite-B text from ECC in OpenPGP document can be moved elsewhere. At the same Suite-B and NSA are, as Jon Callas called them "big elephant in the room" and from this point of view I can see value in the current text that gives an idea of what is needed for Suite-B. It seems that there is good consensus against increase in the text referring to Suite-B in the document. I will wait and listen for a few days regarding how to reduce/improve what currently have. to David Shaw: > I'm not sure that option (B) is really selectable here. Or put > another way, I think option (B) already exists as part of the current > cipher preferences system. > > For example, take the entire installed user base of OpenPGP programs > to date. That's a non-trivial amount of code in active use. Those > programs will not know about the new feature flags, and will thus > ignore them (meaning they will use 3DES as the default algorithm). I meant to introduce it with ECC keys. Here we have an advantage that these keys can only be understood by new software. This is better than circumstances before the adoption of MDC. > Now take the case of an old key (default is 3DES) and a new key > (default is AES) as recipients to a message. Let's assume that there > is no agreement on ciphers, so the cipher of last resort must be > used. A sender using the 4880-compliant program will (correctly) use > 3DES, as it knows nothing about the feature flag telling it do behave > otherwise. A new OpenPGP program might not have 3DES (why bother > since AES is the new default), so one of the recipients won't be able > to read the message. Okay, so we can fix that: we can enhance (B) > with a rule saying that 3DES is still a MUST-implement cipher, to > cover that case. Correct, RFC4880 MUSTs are carried over in general. > Now take the reverse case: the same two recipient keys, but the > sender is a new OpenPGP program that believes AES to be the default. > In the case above, the message will *still* be 3DES, as the older key > does not have the necessary feature flag, so the new program can't > use this new feature across the entire recipient set. The though was that since the feature removes 3DES as implicit default, the two subsets of recipients -- one with 3DES common algorithm and another with AES -- will get empty intersection. This will result in a sending error. > So given that new programs will need to have 3DES anyway to cover the > transition case, and given that messages sent to a mixture of old > and new keys that are forced to use the cipher of last resort will > end up as 3DES.... how is (B) different than the current cipher > preference system with AES listed before 3DES? It is different in one important feature: it allows the removal of legacy algorithm from the default. This is not a panacea and will break interoperability in some cases. > Unless I misunderstand, isn't A really the same as C (or to be very > accurate, isn't A a possible implementation of C?) "A" is a way to have specific Suite-B flag, unlike B, which is more aligned with RFC 4880 and really deals with 3DES-AES succession. There are many "A"s possible, the one given is the bare minimum, since it doesn't say much. C basically says that A and B are out of scope. > This sort of thing risks putting restrictions in places that can't > always handle those restrictions. Take the restriction where the > implementation, in its Suite-B mode, must not allow the sending of > messages to keys that can't handle Suite-B: so much so that it's even > verboten to send two messages. Now take real-world examples like > that of Enigmail, which uses GPG as its crypto engine. How on earth > is GPG, the "OpenPGP implementation" in that system, supposed to stop > Enigmail from doing that? Forget GPG even - outside of a locked down > environment, how is any implementation supposed to stop the user > from doing that? Yes, this thread shows that there is clearly more to Suite-B than a few web pages that NSA has put up. Many of these issues, such as the security level of information, is outside of traditional domain of OpenPGP. I suppose an e-mail application in Suite-B environment might have a UI combobox with SECRET/TOP SECRET choices in the compose window that magically (based on content or at worst manually) are set to the correct level. The rest is easier to program: this would allow software to check that [TS] information is being sent to [S] key(s) and block it. Thank you everybody else, Jon, Werner, and Ian, for their comments. From ferngo@hotmail.com Tue May 6 16:48:43 2008 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 960853A67E5; Tue, 6 May 2008 16:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.6 X-Spam-Level: X-Spam-Status: No, score=-76.6 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IP_ADDR=1.119, HOST_EQ_MODEMCABLE=1.368, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RAZOR2_CHECK=0.5, RDNS_DYNAMIC=0.1, URIBL_BLACK=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 7JCUP95u1nUf; Tue, 6 May 2008 16:48:42 -0700 (PDT) Received: from [86.14.201.146] (cpc3-gran2-0-0-cust401.nott.cable.ntl.com [86.14.201.146]) by core3.amsl.com (Postfix) with ESMTP id 607E728C4F2; Tue, 6 May 2008 16:48:38 -0700 (PDT) Received: from [86.14.201.146] by mx4.hotmail.com; Wed, 7 May 2008 00:48:35 +0100 Message-ID: <01c8afdc$1466b380$92c90e56@ferngo> From: "AdWords-NoReplay" To: Subject: You have one or more alerts. Date: Wed, 7 May 2008 00:48:35 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C8AFDC.1466B380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C8AFDC.1466B380 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. -------------------------------------------------------------------------= - Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment info= rmation. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------= -- We look forward to providing you with the most effective advertising avai= lable. Thank you for choosing AdWords. ------=_NextPart_000_0007_01C8AFDC.1466B380 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable ---------------------------------------------------------------------
This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
------------------------------------------------------------------------<= br> Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment info= rmation.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

-------------------------------------------------------------------------= ----
We look forward to providing you with the most effective advertising avai= lable.
Thank you for choosing AdWords.
-------------------------------------------------------------------------= -
------=_NextPart_000_0007_01C8AFDC.1466B380-- From owner-ietf-openpgp@mail.imc.org Wed May 7 06:52:40 2008 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 0416628C652 for ; Wed, 7 May 2008 06:52:40 -0700 (PDT) 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 mnWg-SNTpLym for ; Wed, 7 May 2008 06:52:35 -0700 (PDT) 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 BDA7928C653 for ; Wed, 7 May 2008 06:51:41 -0700 (PDT) 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 m47Dd6dr041965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 06:39: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 m47Dd6xm041964; Wed, 7 May 2008 06:39: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 fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47Dd4k9041953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 May 2008 06:39:05 -0700 (MST) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 4845D5299; Wed, 7 May 2008 09:39:04 -0400 (EDT) From: Greg Troxel To: "David Crick" Cc: "Andrey Jivsov" , "Jon Callas" , OpenPGP Subject: Re: I have a technical idea/change for the ECC draft References: <117bad160804121421t49a6ed13uc1b106e37c054c95@mail.gmail.com> <7230A39A-46DA-41AC-9967-10D0F461E998@callas.org> <4803C108.6000203@brainhub.org> <117bad160804141423r6dea71a7ye1f0ecb20eb4b29e@mail.gmail.com> X-Hashcash: 1:20:080507:openpgp@brainhub.org::aITVSuUGMnnOCziY:000000000000000000000000000000000000000000nXA X-Hashcash: 1:20:080507:ietf-openpgp@imc.org::aITVSuUGMnnOCziY:000000000000000000000000000000000000000002Cey X-Hashcash: 1:20:080507:jon@callas.org::m16kbULCz3rAf9Rs:00044oV X-Hashcash: 1:20:080507:dacrick@gmail.com::aITVSuUGMnnOCziY:0000000000000000000000000000000000000000000079K+ Date: Wed, 07 May 2008 09:39:04 -0400 In-Reply-To: <117bad160804141423r6dea71a7ye1f0ecb20eb4b29e@mail.gmail.com> (David Crick's message of "Mon, 14 Apr 2008 22:23:51 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix) 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: "David Crick" writes: >> What do we loose if we >> instead use "this key replaces TrippleDES implicit algorithm with AES-128" >> notation? This would be beneficial for RSA keys too. > > what if we have: > > Alice: {AES256, AES128, AESover3DESflag [, 3DES implicitly]} > Bob: {3DES [, AES128 implicitly]} > > Then Bob or his software could legitamately choose 3DES. > > whereas: > > Alice: ECC-384/521 key with {AES256, SuiteBOnly} and > Alice: ECC-256 key with { [AES128 implicit], SuiteBOnly} > > would refuse to encrypt with anything except AES256 and > AES128 respectively. I think there's a fundamental mismatch between OpenPGP-style key preferences and Suite B thinking. As a sender, with labeled information, you can only use approved algorithms. Thus, if a recipient doesn't list the approved algorithm, you just can't send them mail. The OpenPGP-style key preferences are in my view primarily to ensure interoperability and allow for algorithm transitions over long timescales. Are we proposing sender-side rules to match labels to approved algorithms? It seems inadequate to put 'SuiteBOnly' as a key preference on recipients. From owner-ietf-openpgp@mail.imc.org Wed May 7 06:52:54 2008 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 C455328C650 for ; Wed, 7 May 2008 06:52:53 -0700 (PDT) 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 MQY13KLXLUZ0 for ; Wed, 7 May 2008 06:52:43 -0700 (PDT) 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 DFDEF28C657 for ; Wed, 7 May 2008 06:52:39 -0700 (PDT) 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 m47DVKFn039527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 06:31: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 m47DVKTv039526; Wed, 7 May 2008 06:31: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 fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47DVI8j039512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 May 2008 06:31:19 -0700 (MST) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 78EA25299; Wed, 7 May 2008 09:31:17 -0400 (EDT) From: Greg Troxel To: Andrey Jivsov Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> <4820B9B2.1010500@brainhub.org> X-Hashcash: 1:20:080507:ietf-openpgp@imc.org::ZTnTPjQUmfA/2L3D:0000000000000000000000000000000000000000009wd X-Hashcash: 1:20:080507:openpgp@brainhub.org::pog9lR3IbdWxQuMQ:000000000000000000000000000000000000000000hOI Date: Wed, 07 May 2008 09:31:17 -0400 In-Reply-To: <4820B9B2.1010500@brainhub.org> (Andrey Jivsov's message of "Tue, 06 May 2008 13:04:02 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix) 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: Andrey Jivsov writes: > Many of these issues, such as the security level of information, is > outside of traditional domain of OpenPGP. I suppose an e-mail > application in Suite-B environment might have a UI combobox with > SECRET/TOP SECRET choices in the compose window that magically (based > on content or at worst manually) are set to the correct level. The > rest is easier to program: this would allow software to check that > [TS] information is being sent to [S] key(s) and block it. I am a bit boggled as to the point of this discusion. It seems rather unlikely that an OpenPGP software implementation will be approved to handle classified traffic, and even less likely that a user on a computer running a GUI will have available adequate MLS facilities to choose the level of a message. Are we talking about being able to have an OpenPGP implementation be configured to follow Suite B guidelines for S or TS, intended for use with unclassified information? This would perhaps follow the reasonable theory that such guidelines define best practices for algorithm choice. Are we talking about hardened implementations that would implement mail gateways between enclaves? Or something else? I don't mean to be difficult, but I really don't get it. From owner-ietf-openpgp@mail.imc.org Wed May 7 17:53:47 2008 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 8C4973A63D3 for ; Wed, 7 May 2008 17:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.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 CDEqrY4Sno3z for ; Wed, 7 May 2008 17:53:39 -0700 (PDT) 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 5DABA3A6ACC for ; Wed, 7 May 2008 17:53:39 -0700 (PDT) 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 m480bv7V095929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 17:37: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 m480bv6v095928; Wed, 7 May 2008 17:37:57 -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 brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m480bnI6095871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 May 2008 17:37:56 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [10.214.201.192] ([64.1.215.241]) by brainhub.org (8.14.2/8.14.1) with ESMTP id m480bm8o008092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 17:37:49 -0700 Message-ID: <48224B57.90002@brainhub.org> Date: Wed, 07 May 2008 17:37:43 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Greg Troxel CC: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> <4820B9B2.1010500@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Troxel wrote: > Andrey Jivsov writes: > > >> Many of these issues, such as the security level of information, is >> outside of traditional domain of OpenPGP. I suppose an e-mail >> application in Suite-B environment might have a UI combobox with >> SECRET/TOP SECRET choices in the compose window that magically (based >> on content or at worst manually) are set to the correct level. The >> rest is easier to program: this would allow software to check that >> [TS] information is being sent to [S] key(s) and block it. >> > > I am a bit boggled as to the point of this discusion. It seems rather > unlikely that an OpenPGP software implementation will be approved to > handle classified traffic, and even less likely that a user on a > computer running a GUI will have available adequate MLS facilities to > choose the level of a message. > This was an answer to a hypothetical question "Now take real-world examples like that of Enigmail, which uses GPG as its crypto engine. How on earth is GPG, the "OpenPGP implementation" in that system, supposed to stop Enigmail from doing that?". I assumed as an axiom that Enigmail and gpg are running in this environment. I was trying to point out that we need another parameter -- the security level for the information -- and that it should come from "somewhere above" in reference to OpenPGP format. It cannot be deduced from recipient keys. > Are we talking about being able to have an OpenPGP implementation be > configured to follow Suite B guidelines for S or TS, intended for use > with unclassified information? This would perhaps follow the reasonable > theory that such guidelines define best practices for algorithm choice. > > Are we talking about hardened implementations that would implement mail > gateways between enclaves? > OpenPGP format can be used to encrypt any traffic. The proposal even has stronger public key algorithm P-521 beyond P-384 mandated by [TS]. > Or something else? I don't mean to be difficult, but I really don't get > it. > So far, I think we are getting consensus that ECC in OpenPGP should be a format document. How an application is designed is beyond the scope of ECC. Gateway is probably easier to do right, but end-to-end has value in that users can be authenticated using multifactor authentication. I suppose you, Greg, don't argue that OpenPGP format can be used for any Suite-B traffic in properly designed application. ECC in OpenPGP is a format and the system itself can be implemented in hardware, or a combination of software and HSM (this should be our task to ensure this compatibility with smartcards and HSMs). From findlorne@yahoo.com Mon May 12 13:49:36 2008 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 C3B8C3A68C5 for ; Mon, 12 May 2008 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.882 X-Spam-Level: X-Spam-Status: No, score=-41.882 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MSGID_YAHOO=1.713, HELO_EQ_IP_ADDR=1.119, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, 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_DYNAMIC=0.1, SARE_HEAD_BAT_WEB=3.333, 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 JM04H6W50OON for ; Mon, 12 May 2008 13:49:36 -0700 (PDT) Received: from [68.39.21.127] (c-68-39-21-127.hsd1.nj.comcast.net [68.39.21.127]) by core3.amsl.com (Postfix) with ESMTP id EB3FA3A6BA0 for ; Mon, 12 May 2008 13:49:34 -0700 (PDT) Received: from [68.39.21.127] by a.mx.mail.yahoo.com; Mon, 12 May 2008 14:49:33 -0600 Date: Mon, 12 May 2008 14:49:33 -0600 From: "Google-AdWords-noreply" X-Mailer: The Bat! (v2.10.03) Personal Reply-To: findlorne@yahoo.com X-Priority: 3 (Normal) Message-ID: <088478783.61442799262404@yahoo.com> To: openpgp-archive@ietf.org Subject: Account Reactivation. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------{nHEX}" ------------{nHEX} Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 7bit -------------------------------------------------------------------------- Dear Google AdWords Customer, We were unable to process your payment. Your ads will be suspended soon unless we can process your payment. To prevent your ads from being suspended, please update your payment information. Please sign in to your account at http://adwords.google.com/select/login, and update your payment information. -------------------------------------------------------------------------------------- This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message. ----------------------------------------------------------------------------------------------- We look forward to providing you with the most effective advertising available. Thank you for choosing AdWords. ------------{nHEX} Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit -------------------------------------------------------------------------------------------
Dear Google AdWords Customer,

We were unable to process your payment.
Your ads will be suspended soon unless we can process your payment.
To prevent your ads from being suspended, please update your payment information.

Please sign in
to your account at http://adwords.google.com/select/login,
and update your payment information.

--------------------------------------------------------------------------------------
This message was sent from a notification-only email address that does
not accept incoming email. Please do not reply to this message.
-----------------------------------------------------------------------------------
------------{nHEX}-- From owner-ietf-openpgp@mail.imc.org Fri May 16 00:40:51 2008 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 0640128C157 for ; Fri, 16 May 2008 00:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 UeiRhkTSzUUk for ; Fri, 16 May 2008 00:40:50 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id E4BC228C15B for ; Fri, 16 May 2008 00:40:46 -0700 (PDT) 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 m4G71Usj033372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 00:01: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 m4G71UBV033371; Fri, 16 May 2008 00:01: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 mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4G70wnZ033269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 16 May 2008 00:01:30 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m4G77x55020972 for ; Fri, 16 May 2008 03:08:55 -0400 Message-ID: <482D30C4.80402@brainhub.org> Date: Thu, 15 May 2008 23:59:16 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> <87r6d4eu4g.fsf@wheatstone.g10code.de> <4808ECD9.8050204@brainhub.org> <87hcddjca0.fsf@wheatstone.g10code.de> In-Reply-To: <87hcddjca0.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I see three aspects of the issue. 1. The desire to control curves. What degree of freedom is appropriate? Currently the document says: "Future allocations in the registry will be done by IETF Expert Review process after general consensus between implementors of the standard is reached." It doesn't allow other curves without general agreement (exact body that makes approval is not critical). The following item explains the reasons. 2. Different curve is not the same as different RSA key size. The following argument will rely on implementation specifics that are unique to ECC. Currently http://www.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt only allows curves over prime underlying field. The primes selected for these fields are, forgive my exaggeration, weak primes. That is, they are primes very close to 2^m. The purpose of these primes is to construct finite fields with fastest operations for the given field size. This field is called underlying field of EC. The cryptography of ECC doesn't depend on the strength of operations in the underlying field, so the use of such special primes is justified. While it is possible to use general-purpose large-integer library to implement operations in the underlying field, this is not practical for performance reasons. Implementations will achieve better performance by tuning the code for each underlying field at compile time, or, in case of hardware, this may be done by the manufacturing time. Conversely, even when RSA is implemented in hardware, a parameter to RSA key size is almost certainly a variable in software. There is nothing to gain by separately implementing RSA 2048 and RSA 4096 operations. 3. Finally, there is a question of how to reference a curve. Currently the draft uses numeric IDs, consistent with other IDs in RFC 4880. With the exception of using less space to encode more RFC4880-aligned ID v.s. DER OID and slightly better lookup time, I see two approaches as similar. Some of pros and cons were mentioned earlier. Given my opinion on 1., 3., and statement 2., and that the use of OID will need substantial rewrite of the draft, I prefer to use one byte curve ID. I see the difficulty of obtaining curve ID as a feature. I don't see the ease of introduction of new curve ID as a way to improve interoperability. If an implementation publicly stated that it implements IDs 1, 2, and 3, it's a loosing bet to expect that it will support any other curve. Compare this with RSA support. To put this differently, as an implementor I would like to hear in advance that another curve ID is going to be introduced into OpenPGP installation base, while my RSA implementation is capable of handling any key size within a reasonable range. This issue is lingering unresolved between a few of us who expressed their opinions. I would appreciate opinion of the list on the following items. Please read the introduction above and mark your vote. ================================================================== A: Keep current text regarding the procedure to approve new curves (for/against) ================================================================== B: Keep current method to encode curve IDs as numeric IDs (for/against) ================================================================== C: Need extension mechanism specified in the draft to add other curves (for/against) ================================================================== Andrey: A: for B: for C: against Thank you. Werner Koch wrote: > On Fri, 18 Apr 2008 20:47, openpgp@brainhub.org said: > >> Pros for OpenPGP IDs. >> >> 1) Vote of confidence for a particular curve. If it is included, >> potential implementers have agreed on it. It will be more likely >> widely supported. For example this is useful for hardware folks who >> plan far ahead, plays in the decisions about which curve to use in key >> self-signatures, and gives priorities to performance optimizations. > > The same can be said of OIDs. > >> 2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()). > > Well, okay. > >> 3) consistency with the way OpenPGP references other algorithms. > > Only if we agree that a curveID describes an OpenPGP algorithm. In my > view this is a parameter of the algorithm, much like p, q and g in DSA > or even the key size of all aglgorithms. > > For sure I do not want to convey all ECC curve parameters, thus using a > way to describe the curve is important. > >> 4) Named curves can be introduced as an extension. The core set of >> curves will be encoded as integers, others as named curves. > > I thought of that and was about to propose a format using an ID of 0 to > identify a named curve. However the specification as well as the code > will be more complicated - even in the case that named curves are not > supported by the implementation. > >> Do you see any value in having some approval process for new curves? >> Does it bother you that I can use some questionable curve and it will >> carry equal status per the spec to the three curves we discussed so >> far (will we have a method to distinguish "next good" curve past P-521 >> from an experimental curve) ? > > No. We also don't approve implementations and have no real limits on > key sizes. It is easy to get things wrong. Using a good curve is as > important as to use sound parameters for RSA. > >> Can we reach an agreement if the document also defined a method to >> list named curves, along the lines of Werner's proposal? > > If there is no other way to allow for arbitrary curves, I would agree to > it. However, I still believe that an OID with a memcmp in the code is > easier to implement than a numeric ID with a switch and a mechnism to > cope withe the optional OID named curve. > > > Salam-Shalom, > > Werner > > From cabrerarvgjkmko@oxfordaunts.co.uk Sun May 18 09:53:29 2008 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 4BEBA3A6C51; Sun, 18 May 2008 09:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -80.008 X-Spam-Level: X-Spam-Status: No, score=-80.008 tagged_above=-999 required=5 tests=[FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, HELO_DYNAMIC_DHCP=1.52, HELO_DYNAMIC_IPADDR=2.935, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 x65aBx6RVnHk; Sun, 18 May 2008 09:53:28 -0700 (PDT) Received: from cable200-116-144-27.epm.net.co (cable200-116-144-27.epm.net.co [200.116.144.27]) by core3.amsl.com (Postfix) with SMTP id BBBAD28C4F0; Sun, 18 May 2008 09:53:21 -0700 (PDT) X-Originating-IP: 183.226.28.168 by smtp.200.116.144.27; Sun, 18 May 2008 12:53:22 -0500 Message-ID: From: "Don Conner" Reply-To: "Don Conner" To: notifications@ietf.org Subject: Get one of these awesome replicas Date: Sun, 18 May 2008 12:53:22 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit An IWC watch is a uniquely handcrafted time piece that combines a classical element with a timeless elegance. Its appeal comes from their traditional beauty and their superb performance. But this sophistication has always come with a high price tag. Except of course, when you buy an IWC replica. And Prestige Replicas has dozens of IWC replica watches at prices so incredibly low that you can rest assured they won't last long! So, why not head over to Prestige Replicas right now and take a look at their IWC watches? After all, isn't it time you wore a splendid wristwatch without having to spend a fortune? http://taxowera28376.blogspot.com/ No virus found in this outgoing message Checked by PC Tools AntiVirus (4.0.0.26 - 10.072.012). http://www.pctools.com/free-antivirus/ From c.klein@datagis.com Sun May 18 10:00:02 2008 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 786E13A6A56; Sun, 18 May 2008 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.954 X-Spam-Level: X-Spam-Status: No, score=-88.954 tagged_above=-999 required=5 tests=[FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.52, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, 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 ORtwbhsfx3Wn; Sun, 18 May 2008 10:00:01 -0700 (PDT) Received: from adsl-72-50-13-202.prtc.net (adsl-72-50-13-202.prtc.net [72.50.13.202]) by core3.amsl.com (Postfix) with SMTP id 86FA03A67E2; Sun, 18 May 2008 09:59:37 -0700 (PDT) X-Originating-IP: 212.95.164.31 by smtp.72.50.13.202; Sun, 18 May 2008 12:59:37 -0500 Message-ID: From: "Lanny Rhoades" Reply-To: "Lanny Rhoades" To: openpgp-archive@ietf.org Subject: Why get an original watch? Date: Sun, 18 May 2008 12:59:37 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://sepuduwa17004.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://sepuduwa17004.blogspot.com/ From c.lenaerts@waypoint-design.com Sun May 18 13:27:09 2008 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 473113A6800; Sun, 18 May 2008 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -76.263 X-Spam-Level: X-Spam-Status: No, score=-76.263 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, RCVD_IN_BL_SPAMCOP_NET=2.188, RCVD_IN_DSBL=0.753, RCVD_IN_PBL=0.509, RCVD_IN_SORBS_DUL=1.615, RCVD_IN_XBL=2.896, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, 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 w7a9SvQ+EATC; Sun, 18 May 2008 13:27:08 -0700 (PDT) Received: from cliente-10702.iberbanda.es (unknown [82.198.105.204]) by core3.amsl.com (Postfix) with SMTP id 38BFA3A690F; Sun, 18 May 2008 13:26:43 -0700 (PDT) X-Originating-IP: 168.170.57.130 by smtp.82.198.105.204; Sun, 18 May 2008 16:26:44 -0500 Message-ID: From: "Nona Black" Reply-To: "Nona Black" To: atompub-archive@megatron.ietf.org Subject: Replica watches made easy Date: Sun, 18 May 2008 16:26:44 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://rywafyko20118.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://rywafyko20118.blogspot.com/ From cach@coulterhurst.co.uk Sun May 18 23:58:18 2008 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 9805528C124; Sun, 18 May 2008 23:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.257 X-Spam-Level: X-Spam-Status: No, score=-11.257 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, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR=2.426, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 QO3B9ztF8w7a; Sun, 18 May 2008 23:58:17 -0700 (PDT) Received: from bzq-79-176-123-137.red.bezeqint.net (bzq-79-176-123-137.red.bezeqint.net [79.176.123.137]) by core3.amsl.com (Postfix) with SMTP id 810603A69E1; Sun, 18 May 2008 23:57:50 -0700 (PDT) X-Originating-IP: 161.140.196.165 by smtp.79.176.123.137; Mon, 19 May 2008 02:57:50 -0500 Message-ID: From: "Eve Parrish" Reply-To: "Eve Parrish" To: notifications@ietf.org Subject: One of a kind replicas Date: Mon, 19 May 2008 02:57:50 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://tegasufu63235.shheus.com/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://tegasufu63235.shheus.com/ From c.michele@prima88.it Mon May 19 13:22:49 2008 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 34C283A6835; Mon, 19 May 2008 13:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -56.55 X-Spam-Level: X-Spam-Status: No, score=-56.55 tagged_above=-999 required=5 tests=[BAYES_95=3, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR=2.426, 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, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, 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 nRnvxJ0ZRvI1; Mon, 19 May 2008 13:22:48 -0700 (PDT) Received: from d83-186-12-93.cust.tele2.be (d83-186-12-93.cust.tele2.be [83.186.12.93]) by core3.amsl.com (Postfix) with SMTP id 58AF228C0FB; Mon, 19 May 2008 13:22:28 -0700 (PDT) X-Originating-IP: 250.134.27.182 by smtp.83.186.12.93; Mon, 19 May 2008 16:22:30 -0500 Message-ID: From: "Raul Feliciano" Reply-To: "Raul Feliciano" To: notifications@ietf.org Subject: Affordable replica watches Date: Mon, 19 May 2008 16:22:30 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://wohahykaxyt16.blogspot.com/ From owner-ietf-openpgp@mail.imc.org Mon May 19 17:19:41 2008 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 06B313A6AF5 for ; Mon, 19 May 2008 17:19:41 -0700 (PDT) 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 E3RsYX49JsfG for ; Mon, 19 May 2008 17:19:38 -0700 (PDT) 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 62CC23A6978 for ; Mon, 19 May 2008 17:19:36 -0700 (PDT) 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 m4JNpN4L005877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 16:51: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 m4JNpNKg005876; Mon, 19 May 2008 16:51: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 merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4JNpLYH005858 for ; Mon, 19 May 2008 16:51:22 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 2DE07F88BA8 for ; Mon, 19 May 2008 16:51:19 -0700 (PDT) Received: from [10.214.0.157] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 19 May 2008 16:51:21 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 May 2008 16:51:21 -0700 Cc: Andrey Jivsov , OpenPGP Message-Id: <5883F699-2520-47E8-B66D-43CE4EC16F4A@callas.org> From: Jon Callas To: Greg Troxel In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Mon, 19 May 2008 16:51:18 -0700 References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> <4820B9B2.1010500@brainhub.org> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 7, 2008, at 6:31 AM, Greg Troxel wrote: > > Andrey Jivsov writes: > >> Many of these issues, such as the security level of information, is >> outside of traditional domain of OpenPGP. I suppose an e-mail >> application in Suite-B environment might have a UI combobox with >> SECRET/TOP SECRET choices in the compose window that magically (based >> on content or at worst manually) are set to the correct level. The >> rest is easier to program: this would allow software to check that >> [TS] information is being sent to [S] key(s) and block it. > > I am a bit boggled as to the point of this discusion. It seems rather > unlikely that an OpenPGP software implementation will be approved to > handle classified traffic, and even less likely that a user on a > computer running a GUI will have available adequate MLS facilities to > choose the level of a message. Actually, I don't think it at all unlikely. Certainly it's unlikely without SuiteB in the protocol, an OpenPGP implementation would be at a disadvantage. Implementers of software often do things that other people think is unlikely. > > > Are we talking about being able to have an OpenPGP implementation be > configured to follow Suite B guidelines for S or TS, intended for use > with unclassified information? This would perhaps follow the > reasonable > theory that such guidelines define best practices for algorithm > choice. > > Are we talking about hardened implementations that would implement > mail > gateways between enclaves? > > Or something else? I don't mean to be difficult, but I really don't > get > it. > We're talking about the standards work that is needed for people who want to implement SuiteB within OpenPGP to be able to do so. I think a number of your comments are in line with what I perceive the consensus to be. Building software is different from creating the protocol, and we seem to think that the protocol aspects should be minimal. But we don't want to preclude quasi-SuiteB. Let me give as an example, the SuiteB ECC with Camellia rather than AES. The protocol should not preclude this. So let's suppose I have an ECC key, and my symmetric cipher prefs say Twofish, Camellia, AES, [3DES]. Let's suppose that you implement Camellia and AES and 3DES. The standard says you can pick any of those. You might pick Camellia, because I listed that before AES. If there were a "I-Like-SuiteB" flag, you might use that as a hint that I want you to use AES, even though Camellia is first. Or, you might be a system designed to do SuiteB, and you ignore all non-SuiteB algorithms, in which case you use AES, no matter what I say. You might even just use AES when I *don't* have it, even though it is a technical violation of the standard. We'd have to slap your wrist, but you might do it anyway. The advantage of a SuiteB preference is that it would permit the implementation to make sense of options. If I create an ECC certificate with the SuiteB preference, then it makes sense to ensure that AES is in the preferences. If I see an ECC cert with SuiteB and no AES, I can throw an error, as this is inconsistent, or just deal. The disadvantage of a SuiteB preference is that it's just more stuff to have to cope with. That's why I'm happy either way. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIMhJ5sTedWZOD3gYRAlfxAJ91jkeEmJqDjXXOm+DjPO+VF91pIACdHLvK qV0UhETP3rSAbRwlB0qMvBM= =n6u5 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon May 19 17:23:05 2008 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 0CC8E3A6978 for ; Mon, 19 May 2008 17:23:05 -0700 (PDT) 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 OCpoJ2umOlN1 for ; Mon, 19 May 2008 17:23:03 -0700 (PDT) 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 3A3603A6B80 for ; Mon, 19 May 2008 17:22:41 -0700 (PDT) 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 m4K00GfH008985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 17:00:16 -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 m4K00Gv1008984; Mon, 19 May 2008 17:00:16 -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 m4K00CZT008967 for ; Mon, 19 May 2008 17:00:14 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 705CAF88CA1 for ; Mon, 19 May 2008 17:00:10 -0700 (PDT) Received: from [10.214.0.157] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 19 May 2008 17:00:12 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 May 2008 17:00:12 -0700 Cc: "David Crick" , "Andrey Jivsov" , OpenPGP Message-Id: <1F510C70-FA54-4467-A910-666ABDDC62AE@callas.org> From: Jon Callas To: Greg Troxel In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: I have a technical idea/change for the ECC draft Date: Mon, 19 May 2008 17:00:10 -0700 References: <117bad160804121421t49a6ed13uc1b106e37c054c95@mail.gmail.com> <7230A39A-46DA-41AC-9967-10D0F461E998@callas.org> <4803C108.6000203@brainhub.org> <117bad160804141423r6dea71a7ye1f0ecb20eb4b29e@mail.gmail.com> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I think there's a fundamental mismatch between OpenPGP-style key > preferences and Suite B thinking. As a sender, with labeled > information, you can only use approved algorithms. Thus, if a > recipient > doesn't list the approved algorithm, you just can't send them mail. > The > OpenPGP-style key preferences are in my view primarily to ensure > interoperability and allow for algorithm transitions over long > timescales. It's not a mismatch, you just have a language that is more expressive than SuiteB allows. > > Are we proposing sender-side rules to match labels to approved > algorithms? It seems inadequate to put 'SuiteBOnly' as a key > preference > on recipients. No, we're trying to come up with an acceptable protocol. There are some implementers who are going to want to do SuiteB within OpenPGP. We should make their lives easy. But as Werner has noted, it's not our job as an international community to do things that forbid flexibility. It should be *possible* to use ECC and Camellia, as I noted in my other message. The *implementation* may disallow it, but the standard should not. It should be possible to use ECC and Whirlpool (which people keep threatening to do a draft for). A SuiteBOnly pref makes an implementer's job easier if they care about SuiteB. They can detect it and act accordingly. It doesn't remove the requirement that an implementer know what they're doing. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIMhSMsTedWZOD3gYRArkGAJ9IAJUf81i2g6X8dEo8OS+48k2ucwCdHUjy ULDvJvsrKBfVAXLZMfZhuRc= =DR2A -----END PGP SIGNATURE----- From c.vanherp@rotim.com Mon May 19 17:42:28 2008 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 758813A6B39; Mon, 19 May 2008 17:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.766 X-Spam-Level: X-Spam-Status: No, score=-79.766 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, 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 tUCbDO7VdGIh; Mon, 19 May 2008 17:42:27 -0700 (PDT) Received: from 201-255-10-157.mrse.com.ar (unknown [201.255.10.157]) by core3.amsl.com (Postfix) with SMTP id 4C16F3A6B26; Mon, 19 May 2008 17:42:13 -0700 (PDT) X-Originating-IP: 17.37.196.162 by smtp.201.255.10.157; Mon, 19 May 2008 20:42:14 -0500 Message-ID: From: "Galen Rainey" Reply-To: "Galen Rainey" To: atompub-archive@megatron.ietf.org Subject: Save thousands... no one will know Date: Mon, 19 May 2008 20:42:14 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new Porsche Design watches originated from the novel Titanium Chronograph from the 1970's, an absolutely unique creation due to the perfection of its workmanship. Based on its design, the Porsche Design Company developed an appealing, stylish, sporty and highly accurate watch. Unfortunately, these timepieces come with a high price tag. http://nuvohehenyd04.blogspot.com/ That's why a clever group of European manufacturers decided to offer the same exact functionality and style at greatly reduced prices: the Porsche Design replica watches. These replicas are so similar to the brand name pieces that it is practically impossible to tell them apart, other than by their price. They look the same, they function the same and they definitely don't have the same prices :) How would you like to browse through an amazing collection of these watches and marvel yourself with their low prices? Visit Prestige Replicas and see for yourself why sometimes replicas are so much better than the originals! http://nuvohehenyd04.blogspot.com/ From caby@nmlc.net Tue May 20 20:42:02 2008 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 459133A6C24; Tue, 20 May 2008 20:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, 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_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 RttJ3qwPkOqo; Tue, 20 May 2008 20:42:01 -0700 (PDT) Received: from 190-174-142-54.speedy.com.ar (unknown [190.174.142.54]) by core3.amsl.com (Postfix) with SMTP id 9582929335D; Tue, 20 May 2008 16:21:36 -0700 (PDT) X-Originating-IP: 150.40.192.32 by smtp.190.174.142.54; Tue, 20 May 2008 19:21:39 -0500 Message-ID: From: "Earle Elkins" Reply-To: "Earle Elkins" To: notifications@ietf.org Subject: Tag Heuer replicas better than originals Date: Tue, 20 May 2008 19:21:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://www.oidoido.com/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://www.oidoido.com/ From owner-ietf-openpgp@mail.imc.org Wed May 21 09:55:35 2008 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 1F3783A6B41 for ; Wed, 21 May 2008 09:55:35 -0700 (PDT) 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 5Sn0OlaAzEys for ; Wed, 21 May 2008 09:55:34 -0700 (PDT) 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 DB19E3A696B for ; Wed, 21 May 2008 09:55:33 -0700 (PDT) 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 m4LGUIHt033787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:30:18 -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 m4LGUI3k033785; Wed, 21 May 2008 09:30:18 -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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGUEth033764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 21 May 2008 09:30:16 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JyrKm-00027v-Do for ; Wed, 21 May 2008 18:38:36 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1Jyr9h-0006JJ-8L; Wed, 21 May 2008 18:27:09 +0200 From: Werner Koch To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> <87r6d4eu4g.fsf@wheatstone.g10code.de> <4808ECD9.8050204@brainhub.org> <87hcddjca0.fsf@wheatstone.g10code.de> <482D30C4.80402@brainhub.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 21 May 2008 18:27:09 +0200 In-Reply-To: <482D30C4.80402@brainhub.org> (Andrey Jivsov's message of "Thu, 15 May 2008 23:59:16 -0700") Message-ID: <87d4nf62si.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) 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: On Fri, 16 May 2008 08:59, openpgp@brainhub.org said: > 2. Different curve is not the same as different RSA key size. What I want to express withn that comparision is that we already have a wide range of parameters in addtion to the algorithm ID. The curve ID is just another parameter, or well a short-name for the curve parameters. > performance reasons. Implementations will achieve better performance > by tuning the code for each underlying field at compile time, or, in > case of hardware, this may be done by the manufacturing time. They may still do this. I can't see that as an argument pro or con a fixed list of curves. > Conversely, even when RSA is implemented in hardware, a parameter to > RSA key size is almost certainly a variable in software. There is > nothing to gain by separately implementing RSA 2048 and RSA 4096 > operations. I disagree. Even pure software implementations are often tuned for certain key sizes (e.g. to use the Karatsuba algorithm only for certain sizes). With hardware you even need to decide whether the hardware of software implementation is faster for a certain size. > support any other curve. Compare this with RSA support. To put this Or compare that with DSA support. How that we have DSA-2 many implemtations fail because they can't cope with >1k DSA keys. That is a similar interoperability issue as with new curve IDs. > base, while my RSA implementation is capable of handling any key size > within a reasonable range. And what about DSA implementations? > ================================================================== > A: Keep current text regarding the procedure to approve new curves > (for/against) > ================================================================== > B: Keep current method to encode curve IDs as numeric IDs > (for/against) > ================================================================== > C: Need extension mechanism specified in the draft to add other > curves > (for/against) > ================================================================== > > > Andrey: > A: for > B: for > C: against ============================================================== D: Use an OIDs instead of an algorithm ID and define the NIST curves as MUST. (for/against) ================== Werner: A: for (as long as that does not forbit other curves) B: against C: for (as second best choice) D: for Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From c.nipkow@quartierkultur-kreis6.ch Wed May 21 11:00:27 2008 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 F327928C210; Wed, 21 May 2008 11:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.683 X-Spam-Level: **** X-Spam-Status: No, score=4.683 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, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, 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, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SUB_PERFECT=0.725, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SBL=20, 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 yljgolX7-X5T; Wed, 21 May 2008 11:00:25 -0700 (PDT) Received: from cable201-233-159-41.epm.net.co (cable201-233-159-41.epm.net.co [201.233.159.41]) by core3.amsl.com (Postfix) with SMTP id C35893A69B0; Wed, 21 May 2008 11:00:04 -0700 (PDT) X-Originating-IP: 178.30.116.46 by smtp.201.233.159.41; Wed, 21 May 2008 14:00:09 -0500 Message-ID: From: "Pat Gilmore" Reply-To: "Pat Gilmore" To: atompub-archive@megatron.ietf.org Subject: Replica watch is a perfect gift Date: Wed, 21 May 2008 14:00:09 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www.adieks.com/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www.adieks.com/ From c.unfried@secure.medicalnet.at Thu May 22 12:05:26 2008 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 85D033A6B2F; Thu, 22 May 2008 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -72.626 X-Spam-Level: X-Spam-Status: No, score=-72.626 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_DSL=1.129, 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, TVD_RCVD_IP=1.931, 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 WxwIODdaMrWo; Thu, 22 May 2008 12:05:24 -0700 (PDT) Received: from 39-141-223-201.adsl.terra.cl (39-141-223-201.adsl.terra.cl [201.223.141.39]) by core3.amsl.com (Postfix) with SMTP id 4ADEF28C161; Thu, 22 May 2008 12:02:21 -0700 (PDT) X-Originating-IP: 144.223.155.180 by smtp.201.223.141.39; Thu, 22 May 2008 15:02:21 -0500 Message-ID: From: "Morton Quintero" Reply-To: "Morton Quintero" To: atompub-archive@megatron.ietf.org Subject: Beautiful Rado watches for less Date: Thu, 22 May 2008 15:02:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit What comes to mind when you hear the words Louis Vuitton? Of course, the classic style, the superior quality of their bags, their unique look, and their inflated price tag. But, how about being able to afford a beautiful Louis Vuitton handbag without having to dent your budget? It is now possible. Thanks to Prestige Replicas, that Louis Vuitton bag or wallet is closer to you than ever before! Come visit our new designer bag section and pick that special Louis Vuitton handbag that you've always wanted. http://wuhyluhakyr77.blogspot.com/ Remember, Prestige Replicas offers award winning customer service and an absolute guarantee of its products and your privacy! http://wuhyluhakyr77.blogspot.com/ From c.spinelli@microsistemi.com Thu May 22 19:35:43 2008 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 100033A6C00; Thu, 22 May 2008 19:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.655 X-Spam-Level: X-Spam-Status: No, score=-75.655 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_IPADDR2=4.395, J_CHICKENPOX_24=0.6, NO_DNS_FOR_FROM=1.496, 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_NONE=0.1, TVD_RCVD_IP=1.931, 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 ASHNm-uZEMdt; Thu, 22 May 2008 19:35:42 -0700 (PDT) Received: from 201-255-150-17.mrse.com.ar (unknown [201.255.150.17]) by core3.amsl.com (Postfix) with SMTP id 64E3E3A6B94; Thu, 22 May 2008 19:35:30 -0700 (PDT) X-Originating-IP: 251.208.61.70 by smtp.201.255.150.17; Thu, 22 May 2008 22:35:30 -0500 Message-ID: From: "Spencer Gentry" Reply-To: "Spencer Gentry" To: notifications@ietf.org Subject: 15% off on two watches Date: Thu, 22 May 2008 22:35:30 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080522-0, 22/05/2008), Outbound message X-Antivirus-Status: Clean A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://gavopocunaz42.blogspot.com/ From cacsa@saudhouse.com Sun May 25 21:20:28 2008 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 1629D3A6895; Sun, 25 May 2008 21:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.191 X-Spam-Level: X-Spam-Status: No, score=-34.191 tagged_above=-999 required=5 tests=[AWL=-41.465, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, HTTP_ESCAPED_HOST=0.134, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 xZ-X8V0D4Odm; Sun, 25 May 2008 21:20:22 -0700 (PDT) Received: from 201-255-121-108.mrse.com.ar (unknown [201.255.121.108]) by core3.amsl.com (Postfix) with SMTP id 3119F3A6AC4; Sun, 25 May 2008 21:20:08 -0700 (PDT) X-Originating-IP: 104.58.38.212 by smtp.201.255.121.108; Mon, 26 May 2008 00:20:21 -0500 Message-ID: From: "Kory Baldwin" Reply-To: "Kory Baldwin" To: notifications@ietf.org Subject: Save 80% on Brand name replica watches Date: Mon, 26 May 2008 00:20:21 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://www%2Essedkke%2Ecom/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://www%2Essedkke%2Ecom/ From cabmail@woodenradiatorcabinet.com Mon May 26 00:52:39 2008 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 80C143A6B48; Mon, 26 May 2008 00:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.222 X-Spam-Level: X-Spam-Status: No, score=-26.222 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, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTTP_ESCAPED_HOST=0.134, 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_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, URIBL_BLACK=20, URIBL_JP_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 WXMCZfPjKamY; Mon, 26 May 2008 00:52:33 -0700 (PDT) Received: from cm-85-152-146-209.telecable.es (cm-85-152-146-209.telecable.es [85.152.146.209]) by core3.amsl.com (Postfix) with SMTP id 3F7023A6997; Mon, 26 May 2008 00:52:13 -0700 (PDT) X-Originating-IP: 194.81.121.210 by smtp.85.152.146.209; Mon, 26 May 2008 03:52:27 -0500 Message-ID: From: "Pablo Hammer" Reply-To: "Pablo Hammer" To: atompub-archive@megatron.ietf.org Subject: Watches made to impress Date: Mon, 26 May 2008 03:52:27 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Since 1884 Bvlgari watches have drawn inspiration from the timeless beauty of Greek and Roman art. The time pieces that they produce are as much works of art, as a way to tell time, and now you can possess one of these splendid time pieces for a very affordable price, at Prestige Replicas. http://www%2Ejusiile%2Ecom/ This store has the finest collection of Bvlgari replica watches, and you will be astounded at the difference in price as well as amazed at the quality of their timepieces. Prestige Replicas works hard to make sure that your purchase is shipped as fast as your order is processed, and also that your private information is protected. And with the new redesign of the Prestige Replicas website, we are offering 15% off on your purchase of watches! http://www%2Ejusiile%2Ecom/ From c.porot@mutualitefrancaiserhone.fr Mon May 26 12:24:19 2008 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 3DEF53A6BDF; Mon, 26 May 2008 12:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.648 X-Spam-Level: X-Spam-Status: No, score=-15.648 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTTP_ESCAPED_HOST=0.134, 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_SPEC_REPLICA_OBFU=1.812, 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 yIeu7EVVkrdm; Mon, 26 May 2008 12:24:13 -0700 (PDT) Received: from host51-133-dynamic.7-87-r.retail.telecomitalia.it (host51-133-dynamic.7-87-r.retail.telecomitalia.it [87.7.133.51]) by core3.amsl.com (Postfix) with SMTP id CF31E3A69FC; Mon, 26 May 2008 12:24:02 -0700 (PDT) X-Originating-IP: 194.32.17.48 by smtp.87.7.133.51; Mon, 26 May 2008 15:24:17 -0500 Message-ID: From: "Ronnie Grimm" Reply-To: "Ronnie Grimm" To: atompub-archive@megatron.ietf.org Subject: The affordable watch alternative Date: Mon, 26 May 2008 15:24:17 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080526-0, 26/05/2008), Outbound message X-Antivirus-Status: Clean Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eadieks%2Ecom/ From c.j.dissing@dissing.dk Mon May 26 21:45:18 2008 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 4164E3A6858; Mon, 26 May 2008 21:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[BAYES_80=2, 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_DSL=1.129, HTTP_ESCAPED_HOST=0.134, 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_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5F=0.666, TVD_RCVD_IP=1.931, 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 6MJNfIE4lV7L; Mon, 26 May 2008 21:45:12 -0700 (PDT) Received: from 97-133-223-201.adsl.terra.cl (97-133-223-201.adsl.terra.cl [201.223.133.97]) by core3.amsl.com (Postfix) with SMTP id 39BD13A688F; Mon, 26 May 2008 21:44:11 -0700 (PDT) X-Originating-IP: 192.41.116.216 by smtp.201.223.133.97; Tue, 27 May 2008 00:44:26 -0500 Message-ID: From: "Anne Palacios" Reply-To: "Anne Palacios" To: notifications@ietf.org Subject: Affordable brand name watches Date: Tue, 27 May 2008 00:44:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Everybody knows that a Cartier watch is a silent statement of wealth and luxury. But we all know as well that the price of putting one of them on your wrist is for the most unaffordable by the average Joe. That's why replica Cartier watches are becoming more and more popular by the day. They're actually the affordable solution to this dilemma. And thanks to the internet, there is now a place where the highest quality Cartier replicas are available: Prestige Replicas. So, why not take a look at the extensive inventory that this site has to offer? After all, browsing through their hundreds of Cartier watches is absolutely free, and buying the one of your dreams is simply inexpensive. http://www%2Eadieks%2Ecom/ From caciara@caciara.it Tue May 27 01:47:57 2008 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 96C773A6784; Tue, 27 May 2008 01:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.857 X-Spam-Level: X-Spam-Status: No, score=-6.857 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_FR=0.35, HTTP_ESCAPED_HOST=0.134, 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_BAYES_5x7=0.6, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, 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 h2dQy8kDPbVD; Tue, 27 May 2008 01:47:50 -0700 (PDT) Received: from LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr (LPuteaux-151-42-40-146.w193-251.abo.wanadoo.fr [193.251.191.146]) by core3.amsl.com (Postfix) with SMTP id 6F14728C218; Tue, 27 May 2008 01:46:35 -0700 (PDT) X-Originating-IP: 112.96.12.238 by smtp.193.251.191.146; Tue, 27 May 2008 04:46:50 -0500 Message-ID: From: "Jonah Mcgee" Reply-To: "Jonah Mcgee" To: atompub-archive@megatron.ietf.org Subject: Why get an original watch? Date: Tue, 27 May 2008 04:46:50 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is a one of a kind store: the online place where you can find the highest quality replica watches at the best prices in the world! Forget about flying to China to get a mockup Cartier watch... You can now get European quality Cartier replicas at deeply discounted prices at Prestige Replicas! The best part is that our watches are so finely crafted that even the most experienced connoisseur would have a hard time telling our watches from the real deal. http://www%2Ebybyusse%2Ecom/ Visit Prestige Replicas today and discover a wide range of top quality Cartier replica watches offered at unbelievable prices, with a 15% discount when you buy two! http://www%2Ebybyusse%2Ecom/ From c.white.dojyynifordkutl@lloydsmaritimeacademy.msgfocus.com Tue May 27 05:21:25 2008 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 7F7453A6866; Tue, 27 May 2008 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.958 X-Spam-Level: X-Spam-Status: No, score=-10.958 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, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTTP_ESCAPED_HOST=0.134, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, 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 m-Qclvpp0v6n; Tue, 27 May 2008 05:21:18 -0700 (PDT) Received: from 84.125.158.166.dyn.user.ono.com (84.125.158.166.dyn.user.ono.com [84.125.158.166]) by core3.amsl.com (Postfix) with SMTP id C2DF53A68EF; Tue, 27 May 2008 05:20:58 -0700 (PDT) X-Originating-IP: 231.160.28.229 by smtp.84.125.158.166; Tue, 27 May 2008 08:21:06 -0500 Message-ID: From: "Claudine Gagnon" Reply-To: "Claudine Gagnon" To: openpgp-archive@ietf.org Subject: Get 15% off these watches Date: Tue, 27 May 2008 08:21:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://www%2Enunubsyy%2Ecom/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://www%2Enunubsyy%2Ecom/ From ops-area-bounces@ietf.org Tue May 27 05:21:28 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D42933A6994 for ; Tue, 27 May 2008 05:21:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to OPS-AREA awaits moderator approval From: ops-area-bounces@ietf.org To: openpgp-archive@ietf.org Message-ID: Date: Tue, 27 May 2008 05:21:26 -0700 Precedence: bulk X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.9 List-Id: OPS Area e-mail list X-List-Administrivia: yes Sender: ops-area-bounces@ietf.org Errors-To: ops-area-bounces@ietf.org Your mail to 'OPS-AREA' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ops-area/1067e4c52334f8f77fb077a21603374888602a2b From p2prg-bounces@ietf.org Tue May 27 05:21:28 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD5E63A6994 for ; Tue, 27 May 2008 05:21:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to P2prg awaits moderator approval From: p2prg-bounces@ietf.org To: openpgp-archive@ietf.org Message-ID: Date: Tue, 27 May 2008 05:21:26 -0700 Precedence: bulk X-BeenThere: p2prg@ietf.org X-Mailman-Version: 2.1.9 List-Id: Peer-to-Peer Research Group X-List-Administrivia: yes Sender: p2prg-bounces@ietf.org Errors-To: p2prg-bounces@ietf.org Your mail to 'P2prg' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/p2prg/de6ded130d41620a3a852ff1f3f129c9657eecaf From opsawg-bounces@ietf.org Tue May 27 05:21:28 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96363A6994 for ; Tue, 27 May 2008 05:21:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to OPSAWG awaits moderator approval From: opsawg-bounces@ietf.org To: openpgp-archive@ietf.org Message-ID: Date: Tue, 27 May 2008 05:21:26 -0700 Precedence: bulk X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 List-Id: OPSA Working Group Mail List X-List-Administrivia: yes Sender: opsawg-bounces@ietf.org Errors-To: opsawg-bounces@ietf.org Your mail to 'OPSAWG' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/opsawg/275b32b8c6764f1aab01a50a1d905bf84d481ffd From ops-nm-bounces@ietf.org Tue May 27 05:21:28 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD5D3A6994 for ; Tue, 27 May 2008 05:21:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Your message to OPS-NM awaits moderator approval From: ops-nm-bounces@ietf.org To: openpgp-archive@ietf.org Message-ID: Date: Tue, 27 May 2008 05:21:26 -0700 Precedence: bulk X-BeenThere: ops-nm@ietf.org X-Mailman-Version: 2.1.9 List-Id: OPS Area NM e-mail list X-List-Administrivia: yes Sender: ops-nm-bounces@ietf.org Errors-To: ops-nm-bounces@ietf.org Your mail to 'OPS-NM' with the subject Get 15% off these watches Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: https://www.ietf.org/mailman/confirm/ops-nm/35a489e3fb6100ad3232ac47050bb96a2e34bfac From ospf-bounces@ietf.org Tue May 27 05:21:29 2008 Return-Path: X-Original-To: openpgp-archive@ietf.org Delivered-To: ietfarch-openpgp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0288E3A6994 for ; Tue, 27 May 2008 05:21:29 -0700 (PDT) Subject: Get 15% off these watches From: ospf-owner@ietf.org To: openpgp-archive@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1146670791==" Message-ID: Date: Tue, 27 May 2008 05:21:26 -0700 Precedence: bulk X-BeenThere: ospf@ietf.org X-Mailman-Version: 2.1.9 List-Id: The Official IETF OSPG WG Mailing List X-List-Administrivia: yes Sender: ospf-bounces@ietf.org Errors-To: ospf-bounces@ietf.org --===============1146670791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at ospf-owner@ietf.org. To subscribe send an email to ospf-request@ietf.org with a subject line "subscribe". Archives are available at: http://www.ietf.org/mail-archive/web/ospf/current/index.html --===============1146670791== Content-Type: message/rfc822 MIME-Version: 1.0 Return-Path: X-Original-To: ospf@core3.amsl.com Delivered-To: ospf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7453A6866; Tue, 27 May 2008 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.958 X-Spam-Level: X-Spam-Status: No, score=-10.958 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, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HOST_EQ_USERONOCOM=1.444, HTTP_ESCAPED_HOST=0.134, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, 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 m-Qclvpp0v6n; Tue, 27 May 2008 05:21:18 -0700 (PDT) Received: from 84.125.158.166.dyn.user.ono.com (84.125.158.166.dyn.user.ono.com [84.125.158.166]) by core3.amsl.com (Postfix) with SMTP id C2DF53A68EF; Tue, 27 May 2008 05:20:58 -0700 (PDT) X-Originating-IP: 231.160.28.229 by smtp.84.125.158.166; Tue, 27 May 2008 08:21:06 -0500 Message-ID: From: "Claudine Gagnon" Reply-To: "Claudine Gagnon" To: openpgp-archive@ietf.org Subject: Get 15% off these watches Date: Tue, 27 May 2008 08:21:06 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://www%2Enunubsyy%2Ecom/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://www%2Enunubsyy%2Ecom/ --===============1146670791==-- From c.voigt@geisel-privathotels.de Tue May 27 10:56:42 2008 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 D557D3A6A32; Tue, 27 May 2008 10:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.173 X-Spam-Level: X-Spam-Status: No, score=-5.173 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, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR=2.426, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_24=0.6, 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, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, 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 VU2o4-yRg7Y9; Tue, 27 May 2008 10:56:42 -0700 (PDT) Received: from pc-136-124-86-200.cm.vtr.net (pc-136-124-86-200.cm.vtr.net [200.86.124.136]) by core3.amsl.com (Postfix) with SMTP id 817733A67B6; Tue, 27 May 2008 10:56:10 -0700 (PDT) X-Originating-IP: 140.168.105.220 by smtp.200.86.124.136; Tue, 27 May 2008 13:56:26 -0500 Message-ID: From: "Marshall Cassidy" Reply-To: "Marshall Cassidy" To: notifications@ietf.org Subject: The discreet replica store Date: Tue, 27 May 2008 13:56:26 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Bvlgari watch is an extraordinary masterpiece that is born from the marriage of watch making and jewelry expertise. Only the most discriminating and sophisticated watch users dare put a Bv1gari on their wrists, but once the metal touches their skin, they are bound forever... How would you like to become one of the lucky few that have experienced the pleasure of sporting a Bvlgari timepiece? Now you can, and at a very reduced cost! Prestige Replicas offers a tremendous collection of Bvlgari replicas starting just a little above $200... So now there is no reason why you can't have your very own Bvlgari today! http://www%2Ejusiile%2Ecom/ 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 m4LGUIHt033787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 May 2008 09:30:18 -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 m4LGUI3k033785; Wed, 21 May 2008 09:30:18 -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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4LGUEth033764 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 21 May 2008 09:30:16 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JyrKm-00027v-Do for ; Wed, 21 May 2008 18:38:36 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1Jyr9h-0006JJ-8L; Wed, 21 May 2008 18:27:09 +0200 From: Werner Koch To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> <87r6d4eu4g.fsf@wheatstone.g10code.de> <4808ECD9.8050204@brainhub.org> <87hcddjca0.fsf@wheatstone.g10code.de> <482D30C4.80402@brainhub.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 21 May 2008 18:27:09 +0200 In-Reply-To: <482D30C4.80402@brainhub.org> (Andrey Jivsov's message of "Thu, 15 May 2008 23:59:16 -0700") Message-ID: <87d4nf62si.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) 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: On Fri, 16 May 2008 08:59, openpgp@brainhub.org said: > 2. Different curve is not the same as different RSA key size. What I want to express withn that comparision is that we already have a wide range of parameters in addtion to the algorithm ID. The curve ID is just another parameter, or well a short-name for the curve parameters. > performance reasons. Implementations will achieve better performance > by tuning the code for each underlying field at compile time, or, in > case of hardware, this may be done by the manufacturing time. They may still do this. I can't see that as an argument pro or con a fixed list of curves. > Conversely, even when RSA is implemented in hardware, a parameter to > RSA key size is almost certainly a variable in software. There is > nothing to gain by separately implementing RSA 2048 and RSA 4096 > operations. I disagree. Even pure software implementations are often tuned for certain key sizes (e.g. to use the Karatsuba algorithm only for certain sizes). With hardware you even need to decide whether the hardware of software implementation is faster for a certain size. > support any other curve. Compare this with RSA support. To put this Or compare that with DSA support. How that we have DSA-2 many implemtations fail because they can't cope with >1k DSA keys. That is a similar interoperability issue as with new curve IDs. > base, while my RSA implementation is capable of handling any key size > within a reasonable range. And what about DSA implementations? > ================================================================== > A: Keep current text regarding the procedure to approve new curves > (for/against) > ================================================================== > B: Keep current method to encode curve IDs as numeric IDs > (for/against) > ================================================================== > C: Need extension mechanism specified in the draft to add other > curves > (for/against) > ================================================================== > > > Andrey: > A: for > B: for > C: against ============================================================== D: Use an OIDs instead of an algorithm ID and define the NIST curves as MUST. (for/against) ================== Werner: A: for (as long as that does not forbit other curves) B: against C: for (as second best choice) D: for Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. 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 m4K00GfH008985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 17:00:16 -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 m4K00Gv1008984; Mon, 19 May 2008 17:00:16 -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 m4K00CZT008967 for ; Mon, 19 May 2008 17:00:14 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 705CAF88CA1 for ; Mon, 19 May 2008 17:00:10 -0700 (PDT) Received: from [10.214.0.157] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 19 May 2008 17:00:12 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 May 2008 17:00:12 -0700 Cc: "David Crick" , "Andrey Jivsov" , OpenPGP Message-Id: <1F510C70-FA54-4467-A910-666ABDDC62AE@callas.org> From: Jon Callas To: Greg Troxel In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: I have a technical idea/change for the ECC draft Date: Mon, 19 May 2008 17:00:10 -0700 References: <117bad160804121421t49a6ed13uc1b106e37c054c95@mail.gmail.com> <7230A39A-46DA-41AC-9967-10D0F461E998@callas.org> <4803C108.6000203@brainhub.org> <117bad160804141423r6dea71a7ye1f0ecb20eb4b29e@mail.gmail.com> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I think there's a fundamental mismatch between OpenPGP-style key > preferences and Suite B thinking. As a sender, with labeled > information, you can only use approved algorithms. Thus, if a > recipient > doesn't list the approved algorithm, you just can't send them mail. > The > OpenPGP-style key preferences are in my view primarily to ensure > interoperability and allow for algorithm transitions over long > timescales. It's not a mismatch, you just have a language that is more expressive than SuiteB allows. > > Are we proposing sender-side rules to match labels to approved > algorithms? It seems inadequate to put 'SuiteBOnly' as a key > preference > on recipients. No, we're trying to come up with an acceptable protocol. There are some implementers who are going to want to do SuiteB within OpenPGP. We should make their lives easy. But as Werner has noted, it's not our job as an international community to do things that forbid flexibility. It should be *possible* to use ECC and Camellia, as I noted in my other message. The *implementation* may disallow it, but the standard should not. It should be possible to use ECC and Whirlpool (which people keep threatening to do a draft for). A SuiteBOnly pref makes an implementer's job easier if they care about SuiteB. They can detect it and act accordingly. It doesn't remove the requirement that an implementer know what they're doing. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIMhSMsTedWZOD3gYRArkGAJ9IAJUf81i2g6X8dEo8OS+48k2ucwCdHUjy ULDvJvsrKBfVAXLZMfZhuRc= =DR2A -----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 m4JNpN4L005877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 May 2008 16:51: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 m4JNpNKg005876; Mon, 19 May 2008 16:51: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 merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4JNpLYH005858 for ; Mon, 19 May 2008 16:51:22 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 2DE07F88BA8 for ; Mon, 19 May 2008 16:51:19 -0700 (PDT) Received: from [10.214.0.157] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 19 May 2008 16:51:21 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 May 2008 16:51:21 -0700 Cc: Andrey Jivsov , OpenPGP Message-Id: <5883F699-2520-47E8-B66D-43CE4EC16F4A@callas.org> From: Jon Callas To: Greg Troxel In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Mon, 19 May 2008 16:51:18 -0700 References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> <4820B9B2.1010500@brainhub.org> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 7, 2008, at 6:31 AM, Greg Troxel wrote: > > Andrey Jivsov writes: > >> Many of these issues, such as the security level of information, is >> outside of traditional domain of OpenPGP. I suppose an e-mail >> application in Suite-B environment might have a UI combobox with >> SECRET/TOP SECRET choices in the compose window that magically (based >> on content or at worst manually) are set to the correct level. The >> rest is easier to program: this would allow software to check that >> [TS] information is being sent to [S] key(s) and block it. > > I am a bit boggled as to the point of this discusion. It seems rather > unlikely that an OpenPGP software implementation will be approved to > handle classified traffic, and even less likely that a user on a > computer running a GUI will have available adequate MLS facilities to > choose the level of a message. Actually, I don't think it at all unlikely. Certainly it's unlikely without SuiteB in the protocol, an OpenPGP implementation would be at a disadvantage. Implementers of software often do things that other people think is unlikely. > > > Are we talking about being able to have an OpenPGP implementation be > configured to follow Suite B guidelines for S or TS, intended for use > with unclassified information? This would perhaps follow the > reasonable > theory that such guidelines define best practices for algorithm > choice. > > Are we talking about hardened implementations that would implement > mail > gateways between enclaves? > > Or something else? I don't mean to be difficult, but I really don't > get > it. > We're talking about the standards work that is needed for people who want to implement SuiteB within OpenPGP to be able to do so. I think a number of your comments are in line with what I perceive the consensus to be. Building software is different from creating the protocol, and we seem to think that the protocol aspects should be minimal. But we don't want to preclude quasi-SuiteB. Let me give as an example, the SuiteB ECC with Camellia rather than AES. The protocol should not preclude this. So let's suppose I have an ECC key, and my symmetric cipher prefs say Twofish, Camellia, AES, [3DES]. Let's suppose that you implement Camellia and AES and 3DES. The standard says you can pick any of those. You might pick Camellia, because I listed that before AES. If there were a "I-Like-SuiteB" flag, you might use that as a hint that I want you to use AES, even though Camellia is first. Or, you might be a system designed to do SuiteB, and you ignore all non-SuiteB algorithms, in which case you use AES, no matter what I say. You might even just use AES when I *don't* have it, even though it is a technical violation of the standard. We'd have to slap your wrist, but you might do it anyway. The advantage of a SuiteB preference is that it would permit the implementation to make sense of options. If I create an ECC certificate with the SuiteB preference, then it makes sense to ensure that AES is in the preferences. If I see an ECC cert with SuiteB and no AES, I can throw an error, as this is inconsistent, or just deal. The disadvantage of a SuiteB preference is that it's just more stuff to have to cope with. That's why I'm happy either way. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIMhJ5sTedWZOD3gYRAlfxAJ91jkeEmJqDjXXOm+DjPO+VF91pIACdHLvK qV0UhETP3rSAbRwlB0qMvBM= =n6u5 -----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 m4G71Usj033372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 00:01: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 m4G71UBV033371; Fri, 16 May 2008 00:01: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 mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4G70wnZ033269 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 16 May 2008 00:01:30 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m4G77x55020972 for ; Fri, 16 May 2008 03:08:55 -0400 Message-ID: <482D30C4.80402@brainhub.org> Date: Thu, 15 May 2008 23:59:16 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> <87r6d4eu4g.fsf@wheatstone.g10code.de> <4808ECD9.8050204@brainhub.org> <87hcddjca0.fsf@wheatstone.g10code.de> In-Reply-To: <87hcddjca0.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I see three aspects of the issue. 1. The desire to control curves. What degree of freedom is appropriate? Currently the document says: "Future allocations in the registry will be done by IETF Expert Review process after general consensus between implementors of the standard is reached." It doesn't allow other curves without general agreement (exact body that makes approval is not critical). The following item explains the reasons. 2. Different curve is not the same as different RSA key size. The following argument will rely on implementation specifics that are unique to ECC. Currently http://www.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt only allows curves over prime underlying field. The primes selected for these fields are, forgive my exaggeration, weak primes. That is, they are primes very close to 2^m. The purpose of these primes is to construct finite fields with fastest operations for the given field size. This field is called underlying field of EC. The cryptography of ECC doesn't depend on the strength of operations in the underlying field, so the use of such special primes is justified. While it is possible to use general-purpose large-integer library to implement operations in the underlying field, this is not practical for performance reasons. Implementations will achieve better performance by tuning the code for each underlying field at compile time, or, in case of hardware, this may be done by the manufacturing time. Conversely, even when RSA is implemented in hardware, a parameter to RSA key size is almost certainly a variable in software. There is nothing to gain by separately implementing RSA 2048 and RSA 4096 operations. 3. Finally, there is a question of how to reference a curve. Currently the draft uses numeric IDs, consistent with other IDs in RFC 4880. With the exception of using less space to encode more RFC4880-aligned ID v.s. DER OID and slightly better lookup time, I see two approaches as similar. Some of pros and cons were mentioned earlier. Given my opinion on 1., 3., and statement 2., and that the use of OID will need substantial rewrite of the draft, I prefer to use one byte curve ID. I see the difficulty of obtaining curve ID as a feature. I don't see the ease of introduction of new curve ID as a way to improve interoperability. If an implementation publicly stated that it implements IDs 1, 2, and 3, it's a loosing bet to expect that it will support any other curve. Compare this with RSA support. To put this differently, as an implementor I would like to hear in advance that another curve ID is going to be introduced into OpenPGP installation base, while my RSA implementation is capable of handling any key size within a reasonable range. This issue is lingering unresolved between a few of us who expressed their opinions. I would appreciate opinion of the list on the following items. Please read the introduction above and mark your vote. ================================================================== A: Keep current text regarding the procedure to approve new curves (for/against) ================================================================== B: Keep current method to encode curve IDs as numeric IDs (for/against) ================================================================== C: Need extension mechanism specified in the draft to add other curves (for/against) ================================================================== Andrey: A: for B: for C: against Thank you. Werner Koch wrote: > On Fri, 18 Apr 2008 20:47, openpgp@brainhub.org said: > >> Pros for OpenPGP IDs. >> >> 1) Vote of confidence for a particular curve. If it is included, >> potential implementers have agreed on it. It will be more likely >> widely supported. For example this is useful for hardware folks who >> plan far ahead, plays in the decisions about which curve to use in key >> self-signatures, and gives priorities to performance optimizations. > > The same can be said of OIDs. > >> 2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()). > > Well, okay. > >> 3) consistency with the way OpenPGP references other algorithms. > > Only if we agree that a curveID describes an OpenPGP algorithm. In my > view this is a parameter of the algorithm, much like p, q and g in DSA > or even the key size of all aglgorithms. > > For sure I do not want to convey all ECC curve parameters, thus using a > way to describe the curve is important. > >> 4) Named curves can be introduced as an extension. The core set of >> curves will be encoded as integers, others as named curves. > > I thought of that and was about to propose a format using an ID of 0 to > identify a named curve. However the specification as well as the code > will be more complicated - even in the case that named curves are not > supported by the implementation. > >> Do you see any value in having some approval process for new curves? >> Does it bother you that I can use some questionable curve and it will >> carry equal status per the spec to the three curves we discussed so >> far (will we have a method to distinguish "next good" curve past P-521 >> from an experimental curve) ? > > No. We also don't approve implementations and have no real limits on > key sizes. It is easy to get things wrong. Using a good curve is as > important as to use sound parameters for RSA. > >> Can we reach an agreement if the document also defined a method to >> list named curves, along the lines of Werner's proposal? > > If there is no other way to allow for arbitrary curves, I would agree to > it. However, I still believe that an OID with a memcmp in the code is > easier to implement than a numeric ID with a switch and a mechnism to > cope withe the optional OID named curve. > > > Salam-Shalom, > > Werner > > 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 m480bv7V095929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 17:37: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 m480bv6v095928; Wed, 7 May 2008 17:37:57 -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 brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m480bnI6095871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 7 May 2008 17:37:56 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [10.214.201.192] ([64.1.215.241]) by brainhub.org (8.14.2/8.14.1) with ESMTP id m480bm8o008092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 17:37:49 -0700 Message-ID: <48224B57.90002@brainhub.org> Date: Wed, 07 May 2008 17:37:43 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Greg Troxel CC: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> <4820B9B2.1010500@brainhub.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greg Troxel wrote: > Andrey Jivsov writes: > > >> Many of these issues, such as the security level of information, is >> outside of traditional domain of OpenPGP. I suppose an e-mail >> application in Suite-B environment might have a UI combobox with >> SECRET/TOP SECRET choices in the compose window that magically (based >> on content or at worst manually) are set to the correct level. The >> rest is easier to program: this would allow software to check that >> [TS] information is being sent to [S] key(s) and block it. >> > > I am a bit boggled as to the point of this discusion. It seems rather > unlikely that an OpenPGP software implementation will be approved to > handle classified traffic, and even less likely that a user on a > computer running a GUI will have available adequate MLS facilities to > choose the level of a message. > This was an answer to a hypothetical question "Now take real-world examples like that of Enigmail, which uses GPG as its crypto engine. How on earth is GPG, the "OpenPGP implementation" in that system, supposed to stop Enigmail from doing that?". I assumed as an axiom that Enigmail and gpg are running in this environment. I was trying to point out that we need another parameter -- the security level for the information -- and that it should come from "somewhere above" in reference to OpenPGP format. It cannot be deduced from recipient keys. > Are we talking about being able to have an OpenPGP implementation be > configured to follow Suite B guidelines for S or TS, intended for use > with unclassified information? This would perhaps follow the reasonable > theory that such guidelines define best practices for algorithm choice. > > Are we talking about hardened implementations that would implement mail > gateways between enclaves? > OpenPGP format can be used to encrypt any traffic. The proposal even has stronger public key algorithm P-521 beyond P-384 mandated by [TS]. > Or something else? I don't mean to be difficult, but I really don't get > it. > So far, I think we are getting consensus that ECC in OpenPGP should be a format document. How an application is designed is beyond the scope of ECC. Gateway is probably easier to do right, but end-to-end has value in that users can be authenticated using multifactor authentication. I suppose you, Greg, don't argue that OpenPGP format can be used for any Suite-B traffic in properly designed application. ECC in OpenPGP is a format and the system itself can be implemented in hardware, or a combination of software and HSM (this should be our task to ensure this compatibility with smartcards and HSMs). 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 m47Dd6dr041965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 06:39: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 m47Dd6xm041964; Wed, 7 May 2008 06:39: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 fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47Dd4k9041953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 May 2008 06:39:05 -0700 (MST) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 4845D5299; Wed, 7 May 2008 09:39:04 -0400 (EDT) From: Greg Troxel To: "David Crick" Cc: "Andrey Jivsov" , "Jon Callas" , OpenPGP Subject: Re: I have a technical idea/change for the ECC draft References: <117bad160804121421t49a6ed13uc1b106e37c054c95@mail.gmail.com> <7230A39A-46DA-41AC-9967-10D0F461E998@callas.org> <4803C108.6000203@brainhub.org> <117bad160804141423r6dea71a7ye1f0ecb20eb4b29e@mail.gmail.com> X-Hashcash: 1:20:080507:openpgp@brainhub.org::aITVSuUGMnnOCziY:000000000000000000000000000000000000000000nXA X-Hashcash: 1:20:080507:ietf-openpgp@imc.org::aITVSuUGMnnOCziY:000000000000000000000000000000000000000002Cey X-Hashcash: 1:20:080507:jon@callas.org::m16kbULCz3rAf9Rs:00044oV X-Hashcash: 1:20:080507:dacrick@gmail.com::aITVSuUGMnnOCziY:0000000000000000000000000000000000000000000079K+ Date: Wed, 07 May 2008 09:39:04 -0400 In-Reply-To: <117bad160804141423r6dea71a7ye1f0ecb20eb4b29e@mail.gmail.com> (David Crick's message of "Mon, 14 Apr 2008 22:23:51 +0100") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix) 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: "David Crick" writes: >> What do we loose if we >> instead use "this key replaces TrippleDES implicit algorithm with AES-128" >> notation? This would be beneficial for RSA keys too. > > what if we have: > > Alice: {AES256, AES128, AESover3DESflag [, 3DES implicitly]} > Bob: {3DES [, AES128 implicitly]} > > Then Bob or his software could legitamately choose 3DES. > > whereas: > > Alice: ECC-384/521 key with {AES256, SuiteBOnly} and > Alice: ECC-256 key with { [AES128 implicit], SuiteBOnly} > > would refuse to encrypt with anything except AES256 and > AES128 respectively. I think there's a fundamental mismatch between OpenPGP-style key preferences and Suite B thinking. As a sender, with labeled information, you can only use approved algorithms. Thus, if a recipient doesn't list the approved algorithm, you just can't send them mail. The OpenPGP-style key preferences are in my view primarily to ensure interoperability and allow for algorithm transitions over long timescales. Are we proposing sender-side rules to match labels to approved algorithms? It seems inadequate to put 'SuiteBOnly' as a key preference on recipients. 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 m47DVKFn039527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2008 06:31: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 m47DVKTv039526; Wed, 7 May 2008 06:31: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 fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m47DVI8j039512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 May 2008 06:31:19 -0700 (MST) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 78EA25299; Wed, 7 May 2008 09:31:17 -0400 (EDT) From: Greg Troxel To: Andrey Jivsov Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> <4820B9B2.1010500@brainhub.org> X-Hashcash: 1:20:080507:ietf-openpgp@imc.org::ZTnTPjQUmfA/2L3D:0000000000000000000000000000000000000000009wd X-Hashcash: 1:20:080507:openpgp@brainhub.org::pog9lR3IbdWxQuMQ:000000000000000000000000000000000000000000hOI Date: Wed, 07 May 2008 09:31:17 -0400 In-Reply-To: <4820B9B2.1010500@brainhub.org> (Andrey Jivsov's message of "Tue, 06 May 2008 13:04:02 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix) 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: Andrey Jivsov writes: > Many of these issues, such as the security level of information, is > outside of traditional domain of OpenPGP. I suppose an e-mail > application in Suite-B environment might have a UI combobox with > SECRET/TOP SECRET choices in the compose window that magically (based > on content or at worst manually) are set to the correct level. The > rest is easier to program: this would allow software to check that > [TS] information is being sent to [S] key(s) and block it. I am a bit boggled as to the point of this discusion. It seems rather unlikely that an OpenPGP software implementation will be approved to handle classified traffic, and even less likely that a user on a computer running a GUI will have available adequate MLS facilities to choose the level of a message. Are we talking about being able to have an OpenPGP implementation be configured to follow Suite B guidelines for S or TS, intended for use with unclassified information? This would perhaps follow the reasonable theory that such guidelines define best practices for algorithm choice. Are we talking about hardened implementations that would implement mail gateways between enclaves? Or something else? I don't mean to be difficult, but I really don't get it. 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 m46K4AcA002704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 May 2008 13:04: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 m46K4ADS002703; Tue, 6 May 2008 13:04: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 brainhub.org (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m46K485F002693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 May 2008 13:04:09 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from [10.214.201.192] ([64.1.215.241]) by brainhub.org (8.14.2/8.14.1) with ESMTP id m46K48uE005699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 May 2008 13:04:08 -0700 Message-ID: <4820B9B2.1010500@brainhub.org> Date: Tue, 06 May 2008 13:04:02 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> In-Reply-To: <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: [I sent it out incorrectly, re-sending] A few comments to David Crick: > I agree. In fact I would go further and say if A is the way forward > chosen then we should remove *all* mention of Suite-B from the > OpenPGP ECC proposal, except for perhaps a paragraph noting that a > subset of OpenPGP ECC may be used as the basis for Suite B > implementations. I agree that there is inconsistency in that if we go with "C", i.e. we anticipate another separate document (standard or just a best practices write-up), then Suite-B text from ECC in OpenPGP document can be moved elsewhere. At the same Suite-B and NSA are, as Jon Callas called them "big elephant in the room" and from this point of view I can see value in the current text that gives an idea of what is needed for Suite-B. It seems that there is good consensus against increase in the text referring to Suite-B in the document. I will wait and listen for a few days regarding how to reduce/improve what currently have. to David Shaw: > I'm not sure that option (B) is really selectable here. Or put > another way, I think option (B) already exists as part of the current > cipher preferences system. > > For example, take the entire installed user base of OpenPGP programs > to date. That's a non-trivial amount of code in active use. Those > programs will not know about the new feature flags, and will thus > ignore them (meaning they will use 3DES as the default algorithm). I meant to introduce it with ECC keys. Here we have an advantage that these keys can only be understood by new software. This is better than circumstances before the adoption of MDC. > Now take the case of an old key (default is 3DES) and a new key > (default is AES) as recipients to a message. Let's assume that there > is no agreement on ciphers, so the cipher of last resort must be > used. A sender using the 4880-compliant program will (correctly) use > 3DES, as it knows nothing about the feature flag telling it do behave > otherwise. A new OpenPGP program might not have 3DES (why bother > since AES is the new default), so one of the recipients won't be able > to read the message. Okay, so we can fix that: we can enhance (B) > with a rule saying that 3DES is still a MUST-implement cipher, to > cover that case. Correct, RFC4880 MUSTs are carried over in general. > Now take the reverse case: the same two recipient keys, but the > sender is a new OpenPGP program that believes AES to be the default. > In the case above, the message will *still* be 3DES, as the older key > does not have the necessary feature flag, so the new program can't > use this new feature across the entire recipient set. The though was that since the feature removes 3DES as implicit default, the two subsets of recipients -- one with 3DES common algorithm and another with AES -- will get empty intersection. This will result in a sending error. > So given that new programs will need to have 3DES anyway to cover the > transition case, and given that messages sent to a mixture of old > and new keys that are forced to use the cipher of last resort will > end up as 3DES.... how is (B) different than the current cipher > preference system with AES listed before 3DES? It is different in one important feature: it allows the removal of legacy algorithm from the default. This is not a panacea and will break interoperability in some cases. > Unless I misunderstand, isn't A really the same as C (or to be very > accurate, isn't A a possible implementation of C?) "A" is a way to have specific Suite-B flag, unlike B, which is more aligned with RFC 4880 and really deals with 3DES-AES succession. There are many "A"s possible, the one given is the bare minimum, since it doesn't say much. C basically says that A and B are out of scope. > This sort of thing risks putting restrictions in places that can't > always handle those restrictions. Take the restriction where the > implementation, in its Suite-B mode, must not allow the sending of > messages to keys that can't handle Suite-B: so much so that it's even > verboten to send two messages. Now take real-world examples like > that of Enigmail, which uses GPG as its crypto engine. How on earth > is GPG, the "OpenPGP implementation" in that system, supposed to stop > Enigmail from doing that? Forget GPG even - outside of a locked down > environment, how is any implementation supposed to stop the user > from doing that? Yes, this thread shows that there is clearly more to Suite-B than a few web pages that NSA has put up. Many of these issues, such as the security level of information, is outside of traditional domain of OpenPGP. I suppose an e-mail application in Suite-B environment might have a UI combobox with SECRET/TOP SECRET choices in the compose window that magically (based on content or at worst manually) are set to the correct level. The rest is easier to program: this would allow software to check that [TS] information is being sent to [S] key(s) and block it. Thank you everybody else, Jon, Werner, and Ian, for their comments. 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 m45LlT3q041398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 14:47: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 m45LlT4N041397; Mon, 5 May 2008 14:47: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 merrymeet.com (merrymeet.com [66.93.68.160]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45LlSkW041387 for ; Mon, 5 May 2008 14:47:29 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 1FFA2F1FED5 for ; Mon, 5 May 2008 14:47:27 -0700 (PDT) Received: from bgillson-d620.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Mon, 05 May 2008 14:47:28 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 05 May 2008 14:47:28 -0700 Message-Id: <2FC4E7F8-B652-4C63-B2D6-7700C815D429@callas.org> From: Jon Callas To: OpenPGP In-Reply-To: <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Mon, 5 May 2008 14:47:26 -0700 References: <481CD4EB.2020309@brainhub.org> <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 5, 2008, at 6:52 AM, David Crick wrote: > >> Here is promised ballot. "x" for "yes". > > Well unless there is some Microsoft-style vote-stuffing > / strange consensus counting, it looks like Andrey's C > has carried. Excuse me, but we operate by rough consensus, not voting. While it's appropriate to have a straw poll to get the feeling of what the consensus is, things do not "carry" -- and certainly ending a straw poll on Monday afternoon that went out on Saturday might look a lot like vote-stuffing to someone who worried about such things. Having said that, I also like C. Rough consensus seems to be going that way, but we'd want to give people a week or so. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIH4BwsTedWZOD3gYRAjslAKCorzXVHcfv7J0yLgpGKOEDpTZClQCfewPM Pwx+fkHBEPCkLNGiuYiB1Os= =s/Zs -----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 m45Dq8HD050223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 06:52:08 -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 m45Dq8JY050222; Mon, 5 May 2008 06:52:08 -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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45Dq6q0050214 for ; Mon, 5 May 2008 06:52:07 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by nf-out-0910.google.com with SMTP id 30so1132904nfu.24 for ; Mon, 05 May 2008 06:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=c7xMncbiuGKl1Poe9MOm8BZ+K6T66MqY1CRCegl8dFs=; b=B14D/mLHzxvLHvpe0wVkWUOOJ64vTCv3AzIt5940On3ko5DMIA+L5gKGw4RoocIKnqwwhqozoB/QVH8BPfWzmoRINBMTO2h7Tv3IpHfKtX0t7OQIbMXKYj8t0gn7gj2zLumDPIvGL2jwYxxKFKAvE2uJJKHjUFQF+8tr9KR8zLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rksLi9aImkSjE3vWcMWkr/UyIYJRYTYlcQeQGB1k0+Ydz2lw/eoepYB/vbRCHNxaAAr5OWq3PWxYN1BmlARdwelhMpSkedcGPGIMyRUwTouU+d5krc+LsE+T7PSEXKu+L850JCzT6DoLNWt+ddZnZCbNNSYwxg495LQHATmiIgA= Received: by 10.78.21.7 with SMTP id 7mr1619943huu.69.1209995525322; Mon, 05 May 2008 06:52:05 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Mon, 5 May 2008 06:52:05 -0700 (PDT) Message-ID: <117bad160805050652v71d32854vc5b468b78dfc44c6@mail.gmail.com> Date: Mon, 5 May 2008 14:52:05 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Here is promised ballot. "x" for "yes". Well unless there is some Microsoft-style vote-stuffing / strange consensus counting, it looks like Andrey's C has carried. I'm happy with that - I'd rather see Suite-B left out than "put in with problems." Andrey - do you want to start a re-write of the submitted document "without" Suite-B? I will be more than happy to (then) do my long-promised clarity review - although I'm sure removing Suite-B will just by itself reduce a lot of the current complexity and verbiage. 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 m45Ai05f079005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 03:44: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 m45Ai0vo079004; Mon, 5 May 2008 03:44: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 skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45AhwlE078984 for ; Mon, 5 May 2008 03:43:59 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 4AB655D23; Mon, 5 May 2008 11:43:51 +0100 (GMT/BST) Message-ID: <481EE4ED.8060503@systemics.com> Date: Mon, 05 May 2008 12:43:57 +0200 From: Ian G User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Andrey Jivsov Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> In-Reply-To: <481CD4EB.2020309@brainhub.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andrey Jivsov wrote: > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== Iang: A: B: C: x. iang PS: the rest of the original post looks great for an intro to a document describing a potential Suite-B compatible profile. 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 m45ABKcn065893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 03:11: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 m45ABKqg065891; Mon, 5 May 2008 03:11: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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m45ABFpA065863 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 5 May 2008 03:11:17 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JsxnF-0002Cb-Pn for ; Mon, 05 May 2008 12:19:37 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JsxaK-0006ow-BP; Mon, 05 May 2008 12:06:16 +0200 From: Werner Koch To: Andrey Jivsov Cc: ietf-openpgp@imc.org Subject: Re: ECC curve ID References: <87lk564ctl.fsf@wheatstone.g10code.de> <47C5F2BD.6030003@brainhub.org> <87r6d4eu4g.fsf@wheatstone.g10code.de> <4808ECD9.8050204@brainhub.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 05 May 2008 12:06:15 +0200 In-Reply-To: <4808ECD9.8050204@brainhub.org> (Andrey Jivsov's message of "Fri, 18 Apr 2008 11:47:53 -0700") Message-ID: <87hcddjca0.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) 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: On Fri, 18 Apr 2008 20:47, openpgp@brainhub.org said: > Pros for OpenPGP IDs. > > 1) Vote of confidence for a particular curve. If it is included, > potential implementers have agreed on it. It will be more likely > widely supported. For example this is useful for hardware folks who > plan far ahead, plays in the decisions about which curve to use in key > self-signatures, and gives priorities to performance optimizations. The same can be said of OIDs. > 2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()). Well, okay. > 3) consistency with the way OpenPGP references other algorithms. Only if we agree that a curveID describes an OpenPGP algorithm. In my view this is a parameter of the algorithm, much like p, q and g in DSA or even the key size of all aglgorithms. For sure I do not want to convey all ECC curve parameters, thus using a way to describe the curve is important. > 4) Named curves can be introduced as an extension. The core set of > curves will be encoded as integers, others as named curves. I thought of that and was about to propose a format using an ID of 0 to identify a named curve. However the specification as well as the code will be more complicated - even in the case that named curves are not supported by the implementation. > Do you see any value in having some approval process for new curves? > Does it bother you that I can use some questionable curve and it will > carry equal status per the spec to the three curves we discussed so > far (will we have a method to distinguish "next good" curve past P-521 > from an experimental curve) ? No. We also don't approve implementations and have no real limits on key sizes. It is easy to get things wrong. Using a good curve is as important as to use sound parameters for RSA. > Can we reach an agreement if the document also defined a method to > list named curves, along the lines of Werner's proposal? If there is no other way to allow for arbitrary curves, I would agree to it. However, I still believe that an OID with a memcmp in the code is easier to implement than a numeric ID with a switch and a mechnism to cope withe the optional OID named curve. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. 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 m459tnZQ059152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 02:55: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 m459tnTq059151; Mon, 5 May 2008 02:55: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 skaro.afraid.org (skaro.afraid.org [212.169.1.61]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m459tT5E058996 for ; Mon, 5 May 2008 02:55:34 -0700 (MST) (envelope-from iang@systemics.com) Received: from zhukov.local (localhost.cthulhu.dircon.co.uk [127.0.0.1]) by skaro.afraid.org (Postfix) with ESMTP id 5EE895D23; Mon, 5 May 2008 10:55:17 +0100 (GMT/BST) Message-ID: <481ED98A.8040308@systemics.com> Date: Mon, 05 May 2008 11:55:22 +0200 From: Ian G User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: David Shaw Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> <117bad160805040925p2025e620l504b8be6c5f43af@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: >>> how is (B) different than the current cipher preference system with >>> AES listed before 3DES? >> >> right - which is why my original proposal was for a stronger >> suite B flag, which says implementations MUST NOT process >> messages that fall outside of the Suite-B restrictions (that aside, >> Andrey has written in "OpenPGP technical/documentation terms" >> what I was originally trying to get across with my perhaps wrong >> terminology of a Strict Suite-B "flag"). > > This sort of thing risks putting restrictions in places that can't > always handle those restrictions. Take the restriction where the > implementation, in its Suite-B mode, must not allow the sending of > messages to keys that can't handle Suite-B: so much so that it's even > verboten to send two messages. Now take real-world examples like that > of Enigmail, which uses GPG as its crypto engine. How on earth is GPG, > the "OpenPGP implementation" in that system, supposed to stop Enigmail > from doing that? Forget GPG even - outside of a locked down > environment, how is any implementation supposed to stop the user from > doing that? Good example. I don't believe it is possible to assert compliance with Suite-B, simply because we (whoever we are) are not the authorities on it. Others are, NIST, I assume. In such a situation, likely the best we can do is lay the framework for Suite-B *compatible* messages. Get some formats out, get some code written. And Enigmail will become (if it so desires) a Suite-B compatible client. Then, others, perhaps PGP Inc's client, will become certified to do Suite-B by jumping through all the hoops. This will create a different messaging profile, perhaps compatible with the earlier, or perhaps not. Suite-B public compatible profile, versus, Suite-B certified profile. We'll likely end up with a schitzophrenic marketplace. The first thing that will happen is that clients distribute compatible messages, to bootstrap the usage. Then, someone will create a certification profile and get it certified. Then, there will be some tiny proportion of sales for the certification profile, and the vast mass will work to the compatible modes. This is ok, as long as we end up with a large marketplace where the majority of clients speak a compatible mode. The challenge is then only for the official certified version ... how does it switch between "compatible" and "certified" messages? However, that challenge properly belongs to the commercial company that tries to take it through the certification process. (I think I am now agreeing with Jon. The best solution is to do nothing, state nothing in the document. And leave it to the company that takes it through the certification process. And let them create a new convention. And they can share that profile with other *certified* implementations under the NIST process, or with the world, as they see fit.) > I'm okay with some magic flag that says "I do Suite-B", if we leave the > implementation alone to deal with it (within the bounds of > interoperability). I'm even more in favor of combining that with a > "OpenPGP Suite-B" document that lays out all the rules, whether they > pertain to the OpenPGP message format, or how a mail program is allowed > to send mail. A separate document, where those who need those semantics > can have them all specified in detail, but those who don't need those > semantics are not encumbered with by them. I'm ok with that. I now see that it may have been just too complicated to do both ECC and Suite-B in the same document. iang 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 m459km3N055627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 May 2008 02:46:48 -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 m459kmQX055622; Mon, 5 May 2008 02:46:48 -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 kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m459kGFE055460 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 5 May 2008 02:46:17 -0700 (MST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JsxP3-0001zd-Ls for ; Mon, 05 May 2008 11:54:37 +0200 Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JsxCw-0006nY-G7; Mon, 05 May 2008 11:42:06 +0200 From: Werner Koch To: Andrey Jivsov Cc: OpenPGP Subject: Re: OpenPGP keys and Suite-B References: <481CD4EB.2020309@brainhub.org> Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 05 May 2008 11:42:06 +0200 In-Reply-To: <481CD4EB.2020309@brainhub.org> (Andrey Jivsov's message of "Sat, 03 May 2008 14:11:07 -0700") Message-ID: <87lk2pjde9.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.110007 (No Gnus v0.7) 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: On Sat, 3 May 2008 23:11, openpgp@brainhub.org said: > =================================================================== > A. Use key notations "suite-b-key@pgp.com" > with values "top secret" and "secret". > =================================================================== Fine with me, but I see no need to mention it in the standard. > =================================================================== > B. Use feature bits of a key 0x02, 0x4 of > "5.2.3.24. Features" as follows: > 0x02: The default symmetric alg. of the key is AES-128 > 0x04: The default symmetric alg. of the key is AES-256 > These bits can be combined (i.e. they are not mutually > exclusive). > =================================================================== Too complicated. > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== Okay. Werner: A: B: C: x Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. 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 m44KlXX6041234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 13:47:33 -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 m44KlXYm041232; Sun, 4 May 2008 13:47:33 -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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44KlVEJ041203 for ; Sun, 4 May 2008 13:47:31 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44KlUk28204 for ; Sun, 4 May 2008 16:47:30 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44KlPdA008315 for ; Sun, 4 May 2008 16:47:25 -0400 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 16:47:25 -0400 References: <481CD4EB.2020309@brainhub.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote: > > =================================================================== > A. Use key notations "suite-b-key@pgp.com" > with values "top secret" and "secret". > =================================================================== > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== > In other words, A and B are really C+policies. Unless I misunderstand, isn't A really the same as C (or to be very accurate, isn't A a possible implementation of C?) 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 m44KZHqA035973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 13: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 m44KZGak035972; Sun, 4 May 2008 13:35:16 -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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44KZFmb035955 for ; Sun, 4 May 2008 13:35:16 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44KZEk28155 for ; Sun, 4 May 2008 16:35:14 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44KZ9bs008266 for ; Sun, 4 May 2008 16:35:09 -0400 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <117bad160805040925p2025e620l504b8be6c5f43af@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 v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 16:35:09 -0400 References: <481CD4EB.2020309@brainhub.org> <117bad160805040925p2025e620l504b8be6c5f43af@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2008, at 12:25 PM, David Crick wrote: >> So given that new programs will need to have 3DES anyway to cover the >> transition case, and given that messages sent to a mixture of old >> and new >> keys that are forced to use the cipher of last resort will end up >> as 3DES.... > > This is (mainly) about ECC keys, and specifically about the > implementations' [ability to enforce] Suite-B compliance. > > As old applications won't be able to understand ECC keys *at > all*, we've "almost" got a clean sheet with what we do with > ECC keys. "Almost," because at present ECC keys inherit > 3DES as the default cipher from 4880. I understand that this is intended to be about ECC keys, but the slate isn't even "almost" clean so long as as we're playing alongside 4880. There are a bunch of messy cross cases that make this highly resistant to cleanliness. >> how is (B) different than the current cipher preference system with >> AES listed before 3DES? > > right - which is why my original proposal was for a stronger > suite B flag, which says implementations MUST NOT process > messages that fall outside of the Suite-B restrictions (that aside, > Andrey has written in "OpenPGP technical/documentation terms" > what I was originally trying to get across with my perhaps wrong > terminology of a Strict Suite-B "flag"). This sort of thing risks putting restrictions in places that can't always handle those restrictions. Take the restriction where the implementation, in its Suite-B mode, must not allow the sending of messages to keys that can't handle Suite-B: so much so that it's even verboten to send two messages. Now take real-world examples like that of Enigmail, which uses GPG as its crypto engine. How on earth is GPG, the "OpenPGP implementation" in that system, supposed to stop Enigmail from doing that? Forget GPG even - outside of a locked down environment, how is any implementation supposed to stop the user from doing that? I'm okay with some magic flag that says "I do Suite-B", if we leave the implementation alone to deal with it (within the bounds of interoperability). I'm even more in favor of combining that with a "OpenPGP Suite-B" document that lays out all the rules, whether they pertain to the OpenPGP message format, or how a mail program is allowed to send mail. A separate document, where those who need those semantics can have them all specified in detail, but those who don't need those semantics are not encumbered with by them. 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 m44KA2aA024671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 13:10: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 m44KA2GQ024670; Sun, 4 May 2008 13:10: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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44KA0VS024642 for ; Sun, 4 May 2008 13:10:01 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44K9xk28044 for ; Sun, 4 May 2008 16:09:59 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44K9sqZ008196 for ; Sun, 4 May 2008 16:09:54 -0400 Message-Id: <00A8C9D4-E391-4B1E-BF65-2CAD941326D1@jabberwocky.com> From: David Shaw To: OpenPGP In-Reply-To: <117bad160805040934s76a499fheaf977b2d4f5d53e@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 v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 16:09:54 -0400 References: <481CD4EB.2020309@brainhub.org> <20080504161327.GA60504@jabberwocky.com> <117bad160805040934s76a499fheaf977b2d4f5d53e@mail.gmail.com> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 4, 2008, at 12:34 PM, David Crick wrote: > > On Sun, May 4, 2008 at 5:13 PM, David Shaw > wrote: >> >> On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote: >> >>> =================================================================== >>> C. Higher layers of application will govern compliance >>> with Suite B. "ECC in OpenPGP" document will define >>> reasonable superset of features required for Suite-B >>> or similar government documents, but exact >>> specification of the policies to use ECC in OpenPGP >>> is out of scope. >>> =================================================================== >> >> I vote for C. Keep the policies out of the standard and leave it up >> to the implementers. I'm not against having policies specified, but >> I'd rather see them in a different document for use by those people >> who need them. There is precedence here: OpenPGP specifies DSA and >> not DSS. >> >> David > > 4880 13.6 starts with: > > 13.6. DSA > > An implementation SHOULD NOT implement DSA keys of size less than > 1024 bits. It MUST NOT implement a DSA key with a q size of less > than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the > q size MUST be a multiple of 8 bits. > > and ends with: > > Note that earlier versions of this standard only allowed a 160-bit q > with no truncation allowed, so earlier implementations may not be > able to handle signatures with a different q size or a truncated > hash. > > which I would say would be "on using DSA in OpenPGP." But then in > the middle of those two bits has all of this: > > The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be > used in one of the following ways: > > * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or > SHA-512 hash > > * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 > hash > > * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash > > * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash > > The above key and q size pairs were chosen to best balance the > strength of the key with the strength of the hash. Implementations > SHOULD use one of the above key and q size pairs when generating DSA > keys. If DSS compliance is desired, one of the specified SHA hashes > must be used as well. [FIPS186] is the ultimate authority on DSS, > and should be consulted for all questions of DSS compliance. > > > which by your argument "shouldn't be in" OpenPGP. Not at all. There is a very substantial difference between mentioning in passing the difference between the specification and a popular standard and the addition of new semantics to enforce a difference between the specification and a popular standard. Notice we don't have a "Strict DSS" flag or anything like that. If someone wants to enforce it and draw a distinction, that's fine. OpenPGP gives people a lot of crypto parts they can put together in different ways. > We've got the same thing with Suite-B, only the fact that it's not > just > a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is > of 4880), but that there's a conflict between the 4880 spec and > Suite-B > (i.e. (at least) the issue of 3DES). Then publish an additional RFC giving whatever semantics are desired. I wouldn't want to load down the basic "ECC in OpenPGP" spec with it, any more than I'd want to see the traditional PGP trust model specified in 4880. 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 m44GYRnC028937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 09:34:27 -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 m44GYRLq028936; Sun, 4 May 2008 09:34:27 -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.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44GYPI6028916 for ; Sun, 4 May 2008 09:34:26 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so532324fkq.10 for ; Sun, 04 May 2008 09:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VckS+vlqCbaUI4ccZtS61z08+rg7FmKPOnKPSRvM5tY=; b=tsDIlN8Mpu1RaXaXZ5c7z0rRh4jtfCXH6bIVvGUN5woKqvRqjsc3oyn193dUGZZ1zUEwG28FW+rSEWY1OeIIiI7J0dpa0MAiAlEg9joT2IMy7yReZ1UyeBOMhtTriMoZO/53ism8e+vXmGK2Ab70RpbKQRSBXIxru8z9EzyJnMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YdsTyhndQEmtrZgoy5HpL788AmC2or0VJAMa1w6lCGKEAKHn/vw0AJQCbQpbQGLrI8l6/d+3kK8ow5TN7f+++1WpSslMb7uScsBmTLgXmRodvD3dw9o5VEU76iSb4Nx7qQRSHNpmlyjlXWXJiBChIDRBmPDyEcza4qo7nYG/Olc= Received: by 10.78.129.16 with SMTP id b16mr1352300hud.116.1209918864146; Sun, 04 May 2008 09:34:24 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sun, 4 May 2008 09:34:24 -0700 (PDT) Message-ID: <117bad160805040934s76a499fheaf977b2d4f5d53e@mail.gmail.com> Date: Sun, 4 May 2008 17:34:24 +0100 From: "David Crick" To: OpenPGP Subject: Re: OpenPGP keys and Suite-B Cc: "David Shaw" In-Reply-To: <20080504161327.GA60504@jabberwocky.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> <20080504161327.GA60504@jabberwocky.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, May 4, 2008 at 5:13 PM, David Shaw wrote: > > On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote: > > > =================================================================== > > C. Higher layers of application will govern compliance > > with Suite B. "ECC in OpenPGP" document will define > > reasonable superset of features required for Suite-B > > or similar government documents, but exact > > specification of the policies to use ECC in OpenPGP > > is out of scope. > > =================================================================== > > I vote for C. Keep the policies out of the standard and leave it up > to the implementers. I'm not against having policies specified, but > I'd rather see them in a different document for use by those people > who need them. There is precedence here: OpenPGP specifies DSA and > not DSS. > > David 4880 13.6 starts with: 13.6. DSA An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. It MUST NOT implement a DSA key with a q size of less than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the q size MUST be a multiple of 8 bits. and ends with: Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. which I would say would be "on using DSA in OpenPGP." But then in the middle of those two bits has all of this: The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. which by your argument "shouldn't be in" OpenPGP. We've got the same thing with Suite-B, only the fact that it's not just a case of Suite-B being a restricted subset of OpenPGP ECC (as DSS is of 4880), but that there's a conflict between the 4880 spec and Suite-B (i.e. (at least) the issue of 3DES). 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 m44GP9HO024425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 09:25: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 m44GP9ir024424; Sun, 4 May 2008 09:25: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 mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.189]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44GP7th024399 for ; Sun, 4 May 2008 09:25:08 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so851388mue.4 for ; Sun, 04 May 2008 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=mM1mqKl3h6DtR0GKu2fSWBXrObHIBqkWp8Pe32F1Hs0=; b=SOshjU6WDj0ebPHrfFxD5M4BsqRAZpSr/j3JSsTBZNQvXD0NjepS+mYtHEy2N0KofGmnmhqIcp56rQKFxJMVO83UOlGnSMEfTMEyE1kVmeWtgu4LcqHRQQZI2B7/0KzMsGRgXbX4USXFYNUPEx3OhrKnlbORny/+5ccoZNNz71I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lfkGurgdgWIFcxqwq6EAKX/b8S7iU23igdn4csTidvLd4nJEUCHvz0CbdW2SO6AwdOZ4fE9+j7aqExjRaJJ9iLLy9TlZHX3gHqfSpRLAeZ/PaE4EW+K0rOEtFfaemORVfw7zO93gyyFUVoVjGinGIOH2AsHlCKZZR3wJMTNDNCY= Received: by 10.78.147.6 with SMTP id u6mr1386907hud.39.1209918306278; Sun, 04 May 2008 09:25:06 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sun, 4 May 2008 09:25:06 -0700 (PDT) Message-ID: <117bad160805040925p2025e620l504b8be6c5f43af@mail.gmail.com> Date: Sun, 4 May 2008 17:25:06 +0100 From: "David Crick" To: "David Shaw" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP , "Andrey Jivsov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So given that new programs will need to have 3DES anyway to cover the > transition case, and given that messages sent to a mixture of old and new > keys that are forced to use the cipher of last resort will end up as 3DES.... This is (mainly) about ECC keys, and specifically about the implementations' [ability to enforce] Suite-B compliance. As old applications won't be able to understand ECC keys *at all*, we've "almost" got a clean sheet with what we do with ECC keys. "Almost," because at present ECC keys inherit 3DES as the default cipher from 4880. > how is (B) different than the current cipher preference system with > AES listed before 3DES? right - which is why my original proposal was for a stronger suite B flag, which says implementations MUST NOT process messages that fall outside of the Suite-B restrictions (that aside, Andrey has written in "OpenPGP technical/documentation terms" what I was originally trying to get across with my perhaps wrong terminology of a Strict Suite-B "flag"). (And to directly answer your question, Andrey's B is slightly different, in that while the preference system *is* ordered, implementations currently have free rein at how they use the intersection of recipient preferences; Andrey's B says that AES should be used in place of 3DES - but as you've (now) pointed out, for non-ECC keys this may mean some people receiving AES messages when in fact they can e.g. only process 3DES ones). 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 m44GDbaV018570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 09:13: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 m44GDbfd018569; Sun, 4 May 2008 09:13: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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44GDYI7018542 for ; Sun, 4 May 2008 09:13:37 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44GDXk27042 for ; Sun, 4 May 2008 12:13:33 -0400 Received: from jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with SMTP id m44GDSBC007280 for ; Sun, 4 May 2008 12:13:28 -0400 Date: Sun, 4 May 2008 12:13:27 -0400 From: David Shaw To: OpenPGP Subject: Re: OpenPGP keys and Suite-B Message-ID: <20080504161327.GA60504@jabberwocky.com> Mail-Followup-To: OpenPGP References: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481CD4EB.2020309@brainhub.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.17 (2007-11-01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, May 03, 2008 at 02:11:07PM -0700, Andrey Jivsov wrote: > =================================================================== > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. > =================================================================== I vote for C. Keep the policies out of the standard and leave it up to the implementers. I'm not against having policies specified, but I'd rather see them in a different document for use by those people who need them. There is precedence here: OpenPGP specifies DSA and not DSS. 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 m44FfV8X005172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 08:41: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 m44FfVWm005171; Sun, 4 May 2008 08:41: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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44FfUHH005151 for ; Sun, 4 May 2008 08:41:30 -0700 (MST) (envelope-from dshaw@jabberwocky.com) Received: from walrus.jabberwocky.com (c-75-69-177-157.hsd1.ma.comcast.net [75.69.177.157]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id m44FfTk26860 for ; Sun, 4 May 2008 11:41:29 -0400 Received: from [172.24.84.28] (grover.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.1/8.14.1) with ESMTP id m44FfO9Z007130 for ; Sun, 4 May 2008 11:41:24 -0400 Message-Id: From: David Shaw To: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: OpenPGP keys and Suite-B Date: Sun, 4 May 2008 11:41:24 -0400 References: <481CD4EB.2020309@brainhub.org> X-Mailer: Apple Mail (2.919.2) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On May 3, 2008, at 5:11 PM, Andrey Jivsov wrote: > =================================================================== > B. Use feature bits of a key 0x02, 0x4 of > "5.2.3.24. Features" as follows: > 0x02: The default symmetric alg. of the key is AES-128 > 0x04: The default symmetric alg. of the key is AES-256 > These bits can be combined (i.e. they are not mutually > exclusive). > =================================================================== > > TOP SECRET (TS) must have 0x02 > SECRET must have 0x02|0x04=0x06 > > The existence of 0x02 or 0x04 tells that the implicit default > algorithm TripleDES is replaced by (either of) corresponding AES > algorithm(s). > > This specification may appeal to these who don't want to see Suite-B > mentioned in the "protocol/format" document. It also specifies > narrow feature using the concepts compatible with the scope of RFC > 4880. I'm not sure that option (B) is really selectable here. Or put another way, I think option (B) already exists as part of the current cipher preferences system. For example, take the entire installed user base of OpenPGP programs to date. That's a non-trivial amount of code in active use. Those programs will not know about the new feature flags, and will thus ignore them (meaning they will use 3DES as the default algorithm). Now take the case of an old key (default is 3DES) and a new key (default is AES) as recipients to a message. Let's assume that there is no agreement on ciphers, so the cipher of last resort must be used. A sender using the 4880-compliant program will (correctly) use 3DES, as it knows nothing about the feature flag telling it do behave otherwise. A new OpenPGP program might not have 3DES (why bother since AES is the new default), so one of the recipients won't be able to read the message. Okay, so we can fix that: we can enhance (B) with a rule saying that 3DES is still a MUST-implement cipher, to cover that case. Now take the reverse case: the same two recipient keys, but the sender is a new OpenPGP program that believes AES to be the default. In the case above, the message will *still* be 3DES, as the older key does not have the necessary feature flag, so the new program can't use this new feature across the entire recipient set. So given that new programs will need to have 3DES anyway to cover the transition case, and given that messages sent to a mixture of old and new keys that are forced to use the cipher of last resort will end up as 3DES.... how is (B) different than the current cipher preference system with AES listed before 3DES? 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 m44EuANl087521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2008 07:56: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 m44EuAGm087520; Sun, 4 May 2008 07:56: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 fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m44Eu8AL087496 for ; Sun, 4 May 2008 07:56:09 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so502255fkq.10 for ; Sun, 04 May 2008 07:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YnI1/+3DPzBdcHS6xAetyScvAPhPjr818LDxS1tqif4=; b=kLpm9u8h0zNUsSUpboAArR2YI1f1O+g97M7T7sWAy4avDUksvyfXlgyg4bLRrJHDkG6j51O1jI7UMpnHlEnCBfFcIAljUo2jEFVeStYq9tybXIjLiyUu3FrBbBOLF+WRiZBZr7Ese1zM/Hd1xsbUzyvibY33ah6V7bo8yBaKVVQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XSe8dyGpF5K6298MMFrTutfryxVShLUiZqB1FxAq/8EvO7tegHf7b7szg5fe4Ow35V7ric59ekDw1K1QE6iyoYS7CzAVC6iJB/HNFxcvHeCMF948grcI8RAnNkkSIub9JIEjsqk9RuJ5cdHdsimH0O+Rtsw7MfA1M6H93BbeoOw= Received: by 10.78.135.20 with SMTP id i20mr1381550hud.18.1209912967717; Sun, 04 May 2008 07:56:07 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sun, 4 May 2008 07:56:07 -0700 (PDT) Message-ID: <117bad160805040756v1938d69ej47a5a412942e9f64@mail.gmail.com> Date: Sun, 4 May 2008 15:56:07 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, May 3, 2008 at 10:11 PM, Andrey Jivsov wrote: > > Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires > that > > TOP SECRET must use AES-256 > SECRET must use AES-128 or AES-256 > > Labeled security is usually required with these standards. Information is > labeled with certain classification, which assures that the processing of > this information will match the label as data travels through the system. > This results in: > > TOP SECRET keys can receive TOP SECRET and SECRET information > SECRET keys can only receive SECRET information > > Information | | > level | Keys | "Send to" action > -------------------------------------------- > [TS] | [TS],[S] | fail > [S] | [TS],[S] | allow with AES-256 > [TS] | [S] | fail > [S] | [TS] | allow with AES-256 > [TS] | [TS] | allow with AES-256 > [S] | [S] | allow with AES-256/128 > > Note that two first rows represent the same mix of keys but result in > different behavior. This aspect is orthogonal to OpenPGP. Andrey, I really appreciate you putting the effort in to flesh this out. > For completeness, > > Key level | Key preferences > -------------------------------------------- > [TS] | {AES-256} > [S] | {AES-256, AES-128} Note, however, that the [TS]/[S] suites restrict not only the symmetrical cipher but also the public key size and the size of the SHA2 hash used too. Your "key level" implicitly includes these further restrictions, but it needs to be stated explicitly as well, and there would be similar "fails" if the public key size was too small or (say) you were doing conventional encryption and the hash used for the passphrase was too small. The current discussion has sprung from the "inheriting" of 3DES from 4880, however, so that was why the focus has (so far) been on the fact that OpenPGP ECC COULD encrypt using 3DES unless we provide some sort of mechanism or policy to prevent this (and hence this particular document). > I see three approaches. > > A. Use key notations "suite-b-key@pgp.com" > Leave the interpretation of these values to applications. > (If all we have to say is the sentence under A, I would say we keep it out > of the document.) I agree. In fact I would go further and say if A is the way forward chosen then we should remove *all* mention of Suite-B from the OpenPGP ECC proposal, except for perhaps a paragraph noting that a subset of OpenPGP ECC may be used as the basis for Suite B implementations. =================================================================== > B. Use feature bits of a key 0x02, 0x4 of > "5.2.3.24. Features" as follows: > 0x02: The default symmetric alg. of the key is AES-128 > 0x04: The default symmetric alg. of the key is AES-256 > These bits can be combined (i.e. they are not mutually > exclusive). > =================================================================== > > TOP SECRET (TS) must have 0x02 > SECRET must have 0x02|0x04=0x06 > > The existence of 0x02 or 0x04 tells that the implicit default algorithm > TripleDES is replaced by (either of) corresponding AES algorithm(s). this is all good. > This specification may appeal to these who don't want to see Suite-B > mentioned in the "protocol/format" document. It also specifies narrow > feature using the concepts compatible with the scope of RFC 4880. > > The Suite-B meaning need to be layered on top of these bits. interesting - I would say this was "a little bit less" than I was originally intending, i.e. you've made it "profile" (e.g. Suite-B) independent. I'm fine with that as a half-measure; it will help us "remove" 3DES. > Yet, the proposals A and B lack following details: > > * It is not sufficient to rely on key holder to tell which information > level it is eligible to receive. Everyone wants TOP SECRET. This statement > must come from a trusted source, like a certification by a trusted key or > looked up online. The above proposals A and B put data into a > self-signature. OpenPGP "0x50: Third-Party Confirmation signature" may be > needed. It is "may" because in some cases keys are managed, making this > notary signatures unnecessary, or keys may be looked up in some online > directory. > * Furthermore, what a sender does with the information and how it > interprets the flags on a key is not enforceable by a recipient. This must > be enforced by higher levels. right, so this is where my original proposal was "stronger." My original proposal was "strict suite-B flag[s] mean a sender's implementation MUST NOT use anything other than the appropriate ciphers [and hashes/public key sizes] on the recipient[s]' key" If you wish to add this as a further option to the ballot then that's up to you. > Finally: > C. Higher layers of application will govern compliance > with Suite B. "ECC in OpenPGP" document will define > reasonable superset of features required for Suite-B > or similar government documents, but exact > specification of the policies to use ECC in OpenPGP > is out of scope. Hmmm, your C reads very much like your A. In fact now having looked at your C in more detail I actually don't see any value in A - it's almost a "hint from the receiver" that needs the human user on the sending side to see it as such. At least C means something to an implementer. > In other words, A and B are really C+policies. Regardless of which route we > take, we will need "protocol/format" document. This is what implementors > need first. This is what is needed to establish interoperability base. This > is what will make messages flow. This layer alone may get incorrectly > encrypted [TS] information with TripleDES, so higher layer will be needed. This layer doesn't even care whether it's 3DES; it's not "incorrect" at all for this layer. Anyway, as with your "A" option, I see that if "C" is chosen then (almost) all mention of Suite-B should be removed from the OpenPGP ECC specification, aside from as I've mentioned above ("a subset of OpenPGP ECC may be") > However, as an implementor I see value in splitting a Suite-B cloud into > layers that we can implement and test independently. Well your original document was an AES strength ECC with Suite-B capability along with it. What's come out of it was that we either need to deal fully/properly (i.e. we need to enforce ciphers somehow), *or*, we junk all notion of Suite-B in OpenPGP ECC. If we don't "do" Suite-B "properly" then we're not actually doing it at all (it either supports Suite-B or it doesn't, i.e. there is scope for it to wrongly-encrypt with 3DES, or there isn't). > Here is promised ballot. "x" for "yes". > > As an editor I think that voting C will result in faster progress of the > document. Possibly, although the removal of Suite-B from the text will probably take just as long (longer?) than adding the "features bit" (or the "stronger" SSB bit) to the text! So, my vote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 David Crick: A: [_] (meaningless for an implementation spec) B: [x] (ideally as a strict suite B MUST respect / MUST NOT deviate) C: [_] (may as well just remove notion of Suite-B) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iF4EAREIAAYFAkgdy1UACgkQNTbKPm/1JkC8VwD+ILAxlVcej7QfV4YVwyk+i4h4 4Fo5XnMoSPghxJtt7DwA/jVQuwzAwF5wow1k99+5+gE/qy0enRZP7C/V2EnLyVIA =UEJU -----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 m43Mdihv061699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 15:39: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 m43MdiZn061698; Sat, 3 May 2008 15:39: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.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43MdYWc061625 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 3 May 2008 15:39:43 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m43Mge55010912 for ; Sat, 3 May 2008 18:43:37 -0400 Message-ID: <481CE944.7030004@brainhub.org> Date: Sat, 03 May 2008 15:37:56 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: OpenPGP Subject: Re: OpenPGP keys and Suite-B X-Priority: 5 (Lowest) References: <481CD4EB.2020309@brainhub.org> <117bad160805031426x3898f2dcu4ad9129122fc7de1@mail.gmail.com> In-Reply-To: <117bad160805031426x3898f2dcu4ad9129122fc7de1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: >> Here is promised ballot. "x" for "yes". > >> A: >> B: >> C: > > can we mark more than one box...? I suppose prioritized list will convey some information, as long as the best choice is obvious. I also don't mean to suppress offer alternative proposals, but before we go there it would be interesting to see where we stand with this list. 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 m43LQOQ1030320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 14:26:24 -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 m43LQOXZ030319; Sat, 3 May 2008 14:26: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 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 m43LQMgp030294 for ; Sat, 3 May 2008 14:26:23 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so263332fkq.10 for ; Sat, 03 May 2008 14:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=sXiN/ZpzGd/JUXb5f83v+IPlm7zz4dNcOgmY0MS5BEI=; b=dCHI+dOc0CsNW9lwITo2Auy3SQiQrlMaTb4adtNr+A2hE1H8K9sIBN5JPNHqMv1zB0pGEDLpxs595RQH0ZnS97wY7P+HGPII2PihbRnIwjJbrAqRKq6nsAf96UrFdVw7iE41Bd4HtD3R03mjyWTLWt3bOMU0UILHqcl9q8r3vu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o/c+dHg2Y5GaRUdtDi9Onqi3jjS1vSZq7j0EMGaN/YVBNBXsWUjcV+zG8HxCOMoCqNI4lWoYEy65OissK50ewmbMV53mn8NLzPVACxBPooLsdwTYhbnNdIV3xOSZsLNNjCWpSO5waiHgozxupb+W3EttbGQLnbplF4TDeGAyM3I= Received: by 10.78.133.2 with SMTP id g2mr1204430hud.92.1209849981210; Sat, 03 May 2008 14:26:21 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Sat, 3 May 2008 14:26:21 -0700 (PDT) Message-ID: <117bad160805031426x3898f2dcu4ad9129122fc7de1@mail.gmail.com> Date: Sat, 3 May 2008 22:26:21 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: OpenPGP keys and Suite-B Cc: OpenPGP In-Reply-To: <481CD4EB.2020309@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481CD4EB.2020309@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Here is promised ballot. "x" for "yes". > A: > B: > C: can we mark more than one box...? 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 m43LBCsW022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 May 2008 14:11: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 m43LBCw0022687; Sat, 3 May 2008 14:11: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 mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m43LBAF9022664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 3 May 2008 14:11:11 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m43LFQ55031517 for ; Sat, 3 May 2008 17:15:27 -0400 Message-ID: <481CD4EB.2020309@brainhub.org> Date: Sat, 03 May 2008 14:11:07 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: OpenPGP Subject: OpenPGP keys and Suite-B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Suite-B has two profiles: TOP SECRET [TS] and SECRET [S] and it requires that TOP SECRET must use AES-256 SECRET must use AES-128 or AES-256 Labeled security is usually required with these standards. Information is labeled with certain classification, which assures that the processing of this information will match the label as data travels through the system. This results in: TOP SECRET keys can receive TOP SECRET and SECRET information SECRET keys can only receive SECRET information Information | | level | Keys | "Send to" action -------------------------------------------- [TS] | [TS],[S] | fail [S] | [TS],[S] | allow with AES-256 [TS] | [S] | fail [S] | [TS] | allow with AES-256 [TS] | [TS] | allow with AES-256 [S] | [S] | allow with AES-256/128 Note that two first rows represent the same mix of keys but result in different behavior. This aspect is orthogonal to OpenPGP. For completeness, Key level | Key preferences -------------------------------------------- [TS] | {AES-256} [S] | {AES-256, AES-128} I see three approaches. =================================================================== A. Use key notations "suite-b-key@pgp.com" with values "top secret" and "secret". =================================================================== Leave the interpretation of these values to applications. The rationale is that we don't recite government documents in the document like "ECC in OpenPGP". There are other requirements that must be satisfied beyond the scope of the "ECC in OpenPGP" document, such as authentication and how the private keys are unlocked. For example, we cannot enforce the use of PIN pad devices. (If all we have to say is the sentence under A, I would say we keep it out of the document.) =================================================================== B. Use feature bits of a key 0x02, 0x4 of "5.2.3.24. Features" as follows: 0x02: The default symmetric alg. of the key is AES-128 0x04: The default symmetric alg. of the key is AES-256 These bits can be combined (i.e. they are not mutually exclusive). =================================================================== TOP SECRET (TS) must have 0x02 SECRET must have 0x02|0x04=0x06 The existence of 0x02 or 0x04 tells that the implicit default algorithm TripleDES is replaced by (either of) corresponding AES algorithm(s). This specification may appeal to these who don't want to see Suite-B mentioned in the "protocol/format" document. It also specifies narrow feature using the concepts compatible with the scope of RFC 4880. The Suite-B meaning need to be layered on top of these bits. Yet, the proposals A and B lack following details: * It is not sufficient to rely on key holder to tell which information level it is eligible to receive. Everyone wants TOP SECRET. This statement must come from a trusted source, like a certification by a trusted key or looked up online. The above proposals A and B put data into a self-signature. OpenPGP "0x50: Third-Party Confirmation signature" may be needed. It is "may" because in some cases keys are managed, making this notary signatures unnecessary, or keys may be looked up in some online directory. * Furthermore, what a sender does with the information and how it interprets the flags on a key is not enforceable by a recipient. This must be enforced by higher levels. * I thought about how a [TS] information might be encrypted to a Suite-B recipient with hypothetical command line tool. For example, like this: openpgpcmd --suite-B-information=secret --trusted-certifier-top-secret=XXX -trusted-certifier-secret=YYY recipients v.s. openpgpcmd --suite-B-information=secret --trusted-certifier=ZZZ recipients In one case the type of certifier ([TS]/[S]) is determined from key properties, in another case the types of certifiers are passed explicitly. The commands look similar, especially if there are two trusted certifiers in each case. Finally: =================================================================== C. Higher layers of application will govern compliance with Suite B. "ECC in OpenPGP" document will define reasonable superset of features required for Suite-B or similar government documents, but exact specification of the policies to use ECC in OpenPGP is out of scope. =================================================================== In other words, A and B are really C+policies. Regardless of which route we take, we will need "protocol/format" document. This is what implementors need first. This is what is needed to establish interoperability base. This is what will make messages flow. This layer alone may get incorrectly encrypted [TS] information with TripleDES, so higher layer will be needed. However, as an implementor I see value in splitting a Suite-B cloud into layers that we can implement and test independently. Here is promised ballot. "x" for "yes". As an editor I think that voting C will result in faster progress of the document. Andrey: A: B: C: x 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 m42M8oBn097554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 15:08:50 -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 m42M8omc097551; Fri, 2 May 2008 15:08:50 -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 m42M8mr2097527 for ; Fri, 2 May 2008 15:08:48 -0700 (MST) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 70F81F0D730 for ; Fri, 2 May 2008 15:08:47 -0700 (PDT) Received: from bgillson-d620.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Fri, 02 May 2008 15:08:48 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 02 May 2008 15:08:48 -0700 Cc: "Derek Atkins" , "Andrey Jivsov" , OpenPGP Message-Id: From: Jon Callas To: David Crick In-Reply-To: <117bad160805020701k5a24906cs565e43a184bbeed9@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v919.2) Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Date: Fri, 2 May 2008 15:08:44 -0700 References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> <117bad160805020701k5a24906cs565e43a184bbeed9@mail.gmail.com> X-Mailer: Apple Mail (2.919.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 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 2, 2008, at 7:01 AM, David Crick wrote: > > On Fri, May 2, 2008 at 2:32 PM, Derek Atkins wrote: >> David, >> >>> The submitted version doesn't (yet) have mention of the >>> proposed (and generally, it seems, well-received notion of) >>> a StrictSuiteB flag / flags. >> >> Actually, it was not well received. > > oh. I counted at least (quick search of the archive): > > Jon Callas: > I don't think this is a bad idea at all Since I'm being invoked, I must clarify. I don't think it's a bad idea at all. But I think in the interests of minimalism, nothing is better than something. In other words, leaving as much to the implementation as possible is good. But that also includes some flag that says the implementation does SuiteB strictly. It's good to have it, but I'm not sure much more needs to be said. It isn't our job to go into the gory details of what that means. > > ... > * I like David Crick's suggestion of a preference that says, "I'm > going to be strict about Suite B." This is a legislative solution, and > it would work well, it's simple, and elegant. End of story. > > Werner Koch (quoting the "i like David Crick's" paragraph above): > I support this. > > > Further, Andrey Jivsov continued the discussion: > One additional issue I realized that we didn't address is the mixing > of keys for two levels of Suite-B profile. It is similar to the issue > of mixing non-Suite-B and Suite-B keys. > > TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We > cannot make TOP SECRET keys use AES-128, yet this is what happens with > implicit AES-128. Making AES-256 implicit will not work either, > because now SECRET keys will be picked as compatible with TOP SECRET > keys. Finally, having no implicit preferences disallows TOP SECRET > keys to receive SECRET information. > > Do we now need two Suite-B flags? > (end quoting Andrey) > > > so I thought this had some momentum behind it? > >> The "OpenPGP way" of doing this >> is an application putting in the "accepted ciphers" into the public >> key notation. This document doesn't need to describe that because >> it's already well documented in RFC 4880. > > but the problem was that a recipient currently has no > way of saying "strict suite B" beyond setting one/both > of the AESes as higher up in their preference list and > then *hoping* all of the implementations that ever > send messages use this "advisory" information rather > than (legitimately) taking some other arbitrary intersection > of recipient preferences and choosing something other > than the AES of the correct length. > >> Using the notation packet also allows us to support different "Strict >> Suites".. If some other country wants their own stuff in there we >> don't >> need to extend anything; applications just set the appropriate >> supported cipher list. Et Voila, you've got your "flag". > > perhaps I'm not using correct terminology here? My "flag" > (or "flags," if we decide we need one for each of the Suite > B profiles, as per Andrey's last message, quoted above) > was intended to be "something" on the key that the user > can set to say "Strict Suite-B." Is my "flag"/key "something" > the same as what you are calling a "notation packet" ? > > I don't think it is? > > But I emphasis again that the key cipher preference list > *cannot* be guaranteed to make us Suite-B compliant, > as implementations can choose their own intersections. > > So we need something "more." > >> -derek >> -- >> Derek Atkins 617-623-3745 >> derek@ihtfp.com www.ihtfp.com >> Computer and Internet Security Consultant >> > -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFIG5DwsTedWZOD3gYRApUbAKDNKq2ouFglE2+0ckWGtsvjJ8LBCgCfULUi XXedj8ZUuZUf4SHJMMpMM98= =F+Yn -----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 m42I0Rxx086709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 11:00:27 -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 m42I0Rcs086708; Fri, 2 May 2008 11:00:27 -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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42I0QB7086689 for ; Fri, 2 May 2008 11:00:26 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by nf-out-0910.google.com with SMTP id 30so747031nfu.24 for ; Fri, 02 May 2008 11:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2ewe6UKe9ZLe4P35erT2+TmoqEVsJpUZGd9lLQX0v4w=; b=sGngVnHqN6PYfH0Q2Ye6wAURt4KqO5Fs2+dAOtlR3HttfJDCI9E6MUXT1rBvOQVKiQGYwHCMrK7mV9PU+JYbAMkZ96PMVCkfuTbFtb9Uh3+oeL7/GMoxJM/57OV1NaUSZ+1c496+x/ELEiuSvnIW1+wXeC2UW+cTMXfAaFMw7aM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mHEN+thA5xdJ3gLjW/InRbUxn35kwVs40SjEfUsVbT95mol1RpSJS6TKuLdHI99mGc86uYXgf8maWVBvkqBh3aJKwumRO7rfA4oBGL6iw5OvSuCFaUtkMspNsf25ulUDjSks3mOOyDw0V+VTyBBaBoRJZ73qBpqxE5d62ppIm/o= Received: by 10.78.146.13 with SMTP id t13mr948553hud.101.1209751224486; Fri, 02 May 2008 11:00:24 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Fri, 2 May 2008 11:00:24 -0700 (PDT) Message-ID: <117bad160805021100v709e8515u3b049fec5a09ae78@mail.gmail.com> Date: Fri, 2 May 2008 19:00:24 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Cc: OpenPGP In-Reply-To: <481B4F95.7040705@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> <481B4F95.7040705@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, May 2, 2008 at 6:29 PM, Andrey Jivsov wrote: > David Crick wrote: > > > The submitted version doesn't (yet) have mention of the ... > > StrictSuiteB flag / flags. > Given later comments by Derek and your subsequent replies, I think we may > need separate discussion on this. An alternative that I've just thought of is to do some sort of "layering": rfc4880 (base) -> OpenPGP ECC ("anything goes") -> Suite-B, and other (e.g. national) "profiles" So the current "OpenPGP ECC" doc could be completely re-written, stripping out references to Suite-B (but still retaining a "relative strengths" section). This would also simplify the specification. *Then* we could write a standalone Suite-B doc, which would specify a constrained sub-set of OpenPGP ECC. Note, we'd *still* have the "how to make Suite-B strict" problem, so *still* might require some sort of kludge. And/*or* we could even just "avoid" the Strict Suite B issue altogether, and leave it for the implementers! Since Suite-B users will (by definition) only want to communicate with other Suite-B users, then they will be a self-contained userbase, and so can simply not implement 3DES [and other ciphers]. Meanwhile the rest of us just set AES-256 and AES-128 at the head of our cipher preferences and put up with the fact that someone may send us 3DES messages (or using any other cipher for that matter, if they over-ride using [e.g., in gnupg] --cipher-algo and disregard the warning). 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 m42HU7lU072486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 10:30: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 m42HU7NK072485; Fri, 2 May 2008 10:30: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 mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42HU5Ua072465 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 2 May 2008 10:30:06 -0700 (MST) (envelope-from openpgp@brainhub.org) Received: from localhost.localdomain (h-66-134-92-50.snvacaid.covad.net [66.134.92.50]) by mail.cyberonic.com (8.12.8/8.12.8) with ESMTP id m42HXt55009507; Fri, 2 May 2008 13:33:56 -0400 Message-ID: <481B4F95.7040705@brainhub.org> Date: Fri, 02 May 2008 10:29:57 -0700 From: Andrey Jivsov User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: David Crick CC: OpenPGP Subject: Re: ECC in OpenPGP -00.txt is posted as a draft References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> In-Reply-To: <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Crick wrote: >> The discussions we had on pre-submission version of the specification can >> continue with the draft. > > The submitted version doesn't (yet) have mention of the > proposed (and generally, it seems, well-received notion of) > a StrictSuiteB flag / flags. Discussions tailed off on this, but we > (still) need(ed) to give the whole interoperability thing a long > hard look, as per your last message on this topic. > Given later comments by Derek and your subsequent replies, I think we may need separate discussion on this. Without assumption that additional key properties is the way to go and where this description should be, I thought it will be helpful to submit more detailed proposal on how this could be done and what are the issues we need to worry about. I will do this before coming Monday. We can then have some sort of vote on this subject. > > Some comments from me on the (latest) submitted draft: > > | While TripleDES ensures interoperability between applications > | complaint with OpenPGP and ECC specifications, it doesn't help > | interoperability with Suite-B profile. Suppose TripleDES is the > | only shared algorithm within a set of recipients. If Suite-B > | compliant recipient is added to the mentioned recipient set, the > | sender SHALL NOT send out a message. > > shouldn't this be MUST NOT? Will do. > > (continuing to quote section so people can see the context) > | This is because TripleDES is > | excluded from Suite-B and sending out two copies of the same > | message, one encrypted with TripleDES and another with AES-128 or > | AES-256, would mean that the same information that must have been > | protected with Suite-B compliant algorithm was protected instead > | with non-compliant TripleDES. This restriction covers other cases > | in which none of recipients' shared algorithms are allowed by > | Suite-B. One of available methods to a recipient to help ensure > | interoperability with Suite-B is to include one of two Suite-B > | symmetric algorithms, AES-128 or AES-256, or both, in the set of > | preferred algorithms. > (end of that section). > > But how *on earth* are you going to "enforce" people NOT sending > two copies of the same message under different ciphers??! I meant to provide a warning to implementors that once crypto/messaging layer detects sending conflict to a group of recipients, the conflict cannot be resolved by sending two separate messages. While each of two messages with appropriate subset of recipients can satisfy constrains of crypto/messaging layer, this is not the right thing to do from the point of view of information protection. For example, I thought that the following message misses this point: Len Sassaman wrote this in Mar 2008: > Breaking compatibility on the protocol level doesn't mean breaking it on > the actually application level. In a different thread, there as discussion > of people using "regular" DSA/EG keys and then adding a recipient who uses > ECC. So what? The application can encrypt twice, and send the properly > encrypted messages to the appropriate people. > > > Meanwhile, this new bit: > > | While some statements in this specification refer to TripleDES > | algorithm, this is only done to help interoperability with existing > | application and already generated keys; AES-256 is the recommended > | alternative to TripleDES in all circumstances when AES-256 is > | available. > > I (really) like, but probably needs to have added onto the end of it: > > Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC, > and may be preferred in more constrained environments. However, > AES-128 is not allowable when the larger Suite-B profiles are required, > so AES-256 may still need to be implemented for this interoperability. > > (But, as I stated at the start of this email, this whole topic still needs > further thought.) I would say that, overall, AES-128 should remains the lowest common denominator in this specification. It is needed to cover the mix of recipients with smartcards, cellphones, etc. Hopefully, "TOP SECRET Suite-B profile keys" will not be issued on constrained smartcards. Another point, when TOP SECRET keys receive TOP SECRET information, this is when AES-256 must be used, only TOP SECRET keys can be in the list of recipients. AES-256 SHOULD be in the set of preferred algorithms on each key in this case. 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 m42E21HA080692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 07:02: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 m42E21XJ080691; Fri, 2 May 2008 07:02: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 nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42E1xDd080662 for ; Fri, 2 May 2008 07:02:00 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by nf-out-0910.google.com with SMTP id 30so676517nfu.24 for ; Fri, 02 May 2008 07:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=D0px8lu2/9y3me43AtnhVKEyjlDOqnQIQzmdudWtOm0=; b=LFXxzl8SzPopaMdJp93Hf1N+EHWUy22Vmb3spWVMKUpmZE9JPAtJDqgx/nWQ8lacoAI9NUY5sgWYbZ4xBo+61UdTbw6Yi6+oy+pgBlT2zejC/Xe99lgK/bfLIJJSTjauaYEkf9Wn8WMyEuoPzA1A2T5mTJNR6J+BJbZybUZIoWA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sSmeCzec0e1wVotKx2kuppmnwnG6R+qeOvJnTxUWj8OmeWNZqKmNX6k0VHLC65DTwWZbDWFAa1u3t//yiLf4mrcU9iYmixMZJGsYE7tTcNpiW8TEU7H7PrUMh8/UWzSw51fucfWrngK7ir+QqvbDTjuSUEW6EVLsFj3vlQn9g78= Received: by 10.78.20.13 with SMTP id 13mr912394hut.47.1209736916201; Fri, 02 May 2008 07:01:56 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Fri, 2 May 2008 07:01:56 -0700 (PDT) Message-ID: <117bad160805020701k5a24906cs565e43a184bbeed9@mail.gmail.com> Date: Fri, 2 May 2008 15:01:56 +0100 From: "David Crick" To: "Derek Atkins" Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Cc: "Andrey Jivsov" , OpenPGP In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, May 2, 2008 at 2:32 PM, Derek Atkins wrote: > David, > > > The submitted version doesn't (yet) have mention of the > > proposed (and generally, it seems, well-received notion of) > > a StrictSuiteB flag / flags. > > Actually, it was not well received. oh. I counted at least (quick search of the archive): Jon Callas: I don't think this is a bad idea at all ... * I like David Crick's suggestion of a preference that says, "I'm going to be strict about Suite B." This is a legislative solution, and it would work well, it's simple, and elegant. End of story. Werner Koch (quoting the "i like David Crick's" paragraph above): I support this. Further, Andrey Jivsov continued the discussion: One additional issue I realized that we didn't address is the mixing of keys for two levels of Suite-B profile. It is similar to the issue of mixing non-Suite-B and Suite-B keys. TOP SECRET must use AES-256, SECRET must use AES-128 or AES-256. We cannot make TOP SECRET keys use AES-128, yet this is what happens with implicit AES-128. Making AES-256 implicit will not work either, because now SECRET keys will be picked as compatible with TOP SECRET keys. Finally, having no implicit preferences disallows TOP SECRET keys to receive SECRET information. Do we now need two Suite-B flags? (end quoting Andrey) so I thought this had some momentum behind it? > The "OpenPGP way" of doing this > is an application putting in the "accepted ciphers" into the public > key notation. This document doesn't need to describe that because > it's already well documented in RFC 4880. but the problem was that a recipient currently has no way of saying "strict suite B" beyond setting one/both of the AESes as higher up in their preference list and then *hoping* all of the implementations that ever send messages use this "advisory" information rather than (legitimately) taking some other arbitrary intersection of recipient preferences and choosing something other than the AES of the correct length. > Using the notation packet also allows us to support different "Strict > Suites".. If some other country wants their own stuff in there we don't > need to extend anything; applications just set the appropriate > supported cipher list. Et Voila, you've got your "flag". perhaps I'm not using correct terminology here? My "flag" (or "flags," if we decide we need one for each of the Suite B profiles, as per Andrey's last message, quoted above) was intended to be "something" on the key that the user can set to say "Strict Suite-B." Is my "flag"/key "something" the same as what you are calling a "notation packet" ? I don't think it is? But I emphasis again that the key cipher preference list *cannot* be guaranteed to make us Suite-B compliant, as implementations can choose their own intersections. So we need something "more." > -derek > -- > Derek Atkins 617-623-3745 > derek@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > 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 m42DWxOC067438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 May 2008 06:32:59 -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 m42DWxbC067437; Fri, 2 May 2008 06:32:59 -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.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m42DWwfZ067403 for ; Fri, 2 May 2008 06:32:58 -0700 (MST) (envelope-from derek@ihtfp.com) Received: from pgpdev.ihtfp.org (PGPDEV.IHTFP.ORG [204.107.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 4538ABD8464; Fri, 2 May 2008 09:32:57 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m42DWpGj008399; Fri, 2 May 2008 09:32:51 -0400 To: "David Crick" Cc: "Andrey Jivsov" , OpenPGP Subject: Re: ECC in OpenPGP -00.txt is posted as a draft References: <481815F0.8090401@brainhub.org> <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> From: Derek Atkins Date: Fri, 02 May 2008 09:32:51 -0400 In-Reply-To: <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> (David Crick's message of "Thu\, 1 May 2008 22\:44\:53 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) 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: David, "David Crick" writes: >> The discussions we had on pre-submission version of the specification can >> continue with the draft. > > The submitted version doesn't (yet) have mention of the > proposed (and generally, it seems, well-received notion of) > a StrictSuiteB flag / flags. Discussions tailed off on this, but we > (still) need(ed) to give the whole interoperability thing a long > hard look, as per your last message on this topic. Actually, it was not well received. The "OpenPGP way" of doing this is an application putting in the "accepted ciphers" into the public key notation. This document doesn't need to describe that because it's already well documented in RFC 4880. Using the notation packet also allows us to support different "Strict Suites".. If some other country wants their own stuff in there we don't need to extend anything; applications just set the appropriate supported cipher list. Et Voila, you've got your "flag". -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant 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 m41Liwuv039262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 May 2008 14:44:58 -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 m41LivSi039247; Thu, 1 May 2008 14:44:57 -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.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m41LisxM039169 for ; Thu, 1 May 2008 14:44:56 -0700 (MST) (envelope-from dacrick@gmail.com) Received: by fk-out-0910.google.com with SMTP id 18so843729fkq.10 for ; Thu, 01 May 2008 14:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l1yGG210vj7emrzTm9GEJjriv+dHsE9kQvAC43aqM7k=; b=F/06nEnjYJm9dxwIvRiA0WCaRjQGX3M8M2WgV49OHBTHfalAqeu7GabXUBxZMWGX1NOTm2+DOayoJbQXkMGBa/4cqih2PY/T9bEEeTVi6DvrsOvmW+uDF4cAX/5XLz6vLlTH6AZBRxAMp9loNGx+UHyV/0+cxAlSPB0pUSszHeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vKENrmTAhqYEndez+vvgRMBpzdVpndSIDW9ESvSVEiR90Nbat5EjwdvTDU9E9t+suWwmlXYT9oYeOXUOo78jSyriA3i17w57tzA9iN6kTIqRPFQptiIyZV/xse7NpZTrUJmtR1d5nKF68ENd733jphzmMwXF0ddyd2X6qgRz+F4= Received: by 10.78.120.15 with SMTP id s15mr735692huc.108.1209678293785; Thu, 01 May 2008 14:44:53 -0700 (PDT) Received: by 10.78.56.12 with HTTP; Thu, 1 May 2008 14:44:53 -0700 (PDT) Message-ID: <117bad160805011444q436558aaka0e78241f4f508cb@mail.gmail.com> Date: Thu, 1 May 2008 22:44:53 +0100 From: "David Crick" To: "Andrey Jivsov" Subject: Re: ECC in OpenPGP -00.txt is posted as a draft Cc: OpenPGP In-Reply-To: <481815F0.8090401@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <481815F0.8090401@brainhub.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The discussions we had on pre-submission version of the specification can > continue with the draft. The submitted version doesn't (yet) have mention of the proposed (and generally, it seems, well-received notion of) a StrictSuiteB flag / flags. Discussions tailed off on this, but we (still) need(ed) to give the whole interoperability thing a long hard look, as per your last message on this topic. Some comments from me on the (latest) submitted draft: | While TripleDES ensures interoperability between applications | complaint with OpenPGP and ECC specifications, it doesn't help | interoperability with Suite-B profile. Suppose TripleDES is the | only shared algorithm within a set of recipients. If Suite-B | compliant recipient is added to the mentioned recipient set, the | sender SHALL NOT send out a message. shouldn't this be MUST NOT? (continuing to quote section so people can see the context) | This is because TripleDES is | excluded from Suite-B and sending out two copies of the same | message, one encrypted with TripleDES and another with AES-128 or | AES-256, would mean that the same information that must have been | protected with Suite-B compliant algorithm was protected instead | with non-compliant TripleDES. This restriction covers other cases | in which none of recipients' shared algorithms are allowed by | Suite-B. One of available methods to a recipient to help ensure | interoperability with Suite-B is to include one of two Suite-B | symmetric algorithms, AES-128 or AES-256, or both, in the set of | preferred algorithms. (end of that section). But how *on earth* are you going to "enforce" people NOT sending two copies of the same message under different ciphers??! Meanwhile, this new bit: | While some statements in this specification refer to TripleDES | algorithm, this is only done to help interoperability with existing | application and already generated keys; AES-256 is the recommended | alternative to TripleDES in all circumstances when AES-256 is | available. I (really) like, but probably needs to have added onto the end of it: Note, however, that AES-128 is the MUST algorithm for OpenPGP ECC, and may be preferred in more constrained environments. However, AES-128 is not allowable when the larger Suite-B profiles are required, so AES-256 may still need to be implemented for this interoperability. (But, as I stated at the start of this email, this whole topic still needs further thought.)