Re: SHA-xxx OIDs

[[e-mail] (Bodo Moeller)]

Jon Callas <[e-mail]>:

> Does someone want to volunteer to double-check the OIDs I have in bis-03
> for wide SHA?
> 
> [e-mail] claimed to have found them in an IEEE P1363a draft D7.9.
> 
> Does anyone have validation that they exist, or know where to look? The URL
> given for that draft is password-protected, [...]

Just subscribe to one of the P1363 mailing lists (message
"subscribe stds-p1363" and/or "subscribe stds-p1363-discuss" to
[e-mail]) and you will immediately receive the password.
That password "protection" is just a silly IEEE requirement.



Received: by above.proper.com (8.11.6/8.11.3) id f8B9Zub25981 for ietf-openpgp-bks; Tue, 11 Sep 2001 02:35:56 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8B9ZsD25977 for <[e-mail]>; Tue, 11 Sep 2001 02:35:55 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id A07282C93; Tue, 11 Sep 2001 11:03:04 +0200 (MET DST)
Received: id <m15gjKD-000Qe5C@epsilon>; Tue, 11 Sep 2001 10:55:21 +0200 (CEST) 
Message-Id: <m15gjKD-000Qe5C@epsilon>
Date: Tue, 11 Sep 2001 10:55:21 +0200 (CEST)
From: [e-mail] (Bodo Moeller)
To: [e-mail]
Cc: Jon Callas <[e-mail]>
Subject: Re: SHA-xxx OIDs
In-Reply-To: <p05100318b7bb28e4ba91@[192.168.1.180]>
References: <p05100318b7bb28e4ba91@[192.168.1.180]>
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]>:

> Does someone want to volunteer to double-check the OIDs I have in bis-03
> for wide SHA?
> 
> [e-mail] claimed to have found them in an IEEE P1363a draft D7.9.
> 
> Does anyone have validation that they exist, or know where to look? The URL
> given for that draft is password-protected, [...]

Just subscribe to one of the P1363 mailing lists (message
"subscribe stds-p1363" and/or "subscribe stds-p1363-discuss" to
[e-mail]) and you will immediately receive the password.
That password "protection" is just a silly IEEE requirement.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8AJrWH05539 for ietf-openpgp-bks; Mon, 10 Sep 2001 12:53:32 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AJrUD05534 for <[e-mail]>; Mon, 10 Sep 2001 12:53:31 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 6F1712C93; Mon, 10 Sep 2001 21:53:31 +0200 (MET DST)
Received: id <m15gX4b-000Qe5C@epsilon>; Mon, 10 Sep 2001 21:50:25 +0200 (CEST) 
Message-Id: <m15gX4b-000Qe5C@epsilon>
Date: Mon, 10 Sep 2001 21:50:25 +0200 (CEST)
From: [e-mail] (Bodo Moeller)
To: [e-mail]
Reply-To: [e-mail] (Bodo Moeller)
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Comments on ECC draft
In-Reply-To: <[e-mail]>
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>

[e-mail]>:

[...]
> We suggest the initial draft use only prime fields, descriptor 3,
> and trinomial/pentanomial binary fields, descriptors 11 and 12. These
> three are enough to cover all the NIST curves.  They seem to provide
> the advantages which we seek from ECC without multiplying the options
> excessively.
> 
> If the group does want to pursue additional field types, we would like
> to see some rationale for the use of prime extension field types 4-9. Our
> concern with the special primes 1-2 is that this area seems to be covered
> by patents.

[Field decriptors 1 and 2 are for pseudo-Mersenne prime fields.]

What patents?  These should be patents applied for by the NSA (the
optimizations for pseudo-Mersenne primes are due to Jerry Solinas).
I'm not sure how they'd handle licensing -- the patents for Jerry's
algorithms for Koblitz curves have already been issued earlier this
year, and presumably licensing would be similar to that, whatever this
means.  (Hopefully no restrictions, as for DSA, which is also
patented.)

(Note that the FIPS recommended curves over prime fields all are based
on pseudo-Mersenne primes.  Of course applications that want to use
optimized modular arithmetic for these primes can do so, whether or
not special field descriptors are used.)


>              And descriptors 14-16 are for normal bases, where we see
> two problems.  First, they cannot be efficiently implemented in software;
> and second, we do not think it is possible to convert from a normal basis
> into a polynomial basis representation without additional information
> regarding the specific normal basis chosen.  Hence using normal bases
> as an interchange format is not a good choice.  So we would like to see
> more discussion of that aspect if the group wishes to pursue it.

Also, this is an area where patents really appear to be a severe issue.


> (One organizational point: section 4.4 actually describes custom curves,
> and we would prefer to see the draft focus on predefined curves.  We have
> ideas on how to reorganize the draft to define specific coordinate
> fields and curves based on them, which we are getting into shape to
> present shortly.)

The draft obviously intends to provide a lot of flexibility, while in
the sake of efficiency and interoperability it would be better to
sacrifice flexibility and limit the class of allowed curves.


Received: by above.proper.com (8.11.6/8.11.3) id f8AJOdm04885 for ietf-openpgp-bks; Mon, 10 Sep 2001 12:24:39 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8AJOcD04880 for <[e-mail]>; Mon, 10 Sep 2001 12:24:38 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 301CE2C93; Mon, 10 Sep 2001 21:24:39 +0200 (MET DST)
Received: id <m15gWcw-000Qe5C@epsilon>; Mon, 10 Sep 2001 21:21:50 +0200 (CEST) 
Message-Id: <m15gWcw-000Qe5C@epsilon>
Date: Mon, 10 Sep 2001 21:21:50 +0200 (CEST)
From: [e-mail] (Bodo Moeller)
Reply-To: [e-mail] (Bodo Moeller)
To: [e-mail]
Cc: Jon Callas <[e-mail]>, "vedaal" <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
In-Reply-To: <p0510030eb7bb0795e734@[192.168.1.180]>
References: <[e-mail]> <p0510030eb7bb0795e734@[192.168.1.180]>
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]>:

[...]
> ECC does *not* affect the speed of large file encryption. Actually, it's
> the opposite; it matters most for *small* files.

