ECC in OpenPGP -00.txt is posted as a draft

[Andrey Jivsov <[e-mail]>]

 From 
http://www.ietf.org/mail-archive/web/i-d-announce/current/msg20024.html :

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: ECC in OpenPGP
> 	Author(s)	: A. Jivsov
> 	Filename	: draft-jivsov-openpgp-ecc-00.txt
> 	Pages		: 14
> 	Date		: 2008-4-29
> 	
> This document proposes an Elliptic Curve Cryptography extension to
>    the OpenPGP public key format and specifies three Elliptic Curves
>    that enjoy broad support by other standards, including NIST
>    standards.  The document aims to standardize an optimal but narrow
>    set of parameters for best interoperability and it does so within
>    the framework it defines that can be expanded in the future to
>    allow more choices.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> <ftp://ftp.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt>

The same version in PDF and HTML is available here:
http://brainhub.googlepages.com/pgp .

The discussions we had on pre-submission version of the specification 
can continue with the draft.

The only option I was given was to submit the document as a personal 
draft, but don't be discouraged by this. I look forward to continue 
working with you on this document. Even though the WG is closed, this 
doesn't change the fact that most implementers continue to read this 
mailing 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 m3U6msDd012247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2008 23:48:54 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3U6mssK012246; Tue, 29 Apr 2008 23:48:54 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3U6miJl012186 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 29 Apr 2008 23:48:53 -0700 (MST) (envelope-from [e-mail])
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 m3U6oj55018443 for <[e-mail]>; Wed, 30 Apr 2008 02:51:41 -0400
Message-ID: <[e-mail]>
Date: Tue, 29 Apr 2008 23:47:12 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
Subject: ECC in OpenPGP -00.txt is posted as a draft
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

 From 
http://www.ietf.org/mail-archive/web/i-d-announce/current/msg20024.html :

> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: ECC in OpenPGP
> 	Author(s)	: A. Jivsov
> 	Filename	: draft-jivsov-openpgp-ecc-00.txt
> 	Pages		: 14
> 	Date		: 2008-4-29
> 	
> This document proposes an Elliptic Curve Cryptography extension to
>    the OpenPGP public key format and specifies three Elliptic Curves
>    that enjoy broad support by other standards, including NIST
>    standards.  The document aims to standardize an optimal but narrow
>    set of parameters for best interoperability and it does so within
>    the framework it defines that can be expanded in the future to
>    allow more choices.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> <ftp://ftp.ietf.org/internet-drafts/draft-jivsov-openpgp-ecc-00.txt>

The same version in PDF and HTML is available here:
http://brainhub.googlepages.com/pgp .

The discussions we had on pre-submission version of the specification 
can continue with the draft.

The only option I was given was to submit the document as a personal 
draft, but don't be discouraged by this. I look forward to continue 
working with you on this document. Even though the WG is closed, this 
doesn't change the fact that most implementers continue to read this 
mailing 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 m3RJlKIW060345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Apr 2008 12:47:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3RJlKKi060344; Sun, 27 Apr 2008 12:47:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3RJlIeP060337 for <[e-mail]>; Sun, 27 Apr 2008 12:47:19 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 26so5723807fkx.10 for <[e-mail]>; Sun, 27 Apr 2008 12:47:18 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=2COUTrNhfK+ZPxnVrCaurxbM1eheeMGCQ6ZyPuvJNx4=; b=uJJLVTLpF0uA77NXf34DyoOcXh1QJIim6vwBLguJXMCk1JX4GvO9lMv8dmZNKher3spSby+wxRS+bYhWP1nIUcAaa12oH87b+pOiXzcF5qOE+W7YTfHOgM2jok3QdFRPFyISS0//6wwaVaA9AjnQfYK4Np6Jq5ewR3M4b/AprSs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=azchC7m7wWGDUvWHi0vjR01rJc5dCOJK0G6FbMQJAWqD6Va4CY74n4ruLVMBsngp/2n2htBgvPXrUPnWibaZbLBURD1uhufTPtfrsQ1iAyy7dhGKYgmVQziR9mA7BzkynpZ9wmdZZI8H7c88OuJXSDMICTFmLBV76c3k6HBGQ0w=
Received: by 10.78.184.2 with SMTP id h2mr1039210huf.14.1209325637857; Sun, 27 Apr 2008 12:47:17 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Sun, 27 Apr 2008 12:47:17 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sun, 27 Apr 2008 20:47:17 +0100
From: "David Crick" <[e-mail]>
To: [e-mail]
Subject: something else for the pot - Galois/Counter Mode (GCM)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

With talk of moving from our current "PGP"-CFB to CBC at
some "future" point (along with ECC, V5 keys, blah, blah),
what about considering GCM?

It's one of the NIST modes of operation, it's (according
to the authors) unencumbered by patents, plus will be
supported by a specific processor instruction from the
Intel Westmere (ETA 2009) CPUs onwards.  (Westmere
will also have "AES-NI" instructions, giving us hardware
speed and constant time execution round instructions.)

Plus (as a bonus ;)) GCM is only defined for 128-bit block
ciphers.  This would provide us with an authenticity that
would allow us to move away from our current *SHA1*
MDC.  Presumably it [GCM] wouldn't be selectable for
64-bit block ciphers, which would mirror when MDC was
only (by default?) for 128-bit ciphers (originally?).



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 m3PHi2P7031769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Apr 2008 10:44:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3PHi2Sf031768; Fri, 25 Apr 2008 10:44:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3PHi1Hs031748 for <[e-mail]>; Fri, 25 Apr 2008 10:44:01 -0700 (MST) (envelope-from [e-mail])
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 m3PHhxk05262 for <[e-mail]>; Fri, 25 Apr 2008 13:43:59 -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 m3PHhs4V006587 for <[e-mail]>; Fri, 25 Apr 2008 13:43:54 -0400
Date: Fri, 25 Apr 2008 13:43:53 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-openpgp-camellia-03.txt
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Apr 25, 2008 at 10:15:01AM -0700, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.
> 
> 	Title		: The Camellia Cipher in OpenPGP
> 	Author(s)	: D. Shaw
> 	Filename	: draft-ietf-openpgp-camellia-03.txt
> 	Pages		: 5
> 	Date		: 2008-4-25
> 	
> This document presents the necessary information to use the Camellia
>    symmetric block cipher in the OpenPGP protocol.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-03.txt

This is identical to the previous draft except for a few grammatical
tweaks.  If nobody has any further comments, I think this is ready to
start the publication process.

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 m3PHF8C6029443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Apr 2008 10:15:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3PHF8Gg029442; Fri, 25 Apr 2008 10:15:08 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3PHF7Tx029435 for <[e-mail]>; Fri, 25 Apr 2008 10:15:07 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id C17833A6B4A; Fri, 25 Apr 2008 10:15:01 -0700 (PDT)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-camellia-03.txt 
Message-Id: <[e-mail]>
Date: Fri, 25 Apr 2008 10:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: The Camellia Cipher in OpenPGP
	Author(s)	: D. Shaw
	Filename	: draft-ietf-openpgp-camellia-03.txt
	Pages		: 5
	Date		: 2008-4-25
	
This document presents the necessary information to use the Camellia
   symmetric block cipher in the OpenPGP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-camellia-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--



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 m3J5C60u058496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 22:12:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3J5C6ne058495; Fri, 18 Apr 2008 22:12:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3J5C4Vq058472 for <[e-mail]>; Fri, 18 Apr 2008 22:12:05 -0700 (MST) (envelope-from [e-mail])
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 DA45B8B4007; Sat, 19 Apr 2008 01:12:01 -0400 (EDT)
Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.1/8.14.1/Submit) id m3J0Ga02023901; Fri, 18 Apr 2008 20:16:36 -0400
To: "David Crick" <[e-mail]>
Cc: "Jon Callas" <[e-mail]>, OpenPGP <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: Fri, 18 Apr 2008 20:16:36 -0400
In-Reply-To: <[e-mail]> (David Crick's message of "Thu\, 17 Apr 2008 19\:29\:01 +0100")
Message-ID: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi David,

"David Crick" <[e-mail]> writes:

>>  This is one reason why I believe in options. If someone wants to do
>>  SuiteB ECC but with Camellia and Whirlpool, we should not be
>>  restricting that at the standards level.
>
> there is no such thing as "SuiteB ECC but with Camellia and Whirlpool"

True...  However...

> Suite B *is*:
> 384-ecc, sha384, aes256 - cleared for up to TOP SECRET use
> 256-ecc, sha256, aes128 - cleared for up to SECRET use
>
> with both also being suitable for non-classified (sensitive) use.
>
>
> What you *could* have is "_OpenPGP ECC_ with Camellia and
> Whirlpool _at equivelent strength to the SuiteB cipher suites_"

I think the point is that at the protocol level there doesn't need to
be a major difference.  At the APPLICATION you can say "we support
suite B" and when you create keys you say "sha384/aes256" with an
ECC-384 key and "sha256/aes128" with an ECC-256 key...  But someone
else could say "camellia/whirlpool" with an ECC-384 key.  

In other words the OpenPGP protocol (and packet formats) should remain
agnostic about the semantics of the ciphersuites being allowed or
proposed in the notation on a key.

-derek

-- 
       Derek Atkins                 617-623-3745
       [e-mail]             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 m3IIm40K009242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Apr 2008 11:48:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3IIm4W8009241; Fri, 18 Apr 2008 11:48:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3IIm1Ki009229 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 18 Apr 2008 11:48:03 -0700 (MST) (envelope-from [e-mail])
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 m3IIlL55025699; Fri, 18 Apr 2008 14:47:22 -0400
Message-ID: <[e-mail]>
Date: Fri, 18 Apr 2008 11:47:53 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: [e-mail]
CC: Werner Koch <[e-mail]>
Subject: Re: ECC curve ID
References: <[e-mail]>	<[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Werner Koch wrote:
> Hi,
> 
> and sorry for me taking so long to reply.  I struggled too long with
> real world OpenPGP interoperability problems ;-).

One more reason to design this document right ;-)

