Subject: Re: Certification revocation -- identifying the revoked certificate

From: [email-masked]
Date: Wed, 29 Aug 2001 12:45:06 +0200

Thomas Roessler wrote:
> On 2001-08-28 17:54:05 -0400, Michael Young wrote:
> >I'm really not out to be pedantic here.  I think it really is 
> >important to have clear rules for revocation.  If multiple
> >certifications for a key or key/name are to be allowed, or are the 
> >*recommended* way to update preferences/qualities, then it is 
> >essential that a revocation be able to target the proper one.
> 
> Of course, the trivial solution would be to assign a unique serial 
> number to each certificate, and to include that serial number with 
> the revocation.
> -- 
> Thomas Roessler                        http://log.does-not-exist.org/

this will require to change sig format or at least make new subpacket for sernum.
besides it will not solve problem with revoking current sigs because they have
no such number.

I think it's enough to identify the sig by its creation time.
I don't think it's normal to have several sigs created at the same time,
and even if there is several sigs with the same creation time, well, they all
are revoked by single revocation sig that refers to this creation time.

JMHO

== <EOF> ==
Disastry  http://i.am/disastry/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^--GPG for Win32 (supports loadable modules and IDEA)
 ^---PGP 2.6.3ia-multi04 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
     AES, 3DES ciphers and MD5, SHA1, RIPEMD160 hashes)

---

From: Florian Weimer <[email-masked]>
Date: 29 Aug 2001 19:16:56 +0200

> I think it's enough to identify the sig by its creation time.

Yes, that seems to be the right thing to do.

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

---

From: "Michael Young" <[email-masked]>
Date: Wed, 29 Aug 2001 15:49:33 -0400

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

I came upon a simpler idea: include the original *hash* in a
subpacket.  After noting that neither PGP6.5 nor GnuPG puts the
original creation time in its revocation packets, I looked
for a way to achieve backward-compatibility.  Putting the
whole original packet in the new one would work, but it's
too large.  But the original hash should be sufficiently precise
(much better than just the original creation time).

Specifically, I suggest adding another signature subpacket:

    5.2.3.1. (add:)
       31 = revocation identification 

    5.2.3.25. Revocation identification

 (1 octet hash algorithm)
  (N octets hash)

 In revocation certificate, the hash value computed in the
 original certificate being revoked.  This SHOULD appear
 in the hashed portion of the revocation certificate.

This would appear to solve a variety of problems for v4 certificates.
Existing implementations, which won't have the logic to verify
them, should ignore it (unless a sender chooses to mark it critical,
which seems like a bad choice).  New implementations can identify
the original certificate precisely.  It's a little larger than
just the timestamp, but not that much.

There is no analog for v3 certificates, but then there's nothing
interesting that can be updated in a v3 certificate anyway
(just the certificate creation time).  If anyone *really* wants
to do that, I'm happy to require that they use a v4 revocation
or hope that the receiver applies a "most recent prevails" model.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Certification revocation -- identifying the revoked certificate
Date: Wed, 29 Aug 2001 15:49:33 -0400
Sender: [email-masked]

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

I came upon a simpler idea: include the original *hash* in a
subpacket.  After noting that neither PGP6.5 nor GnuPG puts the
original creation time in its revocation packets, I looked
for a way to achieve backward-compatibility.  Putting the
whole original packet in the new one would work, but it's
too large.  But the original hash should be sufficiently precise
(much better than just the original creation time).

Specifically, I suggest adding another signature subpacket:

    5.2.3.1. (add:)
       31 = revocation identification 

    5.2.3.25. Revocation identification

 (1 octet hash algorithm)
  (N octets hash)

 In revocation certificate, the hash value computed in the
 original certificate being revoked.  This SHOULD appear
 in the hashed portion of the revocation certificate.

This would appear to solve a variety of problems for v4 certificates.
Existing implementations, which won't have the logic to verify
them, should ignore it (unless a sender chooses to mark it critical,
which seems like a bad choice).  New implementations can identify
the original certificate precisely.  It's a little larger than
just the timestamp, but not that much.

There is no analog for v3 certificates, but then there's nothing
interesting that can be updated in a v3 certificate anyway
(just the certificate creation time).  If anyone *really* wants
to do that, I'm happy to require that they use a v4 revocation
or hope that the receiver applies a "most recent prevails" model.

To: [email-masked]
Subject: Re: Certification revocation -- identifying the revoked certificate
From: Florian Weimer <[email-masked]>
Date: 29 Aug 2001 19:16:56 +0200
Lines: 10
Sender: [email-masked]

Date: Wed, 29 Aug 2001 12:45:06 +0200
From: [email-masked]
Organization: .NO.SPaM.NET
To: [email-masked]
Subject: Re: Certification revocation -- identifying the revoked certificate
Sender: [email-masked]

JMHO

== <EOF> ==

Date: Wed, 29 Aug 2001 09:06:33 +0200
From: Thomas Roessler <[email-masked]>
To: Michael Young <[email-masked]>
Cc: [email-masked]
Subject: Re: Certification revocation -- identifying the revoked certificate
Mail-Followup-To: Michael Young <[email-masked]>, [email-masked]
Sender: [email-masked]

--W/nzBZO5zC0uMSeA
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2001-08-28 17:54:05 -0400, Michael Young wrote:

>I'm really not out to be pedantic here.  I think it really is=20
>certifications for a key or key/name are to be allowed, or are the=20
>*recommended* way to update preferences/qualities, then it is=20

Of course, the trivial solution would be to assign a unique serial=20
number to each certificate, and to include that serial number with=20
the revocation.

--=20

--W/nzBZO5zC0uMSeA
Content-Type: application/pgp-signature
Content-Disposition: inline

--W/nzBZO5zC0uMSeA--

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Certification revocation -- identifying the revoked certificate
Date: Tue, 28 Aug 2001 17:54:05 -0400
Sender: [email-masked]

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

In the ensuing discussion of self-signature revocations, I didn't see an
answer to a fundamental question: what does one hash in a certification
revocation (type 0x30)?  The specification is explicit for all of the
other types, but not this one.

I skimmed the GnuPG source, and it would appear to hash the target key
and userID, and the usual trailing matter (including the hashed
subpackets from the revocation certificate, (*not* the original).
Is my reading correct, and is that what the specification intends?

I note that this does not identify *which* certification is being revoked,
if there is more than one.  If I created multiple signatures (with
different signature type, timestamp, or subpackets) for the same
key/name pair, I see no way to revoke just one of them.  Are multiple
signatures illegal?  (Clearly, multiple self-signatures are legal,
and the same problem comes up there, as per the recent discussion.)

This seems broken.  A certification revocation should identify the
original certification, and hash the same material as the original
(followed by the revocation certificate material).  The identification
is desirable, but not strictly required -- a receiver could test all
possible certifications.  It would seem that a new subpacket would be
in order.  The original contents are absolutely essential, though.

I suppose one interpretation might be that a revocation should match
an original that has *exactly* the same subpackets (except for the
"revocation reason").  How does this work for these things
[with my guess as to an answer in brackets for each one]?
    v3 signatures, which use an explicit creation time instead of
     subpackets [use v3 revocation with same creation time];
    different signature types (e.g., "persona" vs. "casual")
     [do not permit distinction on this];
    other subpackets that might apply to both the original and the
     revocation (e.g., notation data) [there may not be any]; or,
    revocation of an earlier revocation (as Florian Weimer suggested
     might be valid for "no longer in use" reasons) [disallow this].
In any case, if this was the intention, the specification should say
so (and GnuPG should make it easier to generate an exact match :-).

I'm really not out to be pedantic here.  I think it really is important
to have clear rules for revocation.  If multiple certifications for a
key or key/name are to be allowed, or are the *recommended* way to
update preferences/qualities, then it is essential that a revocation
be able to target the proper one.

Date: Tue, 28 Aug 2001 11:27:18 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Replacement Key
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I welcome any comment on the replacement key draft that just got
posted.  

The point, in case you haven't seen the draft yet, is a way for a user
to specify the key that replaces a revoked or expired key.  General
purpose implementations can use this information to use the new key
(presumably with a warning) if a user requests the old one.  It would
also be useful to automatically fetch the new key from keyservers.

Keyservers could use this to present the proper key (again, with a
warning) if an expired/revoked key is requested.

In particular I'd like to hear opinions on the variable sized
subpacket.  There are other variable sized subpackets in OpenPGP, but
I wonder if this one might not save us much.

David

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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-shaw-openpgp-replacementkey-00.txt
Date: Tue, 28 Aug 2001 10:06:34 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Key Replacement for Revoked Keys in OpenPGP
	Author(s)	: D. Shaw
	Filename	: draft-shaw-openpgp-replacementkey-00.txt
	Pages		: 3
	Date		: 22-Aug-01
	
This document specifies a method in OpenPGP to specify a replacement
for an expired or revoked key.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-shaw-openpgp-replacementkey-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-shaw-openpgp-replacementkey-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-shaw-openpgp-replacementkey-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-shaw-openpgp-replacementkey-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 28 Aug 2001 09:38:49 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Keyserver thoughts (was Re: How to update a self-signature?)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Aug 28, 2001 at 09:47:24AM +0200, Werner Koch wrote:
> 
> On Mon, 27 Aug 2001 16:59:00 -0400, David Shaw said:
> 
> > sort of sanity checking there.  Either way, I think it's safe to say
> > that incorrect clocks are out of the scope of 2440!
> 
> Keyserver may want to discard signature which are timestamped more
> than a few days in the future.  This should greatly help not to spread
> erroneous signatures.

Yes, indeed.

I've often thought it would be good if keyservers could trim keys on
the way out - leaving off invalid signatures, expired subkeys, expired
signatures, etc.

It would be optional and allow someone to request the complete key if
they want it.  Computer programs that try to be "smart" often raise
unforseen problems.

David

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

To: [email-masked]
Subject: Re: How to update a self-signature?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 28 Aug 2001 09:47:24 +0200
Lines: 15
Sender: [email-masked]

On Mon, 27 Aug 2001 16:59:00 -0400, David Shaw said:

> sort of sanity checking there.  Either way, I think it's safe to say
> that incorrect clocks are out of the scope of 2440!

Keyserver may want to discard signature which are timestamped more
than a few days in the future.  This should greatly help not to spread
erroneous signatures.

  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: Mon, 27 Aug 2001 16:59:00 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: How to update a self-signature?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Aug 27, 2001 at 08:48:32PM +0200, Werner Koch wrote:
> 
> On Mon, 27 Aug 2001 12:35:40 -0400, David Shaw said:
> 
> > to really revoke a revocation.  I assume you mean revoking a user ID
> > revocation by re-signing the user ID?
> 
> Yes. I talked with Florian about this recently.
> 
> > I'm only trying to make a case for what happens if after everything is
> > worked out and the implementation ends up with more than one valid
> 
> There shouldn't be any date conflicts with self-signatures - but it
> may happen.  The way to handle it for a general purpose implemention is
> to ignore all signatures during key import which are older than
> existing one. That you ignore all self-signatures which are invalid
> should be clear.

This is effectively the same thing as the "use the latest" suggestion.
Either way, you are picking the most recent signature.  I like your
idea a bit more as it seems more elegant - resolving the problem once
at key import time rather than each time the key is used.  It also
keeps the key small - no long trail of signatures from each preference
change.

It does share a gotcha with the "use the latest" suggestion - if the
user who makes one of those signatures has a wonky clock that thinks
it is 2010, then they could find themselves with a self-signature that
can't be replaced because the implementations will always favor the
signature from the future.  The implementation will need to do some
sort of sanity checking there.  Either way, I think it's safe to say
that incorrect clocks are out of the scope of 2440!

> So I do not see a problem before the year 2106 and most of us won't see
> it ever.

Around 2090, the OpenPGP WG of the future will have to make a key
packet version 58 or so that has an 8 byte time. :)

David

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

To: [email-masked]
Subject: Re: How to update a self-signature?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 27 Aug 2001 20:48:32 +0200
Lines: 27
Sender: [email-masked]

On Mon, 27 Aug 2001 12:35:40 -0400, David Shaw said:

> to really revoke a revocation.  I assume you mean revoking a user ID
> revocation by re-signing the user ID?

Yes. I talked with Florian about this recently.

> I'm only trying to make a case for what happens if after everything is
> worked out and the implementation ends up with more than one valid

There shouldn't be any date conflicts with self-signatures - but it
may happen.  The way to handle it for a general purpose implemention is
to ignore all signatures during key import which are older than
existing one. That you ignore all self-signatures which are invalid
should be clear.

So I do not see a problem before the year 2106 and most of us won't see
it ever.

Ciao,

   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

To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: How to update a self-signature?
From: Derek Atkins <[email-masked]>
Date: 27 Aug 2001 12:58:54 -0400
Lines: 25
Sender: [email-masked]

True.  I was implying a Key Revocation, not a UserID revocation.
My appologies for being ambiguous.

-derek

Florian Weimer <[email-masked]> writes:

> Derek Atkins <[email-masked]> writes:
> 
> > Keep in mind that you DON'T want to over-ride a revocation
> > self-signature.  That would be bad.
> 
> It depends on the revocation reason.  If the revocation says 'user ID
> no longer in use', it makes perfect sense to override it.
> 
> -- 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Mon, 27 Aug 2001 12:35:40 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: How to update a self-signature?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Mon, Aug 27, 2001 at 04:55:20PM +0200, Werner Koch wrote:
> 
> On Mon, 27 Aug 2001 09:48:50 -0400, David Shaw said:
> 
> > "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
> 
> Except for key revocation - any valid revocation (which is a
> self-signature) counts.  For subkeys it should be okay to allow
> overriding of subkey revocations but it is practically worthless.
> Revoking user ID revocations should definitely be possible.

The certification revocation signature is applied to the user id,
rather than to the signature that is being revoked, so there is no way
to really revoke a revocation.  I assume you mean revoking a user ID
revocation by re-signing the user ID?

It is an interesting problem how to work out the results when given a
list of certifications and revocations which may have oddball dates.
I'm only trying to make a case for what happens if after everything is
worked out and the implementation ends up with more than one valid
self-signature.

David

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

Date: Mon, 27 Aug 2001 11:50:17 -0400
From: David Shaw <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: Re: How to update a self-signature?
Mail-Followup-To: Derek Atkins <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Aug 27, 2001 at 11:01:10AM -0400, Derek Atkins wrote:
> 
> Keep in mind that you DON'T want to over-ride a revocation
> self-signature.  That would be bad.

Absolutely.  I am referring only to self certification signatures.
Revocation signatures should not be overridden.  "Bad", indeed.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

To: [email-masked]
Subject: Re: How to update a self-signature?
From: Florian Weimer <[email-masked]>
Date: 27 Aug 2001 17:45:44 +0200
Lines: 12
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:

> Keep in mind that you DON'T want to over-ride a revocation
> self-signature.  That would be bad.

It depends on the revocation reason.  If the revocation says 'user ID
no longer in use', it makes perfect sense to override it.

To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: How to update a self-signature?
From: Derek Atkins <[email-masked]>
Date: 27 Aug 2001 11:01:10 -0400
Lines: 82
Sender: [email-masked]

Keep in mind that you DON'T want to over-ride a revocation
self-signature.  That would be bad.

-derek

David Shaw <[email-masked]> writes:

