Subject: SHA-xxx OIDs

From: Jon Callas <[email-masked]>
Date: Tue, 4 Sep 2001 18:34:41 -0700

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

[email-masked] 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

---

From: Edwin Woudt <[email-masked]>
Date: Wed, 05 Sep 2001 12:49:51 +0200

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

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

---

From: [email-masked] (Bodo Moeller)
Date: Tue, 11 Sep 2001 10:55:21 +0200 (CEST)

Jon Callas <[email-masked]>:

> 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
[email-masked]) and you will immediately receive the password.
That password "protection" is just a silly IEEE requirement.

Date: Tue, 11 Sep 2001 10:55:21 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Cc: Jon Callas <[email-masked]>
Subject: Re: SHA-xxx OIDs
Sender: [email-masked]

Jon Callas <[email-masked]>:

> 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
[email-masked]) and you will immediately receive the password.
That password "protection" is just a silly IEEE requirement.

Date: Mon, 10 Sep 2001 21:50:25 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Reply-To: [email-masked] (Bodo Moeller)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Comments on ECC draft
Sender: [email-masked]

[email-masked]>:

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

Date: Mon, 10 Sep 2001 21:21:50 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
Reply-To: [email-masked] (Bodo Moeller)
To: [email-masked]
Cc: Jon Callas <[email-masked]>, "vedaal" <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

Jon Callas <[email-masked]>:

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

To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Identifying revoked certificates
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 08 Sep 2001 12:07:01 +0200
Lines: 23
Sender: [email-masked]

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Identifying revoked certificates
Date: Fri, 7 Sep 2001 18:05:01 -0400
Sender: [email-masked]

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

<[email-masked]> 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.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Identifying revoked certificates
Date: Fri, 7 Sep 2001 17:27:52 -0400
Sender: [email-masked]

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

"Werner Koch" <[email-masked]> 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.

Date: Fri, 07 Sep 2001 10:01:01 +0200
From: [email-masked]
Organization: .NO.SPaM.NET
To: [email-masked]
Subject: Re: Identifying revoked certificates
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: Identifying revoked certificates
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 07 Sep 2001 08:13:38 +0200
Lines: 37
Sender: [email-masked]

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Identifying revoked certificates
Date: Thu, 6 Sep 2001 22:51:48 -0400
Sender: [email-masked]

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

From: "Jon Callas" <[email-masked]>
> >  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.

Date: Thu, 6 Sep 2001 14:38:46 -0700
To: "Michael Young" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Identifying revoked certificates
Sender: [email-masked]

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

Date: Thu, 6 Sep 2001 14:33:10 -0700
To: David Shaw <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Identifying revoked certificates
Cc: Michael Young <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Identifying revoked certificates
Date: Thu, 6 Sep 2001 17:06:48 -0400
Sender: [email-masked]

-----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" <[email-masked]>
> 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.

Date: Thu, 6 Sep 2001 15:46:24 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Michael Young <[email-masked]>, [email-masked]
Subject: Re: Identifying revoked certificates
Mail-Followup-To: Jon Callas <[email-masked]>, Michael Young <[email-masked]>, [email-masked]
Sender: [email-masked]

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
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

Date: Thu, 6 Sep 2001 12:06:49 -0700
To: "Michael Young" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Identifying revoked certificates
Sender: [email-masked]

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

Date: Thu, 6 Sep 2001 12:02:47 -0700
To: Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Fixing the secret keys, and a small apology
Cc: [email-masked]
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: Comments on ECC draft
Date: Thu, 6 Sep 2001 12:07:53 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

-----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: [email-masked]

Date: Wed, 5 Sep 2001 18:28:32 -0700
From: [email-masked]
To: [email-masked], [email-masked]
Subject: Comments on ECC draft
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

To: [email-masked]
Cc: [email-masked]
Date: Wed, 5 Sep 2001 17:57:53 -0400
Subject: Re: Revised features section (brief)
From: Joe Tag <[email-masked]>
Sender: [email-masked]

Thanks, folks. I have printed this; archived it. 
On Wed, 5 Sep 2001 13:02:40 -0700 Jon Callas <[email-masked]> 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.

Date: Wed, 5 Sep 2001 13:46:56 -0700
To: Jon Callas <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Cc: Ben Laurie <[email-masked]>, [email-masked]
Sender: [email-masked]

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
[email-masked]
   --------------------------------------------------------------------------
   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
   --------------------------------------------------------------------------

Date: Wed, 5 Sep 2001 16:47:06 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Signer's User ID
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

Date: Wed, 5 Sep 2001 13:02:40 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Revised features section
Sender: [email-masked]

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.

To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Fixing the secret keys, and a small apology
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 05 Sep 2001 21:50:27 +0200
Lines: 26
Sender: [email-masked]

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Fixing the secret keys, and a small apology
Date: Wed, 5 Sep 2001 13:55:02 -0400
Sender: [email-masked]

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

From: "Werner Koch" <[email-masked]>
> 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.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Fixing the secret keys, and a small apology
Date: Wed, 5 Sep 2001 11:48:44 -0400
Sender: [email-masked]

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