> 
> On Thu, 28 Feb 2008 00:31, [e-mail] said:
> 
>> I think that support for arbitrary curves has some merits. On the
>> other hand, these benefits must be compared against possibility of
>> ever getting the ECC support in OpenPGP applications.
> 
> My point was to allow an implementor to use a different curve and *if*
> that curve eventually make it into the specs, old messages will still
> work.  We had this problem in the past where we internally agreed on an
> ID (e.g. for Twofish), implemented it in PGP and GPG and then hoped it
> would make it into the standard.  Given the size of the WG at that time,
> we could be pretty confident that it will make it into the standard and
> thus there was no need to use an ID for an experimental algorithm.
> 
> Today it is different.  In particular there are more possible curves to
> use for an algorithms and thus tehre is no room left for experimental
> use.  The experimental IDs don't really work.
> 
>> OpenPGP application is not required to understand ASN.1 /
>> DER. Essentially, this proposal means that we are replacing one-byte
>> ID by multi-byte ID. Would it be good to agree on new curve anyway and
> 
> There is no need to understand them.  In fact we are already using ASN.1
> encodings and I bet that all implementations don't parse them but just
> take them as a binary blob.  Thus the only change would be to specify
> the curve as a DER encoded OID insted of a number and mark that as MUST
> implement.
> 
>> applications will be able to interoperate using curves we disagree
>> on. The freedom will be detrimental to interoperability. (Conversely,
> 
> This is not a problem.  RSA is an optional akgorithm but all smartcards
> use RSA and it just works.  However if someone uses a perfectly OpenPGP
> compliant 8k RSA key, you will get serious interoperability problems.  I
> consider this a very similar problem to non-standard curves.
> 
>> companion proposal or in the next version of the document. For
>> example, ID 254 might mean that there is an ASN.1 structure
>> referencing the curve, inserted somewhere into the sequence of
> 
> Too complicated.  For the sake of backward compatibility we had to use
> such kludges in the past.  For a new feature we should really avoid
> using that.  
> 
> 
> My proposal is thus:
> 
> Change section 8 to:
> 
>   The following algorithm-specific packets are added to Section 5.5.2
>   Public-Key Packet Formats of [RFC4880] to support ECDH and ECDSA.
> 
>   This algorithm-specific portion is:
> 
>     Algorithm-Specific Fields for ECDH keys:
>     
>       * a one-octet length of the next field
> 
>       * an ECC curve OID, defined in section 10
> 
>       * a one-octet value 01, reserved for future extension
> 
>       * a one-octet hash function ID used with KDF
> 
>       * a one-octet algorithm ID for the symmetric algorithm used to
>         wrap the symmetric key for message encryption, see section 7 for
>         details
> 
>       * MPI of EC point representing public key
> 
>     Algorithm-Specific Fields for ECDSA keys:
> 
>       * a one-octet length of the next field
> 
>       * an ECC curve OID, defined in section 10
> 
>       * MPI of EC point representing public key
> 
>   The following algorithm-specific packets are added to section 5.5.3.
>   Secret-Key Packet Formats of [RFC4880] to support ECDH and ECDSA.
> 
>     Algorithm-Specific Fields for ECDH or ECDSA secret keys:
> 
>       * MPI of an integer representing the secret key, which is a scalar
>         of the EC point
> 
> 
> Change section 10 to:
> 
>     The parameter ECC curve OID defines the curve.
> 
>     OID                  Curve description              Curve name
>     ----------------------------------------------------------------   
>     1.2.840.10045.3.1.7  NIST Curve P-256 [FIPS 186-2]  "NIST P-256"
>     1.3.132.0.34         NIST Curve P-384 [FIPS 186-2]  "NIST P-384"  
>     1.3.132.0.35         NIST Curve P-521 [FIPS 186-2]  "NIST P-521"  
> 
>     Implementations MUST implement "NIST P-256", "NIST P-384" and "NIST
>     P-521".  The hexadecimal representation used in the public and
>     private key encodings are:
> 
>     Curve Name   Len  Hexadecimal representation of the OID
>     ----------------------------------------------------------------   
>     "NIST P-256"  8   0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x07 
>     "NIST P-384"  6   0x05, 0x2B, 0x81, 0x04, 0x00, 0x22            
>     "NIST P-521"  6   0x05, 0x2B, 0x81, 0x04, 0x00, 0x23             
>     
>  
>> with Windows Vista, Linux (openssl), etc. Which ECC standard
>> *excludes* the curves specified in the proposal? I claim that the
>> proposed subset of curves is the most widely supported subset of any
> 
> I don't have any  problem with these curves. 
> 
> It is not matter of whether they are exluded but on whether national
> bodies require the use of certain curves.  The US requires thus but
> other countries may require different ones.  Without a way to use their
> curves they won't be abale to use OpenPGP and need to use X.509.  For
> the very same reason we include RIPEMD-160; there is no real technical
> reason to use it but it is required by some legislatives.  We can make
> them all happy with a minor change to yopur porposal.  For an
> implementor it is just a nit to support this chnaged format.  It might
> even be easier because there might be no need for an OpenPGP-Curve-ID
> mapping table.
> 
>> This is where freedom will make interoperability problematic. It is
>> hard to come up with preferences that control the structure of
>> self-signatures, because preferences themselves are stored in
> 
> Same goes for SHA-256 or DSA-2.  We already have interoperability
> problems.
> 
>> self-signatures. The only solution to this chicken-and-egg problem is
>> to establish small core set of curves, the two ones I proposed in the
>> draft, and focus on supporting these curves first.
> 
> Fine with me.

I don't disagree with most of the arguments you provide, it was a close 
call for me. Let me summarize how I see the issue.

Pros for OIDs:

1) OpenPGP depends on another registry, doesn't need to maintain its 
own. The assumption is that OID registry will be up-to-date and any 
curve we will ever need will have an OID.

2) In the time window when OID is available but it is not yet in OpenPGP 
registry, standard-compliant messages can be created faster.


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.

2) Shorter public keys, faster, smaller code (switch() v.s. memcmp()).

3) consistency with the way OpenPGP references other algorithms.

4) Named curves can be introduced as an extension. The core set of 
curves will be encoded as integers, others as named curves.


I wonder if I am a lone supporter of numeric IDs, though.

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) ?

Can we reach an agreement if the document also defined a method to list 
named curves, along the lines of Werner's proposal?

> 
>>> p.s. I don't think that the notion of "Top Secret" And "Secret"
>>> belongs into
>>> an RFC.  I could also ask to add "VS/NfD", which is a secrecy level used
>>> in Germany
>> This seems reasonable. If any of 3 curves in the proposal satisfy
> 
> This was not my point.  It is not a matter of an Internet standard to
> define what is top secret and what is secret.  This is an
> oprganisational issue of the entity using appliactions based on that
> standard.  Add it as an informational note at the end of spec after the
> security considerations and mark is as U.S. specific.  As it stands now
> it looks pretty much like a part of the standard.
> 

I think I share your views on this. This resonates with the discussion 
we had recently regarding profiles v.s. algorithms. Some people wanted 
this spec to be Suite-B only, others -- format spec only. What we have 
now is mostly the format spec, which we need in either case, with a 
short informative section that tells what to do to get Suite-B support. 
I would look past this perceived impurity because Suite-B makes the 
document more relevant.

> 
> Shalom-Salam,
> 
>    Werner
> 

Thank you for the 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 m3HITGlA088527 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 11:29:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3HITGNH088526; Thu, 17 Apr 2008 11:29:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3HIT4ml088513 for <[e-mail]>; Thu, 17 Apr 2008 11:29:07 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id g16so108426nfd.24 for <[e-mail]>; Thu, 17 Apr 2008 11:29:02 -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=NEs5kxhtYaF3+uIDFCataKmnpTBGWsBZM8r/+SNVLdw=; b=bLaBFnkBAt+h5G2T0j86uFZ87NvP+dT9s+9f+EmLc2gXVHOxg6OPh+R2fr02alfDLzTvq4vKG9D2yoW0YoaaOB55fwI0gSNjbcxMiJzq0AZFLfPq6QB7xxUMVZamti+2u6230vazOHsARlCHov9qdcqNgFjqRqfoNr0dLgnbH+0=
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=q7LY+X03XYiQKZtyb6KgCSfch36sbIBkSVmFSi4bj5/xD/ks6aKGGMQf/4/n4rZB6xtmBsy9qJ3zhHumedI4g7s53DslaoLnATB6jkU4M96+jaJDTuRmdTjUwRPp03LRH9f2w7pZo+dWY75hTZR87kkYQQuJFIgSN1O+l5da6Uk=
Received: by 10.78.200.20 with SMTP id x20mr2086470huf.55.1208456941114; Thu, 17 Apr 2008 11:29:01 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Thu, 17 Apr 2008 11:29:01 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Thu, 17 Apr 2008 19:29:01 +0100
From: "David Crick" <[e-mail]>
To: "Jon Callas" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  This is one reason why I believe in options. If someone wants to do
>  SuiteB ECC but with Camellia and Whirlpool, we should not be
>  restricting that at the standards level.

there is no such thing as "SuiteB ECC but with Camellia and Whirlpool"

Suite B *is*:
384-ecc, sha384, aes256 - cleared for up to TOP SECRET use
256-ecc, sha256, aes128 - cleared for up to SECRET use

with both also being suitable for non-classified (sensitive) use.