> On Sat, Aug 25, 2001 at 10:46:14AM -0400, Michael Young wrote:
> 
> > Florian Weimer wrote:
> > > This should probably go into a separate RFC.  Currently, RFC 2440 and
> > > RFC 2440bis deal only with syntactic issues 
> > 
> > and Jon Callas wrote (this and subsequent quotes):
> > > This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> > > a data specification standard, not a user interface guide or software
> > 
> > I understand that the specification primarily covers syntax, but
> > if it doesn't cover at least some interpretation issues, then
> > interoperation is seriously hampered.  Who cares how the bits
> > are ordered if a sender and receiver interpret wildly different things?
> > We need to have a meeting of the minds on more than just formatting.
> > 
> > > Secondarily, one way I look at it is as a receiver. I fetch a key from a
> > > server and it has multiple primaries. How do I resolve this? Yeah, there's
> > 
> > On this specific issue, I want to know what a *sender* must do
> > to change its "primary" marking such that a receiver will
> > understand.  The same applies to any material in the self-signature,
> > and this need may arise several times over a key/userId lifetime.
> 
> The draft does specify have a way to do this - rewriting the
> signature(s) in place ("Since a self-signatures contain important
> information about the key's use, an implementation SHOULD allow the
> user to rewrite the self-signature...").  Both PGP and GnuPG do this.
> 
> The problem arises later, when the key with the new self-signatures is
> added to a keyserver or sent to someone else who already has the key.
> Most current implementations in the field will merge their existing
> copy with the new one, resulting in two self-signatures.  It could be
> argued that they should not do this, but since it's going to happen,
> we should at least make a provision for it.
> 
> Like you, I favor a "most recent prevails" recommendation.  I think
> that revoking and re-making self-signatures is going to result in some
> massive keys if every time someone changes their preferences it means
> a new revocation packet and self-signature.
> 
> I don't think that this is just a syntax issue, and therefore
> inappropriate for 2440bis.  2440bis makes a point of covering syntax
> issues that relate to security.  Since the information in a
> self-signature can affect the security of messages sent to the key,
> I'd say this is an appropriate issue to address in 2440bis.
> 
> "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
> like the sample wording I sent out a couple of days ago, rather than a
> MUST.  In fact, SHOULD describes it nicely (e.g. "We recommend you do
> it this way, but you can do it any way you like if you think about the
> implications first.").
> 
> > > last, unless of course it's in the future. Perhaps an even better answer is
> > > to have the implementation ask the user which one to use.
> > 
> > That's always an option, regardless what the specification suggests.
> > 
> > But, I don't want to *force* user interface pop-ups (or even receiver
> > policy decisions) when the creator has clear intentions.
> 
> Yes.
> 
> David
> 
> -- 
> David Shaw          |  Technical Lead
> <[email-masked]>  |  Enterprise Content Delivery
> 617-250-3028        |  Akamai Technologies

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

To: [email-masked]
Subject: Re: How to update a self-signature?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 27 Aug 2001 16:55:20 +0200
Lines: 19
Sender: [email-masked]

On Mon, 27 Aug 2001 09:48:50 -0400, David Shaw said:

> "Most recent prevails" makes a lot of sense.  It can even be a SHOULD,

Except for key revocation - any valid revocation (which is a
self-signature) counts.  For subkeys it should be okay to allow
overriding of subkey revocations but it is practically worthless.
Revoking user ID revocations should definitely be possible.

Well, these rules should be obvious.

Ciao,

   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

To: [email-masked]
Subject: Re: Diffs for next draft
From: Florian Weimer <[email-masked]>
Date: 27 Aug 2001 16:28:51 +0200
Lines: 16
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual.

Yes, and I strongly suggest to keep it that way.  I might have uttered
a different opinion in the past, but after a closer look at the USEFOR
draft and the associated process I came to the conclusion that one
better clearly separates syntax and basic semantics on the one side
and higher level semantics (even layer 8 stuff) on the other side.

Date: Mon, 27 Aug 2001 09:48:50 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: How to update a self-signature?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Aug 25, 2001 at 10:46:14AM -0400, Michael Young wrote:

> Florian Weimer wrote:
> > This should probably go into a separate RFC.  Currently, RFC 2440 and
> > RFC 2440bis deal only with syntactic issues 
> 
> and Jon Callas wrote (this and subsequent quotes):
> > This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> > a data specification standard, not a user interface guide or software
> 
> I understand that the specification primarily covers syntax, but
> if it doesn't cover at least some interpretation issues, then
> interoperation is seriously hampered.  Who cares how the bits
> are ordered if a sender and receiver interpret wildly different things?
> We need to have a meeting of the minds on more than just formatting.
> 
> > Secondarily, one way I look at it is as a receiver. I fetch a key from a
> > server and it has multiple primaries. How do I resolve this? Yeah, there's
> 
> On this specific issue, I want to know what a *sender* must do
> to change its "primary" marking such that a receiver will
> understand.  The same applies to any material in the self-signature,
> and this need may arise several times over a key/userId lifetime.

The draft does specify have a way to do this - rewriting the
signature(s) in place ("Since a self-signatures contain important
information about the key's use, an implementation SHOULD allow the
user to rewrite the self-signature...").  Both PGP and GnuPG do this.

The problem arises later, when the key with the new self-signatures is
added to a keyserver or sent to someone else who already has the key.
Most current implementations in the field will merge their existing
copy with the new one, resulting in two self-signatures.  It could be
argued that they should not do this, but since it's going to happen,
we should at least make a provision for it.

Like you, I favor a "most recent prevails" recommendation.  I think
that revoking and re-making self-signatures is going to result in some
massive keys if every time someone changes their preferences it means
a new revocation packet and self-signature.

I don't think that this is just a syntax issue, and therefore
inappropriate for 2440bis.  2440bis makes a point of covering syntax
issues that relate to security.  Since the information in a
self-signature can affect the security of messages sent to the key,
I'd say this is an appropriate issue to address in 2440bis.

"Most recent prevails" makes a lot of sense.  It can even be a SHOULD,
like the sample wording I sent out a couple of days ago, rather than a
MUST.  In fact, SHOULD describes it nicely (e.g. "We recommend you do
it this way, but you can do it any way you like if you think about the
implications first.").

> > last, unless of course it's in the future. Perhaps an even better answer is
> > to have the implementation ask the user which one to use.
> 
> That's always an option, regardless what the specification suggests.
> 
> But, I don't want to *force* user interface pop-ups (or even receiver
> policy decisions) when the creator has clear intentions.

Yes.

David

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

To: [email-masked]
Subject: Re: Resolving multiple primary user IDs and self-signatures
From: Florian Weimer <[email-masked]>
Date: 27 Aug 2001 15:36:52 +0200
Lines: 35
Sender: [email-masked]

David Shaw <[email-masked]> writes:

[RFC 2440 et al. as mere syntax]

> True, and it even says that in the Abstract.  There is an exception
> made for security issues: "It does not deal with storage and
> implementation questions.  It does, however, discuss implementation
> issues necessary to avoid security flaws."

I think it limits itself to security flaws which directly break the
cryptographic algorithms involved.  Flaws at a higher level are not
discussed.

> Offhand, I can't think of a security implication to having multiple
> UIDs marked primary (though I'm sure someone here can).  My concern is
> with the security implications of having multiple conflicting
> self-signatures.  Without some suggested way to resolve the conflict,
> there can be security implications.  If it is truly a security issue,
> then it is appropriate in 2440bis.  (Obviously, I think it's enough of
> a security issue to mention - I'd like to hear what others think.)

Differences in interpretation of expiration times can have security
implications, too. ;-)

> > On the other hand, If such additions are accepted, I've got a long
> > list of them...
> 
> Care to work on a "Implementation Suggestions for OpenPGP" with me?

Yes, details will follow in private mail. 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-03.txt
Date: Mon, 27 Aug 2001 06:48:32 -0400
Sender: [email-masked]

--NextPart

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

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, L. Donnerhacke, H. Finney,
                          R. Thayer
	Filename	: draft-ietf-openpgp-rfc2440bis-03.txt
	Pages		: 68
	Date		: 24-Aug-01
	
This document defines many tag values, yet it doesn't describe a
mechanism for adding new tags (for new features). Traditionally the
Internet Assigned Numbers Authority (IANA) handles the allocation of
new values for future expansion and RFCs usually define the
procedure to be used by the IANA.  However there are subtle (and not
so subtle) interactions that may occur in this protocol between new
features and existing features which result in a significant
reduction in over all security. Therefore this document does not
define an extension procedure. Instead requests to define new tag
values (say for new encryption algorithms for example) should be
forwarded to the IESG Security Area Directors for consideration or
forwarding to the appropriate IETF Working Group for consideration.

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-03.txt

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: How to update a self-signature?
Date: Sat, 25 Aug 2001 10:46:14 -0400
Sender: [email-masked]

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

Florian Weimer wrote:
> This should probably go into a separate RFC.  Currently, RFC 2440 and
> RFC 2440bis deal only with syntactic issues 

and Jon Callas wrote (this and subsequent quotes):
> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software

I understand that the specification primarily covers syntax, but
if it doesn't cover at least some interpretation issues, then
interoperation is seriously hampered.  Who cares how the bits
are ordered if a sender and receiver interpret wildly different things?
We need to have a meeting of the minds on more than just formatting.

> Secondarily, one way I look at it is as a receiver. I fetch a key from a
> server and it has multiple primaries. How do I resolve this? Yeah, there's

On this specific issue, I want to know what a *sender* must do
to change its "primary" marking such that a receiver will
understand.  The same applies to any material in the self-signature,
and this need may arise several times over a key/userId lifetime.

I'd be willing to issue a revocation on the old self-signature.  Which
of the "reason" values should be used?  Neither "key is superceded"
nor "userId information is no longer valid" is quite right.  I want
"signature is superceded".  How do people feel about adding such a reason?

While on the subject: the section on "Computing Signatures"
doesn't say what the "signature data" is for a certification
revocation (0x30).  Can we add a description there?

But I also offered a "most recent prevails" policy as an alternative.
One advantage to this approach is that it works even if the sender
has lost an old self-signature.  Another is that it is more compact --
extra revocation packets aren't necessary.

> been one recommendation in the last 24 hours since I started writing this
> reply that it be the first one that counts. Why? Why the first? Why not the

If I said that, I misspoke.  I strongly believe that "most recent prevails"
is the only sensible recommendation (if we make one at all).  But again,
an agreed revocation scheme would satisfy me.

> last, unless of course it's in the future. Perhaps an even better answer is
> to have the implementation ask the user which one to use.

That's always an option, regardless what the specification suggests.

But, I don't want to *force* user interface pop-ups (or even receiver
policy decisions) when the creator has clear intentions.

Date: Sat, 25 Aug 2001 10:44:36 -0400
From: David Shaw <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: Resolving multiple primary user IDs and self-signatures
Mail-Followup-To: Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sat, Aug 25, 2001 at 01:11:52PM +0200, Florian Weimer wrote:
> 
> David Shaw <[email-masked]> writes:
> 
> > Here are two suggestions to help with resolving multiple user IDs
> > marked primary, as well as resolving multiple self-signatures with
> > different subpackets:
> 
> This should probably go into a separate RFC.  Currently, RFC 2440 and
> RFC 2440bis deal only with syntactic issues (apart from a minor glitch
> in RFC 2440bis, 'A revoked certification no longer is a part of
> validity calculations.').

True, and it even says that in the Abstract.  There is an exception
made for security issues: "It does not deal with storage and
implementation questions.  It does, however, discuss implementation
issues necessary to avoid security flaws."

Offhand, I can't think of a security implication to having multiple
UIDs marked primary (though I'm sure someone here can).  My concern is
with the security implications of having multiple conflicting
self-signatures.  Without some suggested way to resolve the conflict,
there can be security implications.  If it is truly a security issue,
then it is appropriate in 2440bis.  (Obviously, I think it's enough of
a security issue to mention - I'd like to hear what others think.)

Self-signatures can carry subpackets that definitely affect the
actions that may be taken with a key.  To use one of my examples from
last night, if/when a symmetric cipher or hash is broken, the user can
simply announce that cipher or hash is not accepted (via a "preferred
symmetric algorithms" or "preferred hash algorithms" subpacket).
Without a way to resolve which self-signature is the one to follow,
the broken cipher or hash may be used, which could compromise the
security of the message.

> On the other hand, If such additions are accepted, I've got a long
> list of them...

Care to work on a "Implementation Suggestions for OpenPGP" with me?

David

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

To: [email-masked]
Subject: Re: Resolving multiple primary user IDs and self-signatures
From: Florian Weimer <[email-masked]>
Date: 25 Aug 2001 13:11:52 +0200
Lines: 18
Sender: [email-masked]

David Shaw <[email-masked]> writes:

> Here are two suggestions to help with resolving multiple user IDs
> marked primary, as well as resolving multiple self-signatures with
> different subpackets:

This should probably go into a separate RFC.  Currently, RFC 2440 and
RFC 2440bis deal only with syntactic issues (apart from a minor glitch
in RFC 2440bis, 'A revoked certification no longer is a part of
validity calculations.').

On the other hand, If such additions are accepted, I've got a long
list of them...

To: <[email-masked]>
Subject: Re: Diffs for next draft
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 25 Aug 2001 13:03:40 +0200
Lines: 26
Sender: [email-masked]

On Fri, 24 Aug 2001 16:42:36 -0700, Jon Callas said:

> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual. It tells implementers the things they have to do to be

I really agree with you here.  There are already so many
implementation details in OpenPGP which frankly don't belong there but
can be justified due to the fact that OpenPGP is the specification of
a long standing de-facto standard.

Adding more of these implementation stuff will eventually make OpenPGP
as complicated and bloated as SET.  There are already a lot of concerns
on the complexity of OpenPGP saying that this won't increase security.

The secret key protection is a flaw in the standard and has to be
addressed. Well, the most simple way of addressing it is to say: an
implementation should never send a secret key packet without and
additonal layer of encryption. OTOH, we have the protection and we
should make sure that it this gives us a real protection.

-- 
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: Fri, 24 Aug 2001 23:23:58 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Michael Young <[email-masked]>, [email-masked]
Subject: Re: Diffs for next draft
Mail-Followup-To: Jon Callas <[email-masked]>, Michael Young <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri, Aug 24, 2001 at 04:42:36PM -0700, Jon Callas wrote:

> Secondarily, one way I look at it is as a receiver. I fetch a key from a
> server and it has multiple primaries. How do I resolve this? Yeah, there's
> been one recommendation in the last 24 hours since I started writing this
> reply that it be the first one that counts. Why? Why the first? Why not the
> last? I can make a convincing argument that it should be the last one, too.
> But why the last. Why not the one with the latest date? I think I can argue
> that the latest date is even more correct than either the first or the
> last, unless of course it's in the future. Perhaps an even better answer is
> to have the implementation ask the user which one to use.
> 
> This is my point: I don't see an obvious best answer. Furthermore, 2440 is
> a data specification standard, not a user interface guide or software
> construction manual. It tells implementers the things they have to do to be
> compliant. What this really says that if you ever see a key with multiple
> primary user names, then your guess is as good as mine, and I'm not going
> to wag my finger at you for whatever rationale makes sense for you.

What do you think about adding some text to help resolve multiple
self-signatures?  Multiple primary user names are one thing, but
self-signatures can carry subpackets with serious implications.

For example: take a key with two self-signatures, one with a
revocation key set and one without.  Which is right?  Granted, it is
very hard to tell for all the reasons you gave above, but the penalty
for guessing wrong here is much worse.  If I add a revocation key to
my key and the revocation key is later compromised, I would want to
ensure the compromised key could not revoke mine.  Without even a
recommendation on how to resolve two self-signatures, the result could
be that my key would be revocable on some implementations, but not
others.  It's a great denial of service attack against the key owner.

Similarly, let's say that a few years down the road someone manages to
break one of the symmetric ciphers.  The solution is for the user to
not accept that cipher via the "preferred algorithms" packet.  With
two self-signatures and no way to disambiguate them, the broken cipher
may be used, which can compromise the secrecy of the message.

I strongly favor a recommendation to use the most recent
self-signature.  Picking the first or last doesn't make much sense to
me, as the signature packets could be placed in any order or
rearranged at any time.  It may not be a perfect way to resolve
conflicts, but it should be able to resolve a large majority of them.

If recommending to use the most recent isn't possible, even a line or
two to mention that this is not a casual question and that there are
security implications to picking the wrong self-signature would be
good.  At least it would remind people of the issue.

David

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

Date: Fri, 24 Aug 2001 16:42:36 -0700
To: "Michael Young" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
Sender: [email-masked]

At 12:06 AM -0400 8/24/01, Michael Young wrote:

>It seems that the most likely reason for a second "primary"
>is that it has been updated.  If so, it seems that one should
>defer to the most recent valid signature.  Can we say
>that an implementation "SHOULD" do that, rather than leaving
>it open?

As I remember it, when we introduced this, there were people who thought it
should be a MUST that there be exactly one of them. I thought this was a
bit fussy, myself -- as it requires the implementations to verify that
there's only one.

I came up with the present wording as a way to subtly admonish the practice
without presuming to know the answer. The simple and obvious way to deal
with the problem of multiple primaries is don't do that. This is the Henny
Youngman Solution (from the old joke: HY goes into the doctor and says,
"Doc, it hurts when I do this," waving an arm. The doctor replies, "Then
don't do that"). The penalty for writing multiple primaries is that the
receiver may do something perverse, and you can't use the standard as a
stick. Don't do that.

Secondarily, one way I look at it is as a receiver. I fetch a key from a
server and it has multiple primaries. How do I resolve this? Yeah, there's
been one recommendation in the last 24 hours since I started writing this
reply that it be the first one that counts. Why? Why the first? Why not the
last? I can make a convincing argument that it should be the last one, too.
But why the last. Why not the one with the latest date? I think I can argue
that the latest date is even more correct than either the first or the
last, unless of course it's in the future. Perhaps an even better answer is
to have the implementation ask the user which one to use.

This is my point: I don't see an obvious best answer. Furthermore, 2440 is
a data specification standard, not a user interface guide or software
construction manual. It tells implementers the things they have to do to be
compliant. What this really says that if you ever see a key with multiple
primary user names, then your guess is as good as mine, and I'm not going
to wag my finger at you for whatever rationale makes sense for you.

	Jon

Date: Fri, 24 Aug 2001 13:56:32 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Resolving multiple primary user IDs and self-signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Here are two suggestions to help with resolving multiple user IDs
marked primary, as well as resolving multiple self-signatures with
different subpackets:

>From 5.2.3.19. Primary user id:

   This is a flag in a user id's self signature that states whether
   this user id is the main user id for this key. It is reasonable for
   an implementation to resolve ambiguities in preferences, etc. by
   referring to the primary user id. If this flag is absent, its value
   is zero. If more than one user id in a key is marked as primary, the
   implementation may resolve the ambiguity in any way it sees fit,
|  but it is RECOMMENDED that priority be given to the user ID with
|  the most recent self signature.

>From 5.2.3.3. Notes on Self-Signatures:

   Since a self-signatures contain important information about the
   key's use, an implementation SHOULD allow the user to rewrite the
   self-signature, and important information in it, such as preferences
   and key expiration.
|  An implementation that encounters multiple self-signatures on the
|  same object may resolve the ambiguity in any way it sees fit, but
|  it is RECOMMENDED that priority be given to the most recent
|  self-signature.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 13:44:45 -0400
Sender: [email-masked]

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

Ingo Luetkebohle replied:
> Well, associating all sorts of special meanings to the pre-S2K byte is
> somewhat of a mess, too, isn't it?
>
> IMHO, it would have been a lot cleaner to *always* use an S2K
> specifier and then have a 0 symmetric algorithm value for "no

Of course.  But we already have a pre-S2K byte, for compatibility
with PGP2, which won't go away.

> encryption". Then, I would have liked a length byte to precede the
> public key data so that you can just skip it entirely without having

If you plan to do any consistency checking on the parameters,
you'll need parse it anyway.  If you include them in the hash,
then you might be willing to skip the checks sometimes, but
then you'd at least need to digest the material (but admittedly
not interpret it).

Rather than put in a length, I'd just put in the whole public
key packet.  That would also allow the secret key packet to have
its own (independent) version number.

> to parse all of the MPI's. Additionally, the differences between the
> different session key packets could have been reduced and aligned to
> be similiar to the encrypted data packet so that the same header
> fields are aligned at the same offsets for all packet types and only
> thes differing fields are at different offsets.

Sure, a clean-slate design might do all of these things.  But our
slate is well-used.  On the whole, that's a good thing ;-).

Most implementations will want to support older formats anyway.
Adding a substantially new format, even if it alone is easier to
parse, means more code than an isolated tweak on the old one.
I wouldn't open the door to any old hack, but this one feels good.

Date: Fri, 24 Aug 2001 10:36:14 -0700
From: [email-masked]
To: [email-masked]
Subject: Re: Encoding "secret key is hashed"
Sender: [email-masked]

On Fri, 24 Aug 2001 11:58:38 -0400, Michael Young said:

> I strongly recommend hashing the entire contents, including the public
> key material.  If you wanted to leave out the material between the

I agree as well with this concept.  The fingerprint calculation also
hashes the creation date and key algorithm; the former is not needed and
was an unfortunate decision, but it is a good idea to protect the latter
(conceivably we could have a case in the future where changing the PK
algorithm and tweaking some MPI values could cause harm).

The question is whether we should include the intervening material between
the public and private key portions.  In some ways that could simplify
the implementor's task, but depending on the order in which parsing and
hashing is done, the data might not be quite as handy as it sounds.

As for the packet algorithm, from implementation experience it is
inconvenient to have public and private parts for the same key with
different versions.  An earlier version of PGP, I think 2.6.0 or .1,
had a bug where if you changed your passphrase your secret key version
would get bumped from 2 to 3 but the public key version stayed the same.
This leads to situations where you import just the secret key packet
and synthesize a public key packet for it, which will also have V3.
Maybe it gets signed and the sig calculated on the version byte of 3.
Then later you see the original public key packet with V2, and signatures
on it calculated on that basis.  It was a real mess and we still have
kludges in our code to deal with this.

So I would recommend that we stick with V4 on the secret key packet.

Hal

Date: Fri, 24 Aug 2001 19:27:40 +0200
From: [email-masked]
Organization: .NO.SPaM.NET
To: Edwin Woudt <[email-masked]>
CC: [email-masked]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Sender: [email-masked]

Edwin Woudt wrote:
> [email-masked] wrote:
> > v5 seckey packet will broke seckey exchange with older versions,
> > while new s2k not - it will still be possible to import seckey in older
> > ver with aged workaround - unprotect them, export, import into older ver,
> > protect again.
> 
> Uhm... this approach will also work for v5 secret key packets: just
> unprotect and convert the packet to v4 before exporting.

it's easy to unprotect (just set passphrase to nothing) but not to convert to v4....

== <EOF> ==
Disastry
http://i.am/disastry/

Date: Fri, 24 Aug 2001 19:23:59 +0200
From: Edwin Woudt <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Sender: [email-masked]

[email-masked] wrote:

> v5 seckey packet will broke seckey exchange with older versions,
> while new s2k not - it will still be possible to import seckey in older
> ver with aged workaround - unprotect them, export, import into older ver,
> protect again.

Uhm... this approach will also work for v5 secret key packets: just 
unprotect and convert the packet to v4 before exporting.

Edwin

Date: Fri, 24 Aug 2001 18:43:14 +0200
From: [email-masked]
Organization: .NO.SPaM.NET
To: [email-masked]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Sender: [email-masked]

Edwin Woudt wrote:

> Jon Callas <[email-masked]> replied:
> >
> > I think an S2K that includes a hash is only mildly hackish, myself. I'd
> > support this. I'd even support an additional one that is merely salted
> > with a hash.
> 
> 
> I disagree. As Werner Koch already pointed out, the 'correct' solution is 
> to introduce version 5 of the secret key packet. I however do not think 
> that there is any real reason for introducing a v5 public key packet, given 
> that nothing changed for public key packets.
> 
> Keeping v4 public key packets will make sure nothing is broken with regard 
> to exchanging public keys. Exchanging secret keys with older 
> implementations will be broken in both cases anyway, because of the new s2k 
> type.
> 
> Edwin

v5 seckey packet will broke seckey exchange with older versions,
while new s2k not - it will still be possible to import seckey in older ver
with aged workaround - unprotect them, export, import into older ver, protect again.

== <EOF> ==

To: <[email-masked]>
Subject: Re: Encoding "secret key is hashed"
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 24 Aug 2001 18:51:28 +0200
Lines: 13
Sender: [email-masked]

On Fri, 24 Aug 2001 11:58:38 -0400, Michael Young said:

> I strongly recommend hashing the entire contents, including the public
> key material.  If you wanted to leave out the material between the

I agree with your proposal.

  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: Fri, 24 Aug 2001 18:42:17 +0200
From: Ingo Luetkebohle <[email-masked]>
To: Michael Young <[email-masked]>
Cc: [email-masked]
Subject: Re: Encoding "secret key is hashed"
Organization: Maybe when I grow up
Sender: [email-masked]

--0ntfKIWw70PvrIHh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 24, 2001 at 11:09:35AM -0400, Michael Young wrote:
> No, I don't want both changes.  Originally, I liked a version
> change, but I've been convinced that its implications are a mess.

Well, associating all sorts of special meanings to the pre-S2K byte is
somewhat of a mess, too, isn't it?

IMHO, it would have been a lot cleaner to *always* use an S2K
specifier and then have a 0 symmetric algorithm value for "no
encryption". Then, I would have liked a length byte to precede the
public key data so that you can just skip it entirely without having
to parse all of the MPI's. Additionally, the differences between the
different session key packets could have been reduced and aligned to
be similiar to the encrypted data packet so that the same header
fields are aligned at the same offsets for all packet types and only
thes differing fields are at different offsets.

*phew*. Excuse the rant. I have just been through implementation of a
key parser and will calm down any minute now.

Regards

--=20
	Ingo Luetkebohle / [email-masked] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--0ntfKIWw70PvrIHh
Content-Type: application/pgp-signature
Content-Disposition: inline

--0ntfKIWw70PvrIHh--

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 11:58:38 -0400
Sender: [email-masked]

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

I like most of Werner Koch's edits.

One section that concerned me was:

> |  The 20 byte SHA-1 digest that follows the algorithm-specific
> |  portion is computed by hashing the plaintext of all the
> |  algorithm-specific octets (including MPI prefix and data). It is
> |  always encrypted like the algorithm-specific data. The deprecated 

I strongly recommend hashing the entire contents, including the public
key material.  If you wanted to leave out the material between the
public-key and secret-key parameters (that is, the pre-S2K byte,
the S2K, and the IV), I could accept that, but I think it would
be more convenient and consistent to include them.

Here's my stab at a description, based on Werner's draft:

| The 20 byte SHA-1 digest that follows the algorithm-specific portion
| is computed by hashing:
|     the public key contents (exactly as for fingerprints,
|       see "KeyIDs and Fingerprints");
|     followed by the secret key packet contents,
|       including the plaintext of the algorithm-specific data
|       (including any MPI prefixes and data).
| The digest is appended to the secret-key parameters, and is
| encrypted along with them, without any CFB resynchronization.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 11:09:35 -0400
Sender: [email-masked]

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

"Edwin Woudt" <[email-masked]> wrote:
> I assume that you still want to change the version number to 5 as in your 
> March posting?

No, I don't want both changes.  Originally, I liked a version
change, but I've been convinced that its implications are a mess.

It seemed that others were uncomfortable with having the the public
and secret key versions out of sync, and I can appreciate that.  The
version number is included in the hashes for fingerprints and for
signatures, so one would either have to map "secret version 5" to
"public version 4", or include the public-key version number in the
secret-key packet.  The latter is cleaner, but it still may be
a little disruptive.

So, Hal Finney's suggestion (change the pre-S2K byte) sounded like
a fair alternative, as it wouldn't require changing the version number,
but it also doesn't disrupt the S2K (which is used elsewhere).

...

By the way, this hash would include *all* the key material, including
the public part, right?

To: <[email-masked]>
Subject: Re: Encoding "secret key is hashed"
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 24 Aug 2001 16:49:21 +0200
Lines: 60
Sender: [email-masked]

On Fri, 24 Aug 2001 09:07:01 -0400, Michael Young said:

> Hal Finney offered the following alternative, which I like
> much better than tweaking the S2K itself:

>> Another place we could represent the alternative format is the byte
>> which comes shortly before the S2K in the secret key packet.  This
>> byte is fixed at a value of 255 to flag that an S2K is in use.  We
>> could perhaps use some alternate value for this byte to flag that the
>> private key is using a different form of checksum protection.

> Perhaps a value of 254?

I certainly support this. So what about this:

     - One octet indicating string-to-key usage conventions.  0
|      indicates that the secret key data is not encrypted.  Values 1
|      to 127 are symmetric-key encryption algorithm specifiers.
|      Values 128 to 253 are reserved. A value of 254 indicates that
|      that a string-to-key specifier is being given, 255 indicates
|      the same but makes use of the deprecated two-octet checksum.

|    - [Optional] If string-to-key usage octet was 254 or 255, a
       one-octet symmetric encryption algorithm.

|    - [Optional] If string-to-key usage octet was 254 or 255, a
       string-to-key specifier.  The length of the string-to-key
       specifier is implied by its type, as described above.

|    - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

     - Encrypted multi-precision integers comprising the secret key
       data. These algorithm-specific fields are as described below.

|    - If the string-to-key usage octet was 254 a 20 byte SHA-1 digest
|      of the algorithm-specific portion.  Otherwise a two-octet
       checksum of the plaintext of the algorithm-specific portion
       (sum of all octets, mod 65536).

   [....]

|  The 20 byte SHA-1 digest that follows the algorithm-specific
|  portion is computed by hashing the plaintext of all the
|  algorithm-specific octets (including MPI prefix and data). It is
|  always encrypted like the algorithm-specific data. The deprecated 
   16-bit checksum that follows the algorithm-specific portion is
   the algebraic sum, mod 65536, of the plaintext of all the algorithm-
   specific octets (including MPI prefix and data).  With V3 keys, the
   checksum is stored in the clear.  With V4 keys, the checksum is
   encrypted like the algorithm-specific data.  This value is used to
|  check that the passphrase was correct.  Implementations SHOULD only
|  use the 20 byte SHA-1 digest.

-- 
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: Fri, 24 Aug 2001 16:36:54 +0200
From: Edwin Woudt <[email-masked]>
To: Michael Young <[email-masked]>, [email-masked]
Subject: Re: Encoding "secret key is hashed"
Sender: [email-masked]

Michael Young <[email-masked]> wrote:

> Back in March, I opined that an S2K bit was out of place,
> noting that the S2K itself isn't broken, and that it is
> used in other contexts.

I agree.

> Hal Finney offered the following alternative, which I like
> much better than tweaking the S2K itself:
>
>> Another place we could represent the alternative format is the byte
>> which comes shortly before the S2K in the secret key packet.  This
>> byte is fixed at a value of 255 to flag that an S2K is in use.  We
>> could perhaps use some alternate value for this byte to flag that the
>> private key is using a different form of checksum protection.
>
> Perhaps a value of 254?

I assume that you still want to change the version number to 5 as in your 
March posting?

In that case, I do not really see a reason to bother with changing this 
value at all, because there is no real reason to support the old checksum 
protection for version 5 keys anyway.

> On a slightly related note, could we also add placeholders
> to the spec for the NAI-specific things that have come into
> practice?  One example is the S2K bits for raw and split keys,
> which is why it came to mind now.  Hal mentioned an X.509
> certificate signature subpacket, and a CRL packet type.  The
> PhotoID packet is yet another that was discussed recently.

This would indeed be helpful.

Edwin

To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: Preparing a new draft...
From: Derek Atkins <[email-masked]>
Date: 24 Aug 2001 10:09:25 -0400
Lines: 37
Sender: [email-masked]

Florian Weimer <[email-masked]> writes:

> "Michael Young" <[email-masked]> writes:
> 
> > Derek Atkins asked:
> > > Have you looked into why it is faster?
> > 
> > A partial-body encoding requires a power-of-two sized buffer be
> > repeatedly filled (completely, or until end-of-input), and then copied
> > to the output stream.  An indeterminate encoding has no length
> > information whatsoever, and so requires no buffering or copying.
> 
> In conjunction with compression, the claim that this affects
> performance is a bit peculiar because compression itself typically
> requires such buffering, and adds much more overhead anyway.

That was my impression as well.  Considering that most modern Unix
systems have some amount of buffering ANYWAYS in the I/O system, I
can't see how doing extra buffering really affects anything.  It's not
like you can really do a copy-in-place because you need to prepend
PGP-packet headers before the transformed data.  And, as you say,
compression has to buffer data anyways.

When Colin and I were first working on this back in '95, we _did_
buffer the data, and quite honestly it seemed to work just fine; much
better than writing to a file like PGP 2.x did.  And yes, we'd
definitely try to reduce the number of memcpy() functions that had to
happen.  But it's just as easy to encrypt-in-place as it is to
encrypt-to-a-different-buffer.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

To: [email-masked]
Subject: Re: Preparing a new draft...
From: Florian Weimer <[email-masked]>
Date: 24 Aug 2001 15:45:27 +0200
Lines: 18
Sender: [email-masked]

"Michael Young" <[email-masked]> writes:

> Derek Atkins asked:
> > Have you looked into why it is faster?
> 
> A partial-body encoding requires a power-of-two sized buffer be
> repeatedly filled (completely, or until end-of-input), and then copied
> to the output stream.  An indeterminate encoding has no length
> information whatsoever, and so requires no buffering or copying.

In conjunction with compression, the claim that this affects
performance is a bit peculiar because compression itself typically
requires such buffering, and adds much more overhead anyway.

Date: Fri, 24 Aug 2001 15:41:12 +0200
From: Ingo Luetkebohle <[email-masked]>
To: Edwin Woudt <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Klima/Rosa attack (was: Re: Diffs for next draft)
Organization: Maybe when I grow up
Sender: [email-masked]

On Fri, Aug 24, 2001 at 02:35:01PM +0200, Edwin Woudt wrote:
> Keeping v4 public key packets will make sure nothing is broken with regard 
> to exchanging public keys. Exchanging secret keys with older 
> implementations will be broken in both cases anyway, because of the new s2k 
> type.

I second Edwins opinion and would be in favor of a v5 secret key
format to solve the issue.

Ingo

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Encoding "secret key is hashed"
Date: Fri, 24 Aug 2001 09:07:01 -0400
Sender: [email-masked]

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

Back in March, I opined that an S2K bit was out of place,
noting that the S2K itself isn't broken, and that it is
used in other contexts.

Hal Finney offered the following alternative, which I like
much better than tweaking the S2K itself:

> Another place we could represent the alternative format is the byte
> which comes shortly before the S2K in the secret key packet.  This
> byte is fixed at a value of 255 to flag that an S2K is in use.  We
> could perhaps use some alternate value for this byte to flag that the
> private key is using a different form of checksum protection.

Perhaps a value of 254?

...

On a slightly related note, could we also add placeholders
to the spec for the NAI-specific things that have come into
practice?  One example is the S2K bits for raw and split keys,
which is why it came to mind now.  Hal mentioned an X.509
certificate signature subpacket, and a CRL packet type.  The
PhotoID packet is yet another that was discussed recently.

Date: Fri, 24 Aug 2001 14:35:01 +0200
From: Edwin Woudt <[email-masked]>
To: Jon Callas <[email-masked]>, [email-masked]
Subject: Klima/Rosa attack (was: Re: Diffs for next draft)
Sender: [email-masked]

Werner Koch <[email-masked]> wrote>
>> The correct solution would be to introduce a version 5 of the secret
>> key packet - this is a major change as we may also want to also
>> introduce a v5 public key packet for symmetry reasons.  I guess this
>> will break a lot of code.
>>
>> The hackish solution is to define a new S2K type identical to type 3
>> (iterated and salted) which would then trigger the use of the new
>> SHA-1 checksum.  It should be made clear that this S2K type is only to
>> be used for the protection of the secret key and not for conventional
>> encryption.
>>
>> I don't like any of these solutions but the latter one is easier to
>> implement. Any other ideas?

Jon Callas <[email-masked]> replied:
>
> I think an S2K that includes a hash is only mildly hackish, myself. I'd
> support this. I'd even support an additional one that is merely salted
> with a hash.

I disagree. As Werner Koch already pointed out, the 'correct' solution is 
to introduce version 5 of the secret key packet. I however do not think 
that there is any real reason for introducing a v5 public key packet, given 
that nothing changed for public key packets.

Keeping v4 public key packets will make sure nothing is broken with regard 
to exchanging public keys. Exchanging secret keys with older 
implementations will be broken in both cases anyway, because of the new s2k 
type.

Edwin

Date: Thu, 23 Aug 2001 21:53:55 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
Sender: [email-masked]

>>The correct solution would be to introduce a version 5 of the secret
>>key packet - this is a major change as we may also want to also
>>introduce a v5 public key packet for symmetry reasons.  I guess this
>>will break a lot of code.
>>
>>The hackish solution is to define a new S2K type identical to type 3
>>(iterated and salted) which would then trigger the use of the new
>>SHA-1 checksum.  It should be made clear that this S2K type is only to
>>be used for the protection of the secret key and not for conventional
>>encryption.
>>
>>I don't like any of these solutions but the latter one is easier to
>>implement. Any other ideas?

I think an S2K that includes a hash is only mildly hackish, myself. I'd
support this. I'd even support an additional one that is merely salted with
a hash.

	Jon

Date: Fri, 24 Aug 2001 00:59:06 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Diffs for next draft
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Aug 24, 2001 at 12:06:09AM -0400, Michael Young wrote:

> The description of the "Primary User ID" subpacket says:
> 
> >    If more than one user id in a key is marked as primary, the
> >    implementation may resolve the ambiguity in any way it sees fit.
> 
> It seems that the most likely reason for a second "primary"
> is that it has been updated.  If so, it seems that one should
> defer to the most recent valid signature.  Can we say
> that an implementation "SHOULD" do that, rather than leaving
> it open?

The draft does say "...an implementation SHOULD allow the user to
rewrite the self-signature, and important information in it, such as
preferences and key expiration", which implies that the implementation
should be able to rewrite the self-signatures to remove the primary
subpacket from one and place it onto the other.

That said, there is certainly going to be an implementation that just
merges things together so there is more than one self-signature on a
given user ID.  The keyservers do this now, I believe.

Perhaps (in addition to what you suggest), it would be good to include
language that suggests that in cases of multiple self-signatures on a
single user ID, the most recent should be followed.

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Fri, 24 Aug 2001 00:43:24 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Diffs for next draft
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Aug 23, 2001 at 11:42:53AM -0700, Jon Callas wrote:

> >I am a little bit curious, can you give a rational why the feature
> >flags are not bit encoded?
> >
> 
> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I think this would be better as a bit vector.  Most everything else
that is of this type of list-of-something data (key server prefs, key
flags) uses bits.  Also, many years down the road we could have a lot
of feature flags, and bits are neater.

Incidentally, in 2440bis-02, the key server subpacket is defined as "N
octets of flags" and the key flags subpacket is defined as "Octet
string".  These should probably be the same. :)

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

Date: Thu, 23 Aug 2001 21:08:30 -0700
To: "Michael Young" <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Encoding of "features" subpacket
Sender: [email-masked]

At 11:51 PM -0400 8/23/01, Michael Young wrote:
>At first, I accepted the explanation in the current draft, that this act like
>other "preferences".  But the only preferences encoded that way are
>algorithms lists; but algorithms are already encoded as bytes, and in
>the lists, order matters.  Features feel more like the keyserver or key
>flags, which are bit-encoded.
>

Good point. Anyone else want to weigh in? I'm now leaning to changing it.

	Jon

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Diffs for next draft
Date: Fri, 24 Aug 2001 00:06:09 -0400
Sender: [email-masked]

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

The description of the "Primary User ID" subpacket says:

>    If more than one user id in a key is marked as primary, the
>    implementation may resolve the ambiguity in any way it sees fit.

It seems that the most likely reason for a second "primary"
is that it has been updated.  If so, it seems that one should
defer to the most recent valid signature.  Can we say
that an implementation "SHOULD" do that, rather than leaving
it open?

I suppose it would be possible to revoke the old signature with a
"primary" subpacket, and then issue a new signature for both the old
and new name.  (The "Reason for Revocation" values include one to
indicate the *key* being superceded, and one to indicate that the user
ID information is no longer valid, but not one to indicate that the
signature has been superceded.)  This seems like a long way to
go to deal with a lack of a firm disambiguation policy.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Encoding of "features" subpacket
Date: Thu, 23 Aug 2001 23:51:01 -0400
Sender: [email-masked]

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

>I am a little bit curious, can you give a rational why the feature
> >> >flags are not bit encoded?
> >
> 
> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

At first, I accepted the explanation in the current draft, that this act like
other "preferences".  But the only preferences encoded that way are
algorithms lists; but algorithms are already encoded as bytes, and in
the lists, order matters.  Features feel more like the keyserver or key
flags, which are bit-encoded.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Preparing a new draft...
Date: Thu, 23 Aug 2001 23:31:40 -0400
Sender: [email-masked]

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

From: "Werner Koch" <[email-masked]>
> On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:
> 
> > You could use new packet lengths to create a stream of packets...
> 
> Well, this is actually done except when the packet is a compressed
> one.  Then we use the old PGP 2.6 method which is a little bit
> faster.  The RFC allows for this.

It's not clear to me what the RFC really allows.  (It is clear that
indeterminate encodings are not *recommended* at any time.)

The RFC first says:
    "If the packet is in a file, this means that the packet
     extends until the end of the file."

It then goes on to say "where the end of the data will be
clear from the context", which is a little more liberal.
I suppose you could interpret "in a file" as "is an
entire file".

In this context, the end is only clear because an *outer*
packet had a hard length.  Using a hard length there seems
inconsistent -- if you're generating output as you go,
you wouldn't know the outer size either.

Werner said earlier:
> Sure, there is no other way to do this when you don't know the length of
> the text in advanced.  This is very common for Unix tools and that
> feature is one of the great advantages of OpenPGP.

I agree that the ability to structure as a "filter" is an advantage.
The partial-body packet encoding achieves this, without having to rely
on some external container (file, or an outer packet) bounding the
length.

If anything, having a truly indeterminate packet inside another packet
makes it harder to use a filter-like implementation for parsing.

Derek Atkins asked:
> Have you looked into why it is faster?

A partial-body encoding requires a power-of-two sized buffer be
repeatedly filled (completely, or until end-of-input), and then copied
to the output stream.  An indeterminate encoding has no length
information whatsoever, and so requires no buffering or copying.

Date: Thu, 23 Aug 2001 18:20:32 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: New draft sent out.
Sender: [email-masked]

You'll see it when it pops out the other end. I fixed a couple of typos I
found in a last scan, too.

	Jon

Date: Thu, 23 Aug 2001 18:08:02 -0700
To: Edwin Woudt <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
Sender: [email-masked]

Thanks. I put those in.

	Jon

Date: Fri, 24 Aug 2001 00:09:33 +0200
From: Edwin Woudt <[email-masked]>
To: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Diffs for next draft
Sender: [email-masked]

Jon Callas <[email-masked]> wrote:

> Here's everything I have. If there's something you want me to do and I've
> been obtuse, let me know again, and it'll get in. I'm planning on
> submitting the draft in about 24 hours. I can always do another one when
> something's omitted, so don't panic.

Here is another clarification of something that was unclear to me at first 
sight (again I needed interoperability testing to figure this out):

--- draft-ietf-openpgp-rfc2440bis-02.txt.orig   Thu Aug 23 21:40:19 2001
+++ draft-ietf-openpgp-rfc2440bis-02.txt        Fri Aug 24 00:02:20 2001
@@ -904,7 +904,9 @@
        which is equivalent to V3 in all other respects.

      - An eight-octet number that gives the key ID of the public key
-       that the session key is encrypted to.
+       that the session key is encrypted to. If the session key is
+       encrypted to a subkey then the key ID of this subkey is used
+       here instead of the key ID of the primary key.

      - A one-octet number giving the public key algorithm used.

@@ -3100,6 +3102,10 @@
    Also note that if V3 and V4 format keys share the same RSA key
    material, they will have different key ids as well as different
    fingerprints.
+
+   Finally, the key ID and fingerprint of a subkey are calculated in the
+   same way as for a primary key, including the 0x99 as the first byte
+   (even though this is not a valid packet ID for a public subkey).

 12. Notes on Algorithms

To: Werner Koch <[email-masked]>
Cc: [email-masked]
Subject: Re: Preparing a new draft...
From: Derek Atkins <[email-masked]>
Date: 23 Aug 2001 17:17:12 -0400
Lines: 25
Sender: [email-masked]

Have you looked into why it is faster?

-derek

Werner Koch <[email-masked]> writes:

> On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:
> 
> > You could use new packet lengths to create a stream of packets...
> 
> Well, this is actually done except when the packet is a compressed
> one.  Then we use the old PGP 2.6 method which is a little bit
> faster.  The RFC allows for this.
> 
> -- 
> 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
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

To: [email-masked]
Subject: Re: Preparing a new draft...
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 23 Aug 2001 22:00:21 +0200
Lines: 12
Sender: [email-masked]

On 23 Aug 2001 19:39:39 +0200, Florian Weimer said:

> You could use new packet lengths to create a stream of packets...

Well, this is actually done except when the packet is a compressed
one.  Then we use the old PGP 2.6 method which is a little bit
faster.  The RFC allows for this.

-- 
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: Thu, 23 Aug 2001 11:42:53 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
Sender: [email-masked]

Late last night, I replied to Werner, not to the list. Here's my reply to
him, and his reply to me (with permission).

	Jon

To: Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft

In our last episode ("Re: Diffs for next draft", shown on 8/23/01), Werner
Koch said:

>On Wed, 22 Aug 2001 15:52:12 -0700, Jon Callas said:
>
>> Here's everything I have. If there's something you want me to do and I've
>> been obtuse, let me know again, and it'll get in. I'm planning on
>
>Did someone else also checked that the OIDs for SHA-xxx are correct?
>

I haven't, myself. I'll put that on my list.

>I am a little bit curious, can you give a rational why the feature
>flags are not bit encoded?
>

No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
vector. Does anyone else have an opinion.

>What about the Klima/Rosa attack?  If this draft is going to be the
>next RFC we should do something about it.  IIRC, we had not much
>discussion about it. The obvious fix would be use a hash instead of
>the simple checksum.  The problem is how to indicate the use of this
>new format.
>
>The correct solution would be to introduce a version 5 of the secret
>key packet - this is a major change as we may also want to also
>introduce a v5 public key packet for symmetry reasons.  I guess this
>will break a lot of code.
>
>The hackish solution is to define a new S2K type identical to type 3
>(iterated and salted) which would then trigger the use of the new
>SHA-1 checksum.  It should be made clear that this S2K type is only to
>be used for the protection of the secret key and not for conventional
>encryption.
>
>I don't like any of these solutions but the latter one is easier to
>implement. Any other ideas?

Let's put this on the list of things to do after this draft for the next one.

John wants to push to a new RFC. Here are three open issues.

	Jon

To: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[email-masked]
Date: 23 Aug 2001 10:00:48 +0200
Lines: 25

Jon,

[It seems that you didn't post to the list.]

On Thu, 23 Aug 2001 00:26:17 -0700, Jon Callas said:

> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I have no problem with that, it is just that other attributes use bit
vectors.  Let's keep it as it is.  Can we start to use it and change
our keys to include feature flags?

> Let's put this on the list of things to do after this draft for the next one.

> John wants to push to a new RFC. Here are three open issues.

Okay.

  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: Thu, 23 Aug 2001 11:39:59 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: This draft or next?
Sender: [email-masked]

Late last night, I replied to Werner, not to the list. Here's his reply to
me, from which you can figure out my reply.

	Jon

To: Jon Callas <[email-masked]>
Subject: Re: Diffs for next draft
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
X-PGP-KeyID: 621CC013
X-Request-PGP: finger://[email-masked]
Date: 23 Aug 2001 10:00:48 +0200
Lines: 25

Jon,

[It seems that you didn't post to the list.]

On Thu, 23 Aug 2001 00:26:17 -0700, Jon Callas said:

> No. A byte vector seemed like a reasonable thing. I suppose we can do a bit
> vector. Does anyone else have an opinion.

I have no problem with that, it is just that other attributes use bit
vectors.  Let's keep it as it is.  Can we start to use it and change
our keys to include feature flags?

> Let's put this on the list of things to do after this draft for the next one.

> John wants to push to a new RFC. Here are three open issues.

Okay.

  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

To: [email-masked]
Subject: Re: Preparing a new draft...
From: Florian Weimer <[email-masked]>
Date: 23 Aug 2001 19:39:39 +0200
Lines: 14
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> > GnuPG encodes the <plaintext> using an old-style indeterminate
> > length packet.  This requires a parser to carve off the
> 
> Sure, there is no other way to do this when you don't know the length of
> the text in advanced.

You could use new packet lengths to create a stream of packets...

To: "Michael Young" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Preparing a new draft...
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 23 Aug 2001 17:39:10 +0200
Lines: 46
Sender: [email-masked]

On Thu, 23 Aug 2001 10:23:16 -0400, Michael Young said:

> Here (my perception of) the structure of a integrity-protected
> packet sequence:

>     SEIP-data packet {
>         <version=1>
>         encrypt-CFBn[key](
>             <plaintext>
>             MDC packet { SHA-1 hash }
>         )
>     }

Correct, however the plaintyext is usually a compressed packet but can
be any other packet as allowed by the OpenPGP grammar.  That the MDC
has a form of a packet is probably due to my request because it can
make things easier.  However an implementation can ignore the fact
that this is a packet and handle it just like a checksum with a fixed
header.

> GnuPG encodes the <plaintext> using an old-style indeterminate
> length packet.  This requires a parser to carve off the

Sure, there is no other way to do this when you don't know the length of
the text in advanced.  This is very common for Unix tools and that
feature is one of the great advantages of OpenPGP.

>     Is the <plaintext> *required* to be an "OpenPGP message"?

Yes.

>     Are indeterminate packets legal inside other indeterminate
>     packets?  If not, are they legal inside strictly bounded

Yes. 

There are only a few places where such packets are not allowed.  I
think this is the case for key packets but I am not sure what the
specs do say; GnuPG handles this automagically.

  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: Preparing a new draft...
Date: Thu, 23 Aug 2001 10:23:16 -0400
Sender: [email-masked]

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

On the subject of MDC packets, I'd like to note a peculiarity
in the GnuPG implementation, and ask whether others consider
it reasonable, in accordance with the specification.

Here (my perception of) the structure of a integrity-protected
packet sequence:

    SEIP-data packet {
        <version=1>
        encrypt-CFBn[key](
            <plaintext>
            MDC packet { SHA-1 hash }
        )
    }

The discussion of the SEIP-data packet doesn't say so explicitly,
but the <plaintext> would be an "OpenPGP message" in the
packet sequence grammar.  Is that required, or simply
a convention?

GnuPG encodes the <plaintext> using an old-style indeterminate
length packet.  This requires a parser to carve off the
MDC packet *from the end* in order to properly bound the
interpretation of that packet.  I can think of at least two
approaches to doing so, but neither is very satisfying:

    Use the bounds provided by the outer packet to limit the
    size of the <plaintext> region.  In a recursive filter-style
    parser, this is unnatural -- rather than consuming a generic
    input stream, the parser must also be given the bounds of
    that stream (and that bound must be carried through any
    layers that might reach another parsing step).  Moreover,
    there is no requirement that the outer packet be bounded;
    it could very reasonably use an old-style indeterminate or
    new-style partial-body encoding itself.

    Maintain a 22-byte lookahead buffer.  If the outer packet
    has indeterminate (*or partial-body*) length, and the
    <plaintext> has indeterminate length, this seems to be the
    only viable option.  (If the <plaintext> could be something
    other than a "OpenPGP message", then it is effectively
    indeterminate.  Partial-body encodings present no problem.)

So, my questions are:

    Is the <plaintext> *required* to be an "OpenPGP message"?

    Are indeterminate packets legal inside other indeterminate
    packets?  If not, are they legal inside strictly bounded
    packets?

Thanks in advance for your thoughts.

To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Diffs for next draft
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 23 Aug 2001 09:16:10 +0200
Lines: 37
Sender: [email-masked]

On Wed, 22 Aug 2001 15:52:12 -0700, Jon Callas said:

> Here's everything I have. If there's something you want me to do and I've
> been obtuse, let me know again, and it'll get in. I'm planning on

Did someone else also checked that the OIDs for SHA-xxx are correct?

I am a little bit curious, can you give a rational why the feature
flags are not bit encoded? 

What about the Klima/Rosa attack?  If this draft is going to be the
next RFC we should do something about it.  IIRC, we had not much
discussion about it. The obvious fix would be use a hash instead of
the simple checksum.  The problem is how to indicate the use of this
new format.

The correct solution would be to introduce a version 5 of the secret
key packet - this is a major change as we may also want to also
introduce a v5 public key packet for symmetry reasons.  I guess this
will break a lot of code.

The hackish solution is to define a new S2K type identical to type 3
(iterated and salted) which would then trigger the use of the new
SHA-1 checksum.  It should be made clear that this S2K type is only to
be used for the protection of the secret key and not for conventional
encryption.

I don't like any of these solutions but the latter one is easier to
implement. Any other ideas?

  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, 22 Aug 2001 15:52:12 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Diffs for next draft
Sender: [email-masked]

Here's everything I have. If there's something you want me to do and I've
been obtuse, let me know again, and it'll get in. I'm planning on
submitting the draft in about 24 hours. I can always do another one when
something's omitted, so don't panic.

	Jon

3,6c3,6
< Category: INTERNET-DRAFT                  Counterpane Internet Security
< draft-ietf-openpgp-rfc2440bis-02.txt
< Expires Apr 2001                                       Lutz Donnerhacke
< October 2000                         IN-Root-CA Individual Network e.V.
---
> Category: INTERNET-DRAFT                       Wave Systems Corporation
> draft-ietf-openpgp-rfc2440bis-03.txt
> Expires Feb 2002                                       Lutz Donnerhacke
> August 2001                          IN-Root-CA Individual Network e.V.
15c15
<                  draft-ietf-openpgp-rfc2440bis-02.txt
---
>                  draft-ietf-openpgp-rfc2440bis-03.txt
18c18
< Copyright 2000 by The Internet Society. All Rights Reserved.
---
> Copyright 2001 by The Internet Society. All Rights Reserved.
400,401c400,401
< 15       -- Symmetrically Encrypted and Integrity Protected Data Packet
< 16       -- Modification Detection Code Packet
---
> 18       -- Symmetrically Encrypted and Integrity Protected Data Packet
> 19       -- Modification Detection Code Packet
530a531,540
> Algorithm Specific Fields for ElGamal signatures:
> .block on -
> MPI of ElGamal value a = g**k mod p.
> MPI of ElGamal value b = (h-a*x)/k mod p-1.
> .block off
>
> The hash h is PKCS-1 padded exactly the same way as for the above
> described RSA signatures.
>
>
537a548,550
> SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
> SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
> SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
545a559,561
> SHA256:     2.16.840.1.101.3.4.2.1
> SHA384:     2.16.840.1.101.3.4.2.2
> SHA512:     2.16.840.1.101.3.4.2.3
567a584,598
> .block blank
> SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
>             0x00, 0x04, 0x20
>
> .block blank
> SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
>             0x00, 0x04, 0x30
>
> .block blank
> SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
>             0x00, 0x04, 0x40
>
765a797,799
> Since the user name space is in the form of an email address,
>implementors MAY wish to arrange for that address to reach a person who
>can be consulted about the use of the named tag.  Note that due to UTF-8
>encoding, not all valid user space name tags are valid email addresses.
>
>
852c886
< 1 - Modification Detection (packets 15 and 16)
---
> 1 - Modification Detection (packets 18 and 19)
863c897
< When a signature is made over a key, the hash data starts with the octet
0x99, followed by a two-octet length of the key, and then body of the key
packet. (Note that this is an old-style packet header for a key packet with
two-octet length.) A subkey signature (type 0x18) then hashes the subkey,
using the same format as the main key. Key revocation signatures (types
0x20 and 0x28) hash only the key being revoked.
---
> When a signature is made over a key, the hash data starts with the octet
>0x99, followed by a two-octet length of the key, and then body of the key
>packet. (Note that this is an old-style packet header for a key packet
>with two-octet length.) A subkey signature (type 0x18) then hashes the
>subkey, using the same format as the main key (also using 0x99 as the
>first octet). Key revocation signatures (types 0x20 and 0x28) hash only
>the key being revoked.
1071c1105,1106
< Two-octet checksum of the plaintext of the algorithm-specific portion
(sum of all octets, mod 65536).
---
> Two-octet checksum of the plaintext of the algorithm-specific portion
>(sum of all octets, mod 65536). This checksum is encrypted together with
>the algorithm- specific fields.
>
1172c1207
< .head 2 Sym. Encrypted Integrity Protected Data Packet (Tag 15)
---
> .head 2 Sym. Encrypted Integrity Protected Data Packet (Tag 18)
1204c1239
< .head 2 Modification Detection Code Packet (Tag 16)
---
> .head 2 Modification Detection Code Packet (Tag 19)
1523c1558
< Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other algorithm.
---
> Implementations MUST implement Triple-DES. Implementations SHOULD
>implement AES-128 and CAST5. Implementations that interoperate with PGP
>2.6 or earlier need to support IDEA, as that is the only symmetric cipher
>those versions use. Implementations MAY implement any other algorithm.
1545c1580
< 4          - Reserved for double-width SHA (experimental)
---
> 4          - Reserved for double-width SHA (experimental, obviated)
1548a1584,1586
> 8          - SHA256                                "SHA256"
> 9          - SHA384                                "SHA384"
> 10         - SHA512                                "SHA512"
1754c1792
< If an Elgamal key is to be used for both signing and encryption, extra
care must be taken in creating the key.
---
> If an Elgamal key [ELGAMAL] is to be used for both signing and
>encryption, extra care must be taken in creating the key.
1756c1794
< An ElGamal key consists of a generator g, a prime modulus p, a secret
exponent x, and a public value y = g^x mod p.
---
> An Elgamal key consists of a generator g, a prime modulus p, a secret
>exponent x, and a public value y = g^x mod p.
1764c1802
< Details on safe use of Elgamal signatures may be found in [MENEZES],
which discusses all the weaknesses described above.
---
> Details on safe use of Elgamal signatures may be found in [MENEZES],
>which discusses all the weaknesses described above. Please note that
>Elgamal signatures are controversial; because of the care that must be
>taken with Elgamal keys, many implementations forego them.
1915,1917c1953,1955
< Counterpane Internet Security, Inc.
< 3031 Tisch Way, suite 100 East Plaza
< San Jose, CA 95128, USA
---
> Wave Systems Corp.
> 1601 S. DeAnza Blvd, Suite 200
> Cupertino, CA 95014, USA
1920,1921c1958,1959
< Email: [email-masked], [email-masked]
< Tel: +1 (408) 556-2445
---
> Email: [email-masked], [email-masked]
> Tel: +1 (408) 448-6801
2059c2097
< Copyright 2000 by The Internet Society. All Rights Reserved.
---
> Copyright 2001 by The Internet Society. All Rights Reserved.

To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Wed, 22 Aug 2001 16:46:44 -0400
Subject: Re: PGP versions 5 and later / ciphertext-format query...../ ON_BREAK / No_rush_to_answer..........
From: Joe Tag <[email-masked]>
Sender: [email-masked]

Thank you for teaching me about the different versions of PGP, and about 
the Internet Draft process.  
As an adult student at Kean University, who has attended the 
U.S. National Colloquiem for Information Systems Security Education, as
well as
New York City-Information Systems Security Association meetings, I
apprecciate
the advice and tutoring this list offers. 

I am a "poor-man" ( LOL ), and I have a 386/25MHz machine, and a
486/33MHz computers
at home, with modems.  I only have 8MB RAM max, in each machine. 
At home, I have installed PGP5.0i for DOS.  I am aware I have to be
careful in the setup, and
the paths/subdirectories things are.  I have NO web/WWW access from home;
only dial-up to 
Juno. 

I can research (with some Computer Science professors tutelage) "internet
archives" 
(i.e.: alt.pgp.**x lists), and I have no problems browsing the web;
accessing while
at the Kean University campus (see http://www.kean.edu/~jtag and
http://www.kean.edu ) . 

I look forward to the replacement of TripleDES with Rijndael. 

Best regards, and thanks again! 

     Joe Tag,Jr. 

--- end --- 

On Wed, 22 Aug 2001 11:39:06 -0700 John  W Noerenberg II
<[email-masked]> writes:
> 
> At 7:53 PM +0200 8/21/01, Werner Koch wrote:
> >  > BTW: Why was Radix-64 developed; and what are the problems of 
> having
> >>  ciphertext
> >>  output as a hexadecimal file?
> >
> >Because it produces only an 33% overhead compared to the 100% 
> overhead
> >of plain hexdigits.
> >
> >We need to save some bandwidth so that we can use more funny mail
> >headers :-)
> 
> In addition to being more compact than hex digits, it uses a 
> character symbol set that is considered "safe" across all systems. 
> It 
> wouldn't do if the encoding method included characters that aren't 
> representable or whose numeric equivalent is ambiguous.
> 
> Bandwidth does matter -- even when the email headers are longer than 
> 
> the message....which is goofy, I know...which is why a message 
> saying 
> only "ok" or "thanks" may be polite, but not necessarily the most 
> efficient thing to do.
> 
> best,
> -- 
> 
> john noerenberg
> [email-masked]
>    
> ----------------------------------------------------------------------
>    If you don't even own your own name, how can you have
>    a sense of self-worth?
>      -- Simson Garfinkel, "Database Nation", 2000
>    
> ----------------------------------------------------------------------
> 

-----/signed/ Joe Tag,Jr.; Elizabeth, New Jersey, USA -----
________________________________________________________________
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, 22 Aug 2001 11:39:06 -0700
To: Werner Koch <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
Cc: [email-masked]
Sender: [email-masked]

At 7:53 PM +0200 8/21/01, Werner Koch wrote:
>  > BTW: Why was Radix-64 developed; and what are the problems of having
>>  ciphertext
>>  output as a hexadecimal file?
>
>Because it produces only an 33% overhead compared to the 100% overhead
>of plain hexdigits.
>
>We need to save some bandwidth so that we can use more funny mail
>headers :-)

In addition to being more compact than hex digits, it uses a 
character symbol set that is considered "safe" across all systems. It 
wouldn't do if the encoding method included characters that aren't 
representable or whose numeric equivalent is ambiguous.

Bandwidth does matter -- even when the email headers are longer than 
the message....which is goofy, I know...which is why a message saying 
only "ok" or "thanks" may be polite, but not necessarily the most 
efficient thing to do.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   If you don't even own your own name, how can you have
   a sense of self-worth?
     -- Simson Garfinkel, "Database Nation", 2000
   ----------------------------------------------------------------------

To: <[email-masked]>
Subject: Re: question on Self-Decrypting Messages !!!
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 22 Aug 2001 20:47:27 +0200
Lines: 18
Sender: [email-masked]

On Wed, 22 Aug 2001 11:17:15 -0700, Jon Callas said:

> -- it's probably simpler and easier to just drive over there. So you bundle
> the thing up in a Windows SDA, and email it to your accountant. Then you
> phone the accountant up, tell them the passphrase, and it unpacks your

Nice feature.  So I hope that my competitor uses such a scheme, I am
in the lucky position to have control over a part of the network used
to send the mail, I catch the message add a new feature to the
decrypting code and pass it on.  Some hours laters the trojan
installed on the tax accountant's box starts to send all the
confidential files to an anonymous account somewhere....

-- 
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, 22 Aug 2001 11:17:15 -0700
To: Werner Koch <[email-masked]>, <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: question on Self-Decrypting Messages !!!
Sender: [email-masked]

At 8:46 AM +0200 8/22/01, Werner Koch wrote:
>
>Don't know what SDA is, but self-decrypting messages are a *very
>stupid* idea.  You receive such a message from soneone you don't know,
>you are not able to check the identity of the sender, otherwise you
>would have installed an OpenPGP implemnentation.  So what you do is to
>allow anyone who is able to send you a message to run arbitrary code
>on your box.  It may decrypt the message but you don't know what the
>code does on the side.
>

Well, the uses are limited, but they exist. The once or twice a year you
want them, they're nice. Here's a scenario:

Your tax accountant wants the records you have from your consulting
business do they can properly get your deductions done. Said accountant
can't spell PGP. You're not in the mood to drive an hour to get there, and
you're not in the mood to teach the accountant how to do it over the phone
-- it's probably simpler and easier to just drive over there. So you bundle
the thing up in a Windows SDA, and email it to your accountant. Then you
phone the accountant up, tell them the passphrase, and it unpacks your
files for them.

The general scenario is that you want to send a message to someone who
doesn't use crypto, and isn't going to regularly use it.

	Jon

To: Joe Tag <[email-masked]>
Cc: [email-masked]
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
From: Florian Weimer <[email-masked]>
Date: 22 Aug 2001 18:29:23 +0200
Lines: 16
Sender: [email-masked]

Joe Tag <[email-masked]> writes:

> I believe that PGP 5.0/5.0i is the MINIMUM BASIC version of the
> software that end-users should use.  That version is available for
> IBM PC-DOS/MS-DOS, and supports CAST/Diffie-Hellman, as well as
> IDEA/RSA algorithms and protocols.

PGP 5 has security-related problems and is not compatible with OpenPGP
either.

> BTW: Why was Radix-64 developed; and what are the problems of having
> ciphertext output as a hexadecimal file?

Hexadecimal streams encode 4 bits per character, while Radix-64
streams encode 6 bits per character, so a Radix-64 is somewhat shorter
than a hexadecimal stream.

To: <[email-masked]>
Subject: Re: question on Self-Decrypting Messages !!!
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 22 Aug 2001 08:46:11 +0200
Lines: 38
Sender: [email-masked]

On Tue, 21 Aug 2001 22:50:58 -0500 (CDT), Rezaul H Safiuddin said:

>  If I encrypt a message and send it to someone who doesn't use PGP, I have
>  to use SDA, and somehow give them the password to it, right ?

Don't know what SDA is, but self-decrypting messages are a *very
stupid* idea.  You receive such a message from soneone you don't know,
you are not able to check the identity of the sender, otherwise you
would have installed an OpenPGP implemnentation.  So what you do is to
allow anyone who is able to send you a message to run arbitrary code
on your box.  It may decrypt the message but you don't know what the
code does on the side.

Okay, you can check that the executable part of that message is
identical to a trusted copy you have - but so why don't use your copy
right away.  You need a shared passphrase, this indicates that you
have established a communication link to the sender by another way -
why not also installing regular software.

You can have some software installed on your box which analyzes the
self-decrypting message and compares the executable part with a known
checksum.  I can see no advantages for such a program because it will
have about the same complexity as a normal decrypting software.

And a self-decrypting thing will never be able to check a signature.

All these self-foo things have another major drawback:  They are only
able to do their job on one platform (i.e. CPU and OS).

Ciao,

  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: Tue, 21 Aug 2001 22:50:58 -0500 (CDT)
From: "Rezaul H. Safiuddin" <[email-masked]>
To: <[email-masked]>
Subject: question on Self-Decrypting Messages !!!
Sender: [email-masked]

 If I encrypt a message and send it to someone who doesn't use PGP, I have
 to use SDA, and somehow give them the password to it, right ?

 Is this secured and protected the same way  as Digitally signed and
 encrypted messages that someone who has PGP would receive ?

 I am a newbie in this thing, any help and explanation will be appreciated.
 Also, what's the best way to encrypt mails if I am using 'hotmail' or
 'yahoo' ?

 Thanks  a lot.

To: [email-masked]
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 21 Aug 2001 19:53:54 +0200
Lines: 26
Sender: [email-masked]

On Tue, 21 Aug 2001 13:23:44 -0400, Joe Tag said:

> I believe that PGP 5.0/5.0i is the MINIMUM BASIC version of the software
> that

With the drawback that it far away from OpenPGP compliant and has a
lot of security issues.

> BTW: Why was Radix-64 developed; and what are the problems of having
> ciphertext
> output as a hexadecimal file? 

Because it produces only an 33% overhead compared to the 100% overhead
of plain hexdigits.

We need to save some bandwidth so that we can use more funny mail
headers :-)

Ciao,

  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

To: <[email-masked]>
Subject: Re: mdc
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 21 Aug 2001 19:49:24 +0200
Lines: 19
Sender: [email-masked]

On Tue, 21 Aug 2001 13:13:56 -0400, vedaal  said:

> how does using MDC protect the sender/recipient more than the signing and
> encrypting of the message?

Many users don't bother to check the signature, there are a lot of
situations where you do not wnat to sign a message: think Mixmaster.

And an MDC is the cleaner and correct solution to fix a flaw in the
encryption layer.

Ciao,

  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

To: [email-masked]
Cc: [email-masked]
Date: Tue, 21 Aug 2001 13:23:44 -0400
Subject: Re: Preparing a new draft.../ PGP versions 5 and later / ciphertext-format query.....
From: Joe Tag <[email-masked]>
Sender: [email-masked]

I believe that PGP 5.0/5.0i is the MINIMUM BASIC version of the software
that
end-users should use.  That version is available for IBM PC-DOS/MS-DOS,
and 
supports CAST/Diffie-Hellman, as well as IDEA/RSA algorithms and
protocols. 

BTW: Why was Radix-64 developed; and what are the problems of having
ciphertext
output as a hexadecimal file? 

/signed/ Joe Tag,Jr. 

On 21 Aug 2001 17:54:28 +0200 Florian Weimer
<[email-masked]> writes:
> 
> Jon Callas <[email-masked]> writes:
> 
> > I agree with you that in a perfect world we'd make it mandatory, 
> but people
> > would howl if we did. If we want to move to that as a goal, step 
> one is to
> > deprecate 2.6.
> 
> You could at least mark it 'obsolescent'. ;-)
> 
> -- 
> Florian Weimer                           

http://www.kean.edu/~jtag

-----/signed/ Joe Tag,Jr.; Elizabeth, New Jersey, USA -----
________________________________________________________________
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.

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: mdc
Date: Tue, 21 Aug 2001 13:13:56 -0400
Sender: [email-masked]

assuming that a sender has signed and encrypted a message,

how does using MDC protect the sender/recipient more than the signing and
encrypting of the message?

what tampering can be done with the message that the recipient would not
detect unless mdc were used?

{have read rfc-2440 bis, sections 5.12 and 5.13, but did not understand the
practical security advantages
over signing and encrypting}

tia for any clarifications,

vedaal

To: [email-masked]
Subject: Re: Preparing a new draft...
From: Florian Weimer <[email-masked]>
Date: 21 Aug 2001 17:54:28 +0200
Lines: 12
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> I agree with you that in a perfect world we'd make it mandatory, but people
> would howl if we did. If we want to move to that as a goal, step one is to
> deprecate 2.6.

You could at least mark it 'obsolescent'. ;-)

To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Preparing a new draft...
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 21 Aug 2001 12:40:53 +0200
Lines: 39
Sender: [email-masked]

On Mon, 20 Aug 2001 14:15:13 -0700, Jon Callas said:

> Oh, yes, yes, yes. They are optional. The mandatory algorithms will not
> change from 2440. They are, however, needed to balance with the newer
> ciphers, or public keys bigger than 1024 bits.

Can you check that we don't have 1024 bit limit for DSA keys in
OpenPGP.

> Yeah, I know you did, and I still think it's a hack. A clever hack, but a
> hack. But hey, that's the difference between a standard and an
> implementation. You're perfectly free to do that.

Yeah.  And it is good that it is just a SHOULD rule ;-)

> I don't know, though, that will ever make the use of MDC mandatory. That
> would break backwards compatibility with anything that's gone before you.

Okay.  An implemenation can print a warning if a non MDC is used.

> I'm still incredulous that there are people who steadfastly cling to 2.6!
> At HAL2001, there were people who *still* adamantly insist that 2.6 is the
> only trustworthy PGP version. I don't get it, but I respect it. And hey,

I know and can't count the mails I wrote on the interoperability
problems due to no IDEA in GnuPG and to explain the advantages of
OpenPGP :-(

> would howl if we did. If we want to move to that as a goal, step one is to
> deprecate 2.6.

And of equal importance is to use PGP/MIME.

  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: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Re: Preparing a new draft...
Date: Tue, 21 Aug 2001 07:16:54 +0200
Sender: [email-masked]

On 20 Aug 2001 22:07:29 +0200, you wrote:

>
>On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:
>
<snip>
>Regarding MDC: PGP and GnuPG both implement MDC but without the use of
>the features flag.  A long time ago I agreed with Hal to use MDC with
>all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
>our knowledge no other application did use one of those algorithms at
>that time.   IMHO, it would be good to stress it even more that the
>MDC packets should be used and that it can be expected that future
>revisions of OpenPGP will make the use of MDC mandatory.
>
PGP does not generate MDC packets, it will however interpret them.

Since MDC's are too new, not mandatory, and may cause an application which
does not implement them to fail to decode, a responsible implementor
should not generate such packets unless otherwise instructed by the user.

Remember, the User Is King, the Implementor is not!

my 2c

>Ciao,
>  Werner

Date: Mon, 20 Aug 2001 14:15:13 -0700
To: Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Preparing a new draft...
Cc: [email-masked]
Sender: [email-masked]

At 10:07 PM +0200 8/20/01, Werner Koch wrote:
>On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:
>
>> I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
>> anyone disagree?
>
>Please mark them as optional.  We should also figure out the new DSA
>parameters to be used with those hashes.  Ist there anything available
>from NIST?  I didn't follow the development very closely.
>

Oh, yes, yes, yes. They are optional. The mandatory algorithms will not
change from 2440. They are, however, needed to balance with the newer
ciphers, or public keys bigger than 1024 bits.

>> Do people here want to see diffs of my source before I submit the draft? (I
>
>Pretty please.
>

Will do, then.

>Regarding MDC: PGP and GnuPG both implement MDC but without the use of
>the features flag.  A long time ago I agreed with Hal to use MDC with
>all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
>our knowledge no other application did use one of those algorithms at
>that time.   IMHO, it would be good to stress it even more that the
>MDC packets should be used and that it can be expected that future
>revisions of OpenPGP will make the use of MDC mandatory.
>

Yeah, I know you did, and I still think it's a hack. A clever hack, but a
hack. But hey, that's the difference between a standard and an
implementation. You're perfectly free to do that.

I don't know, though, that will ever make the use of MDC mandatory. That
would break backwards compatibility with anything that's gone before you.
I'm still incredulous that there are people who steadfastly cling to 2.6!
At HAL2001, there were people who *still* adamantly insist that 2.6 is the
only trustworthy PGP version. I don't get it, but I respect it. And hey,
I'll admit that I'm still using PGP 6.5 when I'm on OS9, but GPG 1.0.6 on
OSX.

I agree with you that in a perfect world we'd make it mandatory, but people
would howl if we did. If we want to move to that as a goal, step one is to
deprecate 2.6.

	Jon

Date: Mon, 20 Aug 2001 13:29:51 -0700
To: Jon Callas <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Preparing a new draft...
Cc: [email-masked]
Sender: [email-masked]

At 12:09 PM -0700 8/20/01, Jon Callas wrote:
>
>I'm going through things needed to put in a new draft, and looking at the
>last few months of comments to see what I should add.

Let's start thinking in terms of this draft as the one that will be 
submitted for DRAFT status of 2440.

To: Derek Atkins <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: About User-ID's
From: Simon Josefsson <[email-masked]>
Date: Mon, 20 Aug 2001 22:35:57 +0200
Lines: 36
Sender: [email-masked]

You can publish PGP keys in DNS right now if you like, see RFC 2538.

Since not every PGP user is trusted with maintaining the DNS
information for the zone where she lives in, I've been thinking about
PGP key "hosting" in DNS.  E.g., it would be possible to publish PGP
keys in DNS on behalf of others as "simon.josefsson.org.dnskeys.pgp.net".

One problem with publishing my PGP key under simon.josefsson.org is
that I already store my S/MIME cert there....  To save bandwidth, it
has been suggested that you could use e.g. "simon._pgp.josefsson.org"
(the dummy _pgp domain is inserted where the `@' is).

Derek Atkins <[email-masked]> writes:

> Who said it was necessary.  I was only suggesting it as one approach.
> One of the benefits we can get by leveraging DNS is that key service
> can be distributed.
>
> -derek
>
> Michael Helm <[email-masked]> writes:
>
>> Derek Atkins writes:
>> > One solution would be to put PGP Keys (Certificates) into DNS.  Then
>> > you could easily lookup a key based on the userID, but you have to
>> > already KNOW the userID.  Unfortunately this doesn't help you lookup
>> > a key by KeyID.
>> 
>> Why is it necessary to put certs into dns in order to accomplish
>> this end?
>
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        [email-masked]                        PGP key available

To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Preparing a new draft...
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 20 Aug 2001 22:07:29 +0200
Lines: 32
Sender: [email-masked]

On Mon, 20 Aug 2001 12:09:04 -0700, Jon Callas said:

> I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
> anyone disagree?

Please mark them as optional.  We should also figure out the new DSA
parameters to be used with those hashes.  Ist there anything available
from NIST?  I didn't follow the development very closely.

> Do people here want to see diffs of my source before I submit the draft? (I

Pretty please.

> I'd like to get this one out ASAP, because I stupidly didn't get it out a
> long time ago with the correct packet numbers for MDC, and I feel badly

Regarding MDC: PGP and GnuPG both implement MDC but without the use of
the features flag.  A long time ago I agreed with Hal to use MDC with
all algorithms having a blocksizes > 64 (i.e. Twofish and AES).  From
our knowledge no other application did use one of those algorithms at
that time.   IMHO, it would be good to stress it even more that the
MDC packets should be used and that it can be expected that future
revisions of OpenPGP will make the use of MDC mandatory.

Ciao,

  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: Mon, 20 Aug 2001 12:09:04 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Preparing a new draft...
Sender: [email-masked]

I'm going through things needed to put in a new draft, and looking at the
last few months of comments to see what I should add.

I think we agreed that we should add in SHA256, SHA384, and SHA512. Does
anyone disagree?

Do people here want to see diffs of my source before I submit the draft? (I
use a Perl formatting program that uses a RUNOFF/roff-like markup language
to produce the actual copy. Sending diffs of the final output is less fun
than it could be, but the source doesn't know page numbers or even section
numbers. On the other hand, it's pretty easy to see the actual changes.)

I'd like to get this one out ASAP, because I stupidly didn't get it out a
long time ago with the correct packet numbers for MDC, and I feel badly
about that. Producing actual drafts if a new one is needed is easy. It's
the figuring out what should go in it that's trouble.

	Jon

To: [email-masked]
Cc: [email-masked]
Subject: Re: About User-ID's
From: Derek Atkins <[email-masked]>
Date: 20 Aug 2001 14:29:43 -0400
Lines: 44
Sender: [email-masked]

Michael Helm <[email-masked]> writes:

> > > > One solution would be to put PGP Keys (Certificates) into DNS.  Then
> 
> makes the linkage look  like a mandatory requirement.

No, it's not a requirement.  The phrase "one solution" means "this is
one approach" implying there are others.

> Am I right that that anything that accomplishes this is ok

Well, yes, but I would still like to see a distributed solution come
sooner rather than later.

> What kinds of uses would cause someone to look up keys w/o knowing
> the user id, or other handle on the key, first? 

Well, I was recently looking for a friend's key because I knew he
changed jobs and his old email address didn't work.  So I searched on
last name to try to find him.  However, I probably could have used
other search methods to do that as well.

Most of the time mailcrypt will just fetch the key using the full
email address.

Perhaps searches should be limited to full-word, lhs queries (so you
can't query on 'mit.edu' but you could query on 'warlord', 'derek',
and 'atkins').  I will note that using DNS loses the ability to do
partial searches; you could only 'search' by full email.

> > One of the benefits we can get by leveraging DNS is that key service
> > can be distributed.
> 
> Let 's not worry about distributability for the  moment.

True, distributability is a separable problem.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

To: [email-masked]
Reply-to: [email-masked]
Subject: Re: About User-ID's 
Date: Mon, 20 Aug 2001 10:57:59 -0700
From: Michael Helm <[email-masked]>
Sender: [email-masked]

Derek Atkins writes:
> Who said it was necessary.  I was only suggesting it as one approach.

This statement

> > > One solution would be to put PGP Keys (Certificates) into DNS.  Then

makes the linkage look  like a mandatory requirement.

Am I right that that anything that accomplishes this is ok

> > > you could easily lookup a key based on the userID, but you have to
> > > already KNOW the userID.  Unfortunately this doesn't help you lookup

(ie this is the  real requirement?)  We could do this by changing the
query rules on the http and ldap servers I would think.
[How] Does this render the servers unusable? What about the distributions
of pre-built databases (I am one of those).

What kinds of uses would cause someone to look up keys w/o knowing
the user id, or other handle on the key, first? 

> One of the benefits we can get by leveraging DNS is that key service
> can be distributed.

Let 's not worry about distributability for the  moment.

To: [email-masked]
Cc: [email-masked]
Subject: Re: About User-ID's
From: Derek Atkins <[email-masked]>
Date: 20 Aug 2001 13:43:17 -0400
Lines: 22
Sender: [email-masked]

Who said it was necessary.  I was only suggesting it as one approach.
One of the benefits we can get by leveraging DNS is that key service
can be distributed.

-derek

Michael Helm <[email-masked]> writes:

> Derek Atkins writes:
> > One solution would be to put PGP Keys (Certificates) into DNS.  Then
> > you could easily lookup a key based on the userID, but you have to
> > already KNOW the userID.  Unfortunately this doesn't help you lookup
> > a key by KeyID.
> 
> Why is it necessary to put certs into dns in order to accomplish
> this end?

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

Date: Mon, 20 Aug 2001 19:33:41 +0200
From: Ingo Luetkebohle <[email-masked]>
To: Michael Young <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: About User-ID's
Organization: Maybe when I grow up
Sender: [email-masked]

--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 20, 2001 at 11:07:53AM -0400, Michael Young wrote:
> If you remove or irreversibly alter the UserID material,

Altering the *real* UserID material is probably not a good
idea. However, you can do a lot on the presentation layer. A keyserver
could allow searching for e-mail addresses (even with substring
search) but not *display* them (or display them in a mangled way).

This helps prevent "tree walking" because knowledge of the content
would be required to retrieve it.

Regards

--=20
	Ingo Luetkebohle / [email-masked] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--rwEMma7ioTxnRzrJ
Content-Type: application/pgp-signature
Content-Disposition: inline

--rwEMma7ioTxnRzrJ--

cc: [email-masked]
Reply-to: [email-masked]
Subject: Re: About User-ID's 
Date: Mon, 20 Aug 2001 10:20:22 -0700
From: Michael Helm <[email-masked]>
Sender: [email-masked]

Derek Atkins writes:
> One solution would be to put PGP Keys (Certificates) into DNS.  Then
> you could easily lookup a key based on the userID, but you have to
> already KNOW the userID.  Unfortunately this doesn't help you lookup
> a key by KeyID.

Why is it necessary to put certs into dns in order to accomplish
this end?

From: "Michael Young" <[email-masked]>
To: "openPGP e-Mail \(E-Mail\)" <[email-masked]>
Subject: Re: About User-ID's 
Date: Mon, 20 Aug 2001 13:00:59 -0400
Sender: [email-masked]

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

>I think he meant: is it realy nessessay that the keyserver
> > present that much id's matching (including all signing id's), or
...
> Additionaly I would add: Is it realy nessessary to allow
> three-letter search-patterns? If I search for a key, I should

Agreed.  It is hardly necessary that any keyserver provide a "verbose"
lookup; some keyservers don't, and some only provide limited
information.  Many keyservers only match on full "words", not
arbitrary substrings.  Many limit the number of hits returned in
one query.  These are all fine restrictions.

That said, it wouldn't be hard for a determined harvester to
get most of the meaningful addresses out of a keyserver.
All the names within a (less-than-huge) domain can be
retrieved by querying on that name.

Yes, I suppose you could require complete, exact matches for
the material within angle-brackets.  I wouldn't find such
a keyserver very useful.

If I really wanted to harvest the keyserver contents, I wouldn't use
the query interface at all.  A couple of keyserver operators make
snapshots of their keyrings available for synchronization.  Even if
they weren't, I could pose as a keyserver operator and ask for someone
to give me a snapshot to get started.  Or, I could use the e-mail
interface that many provide to get recent updates.

Whatever your solution, you'd have to convince all of the synchronized
keyserver operators out there to adopt it if you want to protect the
existing "public" keyring.  To do that, I expect you'd have to
demonstrate a greater threat.  As Len pointed out, it doesn't look
like one has materialized yet.

But if anyone wants to build a "safe" keyserver that doesn't
synchronize (outbound) to the "unsafe" servers, they're welcome to
do it.

content-class: urn:content-classes:message
Subject: AW: About User-ID's 
Date: Mon, 20 Aug 2001 17:50:46 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Michael Young" <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

> From: "Michael Helm" <[email-masked]>
> > Could keys and keyservers be configured [optionally] not to
> > present email-like id's?
> 
> Not without almost completely impairing their use.  Yes, it
> would be easy to turn off name-based lookups, and/or discard or
> alter UserId packets.  But...
?
I think he meant: is it realy nessessay that the keyserver
present that much id's matching (including all signing id's), or
wouldn't it be sufficient to only present the hits (where the
the addresses of those signing the key are only revealed by
dowloading that whole key)?

Additionaly I would add: Is it realy nessessary to allow
three-letter search-patterns? If I search for a key, I should
know the full name (or email address) of the owner (else I
couldn't communicate with that person even without signatures).
Only if NO hit is found, a search for similar key-IDs should
be performed and only the nearest should be revealed.

With such a configuration a keyserver could not be abused as an
address data base.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [email-masked]

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: About User-ID's 
Date: Mon, 20 Aug 2001 11:07:53 -0400
Sender: [email-masked]

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

From: "Michael Helm" <[email-masked]>
> Could keys and keyservers be configured [optionally] not to
> present email-like id's?

Not without almost completely impairing their use.  Yes, it
would be easy to turn off name-based lookups, and/or discard or
alter UserId packets.  But...

If you remove or irreversibly alter the UserID material, then:
(1) associated signatures will fail to verify; and, (2) e-mail system
plug-ins will be unable to do matching.  If you alter them in a way
that is automatically reversible, then any harvester could undo the
alteration just as easily.  You would also have to teach all the
existing tools to undo the alteration(s).

Note that many people use altered addresses in their posts, with the
expectation that they'll be fixed *manually*.  A few people (myself
included) do that for keys they upload.  If the alteration doesn't
affect "words" in the name, then name-based lookups will work against
all?) current keyservers.  Plug-ins may require a more exact
match... since I don't use any, I wouldn't know for sure.  Again,
a smart harvester might use some heuristic de-mangling that would
generate a valid address, but that's a risk I'm willing to live with.
Any "mangling standard" might make it more worth trying.

To: Werner Koch <[email-masked]>
cc: [email-masked]
Reply-to: [email-masked]
Subject: Re: About User-ID's 
Date: Sun, 19 Aug 2001 19:29:27 -0700
From: Michael Helm <[email-masked]>
Sender: [email-masked]

Werner Koch writes:
> People who are currently using PGP keys are not a valuable audience
> for spammers. 

I suspect it's more a matter of ignorance about mining the data
than anything else.

Could keys and keyservers be configured [optionally] not to
present email-like id's?

To: [email-masked]
Subject: Re: About User-ID's
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 19 Aug 2001 19:00:57 +0200
Lines: 23
Sender: [email-masked]

On Sat, 18 Aug 2001 17:08:29 -0700 (PDT), Len Sassaman said:

> So, not to say that this won't happen, but I haven't seen any evidence
> that is does currently.

People who are currently using PGP keys are not a valuable audience
for spammers. 

If in the future it is common to use encryption, spammer will have a
serious problem: They can't use an open relais to send their trash and
save on their on bandwidth - they would have to get the key of each
recipient, encrypt to this key and send them utilizing there own
resourses.  This will be far too expensive for the common mass spam
attacks.  Yes, I assume that every MTA will at that time drop non
encrypted mail ;-)

  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: "Bryan Morris" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: How do I extract my PRIVATE key in PGP CL 6.5???
Date: Sun, 19 Aug 2001 13:35:02 
Sender: [email-masked]

>This is a GNUpg list, not a PGP list...

thanks!

But do you have an answer nonetheless?

thanks so much!

Bryan

>From: Ralf Hildebrandt <[email-masked]>
>To: Bryan Morris <[email-masked]>
>CC: [email-masked], [email-masked], [email-masked], 
>[email-masked], [email-masked]
>Subject: Re: How do I extract my PRIVATE key in PGP CL 6.5???
>Date: Sun, 19 Aug 2001 10:26:05 +0200
>
> > I am using PGP command line v6.5.
>
>This is a GNUpg list, not a PGP list...
>
>--
>[email-masked]                           innominate AG
>+49.(0)30.308806-62  fax: -77                         networking people
>Remember: if brute force doesn't work, you're just not using enough.
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Date: Sun, 19 Aug 2001 12:59:37 +0200
From: Ingo Luetkebohle <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: About User-ID's
Organization: Maybe when I grow up
Sender: [email-masked]

--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sat, Aug 18, 2001 at 04:27:12PM -0700, Jon Callas wrote:
> I don't know about irrelevant -- but I don't know what do do about them. If
> user ids didn't have email addresses on them (which they don't have to), it
> would be hard to find the right key when you want to encrypt mail to
> someone.

Oh, I didn't mean to suggest that. Sorry for not making that clear.

I think "best practices" can be divided in two: 1) best practices on
what to put into a User-ID (obvious and well-established for e-mail,
could be different for SSL keys and so on) and 2) best practices on
how software treats the information.

For an example of the latter, I think current key-server software
makes it exceptionally easy to harvest e-mail address, should someone
desire to do so. I can search for three random letters to get all keys
with those three letters in and the HTML page I get conveniently lists
not just the matching keys but also all the e-mail addresses, *and* --
with the right options -- all e-mail addresses of all signers. This
allows a smart crawler to easily walk the whole server and gather
addresses -- *just* addresses.  Now just consider how much more
difficult it would be if the crawler would have to download the key,
interpret it, go back to the keyserver to fetch all keys referenced in
the signers section and so on. This could be forced by a slight change
in the amount and nature of information revealed by the key-server
(e.g., it could just display the key-id, and the number of
signatures). For legitimate users, who have to download the whole key
anyway, it wouldn't make a difference.

This could be summed up in a suggestion of a best practices document
that software should expect keys to contain sensitive information and
be careful in what it exposes.

There are obviously more open questions, some of which have
traditionally been in FAQ's. Maybe it would help if I draft a small
document with all of them and we can then decide of whether to make an
information RFC from it or just leave it to application developers
documentation?

Regards

--
	Ingo Luetkebohle / [email-masked] / Student of Bioinformatics
/
| Cross-Platform OpenPGP: http://xpg.sourceforge.net/
|
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature
Content-Disposition: inline

--VbJkn9YxBvnuCH5J--

From: "Bryan Morris" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: How do I extract my PRIVATE key in PGP CL 6.5??? 
Date: Sun, 19 Aug 2001 02:46:26 
Sender: [email-masked]

Hi,

I am using PGP command line v6.5.

How do I extract my PRIVATE key?

The documentation only lists extracting the public key.

Thanks for the help.

Brian

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Date: Sat, 18 Aug 2001 17:08:29 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Jon Callas <[email-masked]>
cc: Ingo Luetkebohle <[email-masked]>, <[email-masked]>
Subject: Re: About User-ID's
Sender: [email-masked]

On Sat, 18 Aug 2001, Jon Callas wrote:

> I don't know about irrelevant -- but I don't know what do do about them. If
> user ids didn't have email addresses on them (which they don't have to), it
> would be hard to find the right key when you want to encrypt mail to
> someone.

People have talked about the possibility of spammers harvesting names from
the keyservers for quite some time now. Out of curiousity, last May I
created a key with a unique email address and submitted the keyserver
network as bait. It's been over a year now, and I have yet to receive a
piece of spam to that address.

So, not to say that this won't happen, but I haven't seen any evidence
that is does currently.

Len

--

Len Sassaman

Security Architect            |
Technology Consultant         |  "Let be be finale of seem."
                              |
http://sion.quickie.net       |           --Wallace Stevens

Date: Sat, 18 Aug 2001 16:27:12 -0700
To: Ingo Luetkebohle <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: About User-ID's
Sender: [email-masked]

At 3:32 PM +0200 8/5/01, Ingo Luetkebohle wrote:
>Hello,
>
>I would like to suggest an RFC or other document about best current
>practices regarding User-ID's.
>
>In that, a thorough re-evaluation of the current situation should be
>done, possibly based upon previous works, if there are any (I'm not
>aware of that, if anyone is, I'd be happy about a pointer).
>
>The reason for all this is that I see several problems with the way
>User-ID's are used on OpenPGP implementations right now. Immediately
>obvious is the spam problem because User-ID's contain e-mail addresses
>and people are encouraged to upload their keys to keyservers, which
>are searchable by all but also the uniqueness problem (people have
>multiple addresses and I'm not of the opinion that listing them all is
>the solution) and the problem of anonymity.
>
>What does the working group think? Are the abovementioned problems
>irrelevant in your opinion or, if not, would you agree that a document
>about User-ID's would be a good start at solving them?
>
>Looking forward to your input!
>

I don't know about irrelevant -- but I don't know what do do about them. If
user ids didn't have email addresses on them (which they don't have to), it
would be hard to find the right key when you want to encrypt mail to
someone.

What do you think the solution is?

	Jon

Date: Sat, 18 Aug 2001 09:18:54 -0700
To: OpenPGP mailing list <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: AW: Reasons to include ECC to our charter
Cc: "Ben Laurie" <[email-masked]>, "Dominikus Scherkl" <[email-masked]>
Sender: [email-masked]

At 3:33 PM +0200 8/15/01, Dominikus Scherkl wrote:
>Hi.
>
>>  > IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
>>  > which can be implemented efficiently using two-valued logic.
>>
>>  As I read it, this I-D includes these.
>But it also includes Curves over GF(q), q prime or a power of some
>odd prime. I wouldn't appreciate it much to exclude some stuff,
>now that we have a definition including simply every finite field.

I agree with Dominkus on this point.  As long as what he has defined 
gives a means for any ECC curve deemed useful, I believe that 
finesses the IPR issues raised by Certicom's patents.

However, At 1:42 AM +1200 8/11/01, Peter Gutmann wrote:
>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".

If Peter is accurate, then Certicom's IPR poses a significant 
obstacle to ECC utility.  Do others wish to comment on this?

It may be possible to pursue an agreement along the lines of RFC1790. 
Certicom would have to be agreeable, and  we would have to persuade 
the IETF as a whole such an agreement is in the IETF's interest.  To 
my knowledge, the RFCs covered by agreement documented in 1790 did 
not achieve STD status, but that doesn't mean we would not succeed. 
It is still a useful model.

Assuming we do proceed, it would be appropriate to be warn people 
about classes of curves which are either inefficient to compute, or 
may require licensing from a third party.  Both considerations limit 
utility of some ECC designs.

However, I would like to see more analysis of ECC curves (not to 
slight Peter's assessment), before I consider this matter resolved. 
Further, if someone could point me towards the appropriate person at 
Certicom to discuss the 1790 approach, please do so.

best,
-- 

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: Jon Callas <[email-masked]>
Cc: Ingo Luetkebohle <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ElGamal signature values?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 18 Aug 2001 14:27:59 +0200
Lines: 31
Sender: [email-masked]

On Fri, 17 Aug 2001 15:03:56 -0700, Jon Callas said:

> I'm a little uncomfortable over proper wording here; if they're so bad,
> should they be there at all? I thought the present 12.5 wording was stern

Well, we had so many discussions and I guess that there are still some
folks who have concerns about DSA so that they use ElGamal
signatures. Of course, it is there good right to do this.  OTOH this
often triggers long discussions whether there is a bug in PGP or GnuPG
when one can't check the signature.

Removing that optional algorithm is neither good because we willfor
sure start a long discussion again ;-)

>  Details on safe use of Elgamal signatures may be found in [MENEZES], which
>  discusses all the weaknesses described above. Please note that Elgamal
>  signatures are controversial; because of the care that must be taken with
>  Elgamal keys, many implementations forego them.

> How's that?

That's really nice.

Thanks,

   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: Fri, 17 Aug 2001 15:03:56 -0700
To: Werner Koch <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: ElGamal signature values?
Cc: Ingo Luetkebohle <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 3:41 PM +0200 8/13/01, Werner Koch wrote:

>Please add a reference to section 12.5 [ElGamal] and make clear that
>the use of ElGamal signatures is not suggested.
>

I'm a little uncomfortable over proper wording here; if they're so bad,
should they be there at all? I thought the present 12.5 wording was stern
enough to give anyone pause. Nonetheless, I added another wording. Here's
the complete paragraph:

 Details on safe use of Elgamal signatures may be found in [MENEZES], which
 discusses all the weaknesses described above. Please note that Elgamal
 signatures are controversial; because of the care that must be taken with
 Elgamal keys, many implementations forego them.

How's that?

	Jon

Date: Fri, 17 Aug 2001 16:45:02 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: CFP: Submission deadline for NDSS'02 extended to Aug 29th
Sender: [email-masked]

Due to the unusually large number of requests for an extension,
the submissions deadline for NDSS'02 has been extended to 
Wednesday August 29, 9:00am EST (U.S. east coast time).
 
Paul Van Oorschot  and Virgil Gligor
Co-Chairs, NDSS'02

                             C A L L   F O R   P A P E R S

Internet Society's 2002 Network and Distributed System Security Symposium  (NDSS'02)

Catamaran Resort - San Diego, California
February 6-8, 2002

IMPORTANT DATES
Paper and panel submissions due August 22, 2001
Author notification October 17, 2001
Final version of papers and panels due November 20, 2001

GOAL: The symposium fosters information exchange among research scientists and practitioners of network and distributed system security services. The target audience includes those interested in practical aspects of network and distributed system security, with a focus on actual system design and implementation (rather than theory). A major goal is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings are published by the Internet Society.

GENERAL CHAIR: 
Clifford Neuman, USC Information Sciences Institute

PROGRAM CO-CHAIRS:
Paul Van Oorschot, Entrust Technologies
Virgil Gligor, University of Maryland

TUTORIAL CHAIR:
Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
Terry Weigler, Internet Society

PROGRAM COMMITTEE:
Steve Bellovin, AT&T Labs Research
Dan Boneh, Stanford University
Bill Cheswick, Lumeta Corporation
Li Gong, Sun Microsystems
Peter Gutmann, Univ. of Auckland, N.Z.
Charlie Kaufman, Iris Associates
Steve Kent, BBN Technologies
Markus Kuhn, Univ. of Cambridge, U.K.
Douglas Maughan, DARPA
Kevin McCurley, IBM Almaden Research
Gary McGraw, Cigital
Fabian Monrose, Bell Labs
Sandra Murphy, Network Associates
Radha Poovendran, Univ. of Washington 
Michael Roe, Microsoft Research, U.K. 
Christoph Schuba, Sun Microsystems
Clay Shields, Purdue University
Jonathan Trostle, Cisco Systems
Dan Wallach, Rice University

OUTSTANDING PAPER AWARD: There will be an Outstanding Paper award. The award will be presented at the symposium to the authors of an outstanding paper, as selected by the Program Committee.

SUBMISSIONS: Both technical papers and panel proposals are solicited. Technical papers must include a main body of at most 12 pages, with any additional details in clearly marked appendices for a combined total of at most 20 pages. Technical papers will appear in the proceedings. Panel proposals should be one page and must describe the topic, identify the panel chair, explain the panel format, and list three to four potential panelists. A description of each panel will appear in the proceedings, and may, at the discretion of the panel chair, include written position statements from the panelists.

Submissions are solicited in, but not limited to, the following areas:
* Integrating security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web.
* Intrusion avoidance, detection, and response: systems, experiences and architectures.
* Attack-resistant protocols and services.
* Network perimeter controls: firewalls, packet filters, application gateways.
* Virtual private networks.
* Public key infrastructure, key management, certification, and revocation.
* Secure electronic commerce: e.g., payment, barter, EDI, notarization, timestamping, endorsement, and licensing.
* Supporting security mechanisms and APIs; audit trails; accountability.
* Implementation, deployment and management of network security policies.
* Intellectual property protection: protocols, schemas, implementations, metering, watermarking, digital rights management.
* Fundamental services on network and distributed systems: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability.
* Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, data base management, boot services, mobile computing.
* Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems.
* Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost.
* Security for collaborative applications and services: teleconferencing and video-conferencing, groupwork, etc.

Each submission must contain a separate Submission Overview specifying the submission type (paper or panel), the title or topic, author names with organizational affiliations, and must specify a contact author along with corresponding phone number, FAX number, postal address and email address.

Submissions must be received by August 22, 2001, and must be made electronically in either printable PostScript or PDF. Each submission will be acknowledged by e-mail; if acknowledgment is not received within seven days, contact a program co-chair (see above). Authors and panelists will be notified of acceptance by October 17, 2001, and given instructions for preparing the camera-ready copy. The camera-ready copy must be received by November 20, 2001. 

FURTHER INFORMATION: Official dates, the final call for papers, the advance program, and registration information will be available shortly at http://www.isoc.org/ndss2002. For official submission information, visit http://www.isoc.org/ndss2002/cfp.

Internet Society 

11150 Sunset Hills Road, Suite 100
Reston, VA  20191  USA
Tel:  +1 703 326 9880
Fax:  +1 703 326 9880
www.isoc.org

4, rue des Falaises
CH-1205 Geneva
Switzerland
Tel:  +41 22 807 1444
Fax:  +41 22 807 1445
www.isoc.org

From: "Bryan Morris" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: How do I extract my PRIVATE key in PGP CL 6.5???
Date: Fri, 17 Aug 2001 20:05:42 
Sender: [email-masked]

How do I extract my PRIVATE key in PGP CL 6.5???

Hi,

I am using PGP command line v6.5.

How do I extract my PRIVATE key?

The documentation only lists extracting the public key.

Thanks for the help.

Brian

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

To: IETF-Announce: ;
Subject: RFC 3156 on MIME Security with OpenPGP
Cc: [email-masked], [email-masked]
Date: Fri, 17 Aug 2001 09:12:22 -0700
From: RFC Editor <[email-masked]>
Sender: [email-masked]

--NextPart

A new Request for Comments is now available in online RFC libraries.

        RFC 3156

        Title:	    MIME Security with OpenPGP
        Author(s):  M. Elkins, D. Del Torto, R. Levien, T. Roessler 
        Status:     Standards Track
	Date:       August 2001
        Mailbox:    [email-masked], [email-masked],
                    [email-masked] 
        Pages:      15
        Characters: 26809
        Updates:    RFC 2015

        I-D Tag:    draft-ietf-openpgp-mime-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3156.txt

This document describes how the OpenPGP Message Format can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC 1847.

This document is a product of the An Open Specification for Pretty
Good Privacy Working Group of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

RETRIEVE: rfc
DOC-ID: rfc3156

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3156.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--
--NextPart--

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

Hi.

> > IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
> > which can be implemented efficiently using two-valued logic.
> 
> As I read it, this I-D includes these.
But it also includes Curves over GF(q), q prime or a power of some
odd prime. I wouldn't appreciate it much to exclude some stuff,
now that we have a definition including simply every finite field.
But my suggestion doesn't require an application to use binary
fields, and other curves are also given (and own for which noone
could claim any rights could be generated), so licence problems are
easy to avoid.

As I already mentioned to some people, I think it is the main topic
for an internet standard to enhance interoperability. So im still
convinced it is a good idea to provide a common way to store data
for ECC algorithms even if a particular implementation decide not to
use ECC (or not all suggested curves) for licence reasons.

I see the point that we shouldn't do the work for those who claimed
rights that should not be granted to anyone (like patenting a number).

But 1. most of the work is done, 2. a patent won't last forever and
if a standard is available before it's most likely that future
applications will conform to it.
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [email-masked]

To: [email-masked]
Cc: [email-masked]
Subject: Key flags and Feature packet
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 13 Aug 2001 16:04:00 +0200
Lines: 62
Sender: [email-masked]

Hi,

there used to be a draft (Brown, Back, Laurie: Forward Secrecy
Extensions for OpenPGP) on how to add PFS to OpenPGP.  I recently
looked again at the now expired draft to decide whether it can be
implemented.  It does need a little bit of work but 2 things could be
very helpful if we can put them into OpenPGP now:

  1. A key flag "one time key". I suggest to use the next
     octet for this:
 
       Second octet:

       0x01 - This key should be used only once. 

  2. A feature flag "one time key support", with value 2:  It
     indicates that the implementation is able to handle one time
     keys; i.e. it will never use this key twice for encryption and
     delete the secret key after successful decryption.

Because all details of such a feature can't go right now in 2440bis,
we might just want to mark these values as "reserved for one time key
keys".

BTW, why is the 5.2.3.24. Features defined as just an array of
one-octet values and not similar to the key flags?  I think it would
be much more consistent if we stick to the general OpenPGP bit-saving
technique.  Can we change it to:

5.2.3.24. Features

   (octet string)

   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:    

       Bit 0 - Modification Detection (packets 15 and 16)

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

Ciao,

  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

To: Jon Callas <[email-masked]>
Cc: Ingo Luetkebohle <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ElGamal signature values?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 13 Aug 2001 15:41:12 +0200
Lines: 27
Sender: [email-masked]

On Fri, 10 Aug 2001 09:25:36 -0700, Jon Callas said:

> Can someone who is an implementer answer this? What do I need to do to put
> in the next draft? I'm going to put out another draft in the next couple of

Algorithm Specific Fields for ElGamal signatures:

  - MPI of ElGamal value a = g**k mod p.

  - MPI of ElGamal value b = (h-a*x)/k mod p-1.

The hash h is PKCS-1 padded exactly the same way as for the above
described RSA signatures.

Please add a reference to section 12.5 [ElGamal] and make clear that
the use of ElGamal signatures is not suggested.

> days -- there's time here at HAL -- and if I can clarify, I will.

Hope you had a nice time.

  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

To: IETF-Announce: ;
CC: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-scherkl-openpgp-ecc-00.txt
Date: Mon, 13 Aug 2001 07:04:57 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: OpenPGP Elliptic Curve Algorithm Formats
	Author(s)	: D. Scherkl
	Filename	: draft-scherkl-openpgp-ecc-00.txt
	Pages		: 20
	Date		: 09-Aug-01
	
This document defines which algorithm specific parameters are needed
for elliptic curve cipher (ECC) and elliptic curve digital signature
algorithm (ECDSA) and how they have to be stored in openPGP packets.
Therefore it is an supplement to the openPGP message format [1].
It also defines which checks are needed to validate ECC and ECDSA
keys and which 'top-level' operations must be performed for
encryption/decryption and signing/signature verification. But it
gives no advices how to implement these checks and operations, nor
the underlying mathematics. To do this, look for example at IEEE
P1363 [2].

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-scherkl-openpgp-ecc-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-scherkl-openpgp-ecc-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-scherkl-openpgp-ecc-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-scherkl-openpgp-ecc-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Michael Young" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: ElGamal signature values?
Date: Sat, 11 Aug 2001 13:10:30 -0400
Sender: [email-masked]

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

From: "Jon Callas" <[email-masked]>
> Can someone who is an implementer answer this? What do I need to do to put
> in the next draft? I'm going to put out another draft in the next couple of
> days -- there's time here at HAL -- and if I can clarify, I will.

I haven't implemented it yet, but I've asked a few times, and for
lack of an answer, I've looked over the GnuPG code.

GnuPG computes:
    a=g^k mod p); and,
    b=(h-a*x)/k mod (p-1))
 where k is random and h is the (padded) message hash.

It seems to apply the same PKCS padding as for RSA signatures.
The two MPIs are encoded in that order (a,b).

The computation matches that found in the Handbook of Applied
Cryptography, among others.  I can't comment on whether the PKCS
padding is the usual treatment for ElGamal signatures, though.

Date: Fri, 10 Aug 2001 09:25:36 -0700
To: Ingo Luetkebohle <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: ElGamal signature values?
Cc: [email-masked]
Sender: [email-masked]

At 10:19 PM +0200 8/3/01, Ingo Luetkebohle wrote:

>I couldn't find a specification for ElGamal signature values in the
>RFC or the current (bis-02) draft, even though the current draft
>mentions the possibility of such signatures in section 12.5 and gpg
>seems to support them.
>
>It would seem logical to use the same values as for public-key
>encrypted session keys. Is that correct? Is that what gpg does or is
>there something else I need to know?
>

Can someone who is an implementer answer this? What do I need to do to put
in the next draft? I'm going to put out another draft in the next couple of
days -- there's time here at HAL -- and if I can clarify, I will.

	Jon

Date: Fri, 10 Aug 2001 16:15:35 +0100
From: Ben Laurie <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

Florian Weimer wrote:
> 
> Ben Laurie <[email-masked]> writes:
> 
> > You can't add it to the _standard_ because of restrictive licensing. I
> > guess Informational RFCs are possible, but they don't make me happy -
> > essentially the WG is doing free work, both technical and marketing, for
> > the owner(s) of the patents.
> 
> IIRC, not all ECC stuff is patented, only curves over GF(q), q even,
> which can be implemented efficiently using two-valued logic.

As I read it, this I-D includes these.

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, 11 Aug 2001 01:42:40 +1200 (NZST)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

Florian Weimer <[email-masked]> writes:

>Ben Laurie <[email-masked]> writes:
>>You can't add it to the _standard_ because of restrictive licensing. I
>>guess Informational RFCs are possible, but they don't make me happy -
>>essentially the WG is doing free work, both technical and marketing, for
>>the owner(s) of the patents.
>
>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".

Peter.

Date: Thu, 9 Aug 2001 16:39:18 +0100
To: Rodney Thayer <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Draft openPGP ECC formats
Cc: [email-masked]
Sender: [email-masked]

At 11:34 AM -0700 8/9/01, Rodney Thayer wrote:
>This implies severe process failure -- the draft editor isn't
>supposed to let drafts get in without permission from the WG chair.

There is no restriction on personal submissions.  Dominikus was 
unaware of IETF procedures.  We have discussed it, and he has agreed 
to resubmit it as a personal draft.

To reassure you, the rfc-editor did not accept the document w/o 
consulting with me, and I explained to Dominikus why it could not be 
submitted as a WG document.

-- 

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: Re: Reasons to include ECC to our charter
From: Florian Weimer <[email-masked]>
Date: 09 Aug 2001 17:24:43 +0200
Lines: 14
Sender: [email-masked]

Ben Laurie <[email-masked]> writes:

> You can't add it to the _standard_ because of restrictive licensing. I
> guess Informational RFCs are possible, but they don't make me happy -
> essentially the WG is doing free work, both technical and marketing, for
> the owner(s) of the patents.

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

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

Date: Thu, 9 Aug 2001 17:04:05 +0200
From: Thomas Roessler <[email-masked]>
To: Dominikus Scherkl <[email-masked]>
Cc: Ben Laurie <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Mail-Followup-To: Dominikus Scherkl <[email-masked]>, Ben Laurie <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

On 2001-08-09 16:49:49 +0200, Dominikus Scherkl wrote:

>The openPGP standard is exactly this - "open". So of course we can 
>add ECC (it is still reserved). Or do you mean patents on ECC? 
>That is also no Problem, because patents only apply to the 
>applications that implement the standard - they need to licence 
>the algorithms. If not licenced, the application may not support 
>ECC (but is still conform to the standard - same as for elgamal).

That is, ECC can't be a mandatory part of the standard.

content-class: urn:content-classes:message
Subject: AW: Reasons to include ECC to our charter
Date: Thu, 9 Aug 2001 16:49:49 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "Ben Laurie" <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

> You can't add [ECC] to the _standard_ because of restrictive
licensing.
?!?
The openPGP standard is exactly this - "open". So of course we can add
ECC (it is still reserved). Or do you mean patents on ECC?
That is also no Problem, because patents only apply to the applications
that implement the standard - they need to licence the algorithms.
If not licenced, the application may not support ECC (but is still
conform to the standard - same as for elgamal).
-- 
Dominikus Scherkl
Biodata Application Security AG
mail: [email-masked]

Date: Thu, 09 Aug 2001 15:40:31 +0100
From: Ben Laurie <[email-masked]>
To: Dominikus Scherkl <[email-masked]>
CC: "openPGP e-Mail (E-Mail)" <[email-masked]>
Subject: Re: Reasons to include ECC to our charter
Sender: [email-masked]

Dominikus Scherkl wrote:
> 
> Dear openPGP Working Group,
> 
> Sorry, that I supposed my suggestions for an ECC-extension
> to the openPGP message format to be property of this WG while
> it is only a personal draft.
> 
> Now for my reasons, why this WG should include
> <draft-scherkl-openpgp-ecc-00.txt> to its charter:
> 
> I think it is time to fulfill the promise this WG made by
> reserving space for ECC and ECDSA, if we want to keep this
> standard as wide used as it is.
> 
> Long time has gone since we reserved IDs for ECC algorithms
> and many applications now support ECC but can't provide it in
> an openPGP context. So they uses other standards like S/MIME
> or proprietary protocols to provide these algorithms to those
> who want to enjoy their advantages.
> 
> Different sets of ECC parameters have now been tested long
> enough to outsource all trivialy (and many not so trivial)
> cases that won't provide sufficient security, so ECC becomes
> a "well known" algortithm.
> In this light the somewhat slightly advantages "short keys"
> and "high performance" gain weight due to the lack of
> disadvantages.
> 
> Therefore I'm convinced we can include it in the standard
> without high probability to compromise our security goals.
> 
> The attached draft is thought to be fully conform with the
> openPGP format and even some other standards, and it defines
> all elliptic curves so that no greater changes in the
> future are expected (it keeps no further gaps in the ECC
> definiton as some older suggestions have done).
> If it isn't, I'm sure we can make it with small efford.
> 
> At all, the openPGP standard can only gain by adding this
> draft to the charter.

You can't add it to the _standard_ because of restrictive licensing. I
guess Informational RFCs are possible, but they don't make me happy -
essentially the WG is doing free work, both technical and marketing, for
the owner(s) of the patents.

Cheers,

Ben.

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

content-class: urn:content-classes:message
Subject: AW: Draft openPGP ECC formats
Date: Thu, 9 Aug 2001 13:38:26 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

Hi!

> This implies severe process failure
>
I would enjoy _real_ critics on the content of the
draft very much more than riging on "process failures".

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

content-class: urn:content-classes:message
Subject: Reasons to include ECC to our charter
Date: Thu, 9 Aug 2001 13:33:28 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C120C7.1C1701C3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear openPGP Working Group,

Sorry, that I supposed my suggestions for an ECC-extension
to the openPGP message format to be property of this WG while
it is only a personal draft.

Now for my reasons, why this WG should include
<draft-scherkl-openpgp-ecc-00.txt> to its charter:

I think it is time to fulfill the promise this WG made by
reserving space for ECC and ECDSA, if we want to keep this
standard as wide used as it is.

Long time has gone since we reserved IDs for ECC algorithms
and many applications now support ECC but can't provide it in
an openPGP context. So they uses other standards like S/MIME
or proprietary protocols to provide these algorithms to those
who want to enjoy their advantages.

Different sets of ECC parameters have now been tested long
enough to outsource all trivialy (and many not so trivial)
cases that won't provide sufficient security, so ECC becomes
a "well known" algortithm.
In this light the somewhat slightly advantages "short keys"
and "high performance" gain weight due to the lack of
disadvantages.

Therefore I'm convinced we can include it in the standard
without high probability to compromise our security goals.

The attached draft is thought to be fully conform with the
openPGP format and even some other standards, and it defines
all elliptic curves so that no greater changes in the
future are expected (it keeps no further gaps in the ECC
definiton as some older suggestions have done).
If it isn't, I'm sure we can make it with small efford.

At all, the openPGP standard can only gain by adding this
draft to the charter.

Best Regards
--=20
Dominikus Scherkl
Biodata Application Security AG
mail: [email-masked]

------_=_NextPart_001_01C120C7.1C1701C3
Content-Type: text/plain;
	name="draft-scherkl-openpgp-ecc-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-scherkl-openpgp-ecc-00.txt
Content-Disposition: attachment;
	filename="draft-scherkl-openpgp-ecc-00.txt"

------_=_NextPart_001_01C120C7.1C1701C3--

Date: Thu, 09 Aug 2001 11:34:45 -0700
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: Draft openPGP ECC formats
Cc: [email-masked]
Sender: [email-masked]

This implies severe process failure -- the draft editor isn't
supposed to let drafts get in without permission from the WG chair.

(A hard lesson we learned in IPsec...)

At 01:47 PM 8/8/01 +0100, John  W Noerenberg II wrote:

>At 3:17 PM +0200 8/7/01, Dominikus Scherkl wrote:
>>We consider a new document (attached) about how to store elliptic
>>curve cipher keys and signatures in openPGP messages and how to
>>encrypt/decrypt with ECC vs. sign and verify with ECDSA.
>>
>>You can find it also under
>>http://download.biodata.com/documents/draft-ietf-openpgp-ecc-formats.txt
>
>Please submit this as a personal draft.  This is not a working group item 
>at present.
>--
>
>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: Thu, 9 Aug 2001 00:51:14 -0700
From: Will Price <[email-masked]>
Subject: Re: Draft openPGP ECC formats
Cc: OpenPGP mailing list <[email-masked]>
To: John  W Noerenberg II <[email-masked]>
Sender: [email-masked]

John:

PGP would be strongly supportive of including an ECC draft 
within the charter of the WG. While we do not support ECC now, 
the lack of a draft certainly does not help any potential for 
supporting it in the future.

On Wednesday, August 8, 2001, at 10:49 AM, John W Noerenberg II wrote:

> I've requested Dominikus edit his draft to conform to IETF 
> guidelines, and resubmit it as a personal draft.  Currently,  
> further specification of ECC is not part of our charter, 
> although it might be necessary in order for elliptic curves to 
> be useful within OpenPGP.
>
> Once his draft has been accepted as I-D, I would like your 
> opinions on whether is should be included as a WG item.  Are 
> implementers utilizing ECC in their implementations?
>
> I've asked Dominikus to elaborate his reasons to the WG for 
> including his draft within our charter, once his draft has been 
> accepted as an I-D.  Please give his note and his draft careful 
> consideration.

--

Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.

Date: Wed, 8 Aug 2001 18:49:07 +0100
To: OpenPGP mailing list <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Draft openPGP ECC formats
Cc: "Dominikus Scherkl" <[email-masked]>
Sender: [email-masked]

I've requested Dominikus edit his draft to conform to IETF 
guidelines, and resubmit it as a personal draft.  Currently,  further 
specification of ECC is not part of our charter, although it might be 
necessary in order for elliptic curves to be useful within OpenPGP.

Once his draft has been accepted as I-D, I would like your opinions 
on whether is should be included as a WG item.  Are implementers 
utilizing ECC in their implementations?

I've asked Dominikus to elaborate his reasons to the WG for including 
his draft within our charter, once his draft has been accepted as an 
I-D.  Please give his note and his draft careful consideration.

Thanks!
-- 

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, 8 Aug 2001 13:47:11 +0100
To: "Dominikus Scherkl" <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: Re: Draft openPGP ECC formats
Cc: <[email-masked]>, "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

At 3:17 PM +0200 8/7/01, Dominikus Scherkl wrote:
>We consider a new document (attached) about how to store elliptic
>curve cipher keys and signatures in openPGP messages and how to
>encrypt/decrypt with ECC vs. sign and verify with ECDSA.
>
>You can find it also under
>http://download.biodata.com/documents/draft-ietf-openpgp-ecc-formats.txt

Please submit this as a personal draft.  This is not a working group 
item at present.
-- 

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: John W Noerenberg II <[email-masked]>
Cc: OpenPGP mailing list <[email-masked]>
Subject: Re: interop testing
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 07 Aug 2001 20:57:57 +0200
Lines: 19
Sender: [email-masked]

On Tue, 7 Aug 2001 12:34:48 +0100, John W Noerenberg said:

> If you have particular thoughts about interop testing, please don't
> hesitate to post them to the list.  If you are in London, and would
> like to discuss this in person, please let me know!

I have no particular thoughts.  Beeing able to attend on IRC is
hopefully sufficient.  The important thing is that we have to make
this happen and advance to draft status asap.

The last draft has expired, so we should release a new one.  Jon?

  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

content-class: urn:content-classes:message
Subject: Draft openPGP ECC formats
Date: Tue, 7 Aug 2001 15:17:54 +0200
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Cc: "openPGP e-Mail (E-Mail)" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C11F43.5DDB79E8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello.

We consider a new document (attached) about how to store elliptic
curve cipher keys and signatures in openPGP messages and how to
encrypt/decrypt with ECC vs. sign and verify with ECDSA.

You can find it also under
http://download.biodata.com/documents/draft-ietf-openpgp-ecc-formats.txt

Best Regards.
--=20
Dominikus Scherkl
Biodata Application Security AG
mail: [email-masked]

------_=_NextPart_001_01C11F43.5DDB79E8
Content-Type: text/plain;
	name="draft-ietf-openpgp-ecc-formats.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-ietf-openpgp-ecc-formats.txt
Content-Disposition: attachment;
	filename="draft-ietf-openpgp-ecc-formats.txt"

------_=_NextPart_001_01C11F43.5DDB79E8--

Date: Tue, 7 Aug 2001 12:34:48 +0100
To: OpenPGP mailing list <[email-masked]>
From: John  W Noerenberg II <[email-masked]>
Subject: interop testing
Sender: [email-masked]

Rod Thayer, Ben Laurie, Ian Brown, Fearghas Mckay and I had the 
opportunity yesterday for a brief bar BOF at the IETF meeting this 
week in London to discuss interoperability testing.

We discussed what's necessary for testing to take place, and how to 
get ready for the tests.  I still plan to host the testing at 
Qualcomm, however, it will certainly be a virtual meeting, as I don't 
expect everyone who wants to participate to be able to come to San 
Diego.

If you have particular thoughts about interop testing, please don't 
hesitate to post them to the list.  If you are in London, and would 
like to discuss this in person, please let me know!

As a plan solidifies, I'll make sure the plan is published on the the 
list before we proceed.

-- 

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: Sun, 5 Aug 2001 15:32:39 +0200
From: Ingo Luetkebohle <[email-masked]>
To: [email-masked]
Subject: About User-ID's
Organization: Maybe when I grow up
Sender: [email-masked]

--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

I would like to suggest an RFC or other document about best current
practices regarding User-ID's.

In that, a thorough re-evaluation of the current situation should be
done, possibly based upon previous works, if there are any (I'm not
aware of that, if anyone is, I'd be happy about a pointer).=20

The reason for all this is that I see several problems with the way
User-ID's are used on OpenPGP implementations right now. Immediately
obvious is the spam problem because User-ID's contain e-mail addresses
and people are encouraged to upload their keys to keyservers, which
are searchable by all but also the uniqueness problem (people have
multiple addresses and I'm not of the opinion that listing them all is
the solution) and the problem of anonymity.

What does the working group think? Are the abovementioned problems
irrelevant in your opinion or, if not, would you agree that a document
about User-ID's would be a good start at solving them?

Looking forward to your input!

--=20
	Ingo Luetkebohle / [email-masked] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

--Nq2Wo0NMKNjxTN9z--

Date: Fri, 3 Aug 2001 22:19:04 +0200
From: Ingo Luetkebohle <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: ElGamal signature values?
Organization: Maybe when I grow up
Sender: [email-masked]

--5mCyUwZo2JvN/JJP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello,

I couldn't find a specification for ElGamal signature values in the
RFC or the current (bis-02) draft, even though the current draft
mentions the possibility of such signatures in section 12.5 and gpg
seems to support them.

It would seem logical to use the same values as for public-key
encrypted session keys. Is that correct? Is that what gpg does or is
there something else I need to know?

If its just that I've been too dumb to find the right section in the
spec, pointers are very appreciated :)

Regards

--=20
	Ingo Luetkebohle / [email-masked] / 95428014
/
| Student of Computational Linguistics & Computer Science;
| Fargonauten.DE sysadmin; Gimp Registry maintainer;
| FP: 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature
Content-Disposition: inline

--5mCyUwZo2JvN/JJP--

To: Jon Callas <[email-masked]>
Cc: John Kane <[email-masked]>, [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 03 Aug 2001 09:12:47 +0200
Lines: 14
Sender: [email-masked]

On Fri, 3 Aug 2001 00:58:34 +0200, Thomas Roessler said:

> Correction:  I mis-remembered this from the last time I looked at that
> code.  Thanks to John Kane for telling me that I was wrong about this,
> and apologies to Werner.

Anyway, I removed the default comment string, I don't think it does
make sense anymore.  --comment '' still works of course.

-- 
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: Fri, 3 Aug 2001 00:58:34 +0200
From: Thomas Roessler <[email-masked]>
To: Werner Koch <[email-masked]>, Jon Callas <[email-masked]>, John Kane <[email-masked]>, [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
Mail-Followup-To: Werner Koch <[email-masked]>, Jon Callas <[email-masked]>, John Kane <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2001-08-02 19:41:52 +0200, Thomas Roessler wrote:

>BTW, it would be nice if it was possible to entirely disable that 
>header with gnupg, which doesn't seem to be the case.

Correction:  I mis-remembered this from the last time I looked at 
that code.  Thanks to John Kane for telling me that I was wrong 
about this, and apologies to Werner.

Date: Thu, 2 Aug 2001 19:41:52 +0200
From: Thomas Roessler <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: Jon Callas <[email-masked]>, John Kane <[email-masked]>, [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
Mail-Followup-To: Werner Koch <[email-masked]>, Jon Callas <[email-masked]>, John Kane <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2001-07-31 09:39:15 +0200, Werner Koch wrote:

>The solution is to use "gpg --comment '' ..." to disable the armor 
>commentline or use sed to cut it out later.

That's of course what I have added to mutt's default gnupg
configuration now.  BTW, it would be nice if it was possible to 
entirely disable that header with gnupg, which doesn't seem to be 
the case.

>So it is definitely not a standard problem.

I disagree.

It should be possible to rely upon the ASCII-armored text OpenPGP 
applications generate when creating e-mail messages or anything else 
which is supposed to cross system boundaries.  Armor should for that 
reason be invariant and robust under the usual kinds of character 
set conversions and corruptions.

After all, that's the entire point of ASCII-armor...

Date: Thu, 2 Aug 2001 19:26:03 +0200
From: Thomas Roessler <[email-masked]>
To: Ian Bell <[email-masked]>
Cc: [email-masked]
Subject: Re: Forbidding 8bit text in Armor comments
Mail-Followup-To: Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2001-08-02 17:25:49 +0100, Ian Bell wrote:

>If utf-8 is allowed in Comments then RFC2015bis will need to be 
>amended (if it hasn't got through last call yet) to tell clients 
>what to do with it before sending.

It has gone through last call.

>Double encoding is not a sensible option

No, of course not.

>- either say RFC2015bis clients MUST NOT include comments lines 
>with utf-8 characters, or say that RFC2015bis clients MAY drop 
>utf-8 comments lines, but if they don't they MUST RFC2047 encode 
>them.

This is plain silliness - just like double encoding. We are talking 
about a comment which is:

- hardly ever read by users, because it's not even on the 
   application layer
- mostly used to advertise the program which is used for generating 
   it to those who wonder what kind of "data junk" they are 
   receiving
- is not cryptographically protected
- and, when using utf-8 text, breaks assumptions which have been 
   made for years now, and, in fact, breaks the whole point ASCII 
   armor was designed for

The discussion we are having here is basically equivalent to 
discussing internationalization of SMTP greetings or User-Agent 
headers.

If you ask me, I'd just suggest to drop the Comment armor header. 
Since that's probably not an option, castrate it to 7bit characters.

To: [email-masked]
Cc: [email-masked]
Subject: Re: Setting default UID
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: 02 Aug 2001 09:56:16 +0200
Lines: 27
Sender: [email-masked]

On Wed, 1 Aug 2001 11:42:52 -0700 (PDT), Len Sassaman said:

> www.ietf.org.
> It's the current internet draft.

BTW, it has expired:

Network Working Group                                        Jon Callas
Category: INTERNET-DRAFT                  Counterpane Internet Security
draft-ietf-openpgp-rfc2440bis-02.txt
Expires Apr 2001                                       Lutz Donnerhacke
October 2000                         IN-Root-CA Individual Network e.V.

and I am eagerly waiting for the schedule of the interoperability test
which have been announced for "early summer".  Given the 30 Celsius we
have for a week now here in Gemrany, I am pretty sure that early
summer already passed by - well maybe it was a statement from down
under ;-)

Ciao,

  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