From: "Florian Weimer" <[email-masked]>
> Jon Callas <[email-masked]> 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).

To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Fixing the secret keys, and a small apology
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 05 Sep 2001 09:43:30 +0200
Lines: 34
Sender: [email-masked]

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

Date: Wed, 5 Sep 2001 09:56:30 -0400 (EDT)
From: "Shawn C. Masters" <[email-masked]>
To: Dominikus Scherkl <[email-masked]>
cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: AW: Reasons to include ECC to our charter
Sender: [email-masked]

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

To: [email-masked]
Subject: Re: Fixing the secret keys, and a small apology
From: Florian Weimer <[email-masked]>
Date: 05 Sep 2001 14:57:31 +0200
Lines: 30
Sender: [email-masked]

Jon Callas <[email-masked]> 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 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Wed, 05 Sep 2001 12:49:51 +0200
From: Edwin Woudt <[email-masked]>
To: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: SHA-xxx OIDs
Sender: [email-masked]

Edwin

Date: Wed, 05 Sep 2001 11:44:55 +0100
From: Ben Laurie <[email-masked]>
To: Dominikus Scherkl <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: AW: Reasons to include ECC to our charter
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: AW: Reasons to include ECC to our charter
Date: Wed, 5 Sep 2001 12:40:08 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

> 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: [email-masked]

Date: Wed, 05 Sep 2001 11:26:07 +0100
From: Ben Laurie <[email-masked]>
To: Dominikus Scherkl <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: AW: Reasons to include ECC to our charter
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: AW: Reasons to include ECC to our charter
Date: Wed, 5 Sep 2001 12:21:59 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Jon Callas" <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

> 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: [email-masked]

content-class: urn:content-classes:message
Subject: AW: Reasons to include ECC to our charter
Date: Wed, 5 Sep 2001 11:48:15 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

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: [email-masked]

content-class: urn:content-classes:message
Subject: AW: SHA-xxx OIDs
Date: Wed, 5 Sep 2001 11:13:42 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Jon Callas" <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

> Does someone want to volunteer to double-check the OIDs I 
> have in bis-03 for wide SHA?
> 
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: [email-masked]

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Identifying revoked certificates
Date: Tue, 4 Sep 2001 21:54:06 -0400
Sender: [email-masked]

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

From: "Jon Callas" <[email-masked]>
> 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.)

Date: Tue, 4 Sep 2001 18:34:41 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: SHA-xxx OIDs
Sender: [email-masked]

	Jon

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Fixing the secret keys, and a small apology
Date: Tue, 4 Sep 2001 21:20:39 -0400
Sender: [email-masked]

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

From: "Jon Callas" <[email-masked]>
> * 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. :-]

Date: Tue, 04 Sep 2001 23:43:20 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

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

Date: Tue, 4 Sep 2001 15:40:51 -0700
To: "vedaal" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

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

Date: Tue, 4 Sep 2001 15:34:57 -0700
To: Ben Laurie <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Cc: [email-masked]
Sender: [email-masked]

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

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Date: Tue, 4 Sep 2001 17:56:55 -0400
Sender: [email-masked]

- ----- Original Message ----- 
From: "Jon Callas" <[email-masked]>
To: <[email-masked]>
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

Date: Tue, 04 Sep 2001 22:49:54 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

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

Date: Tue, 4 Sep 2001 14:28:50 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Fixing the secret keys, and a small apology
Sender: [email-masked]

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

Date: Tue, 4 Sep 2001 14:06:05 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

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

Date: Tue, 4 Sep 2001 20:41:18 +0200 (CEST)
To: "Dominikus Scherkl" <[email-masked]>
Cc: [email-masked]
From: Bodo Moeller <[email-masked]>
Subject: Re: AW: Reasons to include ECC to our charter
Sender: [email-masked]

Dominikus Scherkl <[email-masked]>:

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

Date: Tue, 4 Sep 2001 08:49:04 -0700
To: Ben Laurie <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Cc: Bodo Moeller <[email-masked]>, [email-masked], Peter Gutmann <[email-masked]>, [email-masked]
Sender: [email-masked]

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
[email-masked]
   --------------------------------------------------------------------------
   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
   --------------------------------------------------------------------------

To: [email-masked]
Subject: User ID certificates vs key certificates
From: Florian Weimer <[email-masked]>
Date: 04 Sep 2001 16:42:18 +0200
Lines: 28
Sender: [email-masked]

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# <[email-masked]>
sig        E2BB3EE5 2001-09-04  bad test key

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

content-class: urn:content-classes:message
Subject: AW: Reasons to include ECC to our charter
Date: Tue, 4 Sep 2001 11:15:48 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

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: [email-masked]

Date: Mon, 03 Sep 2001 13:11:40 +0100
From: Ben Laurie <[email-masked]>
To: Bodo Moeller <[email-masked]>
Cc: [email-masked], Peter Gutmann <[email-masked]>, [email-masked]
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

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

Date: Sat, 1 Sep 2001 13:44:42 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked], [email-masked] (Peter Gutmann), [email-masked]
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

Peter Gutmann <[email-masked]>:
> Florian Weimer <[email-masked]>:

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