What you *could* have is "_OpenPGP ECC_ with Camellia and
Whirlpool _at equivelent strength to the SuiteB cipher suites_"



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 m3HIAgCL086445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 11:10:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3HIAgoW086444; Thu, 17 Apr 2008 11:10:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3HIAflM086433 for <[e-mail]>; Thu, 17 Apr 2008 11:10:41 -0700 (MST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 5A81BE93CA3 for <[e-mail]>; Thu, 17 Apr 2008 11:10:40 -0700 (PDT)
Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Thu, 17 Apr 2008 11:10:40 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 17 Apr 2008 11:10:40 -0700
Message-Id: <[e-mail]>
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: I have a technical idea/change for the ECC draft
Date: Thu, 17 Apr 2008 11:10:39 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Please recall that OpenPGP is not a national standard.  If more
> provisions for an US standard go into OpenPGP other countries may want
> to see their own rules in there too.  To avoid such attempts I believe
> it is better to have a more neutral language.

Hear, hear!

This is one reason why I believe in options. If someone wants to do  
SuiteB ECC but with Camellia and Whirlpool, we should not be  
restricting that at the standards level.

NIST deserves kudos in the way they did AES, and the way that SuiteB  
navigates the rocks of an effective ECC suite. But I agree with  
Werner, we are a transnational organization.

	Jon



-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIB5KgsTedWZOD3gYRAojiAJ9O6pEcSeEMV3Gy4+rxo7Kt+Rxd9ACg/e4D
nXNAJ7RGcWVndqjkSKToHmk=
=QsqP
-----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 m3H90nB2031100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 02:00:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3H90nPh031099; Thu, 17 Apr 2008 02:00:49 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3H90lZc031092 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 17 Apr 2008 02:00:49 -0700 (MST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JmQ7C-0006ei-9I for <[e-mail]>; Thu, 17 Apr 2008 11:09:10 +0200
Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JmPvz-0006os-8X; Thu, 17 Apr 2008 10:57:35 +0200
From: Werner Koch <[e-mail]>
To: Andrey Jivsov <[e-mail]>
Cc: [e-mail]
Subject: Re: ECC curve ID
References: <[e-mail]> <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Thu, 17 Apr 2008 10:57:35 +0200
In-Reply-To: <[e-mail]> (Andrey Jivsov's message of "Wed, 27 Feb 2008 15:31:09 -0800")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi,

and sorry for me taking so long to reply.  I struggled too long with
real world OpenPGP interoperability problems ;-).

On Thu, 28 Feb 2008 00:31, [e-mail] said:

> I think that support for arbitrary curves has some merits. On the
> other hand, these benefits must be compared against possibility of
> ever getting the ECC support in OpenPGP applications.

My point was to allow an implementor to use a different curve and *if*
that curve eventually make it into the specs, old messages will still
work.  We had this problem in the past where we internally agreed on an
ID (e.g. for Twofish), implemented it in PGP and GPG and then hoped it
would make it into the standard.  Given the size of the WG at that time,
we could be pretty confident that it will make it into the standard and
thus there was no need to use an ID for an experimental algorithm.

Today it is different.  In particular there are more possible curves to
use for an algorithms and thus tehre is no room left for experimental
use.  The experimental IDs don't really work.

> OpenPGP application is not required to understand ASN.1 /
> DER. Essentially, this proposal means that we are replacing one-byte
> ID by multi-byte ID. Would it be good to agree on new curve anyway and

There is no need to understand them.  In fact we are already using ASN.1
encodings and I bet that all implementations don't parse them but just
take them as a binary blob.  Thus the only change would be to specify
the curve as a DER encoded OID insted of a number and mark that as MUST
implement.

> applications will be able to interoperate using curves we disagree
> on. The freedom will be detrimental to interoperability. (Conversely,

This is not a problem.  RSA is an optional akgorithm but all smartcards
use RSA and it just works.  However if someone uses a perfectly OpenPGP
compliant 8k RSA key, you will get serious interoperability problems.  I
consider this a very similar problem to non-standard curves.

> companion proposal or in the next version of the document. For
> example, ID 254 might mean that there is an ASN.1 structure
> referencing the curve, inserted somewhere into the sequence of

Too complicated.  For the sake of backward compatibility we had to use
such kludges in the past.  For a new feature we should really avoid
using that.  


My proposal is thus:

Change section 8 to:

  The following algorithm-specific packets are added to Section 5.5.2
  Public-Key Packet Formats of [RFC4880] to support ECDH and ECDSA.

  This algorithm-specific portion is:

    Algorithm-Specific Fields for ECDH keys:
    
      * a one-octet length of the next field

      * an ECC curve OID, defined in section 10

      * a one-octet value 01, reserved for future extension

      * a one-octet hash function ID used with KDF

      * a one-octet algorithm ID for the symmetric algorithm used to
        wrap the symmetric key for message encryption, see section 7 for
        details

      * MPI of EC point representing public key

    Algorithm-Specific Fields for ECDSA keys:

      * a one-octet length of the next field

      * an ECC curve OID, defined in section 10

      * MPI of EC point representing public key

  The following algorithm-specific packets are added to section 5.5.3.
  Secret-Key Packet Formats of [RFC4880] to support ECDH and ECDSA.

    Algorithm-Specific Fields for ECDH or ECDSA secret keys:

      * MPI of an integer representing the secret key, which is a scalar
        of the EC point


Change section 10 to:

    The parameter ECC curve OID defines the curve.

    OID                  Curve description              Curve name
    ----------------------------------------------------------------   
    1.2.840.10045.3.1.7  NIST Curve P-256 [FIPS 186-2]  "NIST P-256"
    1.3.132.0.34         NIST Curve P-384 [FIPS 186-2]  "NIST P-384"  
    1.3.132.0.35         NIST Curve P-521 [FIPS 186-2]  "NIST P-521"  

    Implementations MUST implement "NIST P-256", "NIST P-384" and "NIST
    P-521".  The hexadecimal representation used in the public and
    private key encodings are:

    Curve Name   Len  Hexadecimal representation of the OID
    ----------------------------------------------------------------   
    "NIST P-256"  8   0x2A, 0x86, 0x48, 0xCE, 0x3D, 0x03, 0x01, 0x07 
    "NIST P-384"  6   0x05, 0x2B, 0x81, 0x04, 0x00, 0x22            
    "NIST P-521"  6   0x05, 0x2B, 0x81, 0x04, 0x00, 0x23             
    
 
> with Windows Vista, Linux (openssl), etc. Which ECC standard
> *excludes* the curves specified in the proposal? I claim that the
> proposed subset of curves is the most widely supported subset of any

I don't have any  problem with these curves. 

It is not matter of whether they are exluded but on whether national
bodies require the use of certain curves.  The US requires thus but
other countries may require different ones.  Without a way to use their
curves they won't be abale to use OpenPGP and need to use X.509.  For
the very same reason we include RIPEMD-160; there is no real technical
reason to use it but it is required by some legislatives.  We can make
them all happy with a minor change to yopur porposal.  For an
implementor it is just a nit to support this chnaged format.  It might
even be easier because there might be no need for an OpenPGP-Curve-ID
mapping table.

> This is where freedom will make interoperability problematic. It is
> hard to come up with preferences that control the structure of
> self-signatures, because preferences themselves are stored in

Same goes for SHA-256 or DSA-2.  We already have interoperability
problems.

> self-signatures. The only solution to this chicken-and-egg problem is
> to establish small core set of curves, the two ones I proposed in the
> draft, and focus on supporting these curves first.

Fine with me.

>> p.s. I don't think that the notion of "Top Secret" And "Secret"
>> belongs into
>> an RFC.  I could also ask to add "VS/NfD", which is a secrecy level used
>> in Germany
>
> This seems reasonable. If any of 3 curves in the proposal satisfy

This was not my point.  It is not a matter of an Internet standard to
define what is top secret and what is secret.  This is an
oprganisational issue of the entity using appliactions based on that
standard.  Add it as an informational note at the end of spec after the
security considerations and mark is as U.S. specific.  As it stands now
it looks pretty much like a part of the standard.


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 m3H75rWn022511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2008 00:05:53 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3H75r33022510; Thu, 17 Apr 2008 00:05:53 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3H75m72022503 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 17 Apr 2008 00:05:50 -0700 (MST) (envelope-from [e-mail])
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1JmOJu-0005wu-RM for <[e-mail]>; Thu, 17 Apr 2008 09:14:10 +0200
Received: from wk by localhost with local (Exim 4.62 #1 (Debian)) id 1JmO86-0006iw-Em; Thu, 17 Apr 2008 09:01:58 +0200
From: Werner Koch <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]> <[e-mail]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[e-mail]
Date: Thu, 17 Apr 2008 09:01:58 +0200
In-Reply-To: <[e-mail]> (Jon Callas's message of "Mon, 14 Apr 2008 12:40:39 -0700")
Message-ID: <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, 14 Apr 2008 21:40, [e-mail] said:

> * 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.

I support this.  

However the preference should not reference another document but
explicitly list the restriction.  There may be an explanatory note
indicating that this is identical to Suite-B.

Please recall that OpenPGP is not a national standard.  If more
provisions for an US standard go into OpenPGP other countries may want
to see their own rules in there too.  To avoid such attempts I believe
it is better to have a more neutral language.


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 m3FL8Wrf055823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 14:08:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3FL8W9h055822; Tue, 15 Apr 2008 14:08:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3FL8Wew055816 for <[e-mail]>; Tue, 15 Apr 2008 14:08:32 -0700 (MST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 1441AE83942 for <[e-mail]>; Tue, 15 Apr 2008 14:08:32 -0700 (PDT)
Received: from [10.214.201.168] ([66.236.113.201]) by keys.merrymeet.com (PGP Universal service); Tue, 15 Apr 2008 14:08:32 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 15 Apr 2008 14:08:32 -0700
Cc: OpenPGP <[e-mail]>, Andrey Jivsov <[e-mail]>, David Crick <[e-mail]>
Message-Id: <[e-mail]>
From: Jon Callas <[e-mail]>
To: Ian G <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: I have a technical idea/change for the ECC draft
Date: Tue, 15 Apr 2008 14:08:29 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 15, 2008, at 5:25 AM, Ian G wrote:
>
> A high level / managerial perspective.  Apologies in advance for  
> where it drifts from actual specifications.
>
>
>
> We are deep down the rabbit hole known as
>
>    _profiles v. algorithms_
>
> It is worth standing back and thinking about this because when V5  
> keys are looked it, it is possible that we could solve this.
>
> PGP was designed in the early 90s when algorithms were thought to be  
> all there was to crypto.  Now, we know that's wrong [1].  Now, we  
> know it is all about applications and users, and they want  
> communication before security, and security before crypto.  From a  
> crypto standpoint, profiles are the only way forward, because they  
> remove interoperability issues, which improves communications.
>
> But, still, today, OpenPGP prefers to indicate algorithms not  
> profiles, so what to do?

 From here, nothing. This is layering. At the bottom layer, there's  
the algorithms, as you note. A layer up from that you get profiles.  
The profiles can either be implicit in the implementation, or they can  
be explicit in some standard.

I would actually say that there's the raw algorithm (like AES), the  
extended algorithm (like CFB), and the protocol (like OpenPGP). Above  
that, as you note are the profiles. This isn't even a Kerchoff issue,  
it's a systems engineering and design issue. If you don't give the  
implementers liberty, they can't do cool things no one else thought  
of. If you give them too much liberty, they write crap. Between those  
two problems is wisdom.

I have no personal interest in making profile documents. I support  
other people who have such interest. The profiles do exist, however.  
They're just implicit in the application.

I think it's better for ECC/SuiteB to have them implicit. But if  
someone else wants to do the work, sure.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIBRlQsTedWZOD3gYRAlLSAKDReEI/NMupzw2Vqgih93rK2oqppACgyX0b
tG/kRNUqBsJPRVClIJ1idA4=
=6cLL
-----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 m3FL1EJg055379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 14:01:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3FL1EZf055378; Tue, 15 Apr 2008 14:01:14 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3FL194w055360 for <[e-mail]>; Tue, 15 Apr 2008 14:01:13 -0700 (MST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 8D224E83801 for <[e-mail]>; Tue, 15 Apr 2008 14:01:08 -0700 (PDT)
Received: from [10.214.201.168] ([66.236.113.201]) by keys.merrymeet.com (PGP Universal service); Tue, 15 Apr 2008 14:01:08 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 15 Apr 2008 14:01:08 -0700
Cc: OpenPGP <[e-mail]>
Message-Id: <[e-mail]>
From: Jon Callas <[e-mail]>
To: David Crick <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: I have a technical idea/change for the ECC draft
Date: Tue, 15 Apr 2008 14:01:07 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 15, 2008, at 3:12 AM, David Crick wrote:
>> Note that 4880 *explicitly* says that you take the intersection of
>> Alice's and Bob's preferences and resolve them any way you see fit.  
>> It
>> is acceptable for an implementation to use 3DES only when nothing  
>> else
>> exists. It's acceptable for an implementation, thus, in Suite B, to
>> always be strict. (To do Suite B, you have to have AES as an option.)
>
> yes, although there *is* a section in 4880 that says about
> the preference listing being ordered.  The two things together
> *aren't* incompatible; rather they say, together, that here's
> some information you *could* use, but really it's up to you.

Exactly. The two things are there and it's by intent. You say what  
your preferences are in order, and I take them under advisement.


>
>
>
>> That's the way I'd do it. I'd do it in the code, not in the standard.
>>
>> However, I realize that not everyone has my matters of taste, and so
>> therefore, I support the legislative solution.
>
> I think the legislative solution should give clear enough
> guidelines to the implementers about what they should
> be doing!

I disagree only in that I'd change "should" to "must." :-) Should is  
opinion, must is fact. There's always someone who has to deviate from  
the best path for reasons we cannot fathom.

	Jon




-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIBReUsTedWZOD3gYRAjQOAJ4oqCm9dBGR1OX9NBoKJN+mtVc+xACgiluE
4Ixix7J9xvggxpejZix7Ar0=
=BDTI
-----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 m3FCPKsB008478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 05:25:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3FCPKDB008477; Tue, 15 Apr 2008 05:25:20 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3FCPCJE008453 for <[e-mail]>; Tue, 15 Apr 2008 05:25:15 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 0B9CC57B26; Tue, 15 Apr 2008 14:25:07 +0200 (CEST)
Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvyPfSMJzURZ; Tue, 15 Apr 2008 14:25:06 +0200 (CEST)
Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 98FA557AF8; Tue, 15 Apr 2008 14:25:06 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2008 14:25:06 +0200
From: Ian G <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: OpenPGP <[e-mail]>
CC: Andrey Jivsov <[e-mail]>, Jon Callas <[e-mail]>, David Crick <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

A high level / managerial perspective.  Apologies in advance 
for where it drifts from actual specifications.



We are deep down the rabbit hole known as

     _profiles v. algorithms_

It is worth standing back and thinking about this because 
when V5 keys are looked it, it is possible that we could 
solve this.

PGP was designed in the early 90s when algorithms were 
thought to be all there was to crypto.  Now, we know that's 
wrong [1].  Now, we know it is all about applications and 
users, and they want communication before security, and 
security before crypto.  From a crypto standpoint, profiles 
are the only way forward, because they remove 
interoperability issues, which improves communications.

But, still, today, OpenPGP prefers to indicate algorithms 
not profiles, so what to do?



1. Leave it entirely out of the ECC document and let the 
implementors discuss it.  The problem with this is as 
highlighted by the Willmer/Laurie case.  They apparently had 
to backtrack from their "cleanroom dox" implementation and 
go find info that was "shared" not written.  So we are 
adding in an additional drag on the implementors.

That's fine if you believe that all implementors should talk 
anyway, but not so fine if some only talk in Chinese and 
others have poor social skills and good code is downloadable 
from sourceforge.



2. "legislative" position in the ECC document.  Something like:

    OpenPGP-ECC has no implied preference,
    and explicitly drops the TripleDES implied preference
    of RFC4880.  Each algorithm must be expressed.

    The existance of preferences AES-128 and AES-256 only
    MAY be taken as a signal that Suite-B is required.

Or somesuch.  Plus side might be that it might mean less 
interop testing and less code.  That would be a big win for 
ECC coders in the mobile field, as they could get a single 
tight profile.

Minus side might be that it might be ignored.  Or, it might 
not, if we choose carefully.  If it is ignored, we've lost 
nothing.  If it is followed, then we've won.



3. "Security Notes / Comments" to the effect that the world 
has moved on and implementations should avoid using the old 
stuff.  Something like:

   Although RFC4880 includes TripleDES as an obligatory
   and common algorithm, this algorithm is out of date.
   Implementors are likely to limit TripleDES to
   interoperability testing only, and application
   developers are likely to not offer TripleDES, or
   offer it under override conditions only.
   Implemetors should follow the profiles
   suggested in Suite-B.

This means that implementors still have to write TripleDES 
code and still have to interop test it.  But application 
developers can ignore it.



4.  Two Key flags to specify Suite-B (S + TS) as suggested 
by Andrey.  This in effect adds profiles.

If we can do this for Suite-B, we can do it for RSA and 
other things.  Consider a Suite-RSA "for the rest of us":

     Secret:     AES-128, RSA-3072, SHA256
     TopSecret:  AES-256, RSA-8192, SHA512

But this might be better off being left for V5?  Dunno.




iang

[1] This is not a new mistake.  Kherdkoffs wrote about it in 
1883.



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 m3FATTIW097333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 03:29:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3FATTZa097332; Tue, 15 Apr 2008 03:29:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3FATRFB097325 for <[e-mail]>; Tue, 15 Apr 2008 03:29:28 -0700 (MST) (envelope-from [e-mail])
Received: by mu-out-0910.google.com with SMTP id w8so1225742mue.4 for <[e-mail]>; Tue, 15 Apr 2008 03:29:26 -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=MZOm1wAxnXeTWrju/HVh3MPki3B5qLf2brVt7pXeFzs=; b=xpL45zpMKeK1xHKUjsBU3b6T/91Tyfnfr8NHtshNf6nHM4JvdaKW4nLM9RsGbzR6VpLIAl41yzL91eziTxnl0UYeJ+x0LlpSSQVBrt0vmmMmvIygN6Q16RJpLhEEO0i0TkLlTOoZijYFeJoh7UTMAqyLw09xfnZnm9WHODk8YLI=
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=nm9atIND4PtrOx2vxtA7uKFpUTuGX0L6lueAeb8jtwwL3rUBtgRyVbhWUNrxM5UAlsmjFy/mJ+3ga6bq/8fk53gjehMPGiM2avT2ivEK9DbaTXh3YmssVyPoarOjB6Ax2kAUzi+Kvupi4oAL0lnYjXfXvmBhcqMVWtHA2lLyX/Y=
Received: by 10.78.182.9 with SMTP id e9mr4041108huf.91.1208255365839; Tue, 15 Apr 2008 03:29:25 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Tue, 15 Apr 2008 03:29:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2008 11:29:25 +0100
From: "David Crick" <[e-mail]>
To: "Andrey Jivsov" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: "Jon Callas" <[e-mail]>, OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  I favor this too.
>
>  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?

My initial reaction was "no": one flag restricts ciphers for both
profiles (TS and S) - and that's absolutely correct for "Suite B."

But "OpenPGP ECC" possibly has several categories (levels):

1. Strict Suite B TS
2. Strict Suite B S
3. ECC with AESes
(3a ECC with Twofish, Camellia)
4. ECC with 3DES
(4a ECC with Twofish, Camellia if you think 3DES is higher)
5. ECC with other ciphers / non-ECC keys

but maybe this is now into the realm of cipher preferences?

I need to give this a bit more thought.



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 m3FACXJL095761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 03:12:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3FACXFx095760; Tue, 15 Apr 2008 03:12:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3FACVGN095750 for <[e-mail]>; Tue, 15 Apr 2008 03:12:32 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id g16so453730nfd.24 for <[e-mail]>; Tue, 15 Apr 2008 03:12:23 -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=4KwmErtMZtSfVqCtzRS1CakX7SNXkeybsPzu5JIyopU=; b=EoM0t52JqFsEyfm61d4/6REtPAer60ahDni5g/R+8DvL9Eze+oh8r0vhX6VBI2U484tLzKgel8IssAFM4yPaxRwJ0moLVu6k8YxFGBWUzWO5CqNqkrcUs5JCDOWhwue4TJTNfSQTsAvJ7FoDKhAgZGNg2Ivawycq0ENI3fqzzWU=
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=eI7AqWxPUPVhhwimGE9Y0DrG/bvbh0mAH0wlzOAYA3ptdLeGZRp9ronQPbRzy2WARuerQPiAeXdreimEDF6kA7DzKIJ/Iz0uJm+HjDA5Wm6rpsfgQMOHaHi0XVyQzL6rSnZUFUOFnNWKWsCMbIeZ3hjHMlmxCJ83ySrf5bcpvSQ=
Received: by 10.78.132.2 with SMTP id f2mr3963665hud.83.1208254343422; Tue, 15 Apr 2008 03:12:23 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Tue, 15 Apr 2008 03:12:23 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2008 11:12:23 +0100
From: "David Crick" <[e-mail]>
To: "Jon Callas" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, Apr 15, 2008 at 3:22 AM, Jon Callas <[e-mail]> wrote:
>
> On Apr 14, 2008, at 3:33 PM, David Crick wrote:
>  >> * 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.
>  >
>  > are you referring to a "key" or "application" preference (or both?!)
>
>  I was thinking a signature subpacket of some sort. That's a "key"
>  preference.

good.

>  Any application-level things are beyond the scope of this group.

again, this is what I was expecting.

>  We did this with DSA/DSS. If you want to be strictly FIPS, you always
>  use DSA with SHA-1, etc. and that gives you DSS. If, however, you look
>  askance at SHA-1, you can use DSA with RIPE-MD/160. There are explicit
>  and implicit issues with that, but you can do it within 4880.
>
>  We could similarly just not worry about it. Let the implementers
>  handle it. Thems what care about strict-SB can implement it the right
>  way.
>
>  I like the legislative solution, but I prefer doing nothing and
>  letting the implementers handle it. This is a style issue. I believe
>  that a standard exists for interoperability, and to make sure you
>  don't end up with two implementations that *cannot* talk to each
>  other. Beyond that, I am a minimalist. A standard is not a how-to
>  guide for an implementer.
>
>  I were an implementer, I would not generate a "loose-Suite-B" message,
>  *ever*. I'd decrypt them, but I wouldn't give my users the option to
>  create them.

I agree with you on all the above.

>  >> Even better would be for implementations to just not offer an
>  >> alternative.
>  >
>  > yes!
>  >
>  > If all applications were to by default add AES (one or both) to
>  > the head of any ECC generated keys, *and* prefer AES over
>  > 3DES as implicit, *but* still be able to "understand" messages
>  > that are encrypted by non-AES ciphers.
>
>  Frankly, I believe that an application should prefer AES or Twofish
>  over 3DES, period.

It's what NIST says (of AES and 3DES; AES is the FIPS, while
3DES has been downgraded to a Special Recommendation).

NSA's blessing of AES (first for classified usage, and then an
even stronger endorsement through Suite B) as far as I'm
concerned is a very clear signal.  In fact, Suite B itself (and I
include SHA2 here, despite people's misgivings given SHA1)
is a strong signal about "what" we (crypto implementers)
should be doing - and why I've been pushing for us to focus
on Suite B (and AES with it) when looking at OpenPGP ECC.

>  Note that 4880 *explicitly* says that you take the intersection of
>  Alice's and Bob's preferences and resolve them any way you see fit. It
>  is acceptable for an implementation to use 3DES only when nothing else
>  exists. It's acceptable for an implementation, thus, in Suite B, to
>  always be strict. (To do Suite B, you have to have AES as an option.)

yes, although there *is* a section in 4880 that says about
the preference listing being ordered.  The two things together
*aren't* incompatible; rather they say, together, that here's
some information you *could* use, but really it's up to you.


>  That's the way I'd do it. I'd do it in the code, not in the standard.
>
>  However, I realize that not everyone has my matters of taste, and so
>  therefore, I support the legislative solution.

I think the legislative solution should give clear enough
guidelines to the implementers about what they should
be doing!



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 m3F76BS2077328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Apr 2008 00:06:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3F76BOO077326; Tue, 15 Apr 2008 00:06:11 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3F768vw077318 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Tue, 15 Apr 2008 00:06:09 -0700 (MST) (envelope-from [e-mail])
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 m3F8BajX020592; Tue, 15 Apr 2008 04:11:38 -0400
Message-ID: <[e-mail]>
Date: Tue, 15 Apr 2008 00:06:01 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: OpenPGP <[e-mail]>, David Crick <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> On Apr 14, 2008, at 3:33 PM, David Crick wrote:
>>> * 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.
>> are you referring to a "key" or "application" preference (or both?!)
>>
> 
> I was thinking a signature subpacket of some sort. That's a "key"  
> preference. Strictly speaking, OpenPGP is a data protocol, and doesn't  
> define applications preferences any more than SMTP tells you how to  
> set up your sendmail or postfix conf file.
> 
> Any application-level things are beyond the scope of this group.
> 
> 
>>> * Test, for interop purposes, 3DES with Suite B.
>> sounds sound
>>
>>> If you don't like this, you could do what David Crick suggested,
>>> but with reverse polarity. I mean that instead of having an "-- 
>>> enforce-
>>> suiteB" option, you have a "--loose-suiteB" option that you have to  
>>> do
>>> to allow anything that's not strict.
>>>
>>> Note that these are not exclusive. You can do both.
>> So are you saying we have:
>>
>> o Strict Suite B key flag ("legislative"; allows recipient to  
>> specify strongly)
>>
>> *plus* (potentially out of scope of the [legistlative] spec?)
>>
>> o an --enforce-suiteB application flag (self-evident)
>> o a --loose-suiteB application flag (but can it override a key-flag?  
>> - or
>> are you using this instead of a keyflag)
> 
> I'm saying that I like the idea of a legislative solution. However, it  
> would be reasonable for us to punt the legislative issue.
> 
> We did this with DSA/DSS. If you want to be strictly FIPS, you always  
> use DSA with SHA-1, etc. and that gives you DSS. If, however, you look  
> askance at SHA-1, you can use DSA with RIPE-MD/160. There are explicit  
> and implicit issues with that, but you can do it within 4880.
> 
> We could similarly just not worry about it. Let the implementers  
> handle it. Thems what care about strict-SB can implement it the right  
> way.
> 
> I like the legislative solution, but I prefer doing nothing and  
> letting the implementers handle it. This is a style issue. I believe  
> that a standard exists for interoperability, and to make sure you  
> don't end up with two implementations that *cannot* talk to each  
> other. Beyond that, I am a minimalist. A standard is not a how-to  
> guide for an implementer.

I favor this too.

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?

> I were an implementer, I would not generate a "loose-Suite-B" message,  
> *ever*. I'd decrypt them, but I wouldn't give my users the option to  
> create them.
> 
> 
>>
>>> Even better would be for implementations to just not offer an
>>> alternative.
>> yes!
>>
>> If all applications were to by default add AES (one or both) to
>> the head of any ECC generated keys, *and* prefer AES over
>> 3DES as implicit, *but* still be able to "understand" messages
>> that are encrypted by non-AES ciphers.
> 
> Frankly, I believe that an application should prefer AES or Twofish  
> over 3DES, period.
> 
> Note that 4880 *explicitly* says that you take the intersection of  
> Alice's and Bob's preferences and resolve them any way you see fit. It  
> is acceptable for an implementation to use 3DES only when nothing else  
> exists. It's acceptable for an implementation, thus, in Suite B, to  
> always be strict. (To do Suite B, you have to have AES as an option.)
> 
> That's the way I'd do it. I'd do it in the code, not in the standard.
> 
> However, I realize that not everyone has my matters of taste, and so  
> therefore, I support the legislative solution. I just prefer not  
> worrying, as it's less work here.
> 
> 	Jon
> 



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 m3F6tDx6075864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 23:55:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3F6tDDp075863; Mon, 14 Apr 2008 23:55:13 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3F6tCD1075849 for <[e-mail]>; Mon, 14 Apr 2008 23:55:12 -0700 (MST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id EBD10E7E116 for <[e-mail]>; Mon, 14 Apr 2008 23:55:11 -0700 (PDT)
Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Mon, 14 Apr 2008 23:55:12 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 14 Apr 2008 23:55:12 -0700
Cc: [e-mail]
Message-Id: <[e-mail]>
From: Jon Callas <[e-mail]>
To: Peter Gutmann <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: I have a technical idea/change for the ECC draft
Date: Mon, 14 Apr 2008 23:55:10 -0700
References: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 14, 2008, at 11:32 PM, Peter Gutmann wrote:
>
> Jon Callas <[e-mail]> writes:
>
>> I have heard it said that there have been no DSA certificates  
>> created in the
>> real world, only ones needed for "interop" testing for the  
>> "mandatory"
>> algorithm.
>
> There are DSA certs created for USG use but they're from a parallel  
> universe
> where X.509 PKI works just fine, people still send X.400 email, and  
> everything
> is predicated on the X.500 Directory, so I don't think it's a good
> representative example :-).

Which is precisely my point. They are the mandatory-to-implement, but  
they exist with Bizarro Superman.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIBFFQsTedWZOD3gYRAg0oAJ9BQ5z+k7ND04k/CP6SR754oNXL1wCfVK2U
jaXXzzIfUrvBmtoMglrrLgA=
=dOG3
-----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 m3F6WQOr074278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 23:32:26 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3F6WQ5d074277; Mon, 14 Apr 2008 23:32:26 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3F6WCI0074262 for <[e-mail]>; Mon, 14 Apr 2008 23:32:21 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D44371895C; Tue, 15 Apr 2008 18:32:09 +1200 (NZST)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dKEwHBUc0sr; Tue, 15 Apr 2008 18:32:09 +1200 (NZST)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A5591893F; Tue, 15 Apr 2008 18:32:09 +1200 (NZST)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 69AE419EC0B9; Tue, 15 Apr 2008 18:32:08 +1200 (NZST)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1Jlei8-0004Gf-9X; Tue, 15 Apr 2008 18:32:08 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I have a technical idea/change for the ECC draft
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 15 Apr 2008 18:32:08 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> writes:

>I have heard it said that there have been no DSA certificates created in the
>real world, only ones needed for "interop" testing for the "mandatory"
>algorithm.

There are DSA certs created for USG use but they're from a parallel universe
where X.509 PKI works just fine, people still send X.400 email, and everything
is predicated on the X.500 Directory, so I don't think it's a good
representative example :-).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3F2N5DG056990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 19:23:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3F2N5Ox056989; Mon, 14 Apr 2008 19:23:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3F2MvgO056978 for <[e-mail]>; Mon, 14 Apr 2008 19:23:04 -0700 (MST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 726E2E7CB23 for <[e-mail]>; Mon, 14 Apr 2008 19:22:57 -0700 (PDT)
Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Mon, 14 Apr 2008 19:22:57 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 14 Apr 2008 19:22:57 -0700
Message-Id: <[e-mail]>
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: I have a technical idea/change for the ECC draft
Date: Mon, 14 Apr 2008 19:22:56 -0700
References: <[e-mail]> <[e-mail]> <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 14, 2008, at 3:33 PM, David Crick wrote:
>> * 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.
>
> are you referring to a "key" or "application" preference (or both?!)
>

I was thinking a signature subpacket of some sort. That's a "key"  
preference. Strictly speaking, OpenPGP is a data protocol, and doesn't  
define applications preferences any more than SMTP tells you how to  
set up your sendmail or postfix conf file.

Any application-level things are beyond the scope of this group.


>> * Test, for interop purposes, 3DES with Suite B.
>
> sounds sound
>
>> If you don't like this, you could do what David Crick suggested,
>> but with reverse polarity. I mean that instead of having an "-- 
>> enforce-
>> suiteB" option, you have a "--loose-suiteB" option that you have to  
>> do
>> to allow anything that's not strict.
>>
>> Note that these are not exclusive. You can do both.
>
> So are you saying we have:
>
> o Strict Suite B key flag ("legislative"; allows recipient to  
> specify strongly)
>
> *plus* (potentially out of scope of the [legistlative] spec?)
>
> o an --enforce-suiteB application flag (self-evident)
> o a --loose-suiteB application flag (but can it override a key-flag?  
> - or
> are you using this instead of a keyflag)

I'm saying that I like the idea of a legislative solution. However, it  
would be reasonable for us to punt the legislative issue.

We did this with DSA/DSS. If you want to be strictly FIPS, you always  
use DSA with SHA-1, etc. and that gives you DSS. If, however, you look  
askance at SHA-1, you can use DSA with RIPE-MD/160. There are explicit  
and implicit issues with that, but you can do it within 4880.

We could similarly just not worry about it. Let the implementers  
handle it. Thems what care about strict-SB can implement it the right  
way.

I like the legislative solution, but I prefer doing nothing and  
letting the implementers handle it. This is a style issue. I believe  
that a standard exists for interoperability, and to make sure you  
don't end up with two implementations that *cannot* talk to each  
other. Beyond that, I am a minimalist. A standard is not a how-to  
guide for an implementer.

I were an implementer, I would not generate a "loose-Suite-B" message,  
*ever*. I'd decrypt them, but I wouldn't give my users the option to  
create them.


>
>
>> Even better would be for implementations to just not offer an
>> alternative.
>
> yes!
>
> If all applications were to by default add AES (one or both) to
> the head of any ECC generated keys, *and* prefer AES over
> 3DES as implicit, *but* still be able to "understand" messages
> that are encrypted by non-AES ciphers.

Frankly, I believe that an application should prefer AES or Twofish  
over 3DES, period.

Note that 4880 *explicitly* says that you take the intersection of  
Alice's and Bob's preferences and resolve them any way you see fit. It  
is acceptable for an implementation to use 3DES only when nothing else  
exists. It's acceptable for an implementation, thus, in Suite B, to  
always be strict. (To do Suite B, you have to have AES as an option.)

That's the way I'd do it. I'd do it in the code, not in the standard.

However, I realize that not everyone has my matters of taste, and so  
therefore, I support the legislative solution. I just prefer not  
worrying, as it's less work here.

	Jon



-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIBBGBsTedWZOD3gYRAswSAKC9DBiIdUo1spLo9r1Ib7EPD7yCRQCfYLv+
CoRisciZg/0HKe2NKHed388=
=f5bh
-----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 m3EMXki9039320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 15:33:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EMXk22039319; Mon, 14 Apr 2008 15:33:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3EMXdu1039291 for <[e-mail]>; Mon, 14 Apr 2008 15:33:40 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id g16so429986nfd.24 for <[e-mail]>; Mon, 14 Apr 2008 15:33:36 -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=rap9uaDykV8K0h4jJoklduIFBVBemkGLiYSMDcQxh48=; b=IXtPpRt1k/fosD834YXYcuuwvWNPIXneSD1wZTuNDlNm7OpK/8awKFSlbJNOfoBxTXuS1N+EvN3F0ByQ77Uk5bFwXr2ZbmdbqG/GWoyFz3B2vDdTLahz8PMNsXqapd6OECGSE8xt/p8bRWXreN4bKMZyANvyb9gXAeepkWbJJQs=
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=rhdz9PTjrTp4p6r0+PJ9rCP2q4si0hOEkUoRbG8httJ0muR7uaGv/7SSoxxazMtU8LkaHDuE8322+Ps1EDgU2Urdkv5DkaDU1TNGKVMo1pIYXCJ+qQeqPhoREC7W+SWtXfFfM3GFa4lJn+GYNwN7/cwTuVT4ZuxQBo5gj35UOpw=
Received: by 10.78.205.16 with SMTP id c16mr3631579hug.109.1208212415852; Mon, 14 Apr 2008 15:33:35 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Mon, 14 Apr 2008 15:33:35 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 23:33:35 +0100
From: "David Crick" <[e-mail]>
To: "Jon Callas" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: OpenPGP <[e-mail]>, "Andrey Jivsov" <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  * 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.

are you referring to a "key" or "application" preference (or both?!)

>  * Test, for interop purposes, 3DES with Suite B.

sounds sound

>  If you don't like this, you could do what David Crick suggested,
>  but with reverse polarity. I mean that instead of having an "--enforce-
>  suiteB" option, you have a "--loose-suiteB" option that you have to do
>  to allow anything that's not strict.
>
>  Note that these are not exclusive. You can do both.

So are you saying we have:

o Strict Suite B key flag ("legislative"; allows recipient to specify strongly)

*plus* (potentially out of scope of the [legistlative] spec?)

o an --enforce-suiteB application flag (self-evident)
o a --loose-suiteB application flag (but can it override a key-flag? - or
are you using this instead of a keyflag)

>  Even better would be for implementations to just not offer an
>  alternative.

yes!

If all applications were to by default add AES (one or both) to
the head of any ECC generated keys, *and* prefer AES over
3DES as implicit, *but* still be able to "understand" messages
that are encrypted by non-AES ciphers.



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 m3EM1SWc037141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 15:01:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EM1SRp037140; Mon, 14 Apr 2008 15:01:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3EM1RAP037130 for <[e-mail]>; Mon, 14 Apr 2008 15:01:28 -0700 (MST) (envelope-from [e-mail])
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 m3EM1Pk29954 for <[e-mail]>; Mon, 14 Apr 2008 18:01:26 -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 m3EM1LvB026448 for <[e-mail]>; Mon, 14 Apr 2008 18:01:21 -0400
Date: Mon, 14 Apr 2008 18:01:21 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-openpgp-camellia-02.txt
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Mon, Apr 14, 2008 at 02:45:01PM -0700, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.
> 
> 	Title		: The Camellia Cipher in OpenPGP
> 	Author(s)	: D. Shaw
> 	Filename	: draft-ietf-openpgp-camellia-02.txt
> 	Pages		: 5
> 	Date		: 2008-4-14
> 	
> This document presents the necessary information to use the Camellia
>    symmetric block cipher in the OpenPGP protocol.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-02.txt

FYI to the list members, this is identical to the previous draft
except for the addition of Camellia-192.  The draft now specifies 128,
192, and 256 bit keys.

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 m3EM0296037002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 15:00:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EM02Qn037001; Mon, 14 Apr 2008 15:00:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3ELxnoc036942 for <[e-mail]>; Mon, 14 Apr 2008 15:00:00 -0700 (MST) (envelope-from [e-mail])
Received: by mu-out-0910.google.com with SMTP id w8so1115737mue.4 for <[e-mail]>; Mon, 14 Apr 2008 14:59:48 -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=+wqb77gIk7QKVmxNWn+V8uAVqTCve/j1cAKcGEtc03I=; b=O6Enm7zWs6DDN+fHm4+ILCUQLAhd3T9lLCRY4WbGn01TkjWw7yoM/1j1p7H8v5RCNHE8pB1ogNmM6IuGYKpOII/q9XDP1Vmnu2C7lQTZgX9V88hnIcH6LJGnuY33tP8EdgDUwuF1TkHrSC1KqmgdPX4g+V5RbIu/JLnOnVLlFCU=
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=S4YHEOdSF8dbyjtffVIlUtWlSh9ny13pJOUDu/TCAMaOBYvGm8AHgtf2e/Gw3gLDNRbBVv1xZ+q+FOHv+Q6S8jd2SVa/JFnbliWgIM2ubchdc3C6/SMeYODlmYXU//miNSk/KiMPBABG3NnBr6h8fVhy4pH55UtrskgpZh32vvw=
Received: by 10.78.196.10 with SMTP id t10mr3609934huf.113.1208210388627; Mon, 14 Apr 2008 14:59:48 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Mon, 14 Apr 2008 14:59:48 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 22:59:48 +0100
From: "David Crick" <[e-mail]>
To: "David Shaw" <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-camellia-02.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>         Filename        : draft-ietf-openpgp-camellia-02.txt
>         Pages           : 5
>         Date            : 2008-4-14


looks good to me.



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 m3ELkMPs036007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 14:46:22 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3ELkMGc036005; Mon, 14 Apr 2008 14:46:22 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3ELkLco035989 for <[e-mail]>; Mon, 14 Apr 2008 14:46:22 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 9F29928C32C; Mon, 14 Apr 2008 14:45:01 -0700 (PDT)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-camellia-02.txt 
Message-Id: <[e-mail]>
Date: Mon, 14 Apr 2008 14:45:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: The Camellia Cipher in OpenPGP
	Author(s)	: D. Shaw
	Filename	: draft-ietf-openpgp-camellia-02.txt
	Pages		: 5
	Date		: 2008-4-14
	
This document presents the necessary information to use the Camellia
   symmetric block cipher in the OpenPGP protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-camellia-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-camellia-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--NextPart--



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 m3ELP5KF034441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 14:25:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3ELP4MN034440; Mon, 14 Apr 2008 14:25:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3ELO97O034374 for <[e-mail]>; Mon, 14 Apr 2008 14:24:12 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id g16so422864nfd.24 for <[e-mail]>; Mon, 14 Apr 2008 14:23:51 -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=CIO24dXBzV52GU0M9L9QdS03IbopVe5TonUfP+0NnjY=; b=k/yqpy+iC/ykMHHj7Or+hkwAR/RxifDy/8W4FxPDLdQYeiWMKAODk5uRgvqg/BgYd6AwBm43TP+M/wn2UCBPZ/F2wBnVQmbkifu1QBkrcsrf1A12XAratAr0LTwk6XPVXYPF3Go1kHaS8mxg7DWuepOZ71dT2sXIlUYcDftyUbc=
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=yIREZhRRGvquGSnPWjHYbj3pYNLANI947x2cFMX0tbl7XFzLZLo8BIS3hhl63p8DOmqpUMm2Jr4Ayn9WjudwwhMq1wf3nhsSLulwdcvVBK7ayUmBxtAu3LWwBsTyUr+TfNv7ZGGXU2e3GLk7GCkhppNdW+9wcf1LU61+e5UdAjU=
Received: by 10.78.198.14 with SMTP id v14mr3571302huf.115.1208208231622; Mon, 14 Apr 2008 14:23:51 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Mon, 14 Apr 2008 14:23:51 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 22:23:51 +0100
From: "David Crick" <[e-mail]>
To: "Andrey Jivsov" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: "Jon Callas" <[e-mail]>, OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  As it stands right now, Suite-B is vaguely defined, thus there will be a
> lot of questions as to what that Suite-B key is.

No, Suite B is very clearly defined:

384 ECC, 384 SHA hash, AES256 ("TOP SECRET")
256 ECC, 256 SHA had (384 also OK), AES128 (AES256 also OK) ("SECRET")


Our "problem" is that we are trying to layer an *ECC* spec
(of which Suite B is a *sub-set*, with specific restrictions)
on top of RFC4880.

Because of that, our "ECC OpenPGP" allows use of 3DES,
but this conflicts with the AES-only nature of the Suite B
subset of our ECC spec.


> 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.


(NB, we're going to hit the same thing with the hash when
- and I use "when" optimistically - Whirlpool gets added; a
SuiteB flag on the key would only allow the correct-sized
SHA2.

NB#2, I'm not entirely sure what "suiteb only" flag means if
you try to encrypt to an ECC key and a non-ECC key?)



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 m3EKdiMq030563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 13:39:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EKdiPp030562; Mon, 14 Apr 2008 13:39:44 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3EKdhVR030555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Apr 2008 13:39:44 -0700 (MST) (envelope-from [e-mail])
Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m3EKdgZE006058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 13:39:42 -0700
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 13:39:36 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas wrote:
> I don't think this is a bad idea at all, but I also think I should  
> bring up something that Jeff Schiller made clear to me years ago, and  
> that's the difference between mandatory-to-implement, and mandatory-to- 
> use.
>
> In this group, we create what are legislative systems. There are also  
> market systems, and we cannot create those. Let me give two examples.
>
> As a result of various decisions made at the 1997 Munich IETF, there's  
> broad "MUST" requirement of Discrete Log PK Crypto and 3DES for  
> symmetric. This was an artifact of the patents for Discrete Log  
> expiring in 1997, and the RSA patents expiring in 2000. However, in  
> the X.509 certificate world, you will almost *never* see a DSA  
> certificate. I have heard it said that there have been no DSA  
> certificates created in the real world, only ones needed for "interop"  
> testing for the "mandatory" algorithm.
>
> Quibble with this if you want, but it's still true that in the real  
> world there are only RSA certificates, despite RSA being an *optional*- 
> to-implement algorithm.
>
> Similarly, I would expect that in the OpenPGP world, you'll now see  
> little to no use of 3DES. Mostly, you'll see AES. I have no supporting  
> facts for my expectation, but I'd bet a beer on it.
>
> In these cases, market trumped legislation. In the RSA case, people  
> agreed to the political discrete log compromise, and then went on  
> doing what they'd been doing -- using RSA. In the AES case, AES has  
> replaced 3DES in the real world through organic growth.
>
> So here's what we can do:
>
> * 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.
>   
I think that there is implicit assumption here that "Suite-B" and "only 
AES" are synonymous for this discussion, but clearly, only one of these 
terms is crystal clear while another one is not.

As it stands right now, Suite-B is vaguely defined, thus there will be a 
lot of questions as to what that Suite-B key is. 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.

> * Test, for interop purposes, 3DES with Suite B. But as an  
> implementor, *don't* *do* *it*. This is similar to what they did with  
> DSA in X.509. As an implementor, don't do anything other than strict  
> Suite B. Don't put it in the UI, don't give any options. Just do Suite  
> B. If you don't like this, you could do what David Crick suggested,  
> but with reverse polarity. I mean that instead of having an "--enforce- 
> suiteB" option, you have a "--loose-suiteB" option that you have to do  
> to allow anything that's not strict.
>
> Note that these are not exclusive. You can do both. There can be a SSB  
> preference, and if enough people do it by default, then there's no  
> issue. Even better would be for implementations to just not offer an  
> alternative.
>
> 	Jon
>
>   



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 m3EJegdE025661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 12:40:42 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EJegg3025660; Mon, 14 Apr 2008 12:40:42 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3EJef12025651 for <[e-mail]>; Mon, 14 Apr 2008 12:40:42 -0700 (MST) (envelope-from [e-mail])
Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id DEDE2E7A339 for <[e-mail]>; Mon, 14 Apr 2008 12:40:40 -0700 (PDT)
Received: from titania.merrymeet.com ([66.93.68.165]) by keys.merrymeet.com (PGP Universal service); Mon, 14 Apr 2008 12:40:40 -0700
X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 14 Apr 2008 12:40:40 -0700
Message-Id: <[e-mail]>
From: Jon Callas <[e-mail]>
To: OpenPGP <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: I have a technical idea/change for the ECC draft
Date: Mon, 14 Apr 2008 12:40:39 -0700
References: <[e-mail]>
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: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I don't think this is a bad idea at all, but I also think I should  
bring up something that Jeff Schiller made clear to me years ago, and  
that's the difference between mandatory-to-implement, and mandatory-to- 
use.

In this group, we create what are legislative systems. There are also  
market systems, and we cannot create those. Let me give two examples.

As a result of various decisions made at the 1997 Munich IETF, there's  
broad "MUST" requirement of Discrete Log PK Crypto and 3DES for  
symmetric. This was an artifact of the patents for Discrete Log  
expiring in 1997, and the RSA patents expiring in 2000. However, in  
the X.509 certificate world, you will almost *never* see a DSA  
certificate. I have heard it said that there have been no DSA  
certificates created in the real world, only ones needed for "interop"  
testing for the "mandatory" algorithm.

Quibble with this if you want, but it's still true that in the real  
world there are only RSA certificates, despite RSA being an *optional*- 
to-implement algorithm.

Similarly, I would expect that in the OpenPGP world, you'll now see  
little to no use of 3DES. Mostly, you'll see AES. I have no supporting  
facts for my expectation, but I'd bet a beer on it.

In these cases, market trumped legislation. In the RSA case, people  
agreed to the political discrete log compromise, and then went on  
doing what they'd been doing -- using RSA. In the AES case, AES has  
replaced 3DES in the real world through organic growth.

So here's what we can do:

* 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.

* Test, for interop purposes, 3DES with Suite B. But as an  
implementor, *don't* *do* *it*. This is similar to what they did with  
DSA in X.509. As an implementor, don't do anything other than strict  
Suite B. Don't put it in the UI, don't give any options. Just do Suite  
B. If you don't like this, you could do what David Crick suggested,  
but with reverse polarity. I mean that instead of having an "--enforce- 
suiteB" option, you have a "--loose-suiteB" option that you have to do  
to allow anything that's not strict.

Note that these are not exclusive. You can do both. There can be a SSB  
preference, and if enough people do it by default, then there's no  
issue. Even better would be for implementations to just not offer an  
alternative.

	Jon


-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 2.6.3
Charset: US-ASCII

wj8DBQFIA7M4sTedWZOD3gYRAsBCAKD7Yt/Qbw+9Sihf1TkjWed5hQhD1gCgoIqt
G7C+2QmpmmTen5+en9A4v0g=
=XmeX
-----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 m3EJG5pl023555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 12:16:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EJG54E023554; Mon, 14 Apr 2008 12:16:05 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.ietf.org (mail.ietf.org [IPv6:2001:1890:1112:1::20]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3EJFvRm023544 for <[e-mail]>; Mon, 14 Apr 2008 12:15:58 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id F176328C1EE; Mon, 14 Apr 2008 12:15:01 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail], [e-mail]
From: The IESG <[e-mail]>
Subject: WG Action: Conclusion of An Open Specification for Pretty Good  Privacy (openpgp) 
Message-Id: <[e-mail]>
Date: Mon, 14 Apr 2008 12:15:01 -0700 (PDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The An Open Specification for Pretty Good Privacy working group (openpgp)
in the Security Area has concluded.

The IESG contact persons are Tim Polk and Pasi Eronen.

The mailing list will remain active.

The openpgp working group has successfully completed its objective of
publishing a message format and specification for PGP/MIME. I'd like
to thank the participants and chair for all their hard work over the
years.

Sam Hartman



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 m3EJBP0V023055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 12:11:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EJBPaG023054; Mon, 14 Apr 2008 12:11:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3EJBLMU023042 for <[e-mail]>; Mon, 14 Apr 2008 12:11:24 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id g16so395750nfd.24 for <[e-mail]>; Mon, 14 Apr 2008 12:11:20 -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=BONYTxWYuUnTxn+FmFJ3B82+M+f8vKCS2pO5TuMbvk4=; b=Xynteltv/OzBKRtCeFl35YuYyLRbnU7Rcn8oAWYb5DYXLa8b3lE28JuN3ITaq2vkAXRn7tx6dmqcvcAvptNMuGtRHOf1MEjuPFV95VSVxBHdSzkBuAKXoTV9xPI72KbnkUg5LB/UVQxV/9RMpEFzhpxGBSgGFTLwDxsJeeM304k=
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=dNi/KbIN1FaQWhmva2LEICboa+SrfccSKTLlbQY+aUj+NtEWgK2aLdWPN1UfLrRz0F281BP0ThS4wSxIzbN8K7CHVpEfGcWv9bvNIQme0PIkbOx6XSYwT+R7axgcHyL4B55Z2sceLTjO9W2oJn9b3+A7Qe8vesvev2yUYpZvlYM=
Received: by 10.78.193.5 with SMTP id q5mr4921106huf.59.1208200280045; Mon, 14 Apr 2008 12:11:20 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Mon, 14 Apr 2008 12:11:19 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 20:11:19 +0100
From: "David Crick" <[e-mail]>
To: "Andrey Jivsov" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  Besides, even without this thought, I don't see how your latest proposal
> gives an ECC public key holder a mechanism to block transmission with 3DES
> (because 3DES sneaks in as an alg. for ECC keys, it may be chosen by the
> sender).

my point was that if we have a key preferences flag on the
key, then this is an instruction to the sender's software, i.e.
"strict suiteb ciphers only" - in other words, don't use 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 m3EJ16Iw022057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 12:01:06 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EJ16sh022056; Mon, 14 Apr 2008 12:01:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3EJ12BK022050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Apr 2008 12:01:05 -0700 (MST) (envelope-from [e-mail])
Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m3EJ10FB005218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 12:01:00 -0700
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 12:00:54 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: David Crick <[e-mail]>
CC: [e-mail]
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]>	 <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Crick wrote:
>>  However, I do see the benefit of a feature. If it were to make into the
>> document I suggest to make it more generic and not Suite-B specific. The
>> following alternatives achieve the same what Davit proposed but are easier
>> do understand:
>>
>>  * this key has no implicit default algorithms
>>  * this key replaces 3DES implicit algorithm with AES-128
>>     
>
> This second one (AES-128 replaces 3DES) *really* appeals to me.
>
> It should also further appeal to resource-constrained environments,
> where (therefore) not having to implement (or use) 3DES would be
> a bonus.
>
> Actually, maybe we need to add / reconsider having a section
> in the ECC doc that says
>
> "if AES-128 is not explicitly in the set of preferred algorithms, then
> it is implicitly added at the end.  If neither AES-128 or 3DES are
> explicitly listed, then both of them are implicitly added, with 3DES
> last."
>
> NB, this is weaker than the idea of a "strict suiteB flag" (my original
> proposal), and slightly weaker than your "AES128 replaces 3DES."
>
>   
I find implicit rules of the RFC 4880 controversial. They could have 
been like this: if there is no encryption keys preferences, only then 
3DES is implicitly present. That is, it would be limited to old keys. I 
would favor explicit rules, if possible.

Besides, even without this thought, I don't see how your latest proposal 
gives an ECC public key holder a mechanism to block transmission with 
3DES (because 3DES sneaks in as an alg. for ECC keys, it may be chosen 
by the sender).



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 m3EIh6B6020452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:43:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EIh6of020451; Mon, 14 Apr 2008 11:43:06 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3EIh5iO020445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Apr 2008 11:43:06 -0700 (MST) (envelope-from [e-mail])
Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m3EIh29G005086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:43:03 -0700
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 11:42:57 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: Ian G <[e-mail]>
CC: David Crick <[e-mail]>, [e-mail]
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Ian G wrote:
>
>
>
> David Crick wrote:
>> "11.3. Interoperability with Suite-B profile" currently states:
>>
>>    "If TripleDES is the only shared algorithms for a set
>>    of recipients, no Suite-B compliant recipient can be added to the
>>    mentioned recipient set."
>
>
> I had to look at all of 11.3 to try and make sense of this, and found 
> that whole subsection to be hopelessly confusing.  Can we have a 
> simple statement as to whether an OpenPGP-ECC key can be used with 
> TripleDES or not?  Can messages be mixed-mode or not?
OK, the suggestion noted. The support for TrippleDES follows from RFC 4880.

>
> It seems to me that if an application creates and exports an 
> OpenPGP-ECC key (only) then that public key cannot be used with 
> TripleDES, as the document does not suggest it anywhere (and implies 
> it is ruled out).  Which means there should be a specific claim that 
> this ECC draft overrules the "guarantee" of TripleDES intersection in 
> RFC4880.
>
The quote above is an example.  It has an "IF" in it. I didn't imply in 
11.3 to rule TrippleDES out.
> (To me, this seems like a reasonable price to pay to get a good, clear 
> result.)
I think it is important that new keys seamlessly integrate with existing 
keys and deployed applications. It's a good cause to allow 
non-government users to increase the strength of their public keys at 
lower cost that ECC provides.

We have similar issue with FIPS.
>
> Alternatively, there should be a specific claim permitting use of 
> TripleDES and describing how/what.

I will add an assertive statement about TrippleDES.

> (I should note that I do not recall the discussions of a few months 
> back.  This should be a "good thing" because it allows me to view it 
> as a first time reader.  My routine excuse is that if I can't 
> understand it from a simple reading then I suspect we are putting an 
> unnecessary burden on first time readers, but not many agree with that!)
>
>
>> but doesn't state how this may be enforced by the *recipient*
>> (who may not currently have a way of specifying this to the
>> sender).
>
>
> Personally, I would have said that the recipient should reject the 
> message with an error.  If there is a mixed mode message, then the 
> sender is in error, allowing for a potential attack.  We might not be 
> able to stop the attack through a misbehaving client, but we should 
> red-flag it when we see it.
>
> (but I've not seen the full sense yet, I may be wrong.)
>
> (Apps have these flags to decrypt even when there are errors in modes, 
> so that's ok.)
>
>
I agree. When Suite-B profile is involved user may not be able to send 
out (encode). Splitting a message into two, one using 3DES and another 
one using AES, is not an option. Depending on how the discussion about 
choosing the Suite-B goes (key or software?), I will add stricter 
statement about the the failure on the sender's side.

>> I therefore have a suggestion:
>>
>> implement a key-packet preference flag that says "strict SuiteB"
>>
>> If this is set, then applications MUST NOT use any other cipher
>> other than one of the allowed AES sizes for that ECC key size.
>>
>> This will allow us to disallow 3DES (and any other non-AES cipher)
>> by setting this key flag.
>>
>>
>> Independent of this, an application may additionally have an
>> --enforce-suiteB flag/checkbox
>>
>>
>> thoughts people?
>
>
> these complexities will roll forward in history :( ...
>
>
> 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 m3EIQcVU018651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:26:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EIQcGB018650; Mon, 14 Apr 2008 11:26:38 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3EIQaBj018643 for <[e-mail]>; Mon, 14 Apr 2008 11:26:37 -0700 (MST) (envelope-from [e-mail])
Received: by ug-out-1314.google.com with SMTP id z38so517558ugc.16 for <[e-mail]>; Mon, 14 Apr 2008 11:26:35 -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=vCE5e+rl0EdUKQNjWavXirUjka03sXGsFzCWrA/OhRM=; b=UP7R7wuo5QpKOOelvCSzm4PtPAx+DxOTx8yeqnq8oM/OpxR8Uxu8UwEGbFOo4PhAW5fuNsHb4VTOr1V5mP0LYmTj5Pcn2iG86sYxYhHuLqYFefOF0djcFVF/nBnMShBFRDB4CsoVKZxuHAf3/ubeSR0daa5Om3kqoP1RtoaNazY=
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=YajjkViulTyQ2NROtlEVrR/JPO/TcetIKfKn1hwrb7JUbJe9AHncBQ1AueerP1ju4AjkxFzahMxe8dBup/tx7e9uXYISd7Ox1eYed9TYixtWKpBdwzibQUlJFwYwxz5NuwVPi4FRpgocOchYdziGmoYBtIxFVHMyCuykpLKCZAE=
Received: by 10.78.189.5 with SMTP id m5mr4848278huf.77.1208197594817; Mon, 14 Apr 2008 11:26:34 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Mon, 14 Apr 2008 11:26:34 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 19:26:34 +0100
From: "David Crick" <[e-mail]>
To: "Andrey Jivsov" <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  However, I do see the benefit of a feature. If it were to make into the
> document I suggest to make it more generic and not Suite-B specific. The
> following alternatives achieve the same what Davit proposed but are easier
> do understand:
>
>  * this key has no implicit default algorithms
>  * this key replaces 3DES implicit algorithm with AES-128

This second one (AES-128 replaces 3DES) *really* appeals to me.

It should also further appeal to resource-constrained environments,
where (therefore) not having to implement (or use) 3DES would be
a bonus.

Actually, maybe we need to add / reconsider having a section
in the ECC doc that says

"if AES-128 is not explicitly in the set of preferred algorithms, then
it is implicitly added at the end.  If neither AES-128 or 3DES are
explicitly listed, then both of them are implicitly added, with 3DES
last."

NB, this is weaker than the idea of a "strict suiteB flag" (my original
proposal), and slightly weaker than your "AES128 replaces 3DES."




>  David Crick wrote:
>
> > "11.3. Interoperability with Suite-B profile" currently states:
> >
> >   "If TripleDES is the only shared algorithms for a set
> >   of recipients, no Suite-B compliant recipient can be added to the
> >   mentioned recipient set."
> >
> > but doesn't state how this may be enforced by the *recipient*
> > (who may not currently have a way of specifying this to the
> > sender).
> >
> > I therefore have a suggestion:
> >
> > implement a key-packet preference flag that says "strict SuiteB"
> >
> > If this is set, then applications MUST NOT use any other cipher
> > other than one of the allowed AES sizes for that ECC key size.
> >
> > This will allow us to disallow 3DES (and any other non-AES cipher)
> > by setting this key flag.
> >
> >
> > Independent of this, an application may additionally have an
> > --enforce-suiteB flag/checkbox
> >
> >
> > thoughts people?
> >
> >
> > (as an aside, re my "editorial [readability] changes," I might be
> > able to sit down and have a go at them on Monday or Tuesday.)
> >
>
>
>



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 m3EIEWPU017749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:14:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3EIEWOB017748; Mon, 14 Apr 2008 11:14:32 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3EIEPWu017713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Mon, 14 Apr 2008 11:14:31 -0700 (MST) (envelope-from [e-mail])
Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m3EIELBS004909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Apr 2008 11:14:22 -0700
Message-ID: <[e-mail]>
Date: Mon, 14 Apr 2008 11:14:16 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: [e-mail]
CC: David Crick <[e-mail]>
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

You are saying there there is no way to remove 3DES from the set of
algorithm preferences, since it is implicitly there per RFC 4880.

If a key has {AES-128, AES-256} as a preference list, right now it is
effectively {AES-128, AES-256, 3DES}.

And I think it follows that the only logical intended action that your 
proposal seeks is to break the transmission if one of recipients is an 
ECC key that disallows 3DES, *if* 3DES is the only shared algorithm for 
the given set of recipients per RFC 4880.

It is possible to keep this feature limited to the mode of operation of 
the software (a command line option --cipher-algo, UI element, etc), 
v.s. making it depend on the attribute of a key.

This assumes that both sides "agree" to use the Suite-B profile. This is 
usually the case. Many other criteria must be met in order to be in 
highly regulated Suite-B profile, especially for Top Secret or 
classified category. These additional requirements include the type of 
authentication to local keys (which AFAIK must be hardware protected 
path authentication).


However, I do see the benefit of a feature. If it were to make into the 
document I suggest to make it more generic and not Suite-B specific. The 
following alternatives achieve the same what Davit proposed but are 
easier do understand:

* this key has no implicit default algorithms
* this key replaces 3DES implicit algorithm with AES-128


David Crick wrote:
> "11.3. Interoperability with Suite-B profile" currently states:
> 
>    "If TripleDES is the only shared algorithms for a set
>    of recipients, no Suite-B compliant recipient can be added to the
>    mentioned recipient set."
> 
> but doesn't state how this may be enforced by the *recipient*
> (who may not currently have a way of specifying this to the
> sender).
> 
> I therefore have a suggestion:
> 
> implement a key-packet preference flag that says "strict SuiteB"
> 
> If this is set, then applications MUST NOT use any other cipher
> other than one of the allowed AES sizes for that ECC key size.
> 
> This will allow us to disallow 3DES (and any other non-AES cipher)
> by setting this key flag.
> 
> 
> Independent of this, an application may additionally have an
> --enforce-suiteB flag/checkbox
> 
> 
> thoughts people?
> 
> 
> (as an aside, re my "editorial [readability] changes," I might be
> able to sit down and have a go at them on Monday or Tuesday.)




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 m3DAmvIk070171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 13 Apr 2008 03:48:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3DAmvF7070170; Sun, 13 Apr 2008 03:48:57 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from goten.sonance.net (goten.sonance.net [88.198.58.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3DAmP2P070141 for <[e-mail]>; Sun, 13 Apr 2008 03:48:27 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id EDED957B0B; Sun, 13 Apr 2008 12:48:21 +0200 (CEST)
Received: from goten.sonance.net ([127.0.0.1]) by localhost (goten.sonance.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyHFnmiLBIqP; Sun, 13 Apr 2008 12:48:21 +0200 (CEST)
Received: from zhukov.local (localhost.localdomain [127.0.0.1]) by goten.sonance.net (Postfix) with ESMTP id 8EE1A57AF8; Sun, 13 Apr 2008 12:48:21 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Sun, 13 Apr 2008 12:48:21 +0200
From: Ian G <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: David Crick <[e-mail]>
CC: Andrey Jivsov <[e-mail]>, [e-mail]
Subject: Re: I have a technical idea/change for the ECC draft
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Crick wrote:
> "11.3. Interoperability with Suite-B profile" currently states:
> 
>    "If TripleDES is the only shared algorithms for a set
>    of recipients, no Suite-B compliant recipient can be added to the
>    mentioned recipient set."


I had to look at all of 11.3 to try and make sense of this, 
and found that whole subsection to be hopelessly confusing. 
  Can we have a simple statement as to whether an 
OpenPGP-ECC key can be used with TripleDES or not?  Can 
messages be mixed-mode or not?

It seems to me that if an application creates and exports an 
OpenPGP-ECC key (only) then that public key cannot be used 
with TripleDES, as the document does not suggest it anywhere 
(and implies it is ruled out).  Which means there should be 
a specific claim that this ECC draft overrules the 
"guarantee" of TripleDES intersection in RFC4880.

(To me, this seems like a reasonable price to pay to get a 
good, clear result.)

Alternatively, there should be a specific claim permitting 
use of TripleDES and describing how/what.

(I should note that I do not recall the discussions of a few 
months back.  This should be a "good thing" because it 
allows me to view it as a first time reader.  My routine 
excuse is that if I can't understand it from a simple 
reading then I suspect we are putting an unnecessary burden 
on first time readers, but not many agree with that!)


> but doesn't state how this may be enforced by the *recipient*
> (who may not currently have a way of specifying this to the
> sender).


Personally, I would have said that the recipient should 
reject the message with an error.  If there is a mixed mode 
message, then the sender is in error, allowing for a 
potential attack.  We might not be able to stop the attack 
through a misbehaving client, but we should red-flag it when 
we see it.

(but I've not seen the full sense yet, I may be wrong.)

(Apps have these flags to decrypt even when there are errors 
in modes, so that's ok.)


> I therefore have a suggestion:
> 
> implement a key-packet preference flag that says "strict SuiteB"
> 
> If this is set, then applications MUST NOT use any other cipher
> other than one of the allowed AES sizes for that ECC key size.
> 
> This will allow us to disallow 3DES (and any other non-AES cipher)
> by setting this key flag.
> 
> 
> Independent of this, an application may additionally have an
> --enforce-suiteB flag/checkbox
> 
> 
> thoughts people?


these complexities will roll forward in history :( ...


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 m3CLM1ck019047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 Apr 2008 14:22:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3CLM13X019046; Sat, 12 Apr 2008 14:22:01 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3CLLs05019018 for <[e-mail]>; Sat, 12 Apr 2008 14:21:59 -0700 (MST) (envelope-from [e-mail])
Received: by fk-out-0910.google.com with SMTP id 26so1160480fkx.10 for <[e-mail]>; Sat, 12 Apr 2008 14:21: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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=1HQGiqL7FlQz00rG0nU7Eg2J1EKT0Vu2Nu1yha4V73w=; b=i4LIVgNB7edNytURIZ26rWIZxpyhOQ4loGMDSd0EBoTtnN+PbMSKqwoy3vFhQMYbU1texWKwUXXQAeW7yEPOnmx1/DSVn4g1L2EnxnEhBdT1YlQpFBy18EGAvAwYQPwARrWxnc67HrI8iCzZD5E0YdQSfrvnGrsMmn7yvJ4x6EE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=lpLaQMZbISGl0luHhI3ayV4AtdGl1ZrFUeaNvC2UR8Y7Spe/UoRQGow+XYQuIrqh5O6i/tialuNFo5MzUbL0s8wzrjUXWUtYBlS9Xx+hIwP3R4U398RxSgfvF1Hpbcdvad6L/t2y9RIWxkzVne47JQ/3a9Rs9ZqCjFDinlrabWo=
Received: by 10.78.138.6 with SMTP id l6mr3436432hud.71.1208035312933; Sat, 12 Apr 2008 14:21:52 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Sat, 12 Apr 2008 14:21:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Sat, 12 Apr 2008 22:21:52 +0100
From: "David Crick" <[e-mail]>
To: "Andrey Jivsov" <[e-mail]>
Subject: I have a technical idea/change for the ECC draft
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"11.3. Interoperability with Suite-B profile" currently states:

   "If TripleDES is the only shared algorithms for a set
   of recipients, no Suite-B compliant recipient can be added to the
   mentioned recipient set."

but doesn't state how this may be enforced by the *recipient*
(who may not currently have a way of specifying this to the
sender).

I therefore have a suggestion:

implement a key-packet preference flag that says "strict SuiteB"

If this is set, then applications MUST NOT use any other cipher
other than one of the allowed AES sizes for that ECC key size.

This will allow us to disallow 3DES (and any other non-AES cipher)
by setting this key flag.


Independent of this, an application may additionally have an
--enforce-suiteB flag/checkbox


thoughts people?


(as an aside, re my "editorial [readability] changes," I might be
able to sit down and have a go at them on Monday or Tuesday.)



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 m3BKITVd024474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 13:18:29 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BKITlK024473; Fri, 11 Apr 2008 13:18:29 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3BKIReD024449 for <[e-mail]>; Fri, 11 Apr 2008 13:18:28 -0700 (MST) (envelope-from [e-mail])
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 m3BKIQk12750 for <[e-mail]>; Fri, 11 Apr 2008 16:18:26 -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 m3BKILUp010487 for <[e-mail]>; Fri, 11 Apr 2008 16:18:21 -0400
Date: Fri, 11 Apr 2008 16:18:21 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: Whirlpool
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.17 (2007-11-01)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Fri, Apr 11, 2008 at 07:01:24PM +0100, David Crick wrote:
> 
> I've seen mention several times on this list (and others)
> of Whirlpool's apparent pending inclusion into OpenPGP,
> but have yet to see any actual drafts on here about it.
> 
> Is anyone willing to admit they are working on one? :)

I think Len was working on one.

Len, you're welcome to the XML from my Camellia draft.  With that XML,
a Whirlpool draft is pretty much cut and paste.

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 m3BJfAol021613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 12:41:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BJfAVl021612; Fri, 11 Apr 2008 12:41:10 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3BJf9A2021604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 11 Apr 2008 12:41:09 -0700 (MST) (envelope-from [e-mail])
Received: from [63.251.255.221] (63-251-255-221.pgp.com [63.251.255.221] (may be forged)) by brainhub.org (8.14.2/8.14.1) with ESMTP id m3BJep2O006982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 12:40:51 -0700
Message-ID: <[e-mail]>
Date: Fri, 11 Apr 2008 12:40:47 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: David Crick <[e-mail]>
CC: [e-mail]
Subject: Re: ECC in OpenPGP ready to be submitted to IETF
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David Crick wrote:
>>  ... or so it seems.
>>     
>
> I saw the subject and my initial thought was "whoa, seems
> a bit hasty!"
>
> Believe me, I'm all in favour of getting ECC into OpenPGP
> ASAP, but the above was my initial reaction.
>
>   
>>  I think there is rough consensus (or the lack of strong disagreement, if
>> you prefer) on the scope of the draft, how it fits into RFC 4880, and
>> expectations about interoperability arising from the use of ECC keys.
>>     
>
> If you put it that way, then I suppose it could be "ready."
>
> I do kind of feel discussions tailed off once we'd run out of
> stream - or at least, once all the arguments (er, viewpoints ;))
> had been voiced _ad nauseam_.
>
>   
>>  I plan to summit the document in a few days as an OpenPGP WG item to IETF.
>>     
>
> I take it there's still "scope" for revision/refinement after that?
>
> (I seem to recall 2440bis took an awful long time to go round
> this bit, if it's that stage you're referring to.)
>   
Yes, definitely.
>   
>>  I updated http://brainhub.googlepages.com/pgp , I hope I haven't overlooked
>> anything substantial.
>>     
>
> I diff'ed ietf-00 with your pre-9 and didn't see anything major...
>
>   
>>  Thank you.
>>     
>
> ...except this!:
>
> |   The author would like to acknowledge the help of many individuals
> |   who kindly voiced their opinions on IETF OpenPGP Working Group
> |   mailing list and, in particular the help of David Crick. [to be
> |   continued]
>
> I hope this is merely an accolade for "loudest objector"!! and
> I do hope that "[to be continued]" signifies the adding of other
> people in due course.
>   
I singled you out so far because of volume of comments originating from 
you and the degree to which they are constructive to the progress of the 
document.

There are many other people who have voiced their valuable opinions, and 
I can expect there will be others who come later. I will definitely add 
more people as the document progresses, including individuals who 
already posted their comments.
> I've still on my "to do" list the "clarity/brevity/structure" polishing
> that I said I felt could still be achieved.  If I manage to get around
> to having a stab at that, I think I'd feel more comfortable/justified
> in having my name mentioned!  But thank you for the gesture.
Yes, you briefly mentioned this work 3 weeks back. I suppose this work 
can continue once the document is an IETF draft. I would appreciate if 
you at least summarize the changes you seek.

Derek Atkins mentioned to me that once the document is an IETF draft, 
more people will see it and may provide additional feedback. It seems 
wise to me to get all the technical feedback first and only then 
transition to editorial changes. Plus, it is interesting to see how the 
issue of closed WG will play out during submission.



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 m3BI1XLL013297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 11:01:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BI1Xrr013296; Fri, 11 Apr 2008 11:01:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3BI1VkA013288 for <[e-mail]>; Fri, 11 Apr 2008 11:01:32 -0700 (MST) (envelope-from [e-mail])
Received: by ug-out-1314.google.com with SMTP id z38so1647664ugc.16 for <[e-mail]>; Fri, 11 Apr 2008 11:01: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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=5GKGFIhxMRFL3BlwmVqKRhspJDrGp7QJvDmJW437Uhg=; b=IVUAWLhEWUpxrPS3E80uw4LpGfTgbbt+9uzE0bwLkyEiDs3hI3VqcmbqbajvklW1QrfC/AzEU8xHJlKsL0pIq/nTUNI6Ayr4RjywBtWVun7GQu/KoD0yZl4xSe0R2o5S6CWtK+5YG89eAo7+vNwGSEWzb4WsA8usLV0zDaHMiVU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=wV1QABna3bF1avpYZIhDathtrUdObxFlTWZeKghx6UABgpmRmpb7sHJhEhdpRZnOulAWL9NylTlUTHLmub3Npl+WMV9y9J+AtUP5SgxUdVu56SouH7lNh5qhJxJY1W0tPkKQi6thm9jiwc8GaXmeLX6006PFd4+SUWBHxOHw3YA=
Received: by 10.78.146.11 with SMTP id t11mr2867453hud.70.1207936885054; Fri, 11 Apr 2008 11:01:25 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Fri, 11 Apr 2008 11:01:24 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 11 Apr 2008 19:01:24 +0100
From: "David Crick" <[e-mail]>
To: [e-mail]
Subject: Whirlpool
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I've seen mention several times on this list (and others)
of Whirlpool's apparent pending inclusion into OpenPGP,
but have yet to see any actual drafts on here about it.

Is anyone willing to admit they are working on one? :)



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 m3BH1hbi007702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 10:01:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BH1hKB007701; Fri, 11 Apr 2008 10:01:43 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3BH1Uih007654 for <[e-mail]>; Fri, 11 Apr 2008 10:01:41 -0700 (MST) (envelope-from [e-mail])
Received: by nf-out-0910.google.com with SMTP id g16so218876nfd.24 for <[e-mail]>; Fri, 11 Apr 2008 10:01: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=oHV2hvyBxCofzd+r3yPzvmudiIUjTx2CyDp3wvw4Lzk=; b=r5876GtHFoWm+sMbzJStwVlxnGUUtM0CI1jlZtHj+mKu3C/xGOEHCd0AgA+HZWlrXokeV2BCnzlQPDPZcIh7peuGNphOgBPXXV3H3Q+QB6wrmXxDJqu1Y+S/JfOJIzKKOZpx07FYxkQON2Oimvk0B+1pYWdis7KTi/8h54ZpkKw=
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=XtfooNoPKthmELmsU+8Jh336J7jvG1hoo5XN+p7WaI/qbRoWBDNFhlwD43ExBMqqtfMm7dNKQVUc3h4eRbQ7INkxweYNaT+eCx/Y1WYlagVfczwoxzBtlOtDent/FK5NYpItHM8kXIcnmf9KuPyrCqFK6VAbsZIZ38EWW0vOF90=
Received: by 10.78.51.9 with SMTP id y9mr2825378huy.58.1207933285111; Fri, 11 Apr 2008 10:01:25 -0700 (PDT)
Received: by 10.78.46.2 with HTTP; Fri, 11 Apr 2008 10:01:25 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 11 Apr 2008 18:01:25 +0100
From: "David Crick" <[e-mail]>
To: "Andrey Jivsov" <[e-mail]>
Subject: Re: ECC in OpenPGP ready to be submitted to IETF
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

>  ... or so it seems.

I saw the subject and my initial thought was "whoa, seems
a bit hasty!"

Believe me, I'm all in favour of getting ECC into OpenPGP
ASAP, but the above was my initial reaction.

>  I think there is rough consensus (or the lack of strong disagreement, if
> you prefer) on the scope of the draft, how it fits into RFC 4880, and
> expectations about interoperability arising from the use of ECC keys.

If you put it that way, then I suppose it could be "ready."

I do kind of feel discussions tailed off once we'd run out of
stream - or at least, once all the arguments (er, viewpoints ;))
had been voiced _ad nauseam_.

>  I plan to summit the document in a few days as an OpenPGP WG item to IETF.

I take it there's still "scope" for revision/refinement after that?

(I seem to recall 2440bis took an awful long time to go round
this bit, if it's that stage you're referring to.)

>  I updated http://brainhub.googlepages.com/pgp , I hope I haven't overlooked
> anything substantial.

I diff'ed ietf-00 with your pre-9 and didn't see anything major...

>  Thank you.

...except this!:

|   The author would like to acknowledge the help of many individuals
|   who kindly voiced their opinions on IETF OpenPGP Working Group
|   mailing list and, in particular the help of David Crick. [to be
|   continued]

I hope this is merely an accolade for "loudest objector"!! and
I do hope that "[to be continued]" signifies the adding of other
people in due course.

I've still on my "to do" list the "clarity/brevity/structure" polishing
that I said I felt could still be achieved.  If I manage to get around
to having a stab at that, I think I'd feel more comfortable/justified
in having my name mentioned!  But thank you for the gesture.



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 m3BAH2x8067933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Apr 2008 03:17:02 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m3BAH2B5067932; Fri, 11 Apr 2008 03:17:02 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] 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 m3BAH0Ll067920 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for <[e-mail]>; Fri, 11 Apr 2008 03:17:02 -0700 (MST) (envelope-from [e-mail])
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 m3BBLIjX004428 for <[e-mail]>; Fri, 11 Apr 2008 07:21:19 -0400
Message-ID: <[e-mail]>
Date: Fri, 11 Apr 2008 03:16:58 -0700
From: Andrey Jivsov <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: [e-mail]
Subject: ECC in OpenPGP ready to be submitted to IETF
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

... or so it seems.

I think there is rough consensus (or the lack of strong disagreement, if 
you prefer) on the scope of the draft, how it fits into RFC 4880, and 
expectations about interoperability arising from the use of ECC keys.

I plan to summit the document in a few days as an OpenPGP WG item to IETF.

I updated http://brainhub.googlepages.com/pgp , I hope I haven't 
overlooked anything substantial.

Thank you.



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 m31MKPSM088996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Apr 2008 15:20:25 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m31MKP10088995; Tue, 1 Apr 2008 15:20:25 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from yxa.extundo.com (yxa.extundo.com [83.241.177.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m31MKEb4088984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Tue, 1 Apr 2008 15:20:16 -0700 (MST) (envelope-from [e-mail])
Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m31MK7eZ006816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Apr 2008 00:20:07 +0200
From: Simon Josefsson <[e-mail]>
To: Derek Atkins <[e-mail]>
Cc: [e-mail]
Subject: OpenPGP mail/news header draft updated
In-Reply-To: <[e-mail]> (Derek Atkins's message of "Tue, 11 Mar 2008 10:01:47 -0400")
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:080401:[e-mail]::nhAeOfxyiOtR8A4V:4fhm
X-Hashcash: 1:22:080401:[e-mail]::rNQ9rnhLrk1izVob:QVpv
Date: Wed, 02 Apr 2008 00:20:07 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled  version=3.1.7
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on yxa-iv
X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com
X-Virus-Status: Clean
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi all!

I have updated the draft about OpenPGP: mail header, see:

http://www.ietf.org/internet-drafts/draft-josefsson-openpgp-mailnews-header-04.txt
http://josefsson.org/openpgp-header/

I have improved the ABNF which was the remaining open issue.

I believe the document is now ready for moving forward, so I'll approach
an AD about that.  Or is there any point in moving this forward via the
OpenPGP WG?

Comments on the document are still welcome, of course.

Thanks,
/Simon

Derek Atkins <[e-mail]> writes:

> Simon Josefsson <[e-mail]> writes:
>
>> I'm curious whether we can get the OpenPGP header document published
>> without a WG or not.  A few MUAs parses the header (Gnus, enigmail,
>> squirrelmail, if I understand correctly).
>
> I don't see why not.  I don't think it would be very contentious.
>
>> /Simon
>
> -derek
>
> -- 
>        Derek Atkins                 617-623-3745
>        [e-mail]             www.ihtfp.com
>        Computer and Internet Security Consultant