You cannot expect elliptic curve based encryption to be faster than
RSA encryption.  Signing and decryption may be faster than for RSA or
DSA/ElGamal (but not necessarily when the platform is a PC or
workstations and if the modular exponentiation implementation is
reasonably well optimized), but it is hard to beat RSA public key
operations with small exponents.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f88LdHL29577 for ietf-openpgp-bks; Sat, 8 Sep 2001 14:39:17 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f88LdDD29573 for <[e-mail]>; Sat, 8 Sep 2001 14:39:14 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15fqkC-0000h9-00; Sun, 09 Sep 2001 00:38:32 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15ff0v-0005LB-00; Sat, 08 Sep 2001 12:07:01 +0200
To: "Michael Young" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Identifying revoked certificates
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]> <[e-mail]> <p0510032fb7bd98d93fcc@[192.168.1.180]> <[e-mail]> <009e01c137e3$f3c40be0$[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 08 Sep 2001 12:07:01 +0200
In-Reply-To: <009e01c137e3$f3c40be0$[e-mail]> ("Michael Young"'s message of "Fri, 7 Sep 2001 17:27:52 -0400")
Message-ID: <[e-mail]>
Lines: 23
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.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 Fri, 7 Sep 2001 17:27:52 -0400, Michael Young said:

>     different types (generic, persona, etc.), possibly with
>      a specific lifetime associated with each;

Better use a different key.

>     different notation data;

>     different trust for separate domains ("regular expressions").

If you can do a new signatue, you can put the old notation data in as
well. 

> Do you not believe in any of these uses?

Partly.


-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: by above.proper.com (8.11.6/8.11.3) id f87M8di23426 for ietf-openpgp-bks; Fri, 7 Sep 2001 15:08:39 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87M8bD23422 for <[e-mail]>; Fri, 7 Sep 2001 15:08:37 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id SAA15520 for <[e-mail]>; Fri, 7 Sep 2001 18:00:43 -0400 (EDT)
Received: from mwyoung (dhcp-194-28.transarc.ibm.com [9.38.194.228]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id SAA09339 for <[e-mail]>; Fri, 7 Sep 2001 18:08:33 -0400 (EDT)
Message-ID: <00ae01c137e9$24037ac0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Identifying revoked certificates
Date: Fri, 7 Sep 2001 18:05:01 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

<[e-mail]> wrote:
> do not forget that sigs can be revoked not only by the *same creator*,
> but also by *designated revoker*.
> (AFAIK currently no PGP implementation supports designated revokers for
> userid signatures, but it is allowed in 5.2.1. 0x30)

I couldn't believe this, so I had to reread the spec, and indeed
that's what it says.  Is it really intended that a designated revoker
should be able to revoke other *certifications* (not just the key)?

[Arguably, a revoker subpacket in a certification would permit that.
We're talking about a revoker subpacket in the key self-signature here.]

Indeed, PGP6.5 does not support this.  It provides no way to generate
one, and even if it receives such a certificate revocation, it
applies only to the issuer (not keys for which it is designated).
[In fact, it isn't applied to subsequent signatures by the issuer,
suggesting that either: it is caching the validity computation
(but asking for reverification doesn't help), or it is applying
a "most recent prevails" rule.]

> btw currently there is not possible to know what is
> revoked by designated revoker - keys self signature or
...

Indeed, this is why this is a bad idea.  I feel strongly that
a "designated revoker" subpacket should apply to only that
certificate.  Usually that's a key-only self-signature,
and a revocation on that would affect *any* other signatures
made by that key.

> 11.1. says that key and subkey revocation is *before* signatures.
> why make it different for userid revocation?

Fair point... "immediately preceding" would be more consistent.
But I am willing to give up on this.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5lEgmNDnIII+QUHAQFXbQf+Ktb06chrGiXgI3c7djOQWeNcd8Hw9D5B
qWGwHllrc03k8kaR3onkm1t6HYhLZqSbSLBspJWcNwBxHl+nmb8uIWSnOlBqukjO
ZpMrs4eZGt7sRTFGMiYu/F+O8EezlOleOpVzGzjqJdGMC/tgenB0Avp0c6ZLYF3A
7o3WjkQ9bTmnBe+PXIehtFROVyKyYpyrQrVk9jdmiM0fhUhzekQ1w0wJGyTmppeh
EX5BOKSkLcRYq6pKJtvlIVbT8liVWfJh9MWBaQBWBs4YJj/3DmoDcZzLqh0Dbsha
/ijzKO9tzPsfM8phAH5NRL2yTjUN4a9fXdhG1JnZOxMYN+Upt/fD+g==
=NFrt
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f87LVTT22795 for ietf-openpgp-bks; Fri, 7 Sep 2001 14:31:29 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f87LVMD22791 for <[e-mail]>; Fri, 7 Sep 2001 14:31:27 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id RAA76726 for <[e-mail]>; Fri, 7 Sep 2001 17:23:17 -0400 (EDT)
Received: from mwyoung (dhcp-194-28.transarc.ibm.com [9.38.194.228]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA09210 for <[e-mail]>; Fri, 7 Sep 2001 17:31:07 -0400 (EDT)
Message-ID: <009e01c137e3$f3c40be0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]><010901c135ad$a7233000$[e-mail]><p05100325b7bd794fd6a4@[192.168.1.180]><[e-mail]><p0510032fb7bd98d93fcc@[192.168.1.180]> <[e-mail]>
Subject: Re: Identifying revoked certificates
Date: Fri, 7 Sep 2001 17:27:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

"Werner Koch" <[e-mail]> wrote:
> I don't see a reason for the revocation target specifiers.  The only
> sound handling of self-signature revocations (and that's what we are
> talking about) is to use the latest valid self-signature, be it a

If "most recent prevails" is the only sound handling, and you
want senders to depend on that, then the specification should say so.
There was some resistance to this, though.

Are multiple certifications illegal?  (If so, the spec should
recommend against doing so.)  I can see a couple of reasons
that I might want to sign the same key/name pair multiple
times:
    different types (generic, persona, etc.), possibly with
     a specific lifetime associated with each;

    different notation data;

    different trust for separate domains ("regular expressions").

Do you not believe in any of these uses?

>   * Sequence of packets messed up. 

As it stands, the ordering section doesn't say where to put
self-signatures, and it doesn't specify ordering for certificate
revocations, so there is no way for things to be "messed up" within a
given context.  [If a revocation is in the wrong context (e.g., for
userId "joe" instead of userId "bob"), then reordering is not
particularly easy.]  Jon Callas objected to adding an ordering
suggestion.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5k71mNDnIII+QUHAQG0IQgAkbnCL9CAiO3+j0NlptEBCBn48YGyC82K
UCqj2v/1dPEhGB+sitCEb8pvWJ4lc37YDW81krBbkhIhHCOBWOxM59vIFSGiejMA
f76TwDlmE7eXYOhTpePZROm3/ABsMjslX2nLCAKq1g2N4DUuFmrS11pVMySN950f
bAoDAkP9K0tR78QljbxOQLP73hT5NfLcZHLH8mmNa6NPRd9GHY/Df5Jg9e5/aJ35
f3HBi+s/60caB7PflpXDBT9uFJKSzWlXlmjzCxG3b9exHPYpLF9h4rjxkwwy4Hrj
NR2EIftGlenCSnZ4kNkcG+AAb5m38IfE6Av4Wswgf7sDt4e6fYYPHA==
=85f5
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f878BQH12874 for ietf-openpgp-bks; Fri, 7 Sep 2001 01:11:26 -0700 (PDT)
Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id f878BKD12861 for <[e-mail]>; Fri, 7 Sep 2001 01:11:22 -0700 (PDT)
Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id <B0000084124@127.0.0.1>; Fri, 07 Sep 2001 09:01:01 +0200
Message-ID: <[e-mail]>
Date: Fri, 07 Sep 2001 10:01:01 +0200
From: [e-mail]
Organization: .NO.SPaM.NET
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Identifying revoked certificates
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: RIPEMD160

> On Thu, Sep 06, 2001 at 12:06:49PM -0700, Jon Callas wrote:
> > Is it worth adding the timestamp from the original signature to help
> > find it without having to look at the (larger) hashes?  On a uid with
> > many signatures, this could speed things up.  Once found, of course,
> > the hash could then be checked for confirmation.
> 
> I don't mind having the timestamp there, but I don't feel a need for
> it, either.  While I feel a need for this subpacket, at the same time,
> I expect this situation to be rare, and there are other ways to
> control the cost:
> 
>   Note that this disambiguation is necessary only for signatures within
>   the same context (key, key/user, key/subkey) and made by the *same
>   creator*.

do not forget that sigs can be revoked not only by the *same creator*,
but also by *designated revoker*.
(AFAIK currently no PGP implementation supports designated revokers for
userid signatures, but it is allowed in 5.2.1. 0x30)

btw currently there is not possible to know what is
revoked by designated revoker - keys self signature or
revokers signature if there is one.
for example:
key A have signed by A (self sig) and B,
in self sig B is specified as designated revoker.
now if B revokes his signature, but currently it looks exactly like
he have revoked A's self signature.


>   Although the current packet ordering rules don't address certificate
>   revocation, I'd suggest that a prudent ordering would put each after
>   its target.

11.1. says that key and subkey revocation is *before* signatures.
why make it different for userid revocation?


== <EOF> ==
Disastry
http://i.am/disastry/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.14 by Disastry / PGPsdk v1.7.1

iQA/AwUBO5hiZjBaTVEuJQxkEQM2ywCcDUR8Ru7Zj12mHGGyZH7Kcdi8XqUAmwVx
SyqrvY8wYoDZOyiyFItJ+RZT
=2jSN
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f8768NR26001 for ietf-openpgp-bks; Thu, 6 Sep 2001 23:08:23 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f8768LD25990 for <[e-mail]>; Thu, 6 Sep 2001 23:08:21 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15fFjZ-0005xk-00; Fri, 07 Sep 2001 09:07:25 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15fEtW-0001Yy-00; Fri, 07 Sep 2001 08:13:38 +0200
To: [e-mail]
Subject: Re: Identifying revoked certificates
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]> <[e-mail]> <p0510032fb7bd98d93fcc@[192.168.1.180]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 07 Sep 2001 08:13:38 +0200
In-Reply-To: <p0510032fb7bd98d93fcc@[192.168.1.180]> (Jon Callas's message of "Thu, 6 Sep 2001 14:33:10 -0700")
Message-ID: <[e-mail]>
Lines: 37
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.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 Thu, 6 Sep 2001 14:33:10 -0700, Jon Callas said:

> Now then, a question for implementors: If this gets put in, would you
> implement it? "Yes, but not right away" is a fine answer, as are "Yes" and

No. 

I don't see a reason for the revocation target specifiers.  The only
sound handling of self-signature revocations (and that's what we are
talking about) is to use the latest valid self-signature, be it a
revocation or a real self-signature.  All other ways makes the
protocol more complex and ambiguous and is error prone.  Checking the
timestamps of valid revocations and self-signatures is sufficient in
about all cases.  There are only 2 problems I can identify with this:

  * 2 signatures done in the same second. 

Solution:  Don't do this and if you receive one, choose one of them
by whatever means.

  * Sequence of packets messed up. 

This should not happen, but if it does there is the same chance that
the UIDs or subkeys and their self-signatures are out of order and so
one would need to specify the UID in the self-signature.  Solution:
Either drop these packets because they don't comply to OpenPGP or
reorder them which might take a couple milliseconds.  From experience
I know that the reordering is only rarely needed and in most cases due
to buggy keyserver implementations.
  

  Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f872sVv20829 for ietf-openpgp-bks; Thu, 6 Sep 2001 19:54:31 -0700 (PDT)
Received: from smtprelay2.adelphia.net (smtprelay2.adelphia.net [64.8.25.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f872sJD20825 for <[e-mail]>; Thu, 6 Sep 2001 19:54:30 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GJ9UR303.33D for <[e-mail]>; Thu, 6 Sep 2001 22:54:39 -0400 
Message-ID: <001f01c13748$0f79d460$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]> <[e-mail]> <002301c13717$dd93a1e0$[e-mail]> <p05100330b7bd9c51106e@[192.168.1.180]>
Subject: Re: Identifying revoked certificates
Date: Thu, 6 Sep 2001 22:51:48 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Jon Callas" <[e-mail]>
> >  that they use order of arrival.  [Just the same, would anyone object
> >  to suggesting this ordering in section 10?]
> 
> Yes. A change to the standard that requires all the implementations to
> change is not desirable. I don't see what good it does for them other than,
> "You'll thank me for this later." Telling them how to write their programs
> adds complexity, and complexity lessens security.

I didn't intend to *require* any ordering, only to *suggest* one,
and only for interchange.

Your principle would argue for eliminating all of the ordering rules.
Why should userIDs precede subkeys?  (For that matter, why should
signatures have to follow the key/userid/subkey to which they
refer -- an implementation *could* always try them all :-).  Ordering
helps receivers match things up.

All that said, I'll retract my suggestion.  It was just a hint,
but as we both noted, matching using the hash is pretty
straightforward, and is dwarfed by the PK verification
anyway.  Sorry for the excursion.


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5g2I2NDnIII+QUHAQGAqgf/dfM0TXVzTwnsJCxl7GbPjS3sHHuPl6uC
0otpvdx/2oqfEMswhzay8xmt1aA+VJL7fflJctG3pRDxFFv4cacg+UqKoaZdWfqv
cZZC7TiFZa4mdCYGCx9AzwvP05zTw7Sa7QMlAqLrxGHTtfcO2DLi/JguowGyfO8A
Pjzmd6jUGGLGdlIPcJ7qInAx3EcmFOHc08xJ2r3tFyQG5Ke9Z5SWsSHMgiIzSJ8E
PaAKmcuP+Kh2Szf2GRqfzFbrXU/A/bP6FC1bnGEIHrD3FcNajJ5SUbbNPyKutUdJ
dq6YMRHoToqSFcRUJHWjbOWQKDMZZ+6gct61w4ATuNONCi/QBRfoVw==
=3O2g
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86Lj0315527 for ietf-openpgp-bks; Thu, 6 Sep 2001 14:45:00 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86LixD15523 for <[e-mail]>; Thu, 6 Sep 2001 14:44:59 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 6 Sep 2001 14:44:57 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100330b7bd9c51106e@[192.168.1.180]>
In-Reply-To: <002301c13717$dd93a1e0$[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]> <[e-mail]> <002301c13717$dd93a1e0$[e-mail]>
Date: Thu, 6 Sep 2001 14:38:46 -0700
To: "Michael Young" <[e-mail]>, <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Identifying revoked certificates
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>

At 5:06 PM -0400 9/6/01, Michael Young wrote:

>  Although the current packet ordering rules don't address certificate
>  revocation, I'd suggest that a prudent ordering would put each after
>  its target.  This would an even stronger hint.  I note that neither
>  PGP6.5 nor GnuPG produces this ordering.  At first glance, it appears
>  that they use order of arrival.  [Just the same, would anyone object
>  to suggesting this ordering in section 10?]
>

Yes. A change to the standard that requires all the implementations to
change is not desirable. I don't see what good it does for them other than,
"You'll thank me for this later." Telling them how to write their programs
adds complexity, and complexity lessens security.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86LYv815362 for ietf-openpgp-bks; Thu, 6 Sep 2001 14:34:57 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86LYtD15358 for <[e-mail]>; Thu, 6 Sep 2001 14:34:55 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 6 Sep 2001 14:34:54 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510032fb7bd98d93fcc@[192.168.1.180]>
In-Reply-To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]> <[e-mail]>
Date: Thu, 6 Sep 2001 14:33:10 -0700
To: David Shaw <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Identifying revoked certificates
Cc: Michael Young <[e-mail]>, [e-mail]
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>

At 3:46 PM -0400 9/6/01, David Shaw wrote:

>Is it worth adding the timestamp from the original signature to help
>find it without having to look at the (larger) hashes?  On a uid with
>many signatures, this could speed things up.  Once found, of course,
>the hash could then be checked for confirmation.
>

My comments:

* The amount of time need to compare bytes is negligible compared to the
time needed to compare signatures. Byte compares are in the nanosecond to
microsecond range, and doing a signature check is in milliseconds. In
microsecond-land, a millisecond is a coffee break. In nanosecond-land, a
millisecond is an American (but not European) vacation.

* It's actually more likely to slow things down. Remember that hashes are
completely uncorrelated. So the first time I compare a byte, there's a
1/256 chance that they match, yet this is not the hash I'm looking for. For
ones that match the first byte, there's a 1/256 chance of a collision on
the second byte, and so on. In an optimal implementation that compares
bus-width quantities, (like 32, 64, or 128 bits), I'll almost never have a
collision beyond the first compare. Adding in the timestamp just gives me
more things to compare, things it is easier to have collisions on, and
therefore slows the process down.

* Having said all that, there's no good reason *not* to put the timestamp
in. The whole reason for having this is as a disambiguator, and why have a
disambiguator that isn't pretty darned specific, eh?


Now then, a question for implementors: If this gets put in, would you
implement it? "Yes, but not right away" is a fine answer, as are "Yes" and
"No."

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86L99n14476 for ietf-openpgp-bks; Thu, 6 Sep 2001 14:09:09 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86L97D14472 for <[e-mail]>; Thu, 6 Sep 2001 14:09:07 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id RAA14616 for <[e-mail]>; Thu, 6 Sep 2001 17:01:12 -0400 (EDT)
Received: from mwyoung (dhcp-194-28.transarc.ibm.com [9.38.194.228]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA02699 for <[e-mail]>; Thu, 6 Sep 2001 17:09:03 -0400 (EDT)
Message-ID: <002301c13717$dd93a1e0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]> <[e-mail]>
Subject: Re: Identifying revoked certificates
Date: Thu, 6 Sep 2001 17:06:48 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

On Thu, Sep 06, 2001 at 12:06:49PM -0700, Jon Callas wrote:
> A signature subpacket called "revocation target" that contains a 1-octet
> PKalg, a 1-octet hash algorithm, and then a hash body. It denotes that a
> revocation signature is intended to revoke the signature so specified.

Sounds good.  I didn't have the PK algorithm in my original proposal.
I don't feel a need for it, but I don't mind having it there, either.

From: "David Shaw" <[e-mail]>
> Is it worth adding the timestamp from the original signature to help
> find it without having to look at the (larger) hashes?  On a uid with
> many signatures, this could speed things up.  Once found, of course,
> the hash could then be checked for confirmation.

I don't mind having the timestamp there, but I don't feel a need for
it, either.  While I feel a need for this subpacket, at the same time,
I expect this situation to be rare, and there are other ways to
control the cost:

  Note that this disambiguation is necessary only for signatures within
  the same context (key, key/user, key/subkey) and made by the *same
  creator*.

  Although the current packet ordering rules don't address certificate
  revocation, I'd suggest that a prudent ordering would put each after
  its target.  This would an even stronger hint.  I note that neither
  PGP6.5 nor GnuPG produces this ordering.  At first glance, it appears
  that they use order of arrival.  [Just the same, would anyone object
  to suggesting this ordering in section 10?]

  I expect many implementations will cache certificate verifications and
  revocation results upon receipt/incorporation, rather than doing them
  every time.

  An implementation that doesn't cache will have to compute the hash
  before using the PK algorithm to verify the original anyway.  Since
  the PK verification is (relatively) expensive, it makes sense to look
  for any revocations first.  A failing 20ish-byte hash match won't take
  longer than an (unaligned big-endian) 4-byte time match (and may fall
  out sooner); a successful match would require the 20ish-byte test anyway.
  If there's a match, the revocation certificate gets tested instead
  (and, assuming it verifies, the original verification can be skipped).

But as I said up front, I don't object strongly to having it.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5flQGNDnIII+QUHAQGuMwf9EIRKx/gEJ5PV2hySzvBJV/2nrGie3ZQN
oNpbE0Gze/rgOZEHjviajeOTcKrCnzNk4JMeiWYT2FiWsNwXHKj/Qkbnifsl8f17
aJ6RBoUTlwjhjiiOJVFC14A0Vy3PWTBLpQ2tCJSd02D5Yvtc5L+SHOez6iwVh1/j
hKv4hQUqCJbfjBH6E5o8BncsZTR4if+zlgrm24IXymr4f83yqCxoOYC+EyhZnANn
9oEzAE7WJiKYznt/wL3THXzZRDPgefVeGH6turU+LMDS7p02gsiWrHGjKU3l/3I5
QvlFsc9KKpahtJGuaq/VymBmfxw1kX/vH2GIWb8QGwMxHXbS60YJRg==
=e/dy
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86Jlbr13033 for ietf-openpgp-bks; Thu, 6 Sep 2001 12:47:37 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86JlaD13029 for <[e-mail]>; Thu, 6 Sep 2001 12:47:36 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id PAA31464; Thu, 6 Sep 2001 15:46:24 -0400
Date: Thu, 6 Sep 2001 15:46:24 -0400
From: David Shaw <[e-mail]>
To: Jon Callas <[e-mail]>
Cc: Michael Young <[e-mail]>, [e-mail]
Subject: Re: Identifying revoked certificates
Message-ID: <[e-mail]>
Mail-Followup-To: Jon Callas <[e-mail]>, Michael Young <[e-mail]>, [e-mail]
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]> <p05100325b7bd794fd6a4@[192.168.1.180]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05100325b7bd794fd6a4@[192.168.1.180]>; from [e-mail] on Thu, Sep 06, 2001 at 12:06:49PM -0700
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waning Gibbous (88% of Full)
X-Pointless-Random-Number: 76
X-Silly-Header: It sure is.
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 Thu, Sep 06, 2001 at 12:06:49PM -0700, Jon Callas wrote:
> 
> Are there any comments on Michael's suggestion?
> 
> Here's a sketch design:
> 
> A signature subpacket called "revocation target" that contains a 1-octet
> PKalg, a 1-octet hash algorithm, and then a hash body. It denotes that a
> revocation signature is intended to revoke the signature so specified.
> 
> Comments?

Is it worth adding the timestamp from the original signature to help
find it without having to look at the (larger) hashes?  On a uid with
many signatures, this could speed things up.  Once found, of course,
the hash could then be checked for confirmation.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: by above.proper.com (8.11.6/8.11.3) id f86J6xw12087 for ietf-openpgp-bks; Thu, 6 Sep 2001 12:06:59 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86J6wD12083 for <[e-mail]>; Thu, 6 Sep 2001 12:06:58 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 6 Sep 2001 12:06:57 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100325b7bd794fd6a4@[192.168.1.180]>
In-Reply-To: <010901c135ad$a7233000$[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <010901c135ad$a7233000$[e-mail]>
Date: Thu, 6 Sep 2001 12:06:49 -0700
To: "Michael Young" <[e-mail]>, <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Identifying revoked certificates
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>

Are there any comments on Michael's suggestion?

Here's a sketch design:

A signature subpacket called "revocation target" that contains a 1-octet
PKalg, a 1-octet hash algorithm, and then a hash body. It denotes that a
revocation signature is intended to revoke the signature so specified.

Comments?

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86J5wr12067 for ietf-openpgp-bks; Thu, 6 Sep 2001 12:05:58 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86J5uD12062 for <[e-mail]>; Thu, 6 Sep 2001 12:05:57 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 6 Sep 2001 12:05:47 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100320b7bd6810c94d@[192.168.1.180]>
In-Reply-To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <[e-mail]>
Date: Thu, 6 Sep 2001 12:02:47 -0700
To: Werner Koch <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Fixing the secret keys, and a small apology
Cc: [e-mail]
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>

At 9:43 AM +0200 9/5/01, Werner Koch wrote:

>This is fine with me.
>
>Another question is the format.  Should we include only the public
>parameters or more stuff in the MDC?  A solution I would like to see
>is to just hash the fingerprint of the key along with the secret
>parameters.  I predict that in future, implementations will use the
>fingerprint to identify a key (and not just the keyID) and therefore
>it is steadily available.

As a couple people noted, I was probably too glib. The byte isn't actually
part of the S2K, it's a marker that says that an S2K follows.

I think that 254 would denote that we have an S2K and a hash. Let's not
call it an MDC, because we're going to get confused if we do. The questions
I see are:

Hash of what?

Is it inside or outside the envelope?

Where is it placed?


Are there any developers that want to come up with a design?

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f86A8B015154 for ietf-openpgp-bks; Thu, 6 Sep 2001 03:08:11 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f86A8AD15150 for <[e-mail]>; Thu, 6 Sep 2001 03:08:10 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 12:07:54 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: Comments on ECC draft
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Thu, 6 Sep 2001 12:07:53 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on ECC draft
Thread-Index: AcE2c0aNs1DEE9/xQwKDT5DCo/DqbgAQ4KuA
From: "Dominikus Scherkl" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 Sep 2001 10:07:54.0024 (UTC) FILETIME=[CB462280:01C136BB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f86A8BD15151
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-----

Hello.

> We have been looking at the ECC issue and have a few comments on the
> proposed draft by Dominikus Scherkl and Christoph Fausak.
Thank you for your comments.

> As efficiency is much of the motivation for going to EC
> technology, we should try to preserve it.
There are fields providing much better performance than even
binary fields do (see below).

> As candidates for the specific fields to use, we recommend
> the selections from NIST [fips186-2], used as ECC groups in IKE
> [draft-ietf-ipsec-ike-ecc-groups-03]. These fields are being deployed
> and are in use in some environments. They provide for efficient
> implementations.
The named curves mentioned in section 9 are exactly these (and a few
more), even using the same names. But as I heared, it's some of
these which patents are claimed for (especialy the Kobliz curves) :-(

> The last point we would like to make is about the field representation
> format (section 4.4 in the draft), where again we would propose
> to reduce the number of options in order to improve interoperability.
> 16 options is too many.
All the parameters are only nessessary for user defined curves.
And they provide an efficient storage format for the named curves,
too (but that's an implementation detail).
If we rely only on the named curves, we don't need them ever.

> If the group does want to pursue additional field types, we would like
> to see some rationale for the use of prime extension field types 4-9.
Especialy the field F(2^31-1)[x]/(x^7-7) [in my own description: D = 4,
r = 31, c = 1, m = 7, w = 7] whose elements can be represented as serven
32bit words provide extremely fast arithmetics (an arbitrary field
multiplication requires only about 6 machine multiplications - on
32bit machines of course) with over all security of 206 bit.
(binary fields of equal length requires about 1400 additions)
I'd add some courves over this field soon.

> we do not think it is possible to convert from a normal basis
> into a polynomial basis representation without additional information
That is not true. You can use an arbitrary root (which can be
calculated efficiently) to convert to some polynomial basis - but
you need to reconvert any result to the normal basis, before using it.
In Fact, this conversion also takes time, so normal bases are not
that fast, I agree.

> (One organizational point: section 4.4 actually describes custom
curves,
> and we would prefer to see the draft focus on predefined curves.

I think it's easy to leave out some parts of my draft, although it's
the better way to have covered all as to have only some parts and need
to make something completey different if we encounter patented pars. ;-)

best regards.
- -- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]

-----BEGIN PGP SIGNATURE-----
Version: Biodata SecureDesk OpenPGP CryptoEngine Version 2.1
Comment: Biodata SecureDesk - http://securedesk.biodata.com

wsBcBAEBAQAQBQI7l0r5CRArmDw6wJyywAAAtEcH/jAhv3NkJOf4+F7Q8DG6jvQR
yHfRijvIvHVXlWKR8OuIdGXnMRxI3En0az28Ydr4w3WEHL6i/LPz33BYI7mI0Igy
FiQ1bcuz+Ox9PLNhW4rx9uJ8mXzhjyDIZIrLElGfgntUKA7yrSkcm/NRdsohyb+k
fHFHHEqGMAalziiN2tBu4ltqRJifksFaWZpBF6x3YOQXIZonGshqtcCJKyqA9p7J
AXXKml0cFTUAnHCDupk7j+YEnzprsWylmpMjpUub3PVdofWXHvDHKsldKoRtcIFN
MhGSmrqDp3qAgWTtbapJ51l5yxjge7TQAaioq5TjUIY87DSlNGyq4hinbvFSYj8=
=/8KB
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f861StM11573 for ietf-openpgp-bks; Wed, 5 Sep 2001 18:28:55 -0700 (PDT)
Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id f861SrD11569 for <[e-mail]>; Wed, 5 Sep 2001 18:28:53 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id SAA02959; Wed, 5 Sep 2001 18:28:32 -0700
Date: Wed, 5 Sep 2001 18:28:32 -0700
From: [e-mail]
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Comments on ECC draft
Cc: [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>

We have been looking at the ECC issue and have a few comments on the
proposed draft by Dominikus Scherkl and Christoph Fausak.

Broadly speaking it looks very good.  Obviously a lot of care and effort
has gone into the work.  It seems to be timely to address the issue of
elliptic curve support as there is interest in this technology from a
number of areas.

Our main concern is the number of variations proposed.  Experience with
OpenPGP and other standards suggests that having a multitude of options
does not lead to interoperability and security.  It is better to focus
on a small number of options that will be used and tested.

In looking at the various forms of elliptic curves, we can separate
consideration of the coordinate field (the field from which the X and
Y coordinates are taken) from the curve group.  Rather than describing
each curve choice as a particular coordinate field and elliptic curve,
we would rather specify a limited set of coordinate fields, and then to
define curves using that set.

Especially when implementing the binary (characteristic 2) fields,
to get good performance it is necessary to optimize the code for the
particular field size and basis.  Knowing the polynomial you can hard-code
the necessary shifts, xors, and array offsets and do the arithmetic
very fast.  Code which treats these values as variables will be much
less efficient. As efficiency is much of the motivation for going to EC
technology, we should try to preserve it.

Therefore we recommend choosing a limited set of field sizes, and for each
one choosing a single coordinate basis.  This will let all implementers
optimize their code for the fields that are actually in use.

As candidates for the specific fields to use, we recommend
the selections from NIST [fips186-2], used as ECC groups in IKE
[draft-ietf-ipsec-ike-ecc-groups-03]. These fields are being deployed
and are in use in some environments. They provide for efficient
implementations.

ECC groups in IKE specifies two curves for each choice of coordinate
field, a random curve which is expected to provide maximal security due
to absence of any exploitable structure, and a Koblitz curve which has
structure that allows for optimization and high speed.  We feel this is a
good model to follow. It provides some flexibility while still providing a
limited number of choices which will promote interoperability.  No special
coding is needed to support the Koblitz curve for interoperation purposes;
effort is only required if you want to get the potential speed advantages.

The last point we would like to make is about the field representation
format (section 4.4 in the draft), where again we would propose to reduce
the number of options in order to improve interoperability. 16 options
is too many.

We suggest the initial draft use only prime fields, descriptor 3,
and trinomial/pentanomial binary fields, descriptors 11 and 12. These
three are enough to cover all the NIST curves.  They seem to provide
the advantages which we seek from ECC without multiplying the options
excessively.

If the group does want to pursue additional field types, we would like
to see some rationale for the use of prime extension field types 4-9. Our
concern with the special primes 1-2 is that this area seems to be covered
by patents.  And descriptors 14-16 are for normal bases, where we see
two problems.  First, they cannot be efficiently implemented in software;
and second, we do not think it is possible to convert from a normal basis
into a polynomial basis representation without additional information
regarding the specific normal basis chosen.  Hence using normal bases
as an interchange format is not a good choice.  So we would like to see
more discussion of that aspect if the group wishes to pursue it.

(One organizational point: section 4.4 actually describes custom curves,
and we would prefer to see the draft focus on predefined curves.  We have
ideas on how to reorganize the draft to define specific coordinate
fields and curves based on them, which we are getting into shape to
present shortly.)

Hal Finney 
Andrey Jivsov 
Network Associates, Inc. 

URLs:
NIST curves: http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf

ECC groups:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-ecc-groups-03.txt


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85Lpvl08155 for ietf-openpgp-bks; Wed, 5 Sep 2001 14:51:57 -0700 (PDT)
Received: from m11.jersey.juno.com (m11.jersey.juno.com [64.136.16.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85LpuD08151 for <[e-mail]>; Wed, 5 Sep 2001 14:51:56 -0700 (PDT)
Received: from cookie.juno.com by cookie.juno.com for <"xS5dSbQuAOKnbKF9wbUrHJ39PYu6gR1FzOY/FcCWdJfFulbvEGnc6Q==">
Received: (from [e-mail]) by m11.jersey.juno.com (queuemail) id GELUQYRN; Wed, 05 Sep 2001 17:51:37 EDT
To: [e-mail]
Cc: [e-mail]
Date: Wed, 5 Sep 2001 17:57:53 -0400
Subject: Re: Revised features section (brief)
Message-ID: <[e-mail]>
X-Mailer: Juno 5.0.33
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Joe Tag <[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>

Thanks, folks. I have printed this; archived it. 
On Wed, 5 Sep 2001 13:02:40 -0700 Jon Callas <[e-mail]> writes:
> 
> This changes it to a bit vector. Brickbats to me.
> 
> 5.2.3.24. Features
> 
>    (N octets of flags)
> 
>    The features subpacket denotes which advanced OpenPGP features a
>    user's implementation supports. This is so that as features are
>    added to OpenPGP that cannot be backwards-compatible, a user can
>    state that they can use that feature.
> 
>    This subpacket is similar to a preferences subpacket, and only
>    appears in a self-signature.
> 
>    An implementation SHOULD NOT use a feature listed when sending to 
> a
>    user who does not state that they can use it.
> 
>    Defined features are:
> 
>        First octet:
> 
>        0x01 - Modification Detection (packets 18 and 19)
> 
>    If an implementation implements any of the defined features, it
>    SHOULD implement the features subpacket, too.
> 
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/tagj.


Received: by above.proper.com (8.11.6/8.11.3) id f85KtFi06803 for ietf-openpgp-bks; Wed, 5 Sep 2001 13:55:15 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85KtED06799 for <[e-mail]>; Wed, 5 Sep 2001 13:55:14 -0700 (PDT)
Received: from [129.46.76.229] (dhcp123.qualcomm.com [129.46.76.229]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f85Kt5C29483; Wed, 5 Sep 2001 13:55:05 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510010eb7bc3b253ad8@[129.46.76.229]>
In-Reply-To: <p0510030db7bb06f4c163@[192.168.1.180]>
References: <[e-mail]>	 <m15d9Cc-000Qe5C@epsilon> <[e-mail]>	 <p05100103b7baa69ace04@[129.46.76.229]> <p05100300b7bac4c03376@[63.73.97.180]> <[e-mail]> <p0510030db7bb06f4c163@[192.168.1.180]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Wed, 5 Sep 2001 13:46:56 -0700
To: Jon Callas <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
Cc: Ben Laurie <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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>

W/r/t Certicom's patents, I'm waiting to hear from a Simon 
Blake-Wilson at Certicom.  I don't know if he's a crypto guy, a 
patent guy,or something else entirely.  If someone knows him and has 
an email address, I'll pester him directly.

At 3:34 PM -0700 9/4/01, Jon Callas wrote:
>I have no idea how to do that, myself. But if someone else does the work
>and convinces us that it's generic, I say go for it. That's also why I said
>to do an informational RFC, make a sample implementation, let someone hack
>up GPG to work with it, and we'll see.

Dominikus'  draft has proposals for changes.  Is the proposal 
generic?  Do the proposals conflict with 2440bis in any way?  Are 
there implementations (and do they interoperate)?  These are the 
issues, *if* we clear the IPR hurdle.
-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.11.6/8.11.3) id f85Kl8E06625 for ietf-openpgp-bks; Wed, 5 Sep 2001 13:47:08 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Kl7D06621 for <[e-mail]>; Wed, 5 Sep 2001 13:47:07 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id QAA07395 for [e-mail]; Wed, 5 Sep 2001 16:47:06 -0400
Date: Wed, 5 Sep 2001 16:47:06 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Signer's User ID
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waning Gibbous (93% of Full)
X-Pointless-Random-Number: 32
X-Silly-Header: It sure is.
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>

In 2440bis-03, the "Signer's User ID" signature subpacket is
discussed, but no way to describe the data itself is included.

I assume this is meant to be a string (like the User ID), so it might
be good to have a "(String)" in there.

David

-- 
David Shaw          |  Technical Lead
<[e-mail]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85K5Xi05497 for ietf-openpgp-bks; Wed, 5 Sep 2001 13:05:33 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85K5WD05493 for <[e-mail]>; Wed, 5 Sep 2001 13:05:32 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Wed, 5 Sep 2001 13:05:29 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030ab7bc353e16fa@[192.168.1.180]>
Date: Wed, 5 Sep 2001 13:02:40 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Revised features section
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>

This changes it to a bit vector. Brickbats to me.

5.2.3.24. Features

   (N octets of flags)

   The features subpacket denotes which advanced OpenPGP features a
   user's implementation supports. This is so that as features are
   added to OpenPGP that cannot be backwards-compatible, a user can
   state that they can use that feature.

   This subpacket is similar to a preferences subpacket, and only
   appears in a self-signature.

   An implementation SHOULD NOT use a feature listed when sending to a
   user who does not state that they can use it.

   Defined features are:

       First octet:

       0x01 - Modification Detection (packets 18 and 19)

   If an implementation implements any of the defined features, it
   SHOULD implement the features subpacket, too.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85JkYf04938 for ietf-openpgp-bks; Wed, 5 Sep 2001 12:46:34 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85JkQD04931 for <[e-mail]>; Wed, 5 Sep 2001 12:46:26 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15ejXp-0002sd-00; Wed, 05 Sep 2001 22:45:09 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15eigt-0003Lo-00; Wed, 05 Sep 2001 21:50:27 +0200
To: "Michael Young" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Fixing the secret keys, and a small apology
References: <p05100309b7baf2e20a43@[192.168.1.180]> <[e-mail]> <005501c13633$e3734960$[e-mail]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 05 Sep 2001 21:50:27 +0200
In-Reply-To: <005501c13633$e3734960$[e-mail]> ("Michael Young"'s message of "Wed, 5 Sep 2001 13:55:02 -0400")
Message-ID: <[e-mail]>
Lines: 26
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.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 Wed, 5 Sep 2001 13:55:02 -0400, Michael Young said:

> But this wouldn't be an OpenPGP format.  The OpenPGP secret key packet

Right. It is an implementation detail which would help to avoid
unprotecting and re-protecting when transferring keys.

> Personally, I find it unlikely that an implementation would cut off
> the public key parameters at all.  It would have to do so very

I know devices which do not have enough storage capacity for all
parameters. 

> public parts.  Lastly, it seems wise to perform consistency checks
> between the public/private parts even in the presence of an MDC.

I don't see a reason for this, if the MDC would not provide a sound
consistency check, what else would do?


   Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85HvFG02382 for ietf-openpgp-bks; Wed, 5 Sep 2001 10:57:15 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Hv8D02378 for <[e-mail]>; Wed, 5 Sep 2001 10:57:14 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id NAA78282 for <[e-mail]>; Wed, 5 Sep 2001 13:49:15 -0400 (EDT)
Received: from mwyoung (dhcp-195-50.transarc.ibm.com [9.38.195.250]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA25957 for <[e-mail]>; Wed, 5 Sep 2001 13:57:04 -0400 (EDT)
Message-ID: <005501c13633$e3734960$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <[e-mail]>
Subject: Re: Fixing the secret keys, and a small apology
Date: Wed, 5 Sep 2001 13:55:02 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Werner Koch" <[e-mail]>
> Another question is the format.  Should we include only the public
> parameters or more stuff in the MDC?  A solution I would like to see
> is to just hash the fingerprint of the key along with the secret

I prefer hashing the full packet (v4-style, even for any v3 packets
that use an MDC), but I could live with hashing the fingerprint.  Old
v3 fingerprints are slightly flawed (in that they don't hash the MPI
sizes), but I suppose an exploit does seem unlikely here.  Hashing
the whole thing just feels more consistent.

> think of putting the secet parameters on a hardware token and there
> might be not enough space to store the public parameters - the

But this wouldn't be an OpenPGP format.  The OpenPGP secret key packet
includes the public key material.  Of course, an implementation can
use its own internal key storage format (and associated protection).
When such a hardware-token transformation cuts off the public key
parameters, it can cut off the MDC (and add a new one if it sees fit).
The spec need only deal with transmission among OpenPGP implementations.

Personally, I find it unlikely that an implementation would cut off
the public key parameters at all.  It would have to do so very
selectively, as many of them are necessary for private key operations
as well.  It also seems to me that you'd want the card to be able to
verify past results from its own key, in which case it might want the
public parts.  Lastly, it seems wise to perform consistency checks
between the public/private parts even in the presence of an MDC.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5Zm4WNDnIII+QUHAQHkZwgAlvxLPocVqq1y9sumbVszcSzh/0+tvvOs
3GljV627UlSEY8CnvZa2cCJEqj3W3ZcQJJODPnJg7ZYhD1BUngQi0aar7n0FaIwz
OBybBNjKoMtiQeoCiUY/TqIUuLomWSA1cT0Z0AGSDwGCwiv3UJ+q4EyxYAIQZqu2
FFD9KufBmf+w0sFXhASVkgtMj1+9NA+WIdlMiYthOFAFmwhWzC1EgvhNm4ASVhUx
6llurDAN9JhJuaCdkctYJw3zhD80gUyMzhvQb2VN0zKI1bz2PuaGnOB/OwJkifig
R7B16UDthP4sjB/CaAxUCzvH1dbuQesSCw+no/KNWeiL+kMZejQPIA==
=Sg/T
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id f85For127580 for ietf-openpgp-bks; Wed, 5 Sep 2001 08:50:53 -0700 (PDT)
Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FopD27575 for <[e-mail]>; Wed, 5 Sep 2001 08:50:52 -0700 (PDT)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA44912 for <[e-mail]>; Wed, 5 Sep 2001 11:42:57 -0400 (EDT)
Received: from mwyoung (dhcp-195-50.transarc.ibm.com [9.38.195.250]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA25321 for <[e-mail]>; Wed, 5 Sep 2001 11:50:47 -0400 (EDT)
Message-ID: <002a01c13622$3ec3eca0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]> <[e-mail]>
Subject: Re: Fixing the secret keys, and a small apology
Date: Wed, 5 Sep 2001 11:48:44 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Florian Weimer" <[e-mail]>
> Jon Callas <[e-mail]> writes:
> > there, then they can't use algorithm 254. However, not only is using a
> > cipher algorithm deprecated, but our present max cipher number is 10.
> 
> This is not quite correct, the numbers 100 to 110 are already
> assigned, too, technically speaking.  However, 254 was never an

But, as Jon pointed out, any use of a cipher algorithm number
here is deprecated.  In fact, the String-to-Key section has
the following commentary already.  Note the explicit mention of IDEA.

[2440bis-03, section 3.7.2.1]:
>    This last possibility, the cipher algorithm number with an implicit
>    use of MD5 and IDEA, is provided for backward compatibility; it MAY
>    be understood, but SHOULD NOT be generated, and is deprecated.

I'd be perfectly happy strengthening this to "MUST NOT be generated
for algorithms outside the ranges 1-10 and 100-110" (or just IDEA).

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5ZGC2NDnIII+QUHAQGSxAf+P/ZbGOKHeRIXE/ikZq0SI5BNBvfTXta0
A8+MoeBRMvSyHWXz1csiaL/N9R/jsGAMlzjOYoTHRqi1ZvcRRaY2VrPoSyQfn+tF
k3V4EpsZq9b/dMtlPkHuuK5wx3kOhXQXSfciH+qZJl49MW/XBOTzKzQZFC98GRUu
hdZKkVGzEtUMlsnAB9JOaC5NmgCLSJi/rs/K81qsyvKXamazx5woqi+sCbI1XXyw
oJqkSIXKu+PfzbbIqe3fbemG9s/OrhZuEZucGWSEJG/GsCvjePEDZ1+VuGxCnUlp
zeHiDoovt5yC+n4WDq9H0sH9BmgHNh2rXA3G/fCMs/qBstrhh8Equg==
=1wOR
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85FKbv24634 for ietf-openpgp-bks; Wed, 5 Sep 2001 08:20:37 -0700 (PDT)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85FKZD24630 for <[e-mail]>; Wed, 5 Sep 2001 08:20:35 -0700 (PDT)
Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.22 #1 (Debian)) id 15efOP-0002Pi-00; Wed, 05 Sep 2001 18:19:09 +0200
Received: from wk by alberti.gnupg.de with local (Exim 3.22 #1 (Debian)) id 15eXLO-0002oO-00; Wed, 05 Sep 2001 09:43:30 +0200
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Fixing the secret keys, and a small apology
References: <p05100309b7baf2e20a43@[192.168.1.180]>
From: Werner Koch <[e-mail]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[e-mail]
Date: 05 Sep 2001 09:43:30 +0200
In-Reply-To: <p05100309b7baf2e20a43@[192.168.1.180]> (Jon Callas's message of "Tue, 4 Sep 2001 14:28:50 -0700")
Message-ID: <[e-mail]>
Lines: 34
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.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 Tue, 4 Sep 2001 14:28:50 -0700, Jon Callas said:

> * Change the String-to-Key specifier. The solution here is adding in the
> tag 254 to 3.7.2.1 and have 254 denote an improved S2K. The benefit here is

This is fine with me.

Another question is the format.  Should we include only the public
parameters or more stuff in the MDC?  A solution I would like to see
is to just hash the fingerprint of the key along with the secret
parameters.  I predict that in future, implementations will use the
fingerprint to identify a key (and not just the keyID) and therefore
it is steadily available.

Implementations wouldn't have to worry about the public key parameters
when unprotecting the secret parameters of a secret key.  One might
think of putting the secet parameters on a hardware token and there
might be not enough space to store the public parameters - the
fingerprint and the secret parameters should be enough to put on a
(memory only) token.

> there, then they can't use algorithm 254. However, not only is using a
> cipher algorithm deprecated, but our present max cipher number is 10. I

Given that we assigned 100-110 for experimental algorithms it is
unlikely that higher algorithms identifiers are ever used. 


   Werner

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85DurA18635 for ietf-openpgp-bks; Wed, 5 Sep 2001 06:56:53 -0700 (PDT)
Received: from fs.imstumped.com (arielle.dsl.patriot.net [209.249.182.205]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85DuqD18631 for <[e-mail]>; Wed, 5 Sep 2001 06:56:52 -0700 (PDT)
Received: from localhost (scm@localhost) by fs.imstumped.com (8.11.0/8.11.0) with ESMTP id f85DuU323335; Wed, 5 Sep 2001 09:56:30 -0400
Date: Wed, 5 Sep 2001 09:56:30 -0400 (EDT)
From: "Shawn C. Masters" <[e-mail]>
To: Dominikus Scherkl <[e-mail]>
cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
Subject: Re: AW: Reasons to include ECC to our charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
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 Wed, 5 Sep 2001, Dominikus Scherkl wrote:

>
> > ECC does *not* affect the speed of large file encryption.
> Agreed. But that's not the point.
> The most convincing argument for including ECC (to me) is
> having another alternative, an algorithm depending on a
> completely different problem, independent to integer
> factorization and discrete logarithms.
>

	Actually it isn't independent of either integer factorization or
the discrete log problem.  All of the ECC systems I've seen are actually
discrete log over the elleptic curve derived number field rather than the
one produced by "mod n".  The only real difference is that no one knows
how to apply a number field sieve to the ECC.  Well more accuratly, no one
knows if there exists a definition of "smoothness", thus the most
effecient factoring algorithm to date is Pollard's Rho which sets the
equivalent key strength to a much smaller multiple of RSA before Number
field seives.

	So you get a faster PK encryption, that uses less memory, but only
because no one has figured out how to apply our best factoring algorithms
to it.  This may not be possible, or may just not be known.  Of course
, the next major advance in factoring may not even be a seive, or
require smoothness.  That is why many people only recommend ECC for small
devices, but these are all if's.

	73,
		Shawn




Received: by above.proper.com (8.11.6/8.11.3) id f85CwDE15711 for ietf-openpgp-bks; Wed, 5 Sep 2001 05:58:13 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85CwCD15705 for <[e-mail]>; Wed, 5 Sep 2001 05:58:12 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15ecFH-0006rm-00 for [e-mail]; Wed, 05 Sep 2001 14:57:31 +0200
To: [e-mail]
Subject: Re: Fixing the secret keys, and a small apology
References: <p05100309b7baf2e20a43@[192.168.1.180]>
From: Florian Weimer <[e-mail]>
Date: 05 Sep 2001 14:57:31 +0200
In-Reply-To: <p05100309b7baf2e20a43@[192.168.1.180]> (Jon Callas's message of "Tue, 4 Sep 2001 14:28:50 -0700")
Message-ID: <[e-mail]>
Lines: 30
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.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>

Jon Callas <[e-mail]> writes:

> * Change the entire public key version number to 5, and add in a check.

I think V5 should be started only if a few other adjustments are made,
too.  The certificate-does-not-cover-key-expiration-time problem comes
to my mind here. ;-)

> * Change the String-to-Key specifier. The solution here is adding in the
> tag 254 to 3.7.2.1

and reserve 254 (and 255) in 9.2 for this kind of use.

> and have 254 denote an improved S2K. The benefit here is
> that it causes the least change to user software, and is as secure as
> anything else. The downside is that if someone uses a cipher algorithm
> there, then they can't use algorithm 254. However, not only is using a
> cipher algorithm deprecated, but our present max cipher number is 10.

This is not quite correct, the numbers 100 to 110 are already
assigned, too, technically speaking.  However, 254 was never an
official private/experimental symmetric algorithm identifier, so I
don't think we have to care about potential problems caused by using
254 at this particular place, especially since using symmetric
algorithm specifiers in this context is deprecated anyway.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f85AnE207900 for ietf-openpgp-bks; Wed, 5 Sep 2001 03:49:14 -0700 (PDT)
Received: from wit387304.student.utwente.nl (wit387304.student.utwente.nl [130.89.234.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85AnCD07887 for <[e-mail]>; Wed, 5 Sep 2001 03:49:12 -0700 (PDT)
Received: from druif.local ([10.235.121.12]) by wit387304.student.utwente.nl with esmtp (Exim 2.05 #1) id 15eaEx-0000WX-00; Wed, 5 Sep 2001 12:49:03 +0200
Date: Wed, 05 Sep 2001 12:49:51 +0200
From: Edwin Woudt <[e-mail]>
To: Jon Callas <[e-mail]>, [e-mail]
Subject: Re: SHA-xxx OIDs
Message-ID: <271142766.999694191@[10.235.121.12]>
In-Reply-To: <p05100318b7bb28e4ba91@[192.168.1.180]>
References:  <p05100318b7bb28e4ba91@[192.168.1.180]>
X-Mailer: Mulberry/2.1.0 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
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>

Jon Callas <[e-mail]> wrote:

> Does someone want to volunteer to double-check the OIDs I have in bis-03
> for wide SHA?

They are also in the PKCS#1 v2.1 draft:
  ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1d2.pdf

The values in the bis-03 draft match the values in this document.


Edwin



Received: by above.proper.com (8.11.6/8.11.3) id f85Aj1g07827 for ietf-openpgp-bks; Wed, 5 Sep 2001 03:45:01 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85Aj0D07821 for <[e-mail]>; Wed, 5 Sep 2001 03:45:00 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 704E62E9BB; Wed,  5 Sep 2001 10:44:55 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 11:44:55 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dominikus Scherkl <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
Subject: Re: AW: Reasons to include ECC to our charter
References: <[e-mail]>
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>

Dominikus Scherkl wrote:
> 
> > Sorry, that's not how patents work - licensing is required
> > to use it at all, not only if you want to sell it.
> Ok, that was nor the right wording.
> We can use it _in a standard_ and _test_ it - unless it is
> used in an implementation.

No, you can't even do that. But even if you could, what would the point
be?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: by above.proper.com (8.11.6/8.11.3) id f85AeOf07705 for ietf-openpgp-bks; Wed, 5 Sep 2001 03:40:24 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85AeND07701 for <[e-mail]>; Wed, 5 Sep 2001 03:40:23 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 12:40:08 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: Reasons to include ECC to our charter
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Wed, 5 Sep 2001 12:40:08 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: Reasons to include ECC to our charter
Thread-Index: AcE19S288tYiOnthRtS10dzT7sMMmAAAEpHA
From: "Dominikus Scherkl" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 05 Sep 2001 10:40:08.0919 (UTC) FILETIME=[2225EE70:01C135F7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f85AeND07702
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>

> Sorry, that's not how patents work - licensing is required
> to use it at all, not only if you want to sell it.
Ok, that was nor the right wording.
We can use it _in a standard_ and _test_ it - unless it is
used in an implementation.
Sure, that is much worse than what I said. :-(
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id f85AQEh06539 for ietf-openpgp-bks; Wed, 5 Sep 2001 03:26:14 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85AQDD06532 for <[e-mail]>; Wed, 5 Sep 2001 03:26:14 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 85AB82E9BB; Wed,  5 Sep 2001 10:26:07 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Wed, 05 Sep 2001 11:26:07 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dominikus Scherkl <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
Subject: Re: AW: Reasons to include ECC to our charter
References: <[e-mail]>
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>

Dominikus Scherkl wrote:
> > What will we see? Clearly its possible to do - so what's
> > interesting about doing it before we can be sure we can use it?
> We indeed _can_ be sure that we can use it - anyone can use it
> unless she want to sell it (which may require licencing).

Sorry, that's not how patents work - licensing is required to use it at
all, not only if you want to sell it.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: by above.proper.com (8.11.6/8.11.3) id f85AMFL06456 for ietf-openpgp-bks; Wed, 5 Sep 2001 03:22:15 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f85AMED06451 for <[e-mail]>; Wed, 5 Sep 2001 03:22:14 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 12:21:59 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: Reasons to include ECC to our charter
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Wed, 5 Sep 2001 12:21:59 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reasons to include ECC to our charter
Thread-Index: AcE1lFZ7vLjBceu3QDWwvQnLt358dQAX5ktA
From: "Dominikus Scherkl" <[e-mail]>
To: "Jon Callas" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 05 Sep 2001 10:22:00.0187 (UTC) FILETIME=[99369CB0:01C135F4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f85AMFD06453
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>

> ECC does *not* affect the speed of large file encryption.
Agreed. But that's not the point.
The most convincing argument for including ECC (to me) is
having another alternative, an algorithm depending on a
completely different problem, independent to integer
factorization and discrete logarithms.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id f859mVC04554 for ietf-openpgp-bks; Wed, 5 Sep 2001 02:48:31 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f859mUD04548 for <[e-mail]>; Wed, 5 Sep 2001 02:48:30 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 11:48:15 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: Reasons to include ECC to our charter
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Wed, 5 Sep 2001 11:48:15 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reasons to include ECC to our charter
Thread-Index: AcE1lP1DGB9nBwWCQHCasLZSMIppWwAVlJSQ
From: "Dominikus Scherkl" <[e-mail]>
To: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 05 Sep 2001 09:48:15.0817 (UTC) FILETIME=[E2984390:01C135EF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f859mVD04550
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>

Hello.

> > > That's precisely the issue - how do we make sure it
> > > doesn't assume a patented technology if we don't know
> > > what the patents are?
I think we agree now that there exists patents, so ECC will
not be mandatory part of the standard. But if it's optional
it is not essential to know what is patented and what not -
it would only be nice to know.

> > If someone comes up with a layout that supports ECC
> > generically, I'd say go with it.
May I remember that it's exactly what I ask for?
To go with what I submitted?

> > if someone else does the work and convinces us that it's
> > generic, I say go for it.
What do you dislike in my proposal? What is not generic enough?
Till mow I've not read any content-specific critics.

> > That's also why I said to do an informational RFC,
Ok, I can submit my draft also as an informational RFC.
Is it that what you want me to do?

> > make a sample implementation, let someone hack up GPG to
> > work with it, and we'll see.

To experiment wit elliptic curves LiDIA (Library for
computational number theory - from the Technische Universitaet
Darmstadt) has all you need. Also P1363 is a good point
to get implementations of most the algorithms needed for
ECC and ECDSA.

I think there are already diverse implementations of ECC
waiting for a standard to interoperate.

> 
> What will we see? Clearly its possible to do - so what's
> interesting about doing it before we can be sure we can use it?
We indeed _can_ be sure that we can use it - anyone can use it
unless she want to sell it (which may require licencing).

Sorry if my words sound too hard. I don't mind.
I don't worry about the discussion. Quite the opposit, it's
worthwhile. But I would enjoy it very much to have an ECC
standard at last.

Best regards.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id f859E0701904 for ietf-openpgp-bks; Wed, 5 Sep 2001 02:14:00 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f859DwD01900 for <[e-mail]>; Wed, 5 Sep 2001 02:13:59 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 11:13:43 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: SHA-xxx OIDs
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Wed, 5 Sep 2001 11:13:42 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SHA-xxx OIDs
Thread-Index: AcE1rVG20AU2WfyHTdCiVaiepAOL5AAPT0iA
From: "Dominikus Scherkl" <[e-mail]>
To: "Jon Callas" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 05 Sep 2001 09:13:43.0275 (UTC) FILETIME=[0F4373B0:01C135EB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f859DxD01901
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>

> Does someone want to volunteer to double-check the OIDs I 
> have in bis-03 for wide SHA?
> 
> [e-mail] claimed to have found them in an IEEE 
> P1363a draft D7.9.
Yes. I found them there too. Looks as they were correct.

> Does anyone have validation that they exist, or know where to 
> look? The URL given for that draft is password-protected
Subscribe to the P1363 discussion list and you will get the
password - also interessting if you want to get a reference
implementation of most ECC-related algorithms.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id f851uHq25786 for ietf-openpgp-bks; Tue, 4 Sep 2001 18:56:17 -0700 (PDT)
Received: from smtprelay3.adelphia.net (smtprelay3.adelphia.net [64.8.25.8]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851uFD25782 for <[e-mail]>; Tue, 4 Sep 2001 18:56:15 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay3.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GJ62QL01.T2B for <[e-mail]>; Tue, 4 Sep 2001 21:56:45 -0400 
Message-ID: <010901c135ad$a7233000$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]>
Subject: Identifying revoked certificates
Date: Tue, 4 Sep 2001 21:54:06 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Jon Callas" <[e-mail]>
> Now then, one of the remaining things really on our agenda is to discuss
> fixing the secret key format.

Can I get something added to the agenda?

Last week, I asked how certificate revocation was supposed to work in
the presence of multiple certificates for the same key/userId (or
key/subkey or just key) material.  I don't buy the argument that the
spec shouldn't cover semantics here -- I don't care if the spec says
how an implementation should treat a revocation, but I think it's
critical that the sender and receiver agree on what is being revoked.

My proposal was to add a signature subpacket to contain the hash
algorithm and value from the certificate being revoked.  Old
implementations should ignore it (unless the sender marks it critical,
in which case they should ignore the revocation itself).  New
implementations can use it to positively identify the original.

Does this sound reasonable?  If not, do you disagree with the premise
that identification is useful?  Or, do you dislike the form of the ID?

(Plus, in doing so, the spec can remain silent on the meaning of
duplicate certificates.  I favor adding a "most recent prevails"
recommendation, but if I can revoke *specific* older ones to make
my intention clear, I don't need to depend on any other rules.)

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5WFnGNDnIII+QUHAQExMgf/bWSykKCbGLUwKBwQg2etB6br0EvUO3ya
33Vz2gxjkeUN/W0v5IeWu0NJHpBFaBkjsM7SvG/jBi4E0Sso7FXn+qu0N+k/Lm2t
B/7WWKnF+hZfYl2s+facScyF5rGQ6xiWsb3godcLjYRxTTcPrbfdD4qzqNEPpa9J
vblPkkD+77TR0FYSsLqOjImGbV+rSgAN5SXa4qDphPT9cZ06PVUY+exD0fLiOPHo
ONd31YjMrlOw8WiNYnhWpGiE7pMx7MLTe44QDWbpIRIVqOjO8B8p2Hm8MhISpC96
FiZiz5PHw7j7ViEgPnse9tV4vwiQ6yzqcV43xhnBkXB84wM33KatGg==
=M5t4
-----END PGP SIGNATURE-----




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f851Z0a22496 for ietf-openpgp-bks; Tue, 4 Sep 2001 18:35:00 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851YxD22491 for <[e-mail]>; Tue, 4 Sep 2001 18:34:59 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Tue, 4 Sep 2001 18:35:02 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100318b7bb28e4ba91@[192.168.1.180]>
Date: Tue, 4 Sep 2001 18:34:41 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: SHA-xxx OIDs
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>

Does someone want to volunteer to double-check the OIDs I have in bis-03
for wide SHA?

[e-mail] claimed to have found them in an IEEE P1363a draft D7.9.

Does anyone have validation that they exist, or know where to look? The URL
given for that draft is password-protected, and I hesitate to reference a
draft anyway. I've done some poking around and haven't found anything.

	Jon


Received: by above.proper.com (8.11.6/8.11.3) id f851NMC22274 for ietf-openpgp-bks; Tue, 4 Sep 2001 18:23:22 -0700 (PDT)
Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f851NAD22265 for <[e-mail]>; Tue, 4 Sep 2001 18:23:20 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GJ612B00.VDK for <[e-mail]>; Tue, 4 Sep 2001 21:20:35 -0400 
Message-ID: <003601c135a9$006a5bc0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <p05100309b7baf2e20a43@[192.168.1.180]>
Subject: Re: Fixing the secret keys, and a small apology
Date: Tue, 4 Sep 2001 21:20:39 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.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>

-----BEGIN PGP SIGNED MESSAGE-----

From: "Jon Callas" <[e-mail]>
> * Change the String-to-Key specifier. The solution here is adding in the
> tag 254 to 3.7.2.1 and have 254 denote an improved S2K.

I concur with Jon's analysis and conclusion (favoring a new pre-S2K tag).

[It really has nothing to do with the S2K, though... it's the "pre-S2K"
byte, and it simply says that the encrypted data (that *follows* the S2K)
includes an MDC.  But I'll accept it whatever wording is used. :-]

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQEVAwUBO5V9xWNDnIII+QUHAQFeGwgAiDTe0w/rBcoO+5MwKKOq125JW8StofkS
J1kUgtTMgPBUAigSpNt1WLsajZk7IuYk+tS470k1PAx/3qj396nKeQ18TqdWNBUA
lh1gSNlGeu3q2omFadC+TZTwNpuQpFvyGg9Te/qgYauENSnEaxCaMmRD3ShBEVyJ
VPcGVi3qf3Q5E3C4qWnSbk48NBvQ+XbfmvGTQEVE5Ltwj/R/tY7FJReyeRbvzID6
2uHdVN7LzguqPAdPbAS7+jHX+dkWNvzkk9YN2nqQemwjpJz3pZJj/O8bj+Wb9Wy4
D8iYeSlTgHyj7qcHXhgS3SlscIuVLYrHWeuSvhgCL5wk7WRL7sqihw==
=eG8B
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id f84MhOY01930 for ietf-openpgp-bks; Tue, 4 Sep 2001 15:43:24 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84MhND01926 for <[e-mail]>; Tue, 4 Sep 2001 15:43:23 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id BD2362E9BB; Tue,  4 Sep 2001 22:43:20 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 23:43:20 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Reasons to include ECC to our charter
References: <[e-mail]>	 <m15d9Cc-000Qe5C@epsilon> <[e-mail]>	 <p05100103b7baa69ace04@[129.46.76.229]> <p05100300b7bac4c03376@[63.73.97.180]> <[e-mail]> <p0510030db7bb06f4c163@[192.168.1.180]>
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>

Jon Callas wrote:
> 
> At 10:49 PM +0100 9/4/01, Ben Laurie wrote:
> 
> >That's precisely the issue - how do we make sure it doesn't assume a
> >patented technology if we don't know what the patents are?
> >
> >Why should this WG spend its time on stuff that may end up patented? By
> >all means, once its clear what we can and can't use, then let's proceed.
> >Until then, what's the point?
> >
> 
> If someone comes up with a layout that supports ECC generically, I'd say go
> with it.
> 
> I have no idea how to do that, myself. But if someone else does the work
> and convinces us that it's generic, I say go for it. That's also why I said
> to do an informational RFC, make a sample implementation, let someone hack
> up GPG to work with it, and we'll see.

What will we see? Clearly its possible to do - so what's interesting
about doing it before we can be sure we can use it?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84Mf1P01868 for ietf-openpgp-bks; Tue, 4 Sep 2001 15:41:01 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84MexD01860 for <[e-mail]>; Tue, 4 Sep 2001 15:40:59 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Tue, 4 Sep 2001 15:40:53 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030eb7bb0795e734@[192.168.1.180]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <m15d9Cc-000Qe5C@epsilon> <[e-mail]> <p05100103b7baa69ace04@[129.46.76.229]> <p05100300b7bac4c03376@[63.73.97.180]> <[e-mail]>
Date: Tue, 4 Sep 2001 15:40:51 -0700
To: "vedaal" <[e-mail]>, <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
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>

At 5:56 PM -0400 9/4/01, vedaal wrote:

>but that would be a very noticeable increase in speed  of encryption of
>very large files,
>or pgp disk encryption at the gb level of pgp disk size
>
>agree fully with the principle of including it as an option even though it
>is patented.
>
>once the advantages become clear enough, someone will hopefully find a way
>to produce a funtionally similar patentless alternative
>

ECC does *not* affect the speed of large file encryption. Actually, it's
the opposite; it matters most for *small* files.

Remember, the bulk encryption is done with a block cipher. If you want it
to be fast, you use CAST, Twofish, or Rijndael. All of them are very fast.
You might spend 50ms with the public key packet, and then 1 or 2 ms with
the data.

The symmetric key is then wrapped in the public key encryption. For a small
file, you spend a lot of time with the wrapper and then pop open the data
packet. With a big file, the heavy cost of the public key operation is a
smaller fraction of the total cost, and ECC matters less. ECC is a win when
you have teeny processors sending small messages.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84MbsN01816 for ietf-openpgp-bks; Tue, 4 Sep 2001 15:37:54 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84MbrD01812 for <[e-mail]>; Tue, 4 Sep 2001 15:37:53 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Tue, 4 Sep 2001 15:37:47 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030db7bb06f4c163@[192.168.1.180]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <m15d9Cc-000Qe5C@epsilon> <[e-mail]>	 <p05100103b7baa69ace04@[129.46.76.229]> <p05100300b7bac4c03376@[63.73.97.180]> <[e-mail]>
Date: Tue, 4 Sep 2001 15:34:57 -0700
To: Ben Laurie <[e-mail]>
From: Jon Callas <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
Cc: [e-mail]
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>

At 10:49 PM +0100 9/4/01, Ben Laurie wrote:

>That's precisely the issue - how do we make sure it doesn't assume a
>patented technology if we don't know what the patents are?
>
>Why should this WG spend its time on stuff that may end up patented? By
>all means, once its clear what we can and can't use, then let's proceed.
>Until then, what's the point?
>

If someone comes up with a layout that supports ECC generically, I'd say go
with it.

I have no idea how to do that, myself. But if someone else does the work
and convinces us that it's generic, I say go for it. That's also why I said
to do an informational RFC, make a sample implementation, let someone hack
up GPG to work with it, and we'll see.

But all of this has a lot of ifs wrapped around it.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84M8Pq01350 for ietf-openpgp-bks; Tue, 4 Sep 2001 15:08:25 -0700 (PDT)
Received: from hotmail.com (oe63.law3.hotmail.com [209.185.240.79]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84M8OD01346 for <[e-mail]>; Tue, 4 Sep 2001 15:08:24 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Sep 2001 14:57:09 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <m15d9Cc-000Qe5C@epsilon> <[e-mail]> <p05100103b7baa69ace04@[129.46.76.229]> <p05100300b7bac4c03376@[63.73.97.180]>
Subject: Re: Reasons to include ECC to our charter
Date: Tue, 4 Sep 2001 17:56:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 04 Sep 2001 21:57:09.0197 (UTC) FILETIME=[8B4EB7D0:01C1358C]
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: RIPEMD160

- ----- Original Message ----- 
From: "Jon Callas" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, September 04, 2001 5:06 PM
Subject: Re: Reasons to include ECC to our charter


> Also as a real-world consideration, there's no need for any desktop or
> laptop user to use ECC. Do I care if ECC means that a decrypt happens ten
> times faster? Nope. The decrypt right now is happening in the blink of an
> eye (like 50ms) or two. I'm not going to notice it taking place in a
> tenth of an eye-blink. 

but that would be a very noticeable increase in speed  of encryption of
very large files,
or pgp disk encryption at the gb level of pgp disk size

agree fully with the principle of including it as an option even though it
is patented.

once the advantages become clear enough, someone will hopefully find a way
to produce a funtionally similar patentless alternative

vedaal

-----BEGIN PGP SIGNATURE-----
Version: 6.5.8ckt build_6_(mdc-fixed)   http://www.ipgpp.com/
Comment: { Acts of Kindness better the World, and protect the Soul }
Comment: KeyID: 0x6A05A0B785306D25
Comment: Fingerprint: 96A6 5F71 1C43 8423  D9AE 02FD A711 97BA

iQEVAwUBO5VOJGoFoLeFMG0lAQNfNQf+JjQ91yKwYzzKymQCMCz9vH4Gzo5pcVpH
5co1x6mqpVzHlq77UtPgphlukG3byCVgCAj0BPryE51izlP2ct8zMJ1lr0L9xKjk
yDiA0jGyJBHyiEMqecWq7i5EKwChADbNJdOgxBz2Pk5TPrB2nJStjFoalYHDfxPK
AcW6Dw6dTaHWb/IoG2Z7p8+vvF9sfAyjQtjquddm3+gBLqFNdF8TZRgFxlCoG/x7
12qsprcm6NQOlN22jjGXQwTAP7GgLsYZGDF6w6sN2JZ9vyqCG7ijSrTGRvkiJWp3
xmmUjRs3vwHfTQl88rUt6WqI0OCllxs8OertWEG5NDvW5LXtM9Fn+g==
=f4EU
-----END PGP SIGNATURE-----



Received: by above.proper.com (8.11.6/8.11.3) id f84Lnx501030 for ietf-openpgp-bks; Tue, 4 Sep 2001 14:49:59 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84LnwD01024 for <[e-mail]>; Tue, 4 Sep 2001 14:49:58 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id 985AD2E9BB; Tue,  4 Sep 2001 21:49:54 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Tue, 04 Sep 2001 22:49:54 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jon Callas <[e-mail]>
Cc: [e-mail]
Subject: Re: Reasons to include ECC to our charter
References: <[e-mail]> <m15d9Cc-000Qe5C@epsilon> <[e-mail]> <p05100103b7baa69ace04@[129.46.76.229]> <p05100300b7bac4c03376@[63.73.97.180]>
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>

Jon Callas wrote:
> We aren't going to make ECC a MUST or even a SHOULD. We will try very hard
> to make the formats for ECC not favor anyone's implementation. We all know
> that. So why don't we encourage some ECC experts to write an informational
> RFC, do some interoperability testing, and make sure that it doesn't assume
> a patented technology?

That's precisely the issue - how do we make sure it doesn't assume a
patented technology if we don't know what the patents are?

Why should this WG spend its time on stuff that may end up patented? By
all means, once its clear what we can and can't use, then let's proceed.
Until then, what's the point?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: by above.proper.com (8.11.6/8.11.3) id f84LcBw00885 for ietf-openpgp-bks; Tue, 4 Sep 2001 14:38:11 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84LcAD00881 for <[e-mail]>; Tue, 4 Sep 2001 14:38:10 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Tue, 4 Sep 2001 14:38:04 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b7baf2e20a43@[192.168.1.180]>
Date: Tue, 4 Sep 2001 14:28:50 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Fixing the secret keys, and a small apology
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>

I screwed up the footers on the last draft, saying 2000 where it should
have said 2001 or 2002. Sorry.

Now then, one of the remaining things really on our agenda is to discuss
fixing the secret key format.

There are a few options for a solution we've discussed:

* Change the secret key version number and add in a check. The plus here is
that it causes the fewest visible changes. The downside is that it causes
skew between the public and private versions, and is going to create
problems and confusion down the road. Enough people expressed disgust at
this that I don't think it needs to be discussed further.

* Change the entire public key version number to 5, and add in a check.
This is the "right" way to the above. From a standards point of view, this
is the most correct way to solve it. However, the downside is that it will
force a lot of client software to have to be revised (nigh unto all of it).
Secret key packets typically do not wander further from the disk than main
memory, and it would be a pity to force everyone to upgrade software
everywhere for this. Lots of people just won't. (See my previous note ECC.)
I'm probably one of them, too. I am reminded of the aphorism that in
theory, theory is the same as practice, but in practice, this turns out not
to be the case. While this may be the best solution from a standards point
of view, it is arguably the worst one from a practical point of view.

* Change the String-to-Key specifier. The solution here is adding in the
tag 254 to 3.7.2.1 and have 254 denote an improved S2K. The benefit here is
that it causes the least change to user software, and is as secure as
anything else. The downside is that if someone uses a cipher algorithm
there, then they can't use algorithm 254. However, not only is using a
cipher algorithm deprecated, but our present max cipher number is 10. I
can't get too upset about this, myself, and it appears this is the best
solution.

Comments?

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84L6LR00294 for ietf-openpgp-bks; Tue, 4 Sep 2001 14:06:21 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84L6KD00290 for <[e-mail]>; Tue, 4 Sep 2001 14:06:20 -0700 (PDT)
Received: from [192.168.1.180] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for <[e-mail]>; Tue, 4 Sep 2001 14:06:11 -0700
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100300b7bac4c03376@[63.73.97.180]>
In-Reply-To: <p05100103b7baa69ace04@[129.46.76.229]>
References: <[e-mail]> <m15d9Cc-000Qe5C@epsilon> <[e-mail]> <p05100103b7baa69ace04@[129.46.76.229]>
Date: Tue, 4 Sep 2001 14:06:05 -0700
To: [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
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>

I'm afraid that I don't see what the hand-wringing is over Certicom and
ECC. In the IETF, we forbid technologies with intellectual property
encumbrances from being *required*, but we don't forbid them from being
optional.

In the real world, any new public key system has an uphill battle to gain
any sort of acceptance. Look at the DSS/EG keys we have now. They were
invented for two reasons: (1) to address security problems in previous key
versions (2) to migrate from encumbered technologies to unencumbered ones.
Yet in some quarters of the user community, OpenPGP is looked on as if it
were fluoridation, for any number of reasons, none of which are really
relevant to this discussion. What *is* relevant is that if we put the ECC
parameters in OpenPGP, they probably won't be widely adopted, intellectual
property or not. So why not put them in, since they don't hurt anyone else?

Also as a real-world consideration, there's no need for any desktop or
laptop user to use ECC. Do I care if ECC means that a decrypt happens ten
times faster? Nope. The decrypt right now is happening in the blink of an
eye (like 50ms) or two. I'm not going to notice it taking place in a tenth
of an eye-blink. The delays I see in encrypted email are all related to UI
and layers and disk accesses and groveling through databases to *find* the
darned key. I might notice an improvement if I'm encrypting a message to a
dozen or more people, but maybe not. The size savings is utterly laughable.

ECC will matter only on constrained devices. If you want to make a OpenPGP
secured pager or SMS cell phone, then we're starting to see a reason for
ECC. Why not let these people do it interoperably?

I can understand some people's concern that the ECC proponents aren't
pushing things. But they did. About three years ago, some Certicom guys
made a presentation at an IETF meeting (Chicago?) and were basically pelted
with tomatoes and hooted out of the room. It was pretty embarrassing. If I
worked for Certicom, my reaction to this working group would be, "When you
want to talk rationally, email me."

We aren't going to make ECC a MUST or even a SHOULD. We will try very hard
to make the formats for ECC not favor anyone's implementation. We all know
that. So why don't we encourage some ECC experts to write an informational
RFC, do some interoperability testing, and make sure that it doesn't assume
a patented technology? And then if we like it, we can put it in a future
draft, or a follow-on document? We already have reserved PK algorithm
numbers for ECC and ECDSA.

	Jon


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84IcJp09839 for ietf-openpgp-bks; Tue, 4 Sep 2001 11:38:19 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84IcHD09585 for <[e-mail]>; Tue, 4 Sep 2001 11:38:17 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 0B8222C88; Tue,  4 Sep 2001 20:38:17 +0200 (MET DST)
Received: id <m15eL8Q-000Qe5C@epsilon>; Tue, 4 Sep 2001 20:41:18 +0200 (CEST) 
Message-Id: <m15eL8Q-000Qe5C@epsilon>
Date: Tue, 4 Sep 2001 20:41:18 +0200 (CEST)
To: "Dominikus Scherkl" <[e-mail]>
Cc: [e-mail]
From: Bodo Moeller <[e-mail]>
Subject: Re: AW: Reasons to include ECC to our charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
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>

Dominikus Scherkl <[e-mail]>:

>>> Certicom may have.  Specifically, Certicom claims to have a patent
>>> application covering point compression, and noone else really knows
>>> what is in it.  So it may be prudent to avoid compressed point
>>> representations.

> I agree to this. Also from a mathematical point of view compression is
> somewhat unfortunate, because no proper algorithm for curves over odd
> extension fields has been developed.

Algorithms for computing square roots in odd-characteristic extension
fields do exist (see chapter 7 in Sachar Paulus, "Algorithmen für
endliche abelsche Gruppen", Diplomarbeit, Unversität des Saarlandes,
1993), but none of the current specifications (such as the IEEE P1363a
drafts) defines what the compression bit should look like.  I think
the most obvious choice would be, given a polynomial representation of
a non-zero field element with coefficients in the underlying prime
field, to find the lowest-indexed non-zero coefficient and use its
LSB.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f84FvSO20005 for ietf-openpgp-bks; Tue, 4 Sep 2001 08:57:28 -0700 (PDT)
Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84FvRD19999 for <[e-mail]>; Tue, 4 Sep 2001 08:57:27 -0700 (PDT)
Received: from [129.46.76.229] (dhcp123.qualcomm.com [129.46.76.229]) by mage.qualcomm.com (8.11.3/8.11.3/1.0) with ESMTP id f84FugC20008; Tue, 4 Sep 2001 08:56:43 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100103b7baa69ace04@[129.46.76.229]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <m15d9Cc-000Qe5C@epsilon> <[e-mail]>
X-Mailer: eudora51-ffc10713011434
X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2  09E8 9480 645A 8857
X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8
Date: Tue, 4 Sep 2001 08:49:04 -0700
To: Ben Laurie <[e-mail]>
From: John  W Noerenberg II <[e-mail]>
Subject: Re: Reasons to include ECC to our charter
Cc: Bodo Moeller <[e-mail]>, [e-mail], Peter Gutmann <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
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>

At 1:11 PM +0100 9/3/01, Ben Laurie wrote:
>It seems to me entirely unacceptable that we should even be discussing
>I-Ds which relate to patents of unknown content. Certicom should either
>reveal what they do or do not have pending, or go away.

Clearly there is significant interest in ECC in this WG. 
Unfortunately, Ben is right, IPR issues are always troubling - there 
can be no mandatory requirements that have IPR restrictions.  Still, 
I have no desire to see this group ignore useful techniques, if it 
improves the utility of OpenPGP.   I'll contact some people at 
Certicom to see whether this can be definitively settled.  If there 
is no resolution soon, we'll have to drop discussion of it w/r/t to 
DRAFT status.

I may ultimately need some help from the IESG on this.  I'll keep you posted.
-- 

john noerenberg
[e-mail]
   --------------------------------------------------------------------------
   Peace of mind isn't at all superficial, really.  It's the whole thing.
   That which produces it is good maintenance; that which disturbs it
   is poor maintenance.
   -- Zen and the Art of Motorcycle Maintenance, Robert M. Pirsig, 1974
   --------------------------------------------------------------------------


Received: by above.proper.com (8.11.6/8.11.3) id f84EgwO13323 for ietf-openpgp-bks; Tue, 4 Sep 2001 07:42:58 -0700 (PDT)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f84EguD13314 for <[e-mail]>; Tue, 4 Sep 2001 07:42:57 -0700 (PDT)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.22 #1) id 15eHP8-0008Gv-00 for [e-mail]; Tue, 04 Sep 2001 16:42:18 +0200
To: [e-mail]
Subject: User ID certificates vs key certificates
From: Florian Weimer <[e-mail]>
Date: 04 Sep 2001 16:42:18 +0200
Message-ID: <[e-mail]>
Lines: 28
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.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>

Sieuwert van Otterloo's paper, 'A security analysis of PGP'
(http://www.bluering.nl/pgp/pgp.ps), describes a more general problem
in a few OpenPGP implementations (but fails to state that it affects
most OpenPGP implementations, not only NAI PGP 5.x to 7.x):

OpenPGP defines certificates as (public key, user ID) pairs, but most
implementations tend to present 'key certificates', and the mapping
from the former to the latter often leaves something to be desired
(especially with PGP 2.6.x, but GnuPG, too, is not yet perfect).

For example, PGP 2.6.3in prints the following messages for a valid
signature created with the key below:

Good signature from user "bad test key".
Signature made 2001/09/04 13:52 GMT using 1024-bit key, key ID E2BB3EE5

However, only the 'good test key' user ID is certified:

pub  1024R/E2BB3EE5 2001-09-04 bad test key
sig        E2BB3EE5 2001-09-04  bad test key
uid                            good test key
sig        C06EC3B5 2001-09-04  Florian Weimer #RC=no RA=RUS CR=own# <[e-mail]>
sig        E2BB3EE5 2001-09-04  bad test key

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.11.6/8.11.3) id f849GmD23449 for ietf-openpgp-bks; Tue, 4 Sep 2001 02:16:48 -0700 (PDT)
Received: from mail1.biodata.com ([62.159.113.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f849GlD23445 for <[e-mail]>; Tue, 4 Sep 2001 02:16:47 -0700 (PDT)
Received: from fra1d001.biodata.org ([10.10.1.51]) by mail1.biodata.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Sep 2001 11:15:49 +0200
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: AW: Reasons to include ECC to our charter
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Tue, 4 Sep 2001 11:15:48 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Reasons to include ECC to our charter
Thread-Index: AcE0dzbH+etp8TeeRgOoF4PA+HR5fAAqFgDg
From: "Dominikus Scherkl" <[e-mail]>
To: "Ben Laurie" <[e-mail]>
Cc: "openPGP e-Mail (E-Mail)" <[e-mail]>
X-OriginalArrivalTime: 04 Sep 2001 09:15:49.0481 (UTC) FILETIME=[30133590:01C13522]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id f849GmD23446
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.

> > Certicom may have.  Specifically, Certicom claims to have a patent
> > application covering point compression, and noone else really knows
> > what is in it.  So it may be prudent to avoid compressed point
> > representations.

I agree to this. Also from a mathematical point of view compression is
somewhat unfortunate, because no proper algorithm for curves over odd
extension fields has been developed. So we better say implementations
MAY use it for prime and char-2 based curves instead of SHOULD.

> 
> It seems to me entirely unacceptable that we should even be discussing
> I-Ds which relate to patents of unknown content. Certicom 
> should either reveal what they do or do not have pending, or go away.

I'm also somewhat concerned that noone of certicom said any word about
the whole discussion over ecc-patents on this list.

Even if it's not our job to care which parts of a standard require
licences
from any corporation to be sold in an implementation, I would be proud
to hear for which parts patents are claimed - or else we couldn't
insert any hints to these patents in the draft (which would be nice).

-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id f83Cc4G23222 for ietf-openpgp-bks; Mon, 3 Sep 2001 05:38:04 -0700 (PDT)
Received: from scuzzy.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f83Cc2D23218 for <[e-mail]>; Mon, 3 Sep 2001 05:38:03 -0700 (PDT)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by scuzzy.ben.algroup.co.uk (Postfix) with ESMTP id A12702E9BA; Mon,  3 Sep 2001 12:11:40 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Mon, 03 Sep 2001 13:11:40 +0100
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bodo Moeller <[e-mail]>
Cc: [e-mail], Peter Gutmann <[e-mail]>, [e-mail]
Subject: Re: Reasons to include ECC to our charter
References: <[e-mail]> <m15d9Cc-000Qe5C@epsilon>
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>

Bodo Moeller wrote:
> A caveat is that we do not know about additional pending patents that
> Certicom may have.  Specifically, Certicom claims to have a patent
> application covering point compression, and noone else really knows
> what is in it.  So it may be prudent to avoid compressed point
> representations.

It seems to me entirely unacceptable that we should even be discussing
I-Ds which relate to patents of unknown content. Certicom should either
reveal what they do or do not have pending, or go away.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


Received: by above.proper.com (8.11.6/8.11.3) id f81Bb5d18137 for ietf-openpgp-bks; Sat, 1 Sep 2001 04:37:05 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id f81Bb3D18133 for <[e-mail]>; Sat, 1 Sep 2001 04:37:04 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 963FD2CA7; Sat,  1 Sep 2001 13:36:52 +0200 (MET DST)
Received: id <m15d9Cc-000Qe5C@epsilon>; Sat, 1 Sep 2001 13:44:42 +0200 (CEST) 
Message-Id: <m15d9Cc-000Qe5C@epsilon>
Date: Sat, 1 Sep 2001 13:44:42 +0200 (CEST)
From: [e-mail] (Bodo Moeller)
To: [e-mail], [e-mail] (Peter Gutmann), [e-mail]
Subject: Re: Reasons to include ECC to our charter
In-Reply-To: <[e-mail]>
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>

Peter Gutmann <[e-mail]>:
> Florian Weimer <[e-mail]>:

>> IIRC, not all ECC stuff is patented, only curves over GF(q), q even, which can
>> be implemented efficiently using two-valued logic.

> The rule of thumb for ECC is something like "ECC curves are divided into three
> groups, weak curves, inefficient curves, and curves patented by Certicom".

While Certicom certainly would like everybody to believe this, there
is few evidence that it is true.  Apart from patents on specific
cryptographic schemes, most patents relevant for ECC are on normal
bases for GF(2^m), which were originally thought to be useful because
they allow for very efficient implementation in custom-made hardware,
but turned out to be pretty irrelevant in practice.  (None of the
recommended curves in Certicom's recent SEC2 specification uses normal
bases.)

Curves over finite prime fields or curves over GF(2^m) when field
elements are represented using polynomial bases do not appear to have
such patent problems.  (Major manufacturers of cryptographic
coprocessors for smartcards implement these without worrying about
Certicom licences.)  For software implementations, they are not
automatically more time efficient than using conventional public key
cryptography in DSA-style groups, though.  The two important speed-up
techniques that can be used for the NIST recommended curves are due to
Jerry Solinas (NSA, not Certicom): All NIST recommended curves over
prime fields are based on specifically chosen primes (pseudo-Mersenne
primes) to allow for fast modular reduction; some of the NIST
recommended curves over GF(2^m) are Koblitz curves to allow for fast
point multiplication (see Jerry Solinas' CRYPTO '97 paper).
This makes ECC efficient in software without, as far as I am aware,
requiring any Certicom patent licences.

A caveat is that we do not know about additional pending patents that
Certicom may have.  Specifically, Certicom claims to have a patent
application covering point compression, and noone else really knows
what is in it.  So it may be prudent to avoid compressed point
representations.