Subject: Re: Behavior of implementations regarding certain key material

From: [email-masked]
Date: Wed, 31 May 2000 16:21:12 -0700

The question arises, what is the purpose or meaning of expiration dates
on keys and signatures.

In the case of keys, expirations have a couple of purposes.  One is
to reduce the attractiveness of the key as a target.  A key with an
indefinite lifespan is more valuable if stolen or cracked than one
which will expire in the near future.  This is especially true in the
context of a brute force attack which may take a long time to mount.
By giving the key an expiration date it may be effectively impossible
to break the key before it expires, so no one would even try.

A related purpose is to limit the damage if the key falls into someone
else's hands.  Ideally you will recognize when this happens and revoke the
key, but the breach may not always be detected.  Giving keys a limited
lifetime and rolling over to new keys periodically will reduce the harm
from this cause.

In the case of signatures I think things are quite different.  Signature
expirations seem primarily used for the case where the certified
information becomes incorrect or obsolete.  In PGP we normally certify
name and email address.  Name is unlikely to change, but people do get
new email addresses relatively frequently.  It may be appropriate for
a signature on an email address to expire periodically, with it being
re-issued if the email address is still valid.

Related to this, some systems may use certification by certain keys as an
authorization method.  Any key signed by the corporate key automatically
gets access to the company network, for example.  When someone quits
their certification gets revoked, but due to difficulties in ensuring
that revocation signatures propagate, putting an expiration in the
original cert provides extra insurance.  Again, valid certs would be
re-issued periodically.

Any other purposes which I have missed?

Given this analysis, it's not clear to me that expired signatures should
be ignored in trust calculations.  Suppose I trust Alice, who has signed
Bob's key, and I also trust Bob.  If Alice's signature on Bob's key
has expired, should I no longer trust signatures made by Bob's key?
Bob is still the same person he always was.  Maybe the sig on his key
has expired because he no longer works at Alice's company, but that
doesn't change who he is.

The purpose of Alice's signature was to identify Bob, not to say that
he is trustworthy.  I am the one who made that latter determination.
Given that Alice at one time certified Bob's identity, the fact that her
certification has expired doesn't change the fact that I still trust him.

In at least some cases, then, it might be reasonable to continue to use
expired signatures in trust calculation.

Hal

---

From: Frank Tobin <[email-masked]>
Date: Wed, 31 May 2000 19:23:11 -0500 (CDT)

> doesn't change who he is.

However, it is possible that his identity has changed.  Perhaps Alice was
signing Bob's position in the company.  Bob's position can change, and
Alice decided when she signed whether she believes Bob's position to be
static or variable information, by deciding on having the expiration or
not.  It is not up to you to decide whether what Alice signed was what she
believes to be permanent or temporary information; she decides that.

If she signed what you believe to be a "permanent identity" (e.g., name)
with an expiration attached, one conclusion you could draw is that
possibly a refinement of his identity in the future when the signature
expires (perhaps another Bob Smith comes into the company, and more
identifying information is needed).

In the end, as time goes on, no identifier created so far will point
directly to the entity known as Bob forever.  This is what the sig
expirations can be thought of as indicating, that the signer can only
assure himself/herself that the signed, confirmed identity, can be trusted
for at most the length of the signature.  Whether that information is
believed to be static or permament is decided by the signer, not by you.  
And if you don't trust the signer to make those distinctions, that's your
decision on your end.

-- 
Frank Tobin		http://www.uiuc.edu/~ftobin/

"To learn what is good and what is to be valued,
those truths which cannot be shaken or changed."  Myst: The Book of Atrus

---

From: [email-masked] (Bodo Moeller)
Date: Thu, 1 Jun 2000 04:49:26 +0200 (CEST)

[email-masked]:

> to reduce the attractiveness of the key as a target.  [...]
> else's hands.  [...]

A rule of thumb for this is as follows: Assume that every owner of a
signing-only key may elect to publish their private key after expiry.
(Further assume that consistent reliable clocks are available to all
participating entities.)  Can signatures created with these
no-longer-private keys lead to problems?  If so, then key expiry is
not properly observed.

> In the case of signatures I think things are quite different.  [...]

This is true, in principle; however note that the workaround for
enforcing key expiry (which is not covered by OpenPGP certificates) by
setting an expiry time in certifying signatures works only if expired
signatures are ignored.  (The *key* expiration time sub-packet
may be used only in self-signatures according to RFC 2440,
so it cannot be used instead.)

"Expired signatures must be ignored" actually is too strong a
statement.  More precisely, signatures must be ignored unless one is
sure that they were created before the signing key expired.  That is,
if you know that you received the signature sufficiently early, then
you may still use it; also if there's some trusted timestamp that
convinces you, you may still use the signature.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Thu, 1 Jun 2000 04:49:26 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

[email-masked]:

> to reduce the attractiveness of the key as a target.  [...]
> else's hands.  [...]

A rule of thumb for this is as follows: Assume that every owner of a
signing-only key may elect to publish their private key after expiry.
(Further assume that consistent reliable clocks are available to all
participating entities.)  Can signatures created with these
no-longer-private keys lead to problems?  If so, then key expiry is
not properly observed.

> In the case of signatures I think things are quite different.  [...]

This is true, in principle; however note that the workaround for
enforcing key expiry (which is not covered by OpenPGP certificates) by
setting an expiry time in certifying signatures works only if expired
signatures are ignored.  (The *key* expiration time sub-packet
may be used only in self-signatures according to RFC 2440,
so it cannot be used instead.)

"Expired signatures must be ignored" actually is too strong a
statement.  More precisely, signatures must be ignored unless one is
sure that they were created before the signing key expired.  That is,
if you know that you received the signature sufficiently early, then
you may still use it; also if there's some trusted timestamp that
convinces you, you may still use the signature.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

Date: Wed, 31 May 2000 17:24:40 -0700
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: patents?
Sender: [email-masked]

At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote:
>Being as no evil lawyers from NAI or elsewhere have swooped down on this
>list or on the IETF I'd say it's safe for now.
>
>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote:
>>Probably just standard boilerplate. They are just putting you on notice
>>that by publishing their source code they are not giving up any rights
>>that the may hold on the code.

You are both being far too optimistic.  While it is possible that you are 
correct, it is equally possible -- and many would say more likely -- that 
patents are, in fact, held or being prosecuted.

The IETF has had some patents emerge very late in the process, so the 
concern is not academic.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Date: Wed, 31 May 2000 19:23:11 -0500 (CDT)
From: Frank Tobin <[email-masked]>
To: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

Date: Wed, 31 May 2000 16:46:24 -0700
To: "William H. Geiger III" <[email-masked]>, Ulf =?US-ASCII?Q?M=94ller_?=<[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: patents?
Cc: [email-masked]
Sender: [email-masked]

Being as no evil lawyers from NAI or elsewhere have swooped down on this
list or on the IETF I'd say it's safe for now.

At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote:
>In <[email-masked]>, on 05/31/00
>    at 01:30 PM, Ulf M"ller <[email-masked]> said:
>
> >>From the PGP documentation: "Network Associates INc. may have patens and/or
> >pentding patent applications covering subject matter in this software or
> >its documentation; the furnishing of this software or documentation does
> >not give you any license to these patents." Does anybody know what that
> >refers to?
>
>Probably just standard boilerplate. They are just putting you on notice
>that by publishing their source code they are not giving up any rights
>that the may hold on the code.
>
>--
>---------------------------------------------------------------
>William H. Geiger III      http://www.openpgp.net
>Geiger Consulting
>
>Data Security & Cryptology Consulting
>Programming, Networking, Analysis
>
>PGP for OS/2:               http://www.openpgp.net/pgp.html
>E-Secure:                   http://www.openpgp.net/esecure.html
>---------------------------------------------------------------

From: [email-masked]
Date: Wed, 31 May 2000 16:21:12 -0700
To: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

Hal

Date: Wed, 31 May 2000 23:25:49 +0200
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

On Wed, May 31, 2000 at 10:13:00AM -0700, [email-masked] wrote:

>>                      [...]  Thus, if someone breaks or steals an
>> expired OpenPGP key, they can renew it, and the old certificates will
>> remain valid for the key with extended validity period or unlimited
>> validity.

> I agree that this is a problem.  In retrospect I wish we had done key
> expirations differently.
> 
> There are two possible attacks: one is to strip away the self signature
> entirely, making it appear that the key has no expiration.  The other
> is to issue a new self signature with a longer expiration.
> 
> The first problem applies to key revocations as well.

Only if you you accept keys without a self-signature.
GnuPG treats self-signatures as mandatory, which avoids this attack.
(As far as self-signatures are concerned -- key revocations are
obviously not mandatory :-)

>                                                        With a good key
> distribution infrastructure this should not be much of an issue.  The
> second problem is specific to expirations.
> 
> A workaround is to adopt the convention that if a key has multiple
> expirations, the earliest one applies.  This prevents the "zombie key",
> where the attacker attempts to bring a dead key back to life.  However it
> also prevents what I think was the original goal in putting expirations
> into self-sigs, which was to allow key holders to extend the life of
> their keys if they choose.

Software could accept such life-extending signatures if they are
received *while the key is still valid* (according to an earlier
self-signature) -- later on, it could be argued that new
self-signatures *must* be ignored because the key-owner told you so
by having his signature key expire.
(In case trusted timestamps by whatever means are available,
date of receipt could be replaced by the timestamp date.)

Note that key-expiration sub-packets as defined in RFC 2440 are still
very useful for sub-keys: During the lifetime of your signature key,
you could publish new encryption keys with short lifetime and with
up-to-date cipher preferences (according to your current choice of
software, availability of hardware accelerators, the state of the art
of cryptography research, and so on), or could re-sign an existing
encryption key with longer lifetime and updated cipher preferences.
So it's not fully true that the original goal of putting expirations
into the self-signatures is missed.

>> Fix: Always include a signature expiration time when certifying a key
>> that has a key expiration date in its self-signature; the time must be
>> chosen such that the certificate's validity does not extend further
>> into the future than the key's validity.

> That's a good idea, whether or not my proposal above was adopted.

>> The bottom line is that if you don't want to rely on signatures by
>> expired keys, then you cannot rely on any certificates that don't
>> contain a signature expiration time (unless the certified key
>> is in a version 3 public key packet).

> I think that my proposal would provide another way of addressing this.

Yes, but it needs stronger assumptions -- you rely on what you call
"a good key distribution infrastracture", i.e. you assume that the
attacker cannot influence the infrastructure to hide existing
signatures from you.

A more prudent approach is to say that the inferred semantics should
be monotonous in the set of signatures that one has seen; that is, to
never base trust in something on the fact that you have *not* seen
certain signatures.  I am fully aware that this does not work for key
revocations, but that's because they are a last resort -- and if you
revoke a key because it has been compromised, then probably you won't
just post the revocation to your favorite key server, but will also
mail it directly to the folks you're communicating with; obviously
such effort cannot usually be expected when handling ordinary key
certificates.  (OK, the S/MIME people do that all the time by
effectively appending the equivalent of a "key ring" to their
messages, but I hope you get the idea ...)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

From: "William H. Geiger III" <[email-masked]>
Date: Wed, 31 May 2000 15:05:15 -0500
To: Ulf =?US-ASCII?Q?M=94ller_?=<[email-masked]>
Cc: [email-masked]
Subject: Re: patents?
Sender: [email-masked]

In <[email-masked]>, on 05/31/00 
   at 01:30 PM, Ulf M”ller <[email-masked]> said:

>>From the PGP documentation: "Network Associates INc. may have patens and/or
>pentding patent applications covering subject matter in this software or
>its documentation; the furnishing of this software or documentation does
>not give you any license to these patents." Does anybody know what that
>refers to?

Probably just standard boilerplate. They are just putting you on notice
that by publishing their source code they are not giving up any rights
that the may hold on the code.

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

Date: Wed, 31 May 2000 13:04:23 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Lutz Donnerhacke <[email-masked]>
cc: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

On 31 May 2000, Lutz Donnerhacke wrote:

> * Werner Koch wrote:
> >On Tue, 30 May 2000, Lutz Donnerhacke wrote:
> >> But certificates of expired keys are still valid.
> >
> >However, this depends on the reason of certification.
> 
> No.
> 
> >For example, a revocation may have been issued to express that the
> >key has been compromised long time in the past and therefore the
> >signature has never been valid.
> 
> Every certificate of an revoked key is invalid. In law all certificates with
> has a timestamp before the key revokation timestamp are valid. German law
> contains a protocol error to not require the timestamp at receiver's end.

You say that every certificate of a revoked key is invalid. The current
draft claims otherwise. From 2440bis2:5.2.3.23:

   If a key has been revoked because of a compromise, all signatures
   created by that key are suspect. However, if it was merely
   superceded or retired, old signatures are still valid. If the
   revoked signature is the self-signature for certifying a user id, a
   revocation denotes that that user name is no longer in use. Such a
   revocation SHOULD inclide [sic] an 0x20 subpacket.

Note that this brings up several issues. Current implementations of PGP do
not use the Reason for Revocation tag, so all signatures made with PGP
currently must be treated as invalid if the signing key is revoked.

In the future, if this tag is used, keys revoked with reasons 0x01 and
0x03 should be considered "safe" in that certifications are still
valid. All other reasons for revocation, including 0x00, should render
certifications invalid.

I have ignored 0x20 on this issue, since it does not apply to revoked
keys.

I think that we should have another revocation reason, 0x04 - Preemptive
revocation certificate. I do not think that generating revocation
certificates at the time of key gen, and saving them for future use is the
best way to handle lost keys, but some people do this, and GnuPG actually
advises the user to make such revocations at the time of key
generation. Currently, they would fall into the category of 0x00, but due
to the lack of a valid timestamp on them, I would prefer to see them with
a more specific reason. Keys revoked with this reason should also render
their certifications invalid.

> >It is not easy to check this because it may be a pre-generated revocation
> >or a malicious revocation.
> 
> Definititly. That's why the law requires a timestamp on revokation and
> ultimate publication.

Again, a good reason to have a new reason for revocation in the case of
pre-generated revocations.

Another interesting problem that appears when certain revocations do not
render certifications invalid is that now we must still provide the user
with the means of re-revoking his key with a different reason for
revocation. If the reason is 0x01 or 0x03, it seems to me that we would
want to allow the user to change it to 0x02 if indeed it had been
compromised.

Or we simply say that all certifications by revoked keys are invalid, and
change the wording in the draft. 

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

Date: Wed, 31 May 2000 21:30:31 +0200
From: =?iso-8859-1?Q?Ulf_M=F6ller?= <[email-masked]>
To: [email-masked]
Subject: patents?
Sender: [email-masked]

>From the PGP documentation: "Network Associates INc. may have patens and/or
pentding patent applications covering subject matter in this software or
its documentation; the furnishing of this software or documentation does not
give you any license to these patents." Does anybody know what that refers
to?

From: [email-masked]
Date: Wed, 31 May 2000 10:13:00 -0700
To: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

Bodo Moeller writes:
> In the old PGP key format, key certification covers the expiration
> time, and all is well. (The validity period [key creation time and key
> expiration time] is part of the version 3 public key packet.)
> However, in the current OpenPGP key format, the key expiration time is
> covered only by self-signatures.  (A version 4 public key packet
> cannot specify a validity period.  The key validity period is in the
> signature packet instead.)  Thus, if someone breaks or steals an
> expired OpenPGP key, they can renew it, and the old certificates will
> remain valid for the key with extended validity period or unlimited
> validity.

I agree that this is a problem.  In retrospect I wish we had done key
expirations differently.

There are two possible attacks: one is to strip away the self signature
entirely, making it appear that the key has no expiration.  The other
is to issue a new self signature with a longer expiration.

The first problem applies to key revocations as well.  With a good key
distribution infrastructure this should not be much of an issue.  The
second problem is specific to expirations.

A workaround is to adopt the convention that if a key has multiple
expirations, the earliest one applies.  This prevents the "zombie key",
where the attacker attempts to bring a dead key back to life.  However it
also prevents what I think was the original goal in putting expirations
into self-sigs, which was to allow key holders to extend the life of
their keys if they choose.

> Fix: Always include a signature expiration time when certifying a key
> that has a key expiration date in its self-signature; the time must be
> chosen such that the certificate's validity does not extend further
> into the future than the key's validity.

That's a good idea, whether or not my proposal above was adopted.

> The bottom line is that if you don't want to rely on signatures by
> expired keys, then you cannot rely on any certificates that don't
> contain a signature expiration time (unless the certified key
> is in a version 3 public key packet).

I think that my proposal would provide another way of addressing this.

Hal

From: [email-masked]
Date: Wed, 31 May 2000 10:05:01 -0700
To: [email-masked], [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

Lutz writes:
> * [email-masked] wrote:
> >PGP versions 5.0 and later do not use expired keys in trust calculations.
>
> Bad choice.

Yet I explained our reasoning in making this choice, and you appeared to
basically agree:

> >The problem is that we don't have a mechanism for securely timestamping
> >signatures.
>
> There are techniques to do so (eternity log, ...) but they are
> contraproductive on signature generation. Timestamps are optionally on
> reception. In most cases they are generated implicit by starting an
> business action.
>
> >If someone breaks or steals an expired key, they can create a back-dated
> >signature with it.
>
> German politics generated a (not required) appendix to the law, prohibitting
> specifically to back-date a computer while signing a document. So I can not
> happen. :-)

Since the techniques to timestamp messages aren't implemented in our
protocol, and since the German law is obviously useless, it should
be clear that the timestamp on a signature is largely meaningless for
security purposes.  Hence comparing that against the expiration time of
the key is not a secure approach.  The method used in PGP is safer.

Hal

Date: Wed, 31 May 2000 15:42:22 +0200
From: Bodo Moeller <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

On Tue, May 30, 2000 at 03:58:57PM -0700, [email-masked] wrote:
> Paul Koning writes, quoting Len Sassaman:

>>> Eh? If you sign my key, and then your *key* expires, your
>>> signature is still included in validity calculations for my
>>> key. Even after your key expires. (However, you had to sign my key
>>> prior to the expiration of yours).

>> Agreed; that's what I meant.  (Checking the signature requires a key
>> that was good at the time that signature was created.  It's the
>> signature that is being verified, and the date of that signature is
>> what matters.)

> The problem is that we don't have a mechanism for securely timestamping
> signatures.  If someone breaks or steals an expired key, they can create
> a back-dated signature with it.
> 
> In my opinion it is risky to rely on a signature by an expired key.

Possibly, but ignoring keys on the grounds that they are expired does
not buy you much because of the expiry date protocol failure in the
OpenPGP key format.  I've brought this up some time ago on this
mailing list, here's a reminder:

In the old PGP key format, key certification covers the expiration
time, and all is well. (The validity period [key creation time and key
expiration time] is part of the version 3 public key packet.)
However, in the current OpenPGP key format, the key expiration time is
covered only by self-signatures.  (A version 4 public key packet
cannot specify a validity period.  The key validity period is in the
signature packet instead.)  Thus, if someone breaks or steals an
expired OpenPGP key, they can renew it, and the old certificates will
remain valid for the key with extended validity period or unlimited
validity.

Fix: Always include a signature expiration time when certifying a key
that has a key expiration date in its self-signature; the time must be
chosen such that the certificate's validity does not extend further
into the future than the key's validity.

The bottom line is that if you don't want to rely on signatures by
expired keys, then you cannot rely on any certificates that don't
contain a signature expiration time (unless the certified key
is in a version 3 public key packet).

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Behavior of implementations regarding certain key material
Date: 31 May 2000 08:44:35 GMT
Organization: IKS GmbH Jena
Lines: 23
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* [email-masked] wrote:
>The problem is that we don't have a mechanism for securely timestamping
>signatures.

There are techniques to do so (eternity log, ...) but they are
contraproductive on signature generation. Timestamps are optionally on
reception. In most cases they are generated implicit by starting an
business action.

>If someone breaks or steals an expired key, they can create a back-dated
>signature with it.

German politics generated a (not required) appendix to the law, prohibitting
specifically to back-date a computer while signing a document. So I can not
happen. :-)

>In my opinion it is risky to rely on a signature by an expired key.

No.

>PGP versions 5.0 and later do not use expired keys in trust calculations.

Bad choice.

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Behavior of implementations regarding certain key material
Date: 31 May 2000 08:36:28 GMT
Organization: IKS GmbH Jena
Lines: 21
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Werner Koch wrote:
>On Tue, 30 May 2000, Lutz Donnerhacke wrote:
>> But certificates of expired keys are still valid.
>
>However, this depends on the reason of certification.

No.

>For example, a revocation may have been issued to express that the
>key has been compromised long time in the past and therefore the
>signature has never been valid.

Every certificate of an revoked key is invalid. In law all certificates with
has a timestamp before the key revokation timestamp are valid. German law
contains a protocol error to not require the timestamp at receiver's end.

>It is not easy to check this because it may be a pre-generated revocation
>or a malicious revocation.

Definititly. That's why the law requires a timestamp on revokation and
ultimate publication.

From: [email-masked]
Date: Tue, 30 May 2000 15:58:57 -0700
To: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

Paul Koning writes, quoting Len Sassaman:
>  L> Eh? If you sign my key, and then your *key* expires, your
>  L> signature is still included in validity calculations for my
>  L> key. Even after your key expires. (However, you had to sign my key
>  L> prior to the expiration of yours).
>
> Agreed; that's what I meant.  (Checking the signature requires a key
> that was good at the time that signature was created.  It's the
> signature that is being verified, and the date of that signature is
> what matters.)

The problem is that we don't have a mechanism for securely timestamping
signatures.  If someone breaks or steals an expired key, they can create
a back-dated signature with it.

In my opinion it is risky to rely on a signature by an expired key.
PGP versions 5.0 and later do not use expired keys in trust calculations.
(PGP 2.6.2 and earlier did not support key expiration.)

Hal

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 14:37:07 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

>>>>> "L" == L Sassaman <[email-masked]> writes:

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

 L> On Tue, 30 May 2000, Paul Koning wrote:

 >> >>>>> "Lutz" == Lutz Donnerhacke <[email-masked]> writes:
 >> 
 Lutz> * Paul Koning wrote:
 >> >> It seems to me the logical thing to do is very easy to
 >> describe: >> expired or revoked certs are treated as if they were
 >> nonexistent.
 >> 
 Lutz> But certificates of expired keys are still valid.
 >>  For verifying old stuff, yes.  Not for new stuff.  So my simple
 >> description was too simplistic.  I would apply it to things
 >> expired or revoked as of the creation date of whatever I want to
 >> verify.

 L> Eh? If you sign my key, and then your *key* expires, your
 L> signature is still included in validity calculations for my
 L> key. Even after your key expires. (However, you had to sign my key
 L> prior to the expiration of yours).

Agreed; that's what I meant.  (Checking the signature requires a key
that was good at the time that signature was created.  It's the
signature that is being verified, and the date of that signature is
what matters.)

     paul

Date: Tue, 30 May 2000 11:32:11 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Paul Koning <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

On Tue, 30 May 2000, Paul Koning wrote:

> >>>>> "Lutz" == Lutz Donnerhacke <[email-masked]> writes:
> 
>  Lutz> * Paul Koning wrote:
>  >> It seems to me the logical thing to do is very easy to describe:
>  >> expired or revoked certs are treated as if they were nonexistent.
> 
>  Lutz> But certificates of expired keys are still valid.
> 
> For verifying old stuff, yes.  Not for new stuff.  So my simple
> description was too simplistic.  I would apply it to things expired or
> revoked as of the creation date of whatever I want to verify.

Eh? If you sign my key, and then your *key* expires, your signature is
still included in validity calculations for my key. Even after your key
expires. (However, you had to sign my key prior to the expiration of
yours).

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 13:43:51 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Newsgroups: iks.lists.ietf-open-pgp
Sender: [email-masked]

>>>>> "Lutz" == Lutz Donnerhacke <[email-masked]> writes:

 Lutz> * Paul Koning wrote:
 >> It seems to me the logical thing to do is very easy to describe:
 >> expired or revoked certs are treated as if they were nonexistent.

 Lutz> But certificates of expired keys are still valid.

For verifying old stuff, yes.  Not for new stuff.  So my simple
description was too simplistic.  I would apply it to things expired or
revoked as of the creation date of whatever I want to verify.

	paul

Date: Tue, 30 May 2000 19:46:32 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, 30 May 2000, Lutz Donnerhacke wrote:

> But certificates of expired keys are still valid.

However, this depends on the reason of certification.  I am not sure
whether the codes we already have for this are sufficient to
automatically determine whether the cerificate is still valid.

For example, a revocation may have been issued to express that the
key has been compromised long time in the past and therefore the
signature has never been valid.  It is not easy to check this because
it may be a pre-generated revocation or a malicious revocation.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: Behavior of implementations regarding certain key material
Date: 30 May 2000 16:39:45 GMT
Organization: IKS GmbH Jena
Lines: 5
NNTP-Posting-Host: taranis.iks-jena.de
Sender: [email-masked]

* Paul Koning wrote:
>It seems to me the logical thing to do is very easy to describe:
>expired or revoked certs are treated as if they were nonexistent.

But certificates of expired keys are still valid.

From: Paul Koning <[email-masked]>
Date: Tue, 30 May 2000 12:17:54 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

>>>>> "Florian" == Florian Weimer <[email-masked]> writes:

 Florian> Jon Callas <[email-masked]> writes:
 >> At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >From
 >> draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for
 >> >Revocation": > >| A revoked certification no longer is a part of
 >> validity >| calculations.  > >We were a bit surprised when we
 >> discovered this change to RFC 2440 >because RFC 2440 primarily
 >> specifies the OpenPGP message format, >and not the behavior of
 >> implementations when they encounter certain >OpenPGP messages,
 >> much to our discomfort.  >
 >> 
 >> Umm, so what is the problem? Is there a reason that a revoked
 >> certification *should* be part of validity calculations?

 Florian> No, of course not.  Our point is: There is no reason why an
 Florian> expired certification should be part of validity
 Florian> calculations, either (at least by default).  Ditto for
 Florian> expired keys.  But 2440bis does not state what to do in
 Florian> these cases, and in fact, implementations already show
 Florian> different behavior. 

It seems to me the logical thing to do is very easy to describe:
expired or revoked certs are treated as if they were nonexistent.

	paul

To: "William H. Geiger III" <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
From: Florian Weimer <[email-masked]>
Date: 30 May 2000 16:47:23 +0200
Lines: 55
Sender: [email-masked]

"William H. Geiger III" <[email-masked]> writes:

> Why can't you set an expiration time for the signature? This would seem
> the optimal way to do this.

AFAIK, there are implementations which use expired certificates in
validity calculations.  The certificate is used once to propagate
trust, and if the neighborhood of the web of trust doesn't change,
nothing happens if a certificate expires.

> Well either you need to have some standardization or you are going to have
> everyone doing their own thing. 

I believe that everyone shall build his own web of trust as he sees
fit, but that's more a political statement than a technical one, of
course.  But I do want to have control over the validity of
certificates issued by myself, that's the reason why I think that some
standardization (i.e. some necessary (but not sufficient) conditions
for certificate and key validity) are very useful.

> While I don't think a rigid RFC would be
> needed I do think a separate informational RFC would be advised.

Yes, that was our internal conclusion as well.  Oliver Goebel
<[email-masked]> is preparing such a document.  In
addition, the document will contain recommendations for interactive
OpenPGP implementations in borderline situations (just as an example,
what to do if a chain of trust can be established to a key, but some
of the links are expired certificates? -- the user should be given the
choice not to use the key, use it anyway, or sign it locally to
prevent future questions).

> From the point of view of interoperability it will be important for
> developers to know how the WoT is being handled by the various vendors.
> The major issue is keyring sharing. 

I don't think this is a problem.  Vendors can provide suitable
conversion programs.  In fact, OpenPGP implies a rather canonical key
ring exchange format (simple concatenation of keys), and I think all
OpenPGP implementation can handle this format.

On the other hand, say if a secret key is protected by a passphrase
and OpenPGP-optional symmetric cipher, there will always be
implementations which cannot do anything useful with it, simply
because the actual key material is protected by an unsupported cipher.

(Direct key ring sharing doesn't make sense anyway because the actual
key ring data structure depends heavily on the given application.
Locking is another issue.)

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

From: "William H. Geiger III" <[email-masked]>
Date: Mon, 29 May 2000 19:44:35 -0500
To: Florian Weimer <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

In <[email-masked]>, on 05/27/00 
   at 10:49 AM, Florian Weimer <[email-masked]> said:

>Jon Callas <[email-masked]> writes:

>> At 10:46 AM +0200 5/26/00, Florian Weimer wrote:
>> >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for
>> >Revocation":
>> >
>> >| A revoked certification no longer is a part of validity
>> >| calculations.
>> >
>> >We were a bit surprised when we discovered this change to RFC 2440
>> >because RFC 2440 primarily specifies the OpenPGP message format,
>> >and not the behavior of implementations when they encounter certain
>> >OpenPGP messages, much to our discomfort.
>> >
>> 
>> Umm, so what is the problem? Is there a reason that a revoked certification
>> *should* be part of validity calculations?

>No, of course not.  Our point is: There is no reason why an expired
>certification should be part of validity calculations, either (at least
>by default).  Ditto for expired keys.  But 2440bis does not state what to
>do in these cases, and in fact, implementations already show different
>behavior.  This is quite annoying if you want to limit in time the
>validity of your certificates.  In the past, the only way to do that was
>to revoke the certifying keys (yuk!); with 2440bis, you have to revoke
>the certificates.  Both options lead to a quickly growing CRL, which is
>very suboptimal.

Why can't you set an expiration time for the signature? This would seem
the optimal way to do this.

>Just to make one thing clear: We do not want to standardize the validity
>calculations themselves, nor the way the web of trust is built.  But we
>do want to have a set of conditions under which a certificate or a key
>won't be considered by validity calculations at all.

Well either you need to have some standardization or you are going to have
everyone doing their own thing. While I don't think a rigid RFC would be
needed I do think a separate informational RFC would be advised. 

>From the point of view of interoperability it will be important for
developers to know how the WoT is being handled by the various vendors.
The major issue is keyring sharing. Take the situation of 5 OpenPGP
vendors developing both standalone and application integration products.
Either the vendors must require the end user to make use of separate
keyrings or there must be some documentation in this area so the various
vendor products can share keyrings.

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

Date: Sun, 28 May 2000 14:12:25 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000, Jon Callas wrote:

> If I were really going to roto-till the spec, I'd get rid of key ids
> altogether and only use fingerprints. There have already been problems with

I'd second this.  However, the user will not see a difference as we
can still present him a keyID, although we are not using it anymore.
Using the keyID as a way to select a key is still a nice feature
because typing the whole fingerprint is not that easy.  

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

From: [email-masked]
To: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Sun, 28 May 2000 11:16:54 +0900
Lines: 102
Sender: [email-masked]

From: Jon Callas <[email-masked]>
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question  about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Fri, 26 May 2000 17:52:22 -0700
Message-ID: <p0431010eb554c334a4a3@[63.73.97.188]>

> Does anyone want to suggest wording on this?

below is one attempt.

p.s. there are other sections that i think could be made clearer.  are
     people amenable to receiving other suggestions for wording as well?

3.6.1.1. Simple S2K

   This directly hashes the string to produce the key data.  See below
   for how this hashing is done.

       Octet 0:        0x00
       Octet 1:        hash algorithm

   Simple S2K hashes the passphrase to produce the session key.  The
   manner in which this is done depends on the size of the session key
   (which will depend on the cipher used) and the size of the hash
   algorithm's output. If the hash size is greater than or equal to the
   session key size, the high-order (leftmost) octets of the hash are
   used as the key.

   If the hash size is less than the key size, the key is determined as
   the result of the concatenation of multiple hash values -- enough to 
   produce the required key data.  

   Prior to each hash calculation, an appropriate number of octets of zeros 
   are prepended to the data (in this case, the passphrase):

       hash(data)
       hash(0, data)
       hash(0, 0, data)

       ... and so on

   i.e. no prepending for the first hash computation, prepending one octet
   for the second hash computation, and thereafter increasing the number of 
   prepended octets of zeros by one for each subsequent hash computation.  

   The hash results are concatenated, first hash leftmost, to produce
   the key data, with any excess octets on the right discarded.

   Note that each hash computation should produce different output since
   in each case a different sequence of octets is hashed.
   
3.6.1.2. Salted S2K

   This includes a "salt" value in the S2K specifier -- some arbitrary
   data -- that gets hashed along with the passphrase string, to help
   prevent dictionary attacks.

       Octet  0:        0x01
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value

   Salted S2K is exactly like Simple S2K, except that the input to the
   hash function(s) consists of an appropriate number of octets of zeros, 
   8 octets of salt from the S2K specifier, followed by the passphrase.

3.6.1.3. Iterated and Salted S2K

   This includes both a salt and an octet count.  The salt is combined
   with the passphrase repeatedly depending on the octet count, and
   the resulting value is hashed.  This further increases the amount of 
   work an attacker must do to try dictionary attacks.

       Octet  0:        0x03
       Octet  1:        hash algorithm
       Octets 2-9:      8-octet salt value
       Octet  10:       count, a one-octet, coded value

   The count is coded into a one-octet number using the following
   formula:

       #define EXPBIAS 6
           count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);

   The above formula is in C, where "Int32" is a type for a 32-bit
   integer, and the variable "c" is the coded count, Octet 10.

   The input to the hash function(s) is determined in the following
   manner.  First, concatenate the 8 octets of salt from the S2K specifier 
   and the passphrase.  If the total length of the result is less than
   the count obtained by the above formula, concatenate sufficient
   octets from the salt and/or the passphrase such that the length of the
   resulting sequence is exactly equal to the count.  Finally,
   prepend an appropriate number of octets of zeros:

       zero(s), salt, passphrase, salt, passphrase, salt, ...

                <--------------- count octets -------------->

   Note that the count does not apply to the number of prepended octets 
   of zeros.  Also, if the octet count is less than the size of the salt 
   plus passphrase, the full salt plus passphrase will be hashed even 
   though that is greater than the octet count.

To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Behavior of implementations regarding certain key material
From: Florian Weimer <[email-masked]>
Date: 27 May 2000 10:49:21 +0200
Lines: 39
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> At 10:46 AM +0200 5/26/00, Florian Weimer wrote:
> >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for
> >Revocation":
> >
> >| A revoked certification no longer is a part of validity
> >| calculations.
> >
> >We were a bit surprised when we discovered this change to RFC 2440
> >because RFC 2440 primarily specifies the OpenPGP message format,
> >and not the behavior of implementations when they encounter certain
> >OpenPGP messages, much to our discomfort.
> >
> 
> Umm, so what is the problem? Is there a reason that a revoked certification
> *should* be part of validity calculations?

No, of course not.  Our point is: There is no reason why an expired
certification should be part of validity calculations, either (at
least by default).  Ditto for expired keys.  But 2440bis does not
state what to do in these cases, and in fact, implementations already
show different behavior.  This is quite annoying if you want to limit
in time the validity of your certificates.  In the past, the only way
to do that was to revoke the certifying keys (yuk!); with 2440bis, you
have to revoke the certificates.  Both options lead to a quickly
growing CRL, which is very suboptimal.

Just to make one thing clear: We do not want to standardize the
validity calculations themselves, nor the way the web of trust is
built.  But we do want to have a set of conditions under which a
certificate or a key won't be considered by validity calculations at
all.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

Date: Fri, 26 May 2000 17:52:22 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question  about section 3.6.1.1 simple s2k: how does preloading  work?)
Sender: [email-masked]

Does anyone want to suggest wording on this?

	Jon

Date: Fri, 26 May 2000 17:10:36 -0700
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

I think it really is just aesthetics whether you use the left or right bits
as a key id. I also believe that the left bits are the more aesthetic ones
to use, and I say that as a confirmed little-endian.

I'll also concur that the key server can use whatever bytes it wants.
That's no biggie.

If I were to make a V5 key structure, the thing I'd change would be *not*
to include the key creation time in with the SHA-1 hash for the
fingerprint. This was unfortunate. It means that two keys that have the
same key material, but different creation times have different key ids. At
one time I thought this was a feature, and I've come to believe it's a bug.

If I were really going to roto-till the spec, I'd get rid of key ids
altogether and only use fingerprints. There have already been problems with
key id collisions, and it would be much better to just use fingerprints. We
already say that you SHOULD NOT assume they're unique, but arguably that
really should be MUST NOT.

However, I think that none of those changes can be made. There comes a
point in any protocol's life where you just live with the warts because
correcting them causes more problems. The key id selection is one of those.
If we change things, we add more cruft into a system that already has cruft
in it.

There is already a separate algorithm for V3 keys and V4 keys. This would
give us another one, and one that exists for no good reason. And as Hal has
mentioned, the proper proper fix would be to make the UI that shows a 32
bit key id show the left 32 bits rather than the right ones. Fortunately,
we've managed to bury that issue completely and not even mention them. 32
bit key ids only exist in implementations.

	Jon

Date: Fri, 26 May 2000 16:47:25 -0700
To: Florian Weimer <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Behavior of implementations regarding certain key material
Sender: [email-masked]

At 10:46 AM +0200 5/26/00, Florian Weimer wrote:
>From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for
>Revocation":
>
>| A revoked certification no longer is a part of validity
>| calculations.
>
>We were a bit surprised when we discovered this change to RFC 2440
>because RFC 2440 primarily specifies the OpenPGP message format,
>and not the behavior of implementations when they encounter certain
>OpenPGP messages, much to our discomfort.
>

Umm, so what is the problem? Is there a reason that a revoked certification
*should* be part of validity calculations?

You're correct that 2440 is a syntax document, not a semantics document.
However, there are times when you have to hint at semantics when you're
describing syntax.

In this particular case, OpenPGP does not specify a trust model. At one
time, there were going to be a series of documents describing various trust
models that one might use (for example, the so-called web of trust), but no
one has seen fit to write these documents.

However, even though we don't specify what validity calculations to use,
there are nonetheless syntactic things we have to say about them. Whatever
validity model you're using, it seems pretty straight forward that a
revoked certification is null and void. That's all this is saying. It's in
2440bis because consensus asked that it be there.

	Jon

Date: Fri, 26 May 2000 12:50:56 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Marc Horowitz <[email-masked]>
cc: Jon Callas <[email-masked]>, [email-masked], [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

On 26 May 2000, Marc Horowitz wrote:

> "L. Sassaman" <[email-masked]> writes:
> 
> >> It's not just aesthetics. This issue was brought up by Marc Horowitz at
> >> the Keyserver Symposium this week. He thinks that it could have a positive
> >> impact on the internal workings of the keyservers, and would simplfy
> >> seaches for the user. 
> 
> I think Len is putting words in my mouth.  I do have some ideas which
> came out of the meeting for changes which would have a positive impact
> on the internal workings of the keyservers, and on the externally
> visible functioning of the network as a whole, but changing how keyids
> are generated and interpreted isn't one of them.

Sorry about that. I didn't mean to imply you suggested we change the
keyids (though I see that my paragraph above looks like I meant
that). But, if I am recalling correctly, you had thought it was something
that "would have been nice" if done the way Phil had wanted.

But then again, my recollection might be totally wrong... ;)
 
> To address Phil's concerns as described by Hal, there's no reason that
> you couldn't use the variable rightmost N bits of the fingerprint to
> identify a key with arbitrary specificity today.  For people's
> keyrings, the linear search won't take any more or less time.  For the
> keyserver, if people wanted this feature, it would be possible to
> start keeping an index of the fingerprint in reverse bit order.
> Changes would be necessary in the keyserver to support lookup by
> anything but a fixed position+length of the fingerprint, anyway.  This
> isn't pretty, but it would be complexity hidden from the user.

Completely hidden from the user, but not as fluid as a leftmost
keyid. Expanding from the right is less natural to users whose language
reads from left to right, in my opinion.
 
> I agree with everyone else that using the leftmost N bits would have
> been prettier, but isn't strictly necessary.

Then it is probably best to leave this as it is, and not make the
change. Unless Jon can think of other things this group has discussed that
would justify a v5 key format on their own...

- --Len.

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

Date: Fri, 26 May 2000 12:45:05 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: "David P. Kemp" <[email-masked]>
cc: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

On Fri, 26 May 2000, David P. Kemp wrote:

> Can someone explain the rationale for preferring to use one portion
> of a fingerprint rather than another as a key id?
> 
> My interest is academic rather than strictly PGP related.
> X.509 also uses key ids which are profiled to be fixed sized fields
> containing a hash value, so the situation is not unique to PGP.  My
> assumption is that: 1) no particular bits of a good cryptographic hash
> algorithm have any better collision resistance properties than any
> other bits, and 2) there is no significant computation savings in
> generating only a subset of the hash output, much less a difference in
> generating only high bits vs. only low bits.
> 
> Is this assumption wrong, or are there other reasons that using the low
> n bits of the output of a cryptographic hash as a key id is a blunder?
> It would be unfortunate if the same mistake were repeated elsewhere.

The issue here wasn't a technical one, but an "ease-of-use" one really. If
you obtain the keyid from the left of the fingerprint, it is easier for
the user to adjust the length of the keyid when necessary. I am further
assuming that your two assumptions are correct. The only benefit I see
here is the ability to dynamically adjust the size of the "keyid" when
searching for keys on a server or keyring, and when encrypting to keys.

> Dave Kemp
> 
> (I considered the possiblity that the message from Hal was dated
> 1 April and was delayed in transit, and verified that it was not.)

Hah! :)

- --Len.

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

From: Paul Koning <[email-masked]>
Date: Fri, 26 May 2000 15:34:02 -0400 (EDT)
To: [email-masked]
Cc: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

>>>>> "L" == L Sassaman <[email-masked]> writes:

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

 L> On Thu, 25 May 2000, Jon Callas wrote:

 >> If this blunder needs to be fixed, the correct way to fix it is to
 >> make a V5 key structure. (For that matter, there are a couple
 >> other things I'd fix, too, if we made a V5 key structure.)
 >> However, I think that as unfortunate as this is, simplicity and
 >> compatibility override aesthetics, and we should just live with
 >> things as they are.

 L> It's not just aesthetics. This issue was brought up by Marc
 L> Horowitz at the Keyserver Symposium this week. He thinks that it
 L> could have a positive impact on the internal workings of the
 L> keyservers,...

That doesn't compute.

If key servers want to have "high order" bits used as lookup index,
perhaps so standard database mechanisms that search for "match on
leading bits" can be used, that's fine.  This does NOT require a
protocol change!  A key server is perfectly well entitled to swizzle
the data around in any way it chooses for its own convenience; all
that is expected of it is that it unswizzles it before sending it back
out.

So if it's good for key servers, let the key servers internally turn
the fingerprint end for end.  Trivial coding and no protocol change
needed.  Not only that, but if you use a different database where this
approach is not useful, or even counterproductive, or a different
optimization is better, then you just do something else instead.  But
all of this is an internal implementation detail.

    paul

From: Paul Koning <[email-masked]>
Date: Fri, 26 May 2000 15:26:32 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

>>>>> "Jon" == Jon Callas <[email-masked]> writes:

 Jon> I agree that in retrospect, it would have been better to have
 Jon> the key id be the high-order bits of the fingerprint rather than
 Jon> the low-order bits. I, too, think this was a mistake. However,
 Jon> that decision was made before this working group was
 Jon> formed. (And before I joined PGP, Inc. for that matter.)

 Jon> I believe that changing this and making it be dependent on the
 Jon> algorithm type would be utterly wrong. It would add one more
 Jon> little gnarly bit into a system that is already filled with too
 Jon> many gnarly bits.

I agree that it should not be changed.  For that matter, I am
thoroughly puzzled why anyone would say that it's better to use high
order bits than low order bits.  We're talking about taking a subset
of the bits of a hash function, right?  Any old subset is as good as
any other.  A random subset of the bits would be just as good, or just
as bad, as the high order bits, or the low order bits.

   paul

Date: Fri, 26 May 2000 19:20:20 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, 26 May 2000, [email-masked] wrote:

> Or of course we could leave it as it is now.  I am still not convinced

Yes, please.  There is not that much difference in the code for either
of the ones.  Adding code for taking the keyid from the left side
just adds more complexity in terms of backward compatibilty and we
already have so much code just for backword issues.

> that the universe is constructed such that left substrings are inherently
> more natural than right ones.  Endian wars, anyone?

No, thanks.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

To: [email-masked]
Path: lutz
From: [email-masked] (Lutz Donnerhacke)
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: KeyID as left vs right substring of fingerprint
Date: 26 May 2000 15:40:07 GMT
Organization: IKS GmbH Jena
Lines: 13
NNTP-Posting-Host: taranis.iks-jena.de
Status: RO
Sender: [email-masked]

* [email-masked] wrote:
[Problem of retrieving]
>However, in the circumstances above where this arises, we don't know
>the key's version number.  We have only the algorithm id and the keyid.
>So we can't base the decision on anything other than the algorithm id.

So I urge to keep the current mechanism. Key IDs may expand to the left.

>Or of course we could leave it as it is now.  I am still not convinced
>that the universe is constructed such that left substrings are inherently
>more natural than right ones.  Endian wars, anyone?

Exactly. Keep it or run in trouble.

* [email-masked] wrote:
[Problem of retrieving]
>However, in the circumstances above where this arises, we don't know
>the key's version number.  We have only the algorithm id and the keyid.
>So we can't base the decision on anything other than the algorithm id.

So I urge to keep the current mechanism. Key IDs may expand to the left.

>Or of course we could leave it as it is now.  I am still not convinced
>that the universe is constructed such that left substrings are inherently
>more natural than right ones.  Endian wars, anyone?

Exactly. Keep it or run in trouble.

From: [email-masked]
Date: Fri, 26 May 2000 08:06:13 -0700
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

There is one possibly minor technical problem with making the change.

Presently some of the pgp clients display only 32 bits of the 64
bit keyid.  This might be done for example if they receive a message
encrypted to or signed by a key they don't know.  In that case they have
the 64 bit keyid but they sometimes only display 32 bits because that
is a more manageable size for humans.  Manual key server searches have
also supported 32 bit keyids.

With keyids as the right substring of both V3 RSA moduli and V4
fingerprints, it is most logical to use the right 32 bits of the 64 bits
for this purpose, and that is how it has been done.

If some keys start using left substrings, then it would be awkward
to continue to use the right 32 bits of the keyid as the short form.
This would end up being bits 32-63 of the fingerprint.  For keys that
use left substrings, it would be more appropriate to use the left 32
bits of the 64 as the short form of the keyid.

However, in the circumstances above where this arises, we don't know
the key's version number.  We have only the algorithm id and the keyid.
So we can't base the decision on anything other than the algorithm id.

There are a few possible solutions.

We could eliminate the 32-bit keyid display entirely, and only show
and input 64 bit keyids.  This is really a UI issue which is outside
the scope of this group, and while we have no obligation to support any
particular shortening of keyids, I think we should be aware of the impact
our decisions make on other parts of the system.

We could make the decision about which way to shorten it depend entirely
on the key algorithm, so that we'd need a new algorithm identifier for
RSA keys which used the new convention.

We could make new signature and pkesk packets which include more
information about the keyid, enough to allow it to be shortened
unambiguously (and perhaps supporting variable length keyids).

Or of course we could leave it as it is now.  I am still not convinced
that the universe is constructed such that left substrings are inherently
more natural than right ones.  Endian wars, anyone?

Hal

Date: Fri, 26 May 2000 09:12:13 -0400 (EDT)
From: "David P. Kemp" <[email-masked]>
Reply-To: "David P. Kemp" <[email-masked]>
Subject: Re: KeyID as left vs right substring of fingerprint
To: [email-masked]
Content-MD5: mmVajd5lUQd7KC36Tdej6w==
Sender: [email-masked]

Can someone explain the rationale for preferring to use one portion
of a fingerprint rather than another as a key id?

My interest is academic rather than strictly PGP related.
X.509 also uses key ids which are profiled to be fixed sized fields
containing a hash value, so the situation is not unique to PGP.  My
assumption is that: 1) no particular bits of a good cryptographic hash
algorithm have any better collision resistance properties than any
other bits, and 2) there is no significant computation savings in
generating only a subset of the hash output, much less a difference in
generating only high bits vs. only low bits.

Is this assumption wrong, or are there other reasons that using the low
n bits of the output of a cryptographic hash as a key id is a blunder?
It would be unfortunate if the same mistake were repeated elsewhere.

Dave Kemp

(I considered the possiblity that the message from Hal was dated
1 April and was delayed in transit, and verified that it was not.)

> Date: Thu, 25 May 2000 17:28:41 -0700
> To: [email-masked], [email-masked]
> From: Jon Callas <[email-masked]>
> Subject: Re: KeyID as left vs right substring of fingerprint
> 
> I agree that in retrospect, it would have been better to have the key id be
> the high-order bits of the fingerprint rather than the low-order bits. I,
> too, think this was a mistake. However, that decision was made before this
> working group was formed. (And before I joined PGP, Inc. for that matter.)
> 
> I believe that changing this and making it be dependent on the algorithm
> type would be utterly wrong. It would add one more little gnarly bit into a
> system that is already filled with too many gnarly bits.
> 
> If this blunder needs to be fixed, the correct way to fix it is to make a
> V5 key structure. (For that matter, there are a couple other things I'd
> fix, too, if we made a V5 key structure.) However, I think that as
> unfortunate as this is, simplicity and compatibility override aesthetics,
> and we should just live with things as they are.
> 
> 	Jon
> 
> 
> 
> *****************************************************************************
> This confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> ******************************************************************************

From: Marc Horowitz <[email-masked]>
To: "L. Sassaman" <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked], [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Date: 26 May 2000 09:14:40 -0400
Lines: 27
Sender: [email-masked]

"L. Sassaman" <[email-masked]> writes:

>> It's not just aesthetics. This issue was brought up by Marc Horowitz at
>> the Keyserver Symposium this week. He thinks that it could have a positive
>> impact on the internal workings of the keyservers, and would simplfy
>> seaches for the user. 

I think Len is putting words in my mouth.  I do have some ideas which
came out of the meeting for changes which would have a positive impact
on the internal workings of the keyservers, and on the externally
visible functioning of the network as a whole, but changing how keyids
are generated and interpreted isn't one of them.

To address Phil's concerns as described by Hal, there's no reason that
you couldn't use the variable rightmost N bits of the fingerprint to
identify a key with arbitrary specificity today.  For people's
keyrings, the linear search won't take any more or less time.  For the
keyserver, if people wanted this feature, it would be possible to
start keeping an index of the fingerprint in reverse bit order.
Changes would be necessary in the keyserver to support lookup by
anything but a fixed position+length of the fingerprint, anyway.  This
isn't pretty, but it would be complexity hidden from the user.

I agree with everyone else that using the leftmost N bits would have
been prettier, but isn't strictly necessary.

		Marc

To: [email-masked]
Subject: Behavior of implementations regarding certain key material
From: Florian Weimer <[email-masked]>
Date: 26 May 2000 10:46:46 +0200
Lines: 26
Sender: [email-masked]

>From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for
Revocation":

| A revoked certification no longer is a part of validity
| calculations.

We were a bit surprised when we discovered this change to RFC 2440
because RFC 2440 primarily specifies the OpenPGP message format,
and not the behavior of implementations when they encounter certain
OpenPGP messages, much to our discomfort.

We would like to see other requirements such as "An expired
certification is no longer part of validity calculations."  If you
are running a CA, you certainly want all implementations to react
to certfication expiration, certifying key expiration, certication
revocation etc. in the same manner.

If you agree that this should be addressed, we can document additional
requirements which make sense from our point of view as a basis for
further discussion.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

Date: Fri, 26 May 2000 10:21:09 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On 2000-05-25 09:45:24 -0700, [email-masked] wrote:

> The only keys that used right substrings would be
> "legacy" DSA and ElGamal keys (assuming that no one
> else has implemented RSA V4 keys, which I am not sure
> about).  We might do some kind of upgrade to DSA keys
> when the new larger hash is announced later this year,
> and they could switch at that time.  Maybe some
> arbitrary change could be made to ElGamal as well.

If things absolutely have to be changed in an incompatible
way, please use a different packet version (say, V5) for
this, so old software nicely breaks on it.

Everything else will lead to considerable confusion of
users and software.

-- 
http://www.guug.de/~roessler/

Date: Fri, 26 May 2000 00:45:14 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: Jon Callas <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

On Thu, 25 May 2000, Jon Callas wrote:

> If this blunder needs to be fixed, the correct way to fix it is to make a
> V5 key structure. (For that matter, there are a couple other things I'd
> fix, too, if we made a V5 key structure.) However, I think that as
> unfortunate as this is, simplicity and compatibility override aesthetics,
> and we should just live with things as they are.

It's not just aesthetics. This issue was brought up by Marc Horowitz at
the Keyserver Symposium this week. He thinks that it could have a positive
impact on the internal workings of the keyservers, and would simplfy
seaches for the user. However, I do agree that we should not break more
than we fix. If the benefits of doing keyids this way do not outweigh the
drawbacks, we probably shouldn't do it.

Out of curiosity, what are the other things you would like to fix, given
the chance to do a v5 key structure?

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

Date: Fri, 26 May 2000 00:35:31 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

I agree with Phil on this point.

As it stands right now, we have only two types of keys in use: v3 RSA and
v4 DSA/ElG keys. (I am ignoring ElGamal signing keys since I don't see
anyone using them on any significant scale).

Presently, both of the key types obtain their keyid in different ways, and
there haven't been any problems with that.

Granted, changing the scheme once again for obtaining the keyid would add
confusion to the spec, but I think that obtaining the keyid from the left
of the fingerprint would add considerable benefit.

In fact, if we were to do it this way, the fingerprint itself would become
the keyid, and users or implementations could provide as much or as little
of the fingerprint as was determined necessary for a unique match. 

This would also allow for cases where a unique match was not desirable,
such as anonymous communication where the user did not wish to have the
key id of the recipient visible in the encrypted blob, but wished to
provide a "hint" to the recipient as to which key it was encrypted. This
would be useful for those with several private keys on the same keyring.

A "v5" signature format would probably be the cleanest way to go (and then
we could possibly convert all existing keys to v5 as well), but we run
into backward compatability problems.

As for other implementations using RSA v4 keys, I know that GnuPG doesn't
generate them (though I provided Werner with an RSA v4 test keypair a
while back).

Thoughts?

- --Len.

__

L. Sassaman

System Administrator                |  "It's a nice day 
Technology Consultant               |   to start again."
icq.. 10735603                      |    
pgp.. finger://ns.quickie.net/rabbi |        --Billy Idol

On Thu, 25 May 2000 [email-masked] wrote:

> Currently in V4 keys, the keyid is defined to be the rightmost 64 bits
> of the fingerprint.  Phil Zimmermann has often complained about this
> and expressed the opinion that this was a blunder, and that we should
> have chosen the leftmost bits rather than the rightmost bits.
> 
> He says that this would facilitate a generalization of the keyid to be
> the leftmost N bits of the fingerprint.  N could be as long as the entire
> fingerprint, to have an essentially unambiguous pointer to a given key.
> Or N could be short, just a few bits, to have a nearly-"anonymous"
> key, where the set of possible keys was understood by all parties to be
> very small.
> 
> He also suggests that this would facilitate going to a key server storage
> model where a length-N keyid was the index.  N could be shorter or longer,
> and by using left substrings rather than right, he says that the server
> would have an easier time adapting to the variable length indexes.
> 
> PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for
> the first time.  These will use the hash method to derive the fingerprint
> and keyid, as with other V4 keys.
> 
> Phil proposed to me that we change the keyid calculation for these keys to
> use a left substring of the fingerprint rather than the right substring.
> More generally, all new key types would use left substrings.
> 
> The only keys that used right substrings would be "legacy" DSA and ElGamal
> keys (assuming that no one else has implemented RSA V4 keys, which I am
> not sure about).  We might do some kind of upgrade to DSA keys when the
> new larger hash is announced later this year, and they could switch at
> that time.  Maybe some arbitrary change could be made to ElGamal as well.
> 
> I will refrain from giving my own opinion about this idea, its
> justification, its timing, and its impact.  Input from others is welcome.
> 
> Hal
> 

From: [email-masked]
To: [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1
Date: Fri, 26 May 2000 15:07:54 +0900
Lines: 21
Sender: [email-masked]

From: "William H. Geiger III" <[email-masked]>
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1
Date: Tue, 23 May 2000 07:29:01 -0500
Message-ID: <[email-masked]>

...

> As an open question to list members:
> 
> What do you consider the proper response of OpenPGP software (client &
> server) when an established key (ie a key on the server or users keyring)
> is "updated" and unhashed data has been changed?

it seems to me that this might be handled in a number of ways depending
on the particular situation:

  -determined by "local" policy (the client or server has a policy which it
   follows)

  -determined by "key" policy (a policy is determined from some signed
   portion of the key)

Date: Thu, 25 May 2000 17:28:41 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

I agree that in retrospect, it would have been better to have the key id be
the high-order bits of the fingerprint rather than the low-order bits. I,
too, think this was a mistake. However, that decision was made before this
working group was formed. (And before I joined PGP, Inc. for that matter.)

I believe that changing this and making it be dependent on the algorithm
type would be utterly wrong. It would add one more little gnarly bit into a
system that is already filled with too many gnarly bits.

If this blunder needs to be fixed, the correct way to fix it is to make a
V5 key structure. (For that matter, there are a couple other things I'd
fix, too, if we made a V5 key structure.) However, I think that as
unfortunate as this is, simplicity and compatibility override aesthetics,
and we should just live with things as they are.

	Jon

From: [email-masked]
To: [email-masked]
Subject: Re: KeyID as left vs right substring of fingerprint
Date: Fri, 26 May 2000 08:55:22 +0900
Lines: 18
Sender: [email-masked]

From: [email-masked]
Subject: KeyID as left vs right substring of fingerprint
Date: Thu, 25 May 2000 09:45:24 -0700
Message-ID: <[email-masked]>

> Currently in V4 keys, the keyid is defined to be the rightmost 64 bits
> of the fingerprint.  Phil Zimmermann has often complained about this
> and expressed the opinion that this was a blunder, and that we should
> have chosen the leftmost bits rather than the rightmost bits.

is the idea of giving the leftmost N bits a name other than "keyid"
doable?  then both concepts can continue to exist and "keyid" can be
deprecated.  some names that came to mind (in no particular order):

   left keyid,
   lkeyid, 
   general keyid,
   revised keyid

From: [email-masked]
To: [email-masked]
Subject: Re: minor typos/points?
Date: Fri, 26 May 2000 08:49:53 +0900
Lines: 12
Sender: [email-masked]

From: "William H. Geiger III" <[email-masked]>
Subject: Re: minor typos/points?
Date: Tue, 23 May 2000 07:40:44 -0500
Message-ID: <[email-masked]>

> I always make it a practice to zip even individual files *before*
> encryption and sending. Zip seems better at dealing with file system
> issues better than PGP is (CRLF<->LF conversions, preserving EA's,
> ...ect).

i would be interested in seeing concrete examples demonstrating the
differences.  can you provide any?

From: [email-masked]
Date: Thu, 25 May 2000 09:45:24 -0700
To: [email-masked]
Subject: KeyID as left vs right substring of fingerprint
Sender: [email-masked]

Currently in V4 keys, the keyid is defined to be the rightmost 64 bits
of the fingerprint.  Phil Zimmermann has often complained about this
and expressed the opinion that this was a blunder, and that we should
have chosen the leftmost bits rather than the rightmost bits.

He says that this would facilitate a generalization of the keyid to be
the leftmost N bits of the fingerprint.  N could be as long as the entire
fingerprint, to have an essentially unambiguous pointer to a given key.
Or N could be short, just a few bits, to have a nearly-"anonymous"
key, where the set of possible keys was understood by all parties to be
very small.

He also suggests that this would facilitate going to a key server storage
model where a length-N keyid was the index.  N could be shorter or longer,
and by using left substrings rather than right, he says that the server
would have an easier time adapting to the variable length indexes.

PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for
the first time.  These will use the hash method to derive the fingerprint
and keyid, as with other V4 keys.

Phil proposed to me that we change the keyid calculation for these keys to
use a left substring of the fingerprint rather than the right substring.
More generally, all new key types would use left substrings.

The only keys that used right substrings would be "legacy" DSA and ElGamal
keys (assuming that no one else has implemented RSA V4 keys, which I am
not sure about).  We might do some kind of upgrade to DSA keys when the
new larger hash is announced later this year, and they could switch at
that time.  Maybe some arbitrary change could be made to ElGamal as well.

I will refrain from giving my own opinion about this idea, its
justification, its timing, and its impact.  Input from others is welcome.

Hal

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 23 May 2000 07:29:01 -0500
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1
Sender: [email-masked]

In <[email-masked]>, on 05/22/00 
   at 09:36 AM, [email-masked] said:

>> so is the signing key id the only subpacket that is allowed to go in
>> the unhashed area?

>No, anything which might reasonably be considered to be "advisory" and
>not security critical could go there.  For example the URL where the cert
>can be found.  I don't know if there is an exhaustive list. The point is
>that the software needs to be aware that material in the unhashed region
>is not authenticated and could have been tampered with.

>> also, for a given subpacket type, can instances of
>> that subpacket appear in either the hashed subpacket field or the
>> unhashed subpacket field, or is it a mutually exclusive situation?

>I don't see any problem in allowing that.

As an open question to list members:

What do you consider the proper response of OpenPGP software (client &
server) when an established key (ie a key on the server or users keyring)
is "updated" and unhashed data has been changed?

Take the example:

Software A lets the user enter on his key the prefered URL to obtain his
key on the self-sig for his key and the software stores it in an unhashed
subpacket.

The user distributes his key (other users, servers, ...ect).

Software A also allows the user to change this at a later date without
creating a new signature.

The user distributes this "updated" key.

How should the receiving software treat this "updated" data?

-- Ignore the "new" data

-- Accept the "new" data in place of the old data

-- Notify the receiver that there is "new" data and let him decide

-- ....?

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

From: "William H. Geiger III" <[email-masked]>
Date: Tue, 23 May 2000 07:40:44 -0500
To: [email-masked]
Cc: [email-masked]
Subject: Re: minor typos/points?
Sender: [email-masked]

In <[email-masked]>, on 05/22/00 
   at 09:16 PM, [email-masked] said:

>> This is an area of ambiguity we have run into.  Can you put multiple
>> literal data packets into compressed or encrypted data?  Can they be
>> inside/after signature packets?
>> 
>> My feeling is that it should be allowed.  Literal packets can have file
>> names associated with them and so this would be an efficient mechanism
>> for transferring multiple files.  I don't know what the current
>> implementations do.

>i wonder about how well this would work w/ mime.  for mail situations, i
>wonder whether it wouldn't be simpler and easier for users and
>implementors to either tar or zip up multiple files as a single file or
>to attach multiple files.

>for situations where the data is being processed directly by an openpgp
>implementation, processing multiple contiguous literal data packets seems
>fine...but openpgp and zip seem to be merging :-)

I always make it a practice to zip even individual files *before*
encryption and sending. Zip seems better at dealing with file system
issues better than PGP is (CRLF<->LF conversions, preserving EA's,
...ect).

-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------

Date: Wed, 24 May 2000 12:14:36 -0400
To: [email-masked], [email-masked], [email-masked]
From: Don Davis <[email-masked]>
Subject: Key Generation Security Flaw in PGP 5.0
Cc: [email-masked], [email-masked], Dan Geer <[email-masked]>
Sender: [email-masked]

> So the intervals between individual key presses remain as a source
> of randomness.
> Assuming that the user types at a rate of about 120 characters per
> minute, we have an interval of approximately 0.5 seconds between two
> key presses. Dropping the upmost non-random bit of the interval
> length, we get about 18 bits of random timing information per key
> press.

i'm sorry, but i think your estimate here is badly
flawed. you seem to assume that keyboard-timings
come in microsecond-scale resolutions.  it turns
out, though, that keyboard controllers check the
keyboard for input only every few milliseconds
(10 msec, if i remember correctly).  thus, your
keyboard-timings come in hundredth-sec increments,
and you get at most 6 or 7 bits of variability per
keystroke.  further. these timings are not uniformly
distributed, but probably show a normal distribution
centered at, say, 500 msec.  my guess is you're
getting only 3 or 4 bits of entropy per keystroke,
at most. i can calculate the entropy more precisely,
if you want.

> This estimate gets worse for experienced and
> fast-typing users.

much worse, because their keystroke timings will
be highly correlated with the textual content.
english text carries only around 1 bit of entropy
per character.

i congratulate you upon your discovery, and i thank
you for your diligence.  fwiw, i'm the author of a
paper about extracting randomness from disk timings,
which appeared at crypto '94, and which is cited in
rfc 1750 "recommendations for randomness."

				- don davis
				  http://world.std.com/~dtd

-

Date: Wed, 24 May 2000 09:43:06 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: FYI: Key Generation Security Flaw in PGP 5.0
Reply-To: [email-masked], [email-masked], [email-masked]
Mail-Followup-To: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

----- Forwarded message from [email-masked] -----

Date: Tue, 23 May 2000 14:13:23 -0700
From: [email-masked]
To: undisclosed-recipients: ;
Subject: Key Generation Security Flaw in PGP 5.0
Reply-To: [email-masked], [email-masked]
Mail-Followup-To: [email-masked], [email-masked]

                       SECURITY FLAW IN PGP 5.0
                       ========================

                          EXECUTIVE SUMMARY
                          -----------------

A flaw has been found in the randomness gathering code of PGP 5.

PGP 5 will, under certain well-defined circumstances, generate
public/private key pairs with no or only a small amount of
randomness. Such keys are insecure.

Chances are very high that you have no problem. So, don't panic.

                          WHO IS AFFECTED?
                          ----------------

The flaw has been found in the PGP 5.0i code base.  It is specific
to Unix systems such as Linux or various BSD dialects with a
/dev/random device.

Versions 2.* and 6.5 of PGP do NOT share this problem.

PGP versions ported to other platforms do NOT share this problem.

The problem does NOT manifest itself under the following
circumstances:

- You typed in a lot of data while generating your key, including
  long user ID and pass phrase strings.

- A random seed file PGP 5 could use existed on your system before
  you generated the key.

However, the problem affects you in the worst possible manner if you
started from scratch with pgp 5 on a Unix system with a /dev/random
device, and created your key pair non-interactively with a command
line like this one:

pgpk -g <DSS or RSA> <key-length> <user-id> <timeout> <pass-phrase>

                            WHAT TO DO?
                            -----------

If you have generated your key non-interactively, you may wish to
revoke it, and create a new key using a version of PGP which works
correctly.

                             DETAILS
                             -------

In order to generate secure cryptographic keys, PGP needs to gather
random numbers from reliable sources, so keys can't be predicted by
attackers.

Randomness sources PGP generally uses include:

- a seed file with random data from previous sessions
- user input and input timing

Additionally, certain Unix systems such as OpenBSD, Linux, and others,
offer a stream of random data over a central service typically called
/dev/random or the like.  If present, this service is used by PGP
as a source of random data.

PGP 5.0i's reading of these random numbers does not work. Instead of
random numbers, a stream of bytes with the value "1" is read.

In practice, this implies two things:

1. PGP5 will generally overestimate the amount of randomness
   available.  We have not researched the effects of this in detail.

   However, we believe that the amount of randomness gathered from
   input data, timing information, and old random data will be
   sufficient for most applications.  (See below for a detailed
   estimate.)

2. In situations in which no other randomness sources are available,
   PGP relies on the /dev/random service, and thus uses predictable 
   instead of random numbers. This is not a flaw of the random
   service, but of the PGP5 implementation.

One particular example of such a situation is non-interactive key
generation with a virgin PGP 5 installation, like described above.

Example:

  $ mkdir /tmp/pgp5test
  $ PGPPATH=/tmp/pgp5test 
  $ pgpk -g RSA 1024 [email-masked] 0 "passphrase string"

In fact, RSA keys generated this way are entirely predictable, which
can easily be verified by comparing key IDs and fingerprints.

When using DSA/ElGamal keys, the DSA signature key is predictable,
while the ElGamal encryption subkey will vary. Note that
fingerprints and key IDs of the predictable DSA keys depend on a
time stamp, and are themselves not predictable.

Proof of concept key rings generated with pgp 5.0i are available
from <http://olymp.org/~caronni/pgpbug-keyrings.tgz>.

                           GORY DETAILS
                           ------------

1. Code

Here's the flawed code from src/lib/ttyui/pgpUserIO.c:

 1314	static unsigned
 1315	pgpDevRandomAccum(int fd, unsigned count)
 1316	{
 1317	    char RandBuf;
 1318	    unsigned short i = 0;
 1319
 1320	    pgpAssert(count);
 1321	    pgpAssert(fd >= 0);
 1322
 1323	    for(i = 0; i <= count; ++i) {
>1324		RandBuf = read(fd, &RandBuf, count);
 1325		pgpRandomAddBytes(&pgpRandomPool, (byte *)&RandBuf, sizeof(RandBuf));
 1326		pgpRandPoolAddEntropy(256);
 1327	    }
 1328
 1329	    return(i);
 1330	}

The count parameter is always set to the value 1 by the calling
code.  The byte read from the file descriptor fd into the RandBuf
buffer is subsequently overwritten with the read() function's return
value, which will be 1.  The actual random data are not used.

This can be fixed by replacing line 1324 by the following line of
code:

	       read (fd, &RandBuf, 1);

2. "Random" data

A dump of random data gathered during an interactive key generation
session is available at <http://olymp.org/~caronni/randlog-keygen>.  
This was dumped as passed to the pgpRandomAddByte() function, one 
byte at a time.

Note the streams of bytes with the value 1 which should actually
contain data gathered from /dev/random.  Also note that the pass
phrase ("asdf") and the user ID ("[email-masked]") are clearly
visible, but mixed with timing data from the individual key presses.

No random data occuring after the second stream of ones were
generated from external events prior to the generation of the DSA
key in question.

3. Some estimates

We give a back-of-the-envelope upper estimate of the amount of
random bits PGP may gather during interactive key generation.  We
assume that /dev/random reading is flawed, and that no seed file
exists prior to running PGP. Timing is assumed to have a resolution
of 1 us (gettimeofday()).

During a PGP session of one minute, we can get at most 2^28
different time stamps (2^28 ~ 60*10^6).

Note that one time stamp close to the point of time of key
generation is known to attackers from the time stamp PGP leaves on
the key.

So the intervals between individual key presses remain as a source
of randomness.

Assuming that the user types at a rate of about 120 characters per
minute, we have an interval of approximately 0.5 seconds between two
key presses. Dropping the upmost non-random bit of the interval
length, we get about 18 bits of random timing information per key
press.

This estimate gets worse for experienced and fast-typing users.

With a user ID of 20 characters, and no pass phrase, PGP will have
gathered roughly 300-400 random bits interactively.  While this is
not bad, it is not sufficient by PGP's own standards.

                             CONCLUSIONS
                             -----------

        Public code review is a good thing - if it happens.

                               CREDITS
                               -------

This problem was found by Germano Caronni <[email-masked]>, and
verified by Thomas Roessler <[email-masked]> and Marcel Waldvogel
<[email-masked]>.

----- End forwarded message -----

Date: Tue, 23 May 2000 09:31:21 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: PGP/MIME: Time for last call?
Sender: [email-masked]

On Mon, 22 May 2000, Thomas Roessler <[email-masked]> wrote:
>On 2000-05-11 09:44:28 +0100, Ian Bell wrote:
>
>> 1) Simply state the problem, and indicate that for
>>    one-pass processing, two hashes will have to be
>>    prepared - one for binary-mode signatures and one
>>    for text-mode signatures.
>
>> 2) Mandate which form of signature must be used.
>>    Trailing spaces are often significant in email/news
>>    (sig-seps, RFC2646), so a binary-mode signature
>>    might seem preferable. However, existing PGP/MIME
>>    clients may be using either.
>
>> 3) Define a "pgp-mode" parameter, pgp-mode=binary or
>>    pgp-mode=text and ensure that new clients add the
>>    parameter to the multipart/signed header. If the
>>    parameter is missing (RFC2015 messages), then
>>    one-pass clients will have to prepare two hashes.
>
>Well...  As a fourth possibility, we could mandate that
>any trailing whitespace within body parts should lead to
>the use of quoted-printable or base64, thus effectively
>working around the problem.  However, this is _not_
>currently mandated by RFC 1847.

Mandating quoted-printable just as a workround for a sig-mode problem 
seems a little of a kludge - 3) still seems to me the solution that fits 
best with the aims of RFC1847.

[However, Turnpike already forces its PGP-signed messages into 
quoted-printable so that trailing-space corruption and Berkeley-From 
corruption problems are avoided]

-- 
Ian Bell                                           T U R N P I K E  Ltd

From: [email-masked]
To: [email-masked]
Subject: Re: minor typos/points?
Date: Tue, 23 May 2000 12:16:35 +0900
Lines: 115
Sender: [email-masked]

From: [email-masked]
Subject: Re: minor typos/points?
Date: Mon, 22 May 2000 08:45:29 -0700
Message-ID: <[email-masked]>

> >    5.2.3.4. Issuer
> >
> >       (8 octet key ID)
> >
> >       The OpenPGP key ID of the key issuing the signature.
> >
> >       MUST be present in the hashed area.
> 
> keyid can be unhashed.  I'm not sure it makes sense to have a mandatory
> unhashed packet, since unhased packets can have no security properties.

so, the issuer subpacket should not be mandatory then?

> > section 5.6 says:
> >
> >    Typically, this packet is found as the contents of an encrypted packet, 
> >    or following a Signature or One-Pass Signature packet, and contains 
> >    literal data packets.
> >
> > does this mean that multiple contiguous literal data packets can be
> > compressed into a compressed data packet?  if so, how is an
> > implementation supposed to interpret multiple literal data packets
> > contained in a single compressed data packet?
> 
> This is an area of ambiguity we have run into.  Can you put multiple
> literal data packets into compressed or encrypted data?  Can they be
> inside/after signature packets?
> 
> My feeling is that it should be allowed.  Literal packets can have file
> names associated with them and so this would be an efficient mechanism
> for transferring multiple files.  I don't know what the current
> implementations do.

i wonder about how well this would work w/ mime.  for mail situations,
i wonder whether it wouldn't be simpler and easier for users and
implementors to either tar or zip up multiple files as a single file
or to attach multiple files.

for situations where the data is being processed directly by an
openpgp implementation, processing multiple contiguous literal data
packets seems fine...but openpgp and zip seem to be merging :-)

> > section 6.1 has:
> >
> >   #define CRC24_POLY 0x1864cfbL
> >
> > should this not be:
> >
> >   #define CRC24_POLY 0x864cfbL
> 
> Not if you want the code to work... 

doh!

> note the line where that constant is used, the high "1" is used to
> clear a "1" in the crc variable.

how about the following code then?  i think it would make the text and
the code eaiser to understand and thus help prevent the question that
i asked from being asked again in the future (hopefully, it wouldn't
generate additional ones).

       #define CRC24_GENERATOR 0x864cfbL
       #define CRC24_POLY (CRC24_GENERATOR | 0x1000000L)

> > section 11.2 says:
> >
> >    A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
> >    Tag, followed by the two-octet packet length, followed by the entire
> >    Public Key packet starting with the version field.
> >
> > strictly speaking, this seems to imply that only old packet format packets
> > can be used.  i presume that is not what is meant.  how about the following
> > wording:
> >
> >    A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key
> >    packet (i.e. the entire packet header and all of the packet body fields).
> 
> No, it has to be a two byte length.  The length must be canonicalized
> to two bytes.  Otherwise there may be ambiguity in that the same length
> can be expressed in different forms.

ok i understand.  i see i was completely off regarding the old format
packets.

how about adding an explicit note in the rfc noting that the length
must be canonicalized to two bytes to prevent ambiguity in expressing
a particular length?  

i presume that two-octet lengths are sufficient for all the relevant
key sizes...

i keep wondering why there are even one-octet and two-octet lengths in
new format packets.  it seems far simpler to just have five-octet and
partial lengths.  are there significant advantages to having one- and
two-octet lengths?

> > section 12.1 says:
> >
> >   Note also that if an implementation does not implement the preference,
> >   then it is implicitly a TripleDES-only implementation.
> >
> > what does the phrase "the preference" refer to?  does it mean if an
> > implementation doesn't implement a system of preferences?
> 
> More specifically, that it doesn't support the preferred algorithm
> subpacket.  It doesn't create them, it doesn't read them.  It should
> always use triple des.

thanks for the clarification.

From: [email-masked]
Date: Mon, 22 May 2000 08:45:29 -0700
To: [email-masked], [email-masked]
Subject: Re: minor typos/points?
Sender: [email-masked]

>    5.2.3.4. Issuer
>
>       (8 octet key ID)
>
>       The OpenPGP key ID of the key issuing the signature.
>
>       MUST be present in the hashed area.

keyid can be unhashed.  I'm not sure it makes sense to have a mandatory
unhashed packet, since unhased packets can have no security properties.

> section 5.6 says:
>
>    Typically, this packet is found as the contents of an encrypted packet, 
>    or following a Signature or One-Pass Signature packet, and contains 
>    literal data packets.
>
> does this mean that multiple contiguous literal data packets can be
> compressed into a compressed data packet?  if so, how is an
> implementation supposed to interpret multiple literal data packets
> contained in a single compressed data packet?

This is an area of ambiguity we have run into.  Can you put multiple
literal data packets into compressed or encrypted data?  Can they be
inside/after signature packets?

My feeling is that it should be allowed.  Literal packets can have file
names associated with them and so this would be an efficient mechanism
for transferring multiple files.  I don't know what the current
implementations do.

> section 6.1 has:
>
>   #define CRC24_POLY 0x1864cfbL
>
> should this not be:
>
>   #define CRC24_POLY 0x864cfbL

Not if you want the code to work... note the line where that constant
is used, the high "1" is used to clear a "1" in the crc variable.

> section 11.2 says:
>
>    A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
>    Tag, followed by the two-octet packet length, followed by the entire
>    Public Key packet starting with the version field.
>
> strictly speaking, this seems to imply that only old packet format packets
> can be used.  i presume that is not what is meant.  how about the following
> wording:
>
>    A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key
>    packet (i.e. the entire packet header and all of the packet body fields).

No, it has to be a two byte length.  The length must be canonicalized
to two bytes.  Otherwise there may be ambiguity in that the same length
can be expressed in different forms.

> section 11.2 says:
>
>   a.2) high order length octet of (b)-(f) (1 octet)
>
>   a.3) low order length octet of (b)-(f) (1 octet)
>
> what does (f) refer to here?

Should be (e).

> section 12.1 says:
>
>   Note also that if an implementation does not implement the preference,
>   then it is implicitly a TripleDES-only implementation.
>
> what does the phrase "the preference" refer to?  does it mean if an
> implementation doesn't implement a system of preferences?

More specifically, that it doesn't support the preferred algorithm
subpacket.  It doesn't create them, it doesn't read them.  It should
always use triple des.

Hal

From: [email-masked]
Date: Mon, 22 May 2000 08:36:36 -0700
To: [email-masked], [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Sender: [email-masked]

> so is the signing key id the only subpacket that is allowed to go in
> the unhashed area?

No, anything which might reasonably be considered to be "advisory"
and not security critical could go there.  For example the URL where
the cert can be found.  I don't know if there is an exhaustive list.
The point is that the software needs to be aware that material in the
unhashed region is not authenticated and could have been tampered with.

> also, for a given subpacket type, can instances of
> that subpacket appear in either the hashed subpacket field or the
> unhashed subpacket field, or is it a mutually exclusive situation?

I don't see any problem in allowing that.

Hal

Date: Mon, 22 May 2000 13:14:29 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Subject: Re: PGP/MIME: Time for last call?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On 2000-05-11 09:44:28 +0100, Ian Bell wrote:

> 1) Simply state the problem, and indicate that for
>    one-pass processing, two hashes will have to be
>    prepared - one for binary-mode signatures and one
>    for text-mode signatures.

> 2) Mandate which form of signature must be used.
>    Trailing spaces are often significant in email/news
>    (sig-seps, RFC2646), so a binary-mode signature
>    might seem preferable. However, existing PGP/MIME
>    clients may be using either.

> 3) Define a "pgp-mode" parameter, pgp-mode=binary or
>    pgp-mode=text and ensure that new clients add the
>    parameter to the multipart/signed header. If the
>    parameter is missing (RFC2015 messages), then
>    one-pass clients will have to prepare two hashes.

Well...  As a fourth possibility, we could mandate that
any trailing whitespace within body parts should lead to
the use of quoted-printable or base64, thus effectively
working around the problem.  However, this is _not_
currently mandated by RFC 1847.

Actually, doing this is suggested in one of the example
messages, but for different reasons.

-- 
http://www.guug.de/~roessler/

From: [email-masked]
To: [email-masked]
Subject: minor typos/points?
Date: Mon, 22 May 2000 19:40:07 +0900
Lines: 131
Sender: [email-masked]

below are some minor typos/points i came across.

setion 5.2.1 says:

   0x18: Subkey Binding Signature
         This signature is a statement by the top-level signing key
         indicates that it owns the subkey.

shouldn't this be:

   0x18: Subkey Binding Signature
         This signature is a statement by the top-level signing key
         indicating that it owns the subkey.

?

section 5.2.4.1 says:

   An implementation SHOULD put the two mandatory subpackets, creation
   time and issuer, as the first subpackets in the subpacket list,
   simply to make it easier for the implementer to find them.

but, section 5.2.3.4 says:

   5.2.3.4. Issuer

      (8 octet key ID)

      The OpenPGP key ID of the key issuing the signature.

and does not mention that the issuer subpacket is mandatory, while section
5.2.3.3 mentions that the signature creation time is mandatory and that it
is present in the hashed area.  i presume that 5.2.3.4 could read:

   5.2.3.4. Issuer

      (8 octet key ID)

      The OpenPGP key ID of the key issuing the signature.

      MUST be present in the hashed area.

section 5.3 says:

   Zero or more Encrypted Session Key packets and/or Symmetric-Key
   Encrypted Session Key packets may precede a Symmetrically Encrypted
   Data Packet that holds an encrypted message.

does the phrase "more Encrypted Session Key packets" mean:

  more Public Key Encrypted Session Key packets

?

section 5.6 says:

   Typically, this packet is found as the contents of an encrypted packet, 
   or following a Signature or One-Pass Signature packet, and contains 
   literal data packets.

does this mean that multiple contiguous literal data packets can be
compressed into a compressed data packet?  if so, how is an
implementation supposed to interpret multiple literal data packets
contained in a single compressed data packet?

section 6 says:

   The checksum is a 24-bit CRC converted to four characters of radix-64
   encoding

shouldn't this be:

   The checksum is a 24-bit CRC converted to four characters of base64
   encoding

?

section 6.1 has:

  #define CRC24_POLY 0x1864cfbL

should this not be:

  #define CRC24_POLY 0x864cfbL

?

if not, shouldn't the constant listed in section 6:

  The CRC is computed by using the generator 0x864CFB and an
  initialization of 0xB704CE.

be 0x1864CFB?

section 11.2 says:

   A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
   Tag, followed by the two-octet packet length, followed by the entire
   Public Key packet starting with the version field.

strictly speaking, this seems to imply that only old packet format packets
can be used.  i presume that is not what is meant.  how about the following
wording:

   A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key
   packet (i.e. the entire packet header and all of the packet body fields).

section 11.2 says:

  a.2) high order length octet of (b)-(f) (1 octet)

  a.3) low order length octet of (b)-(f) (1 octet)

what does (f) refer to here?

section 12.1 says:

  Note also that if an implementation does not implement the preference,
  then it is implicitly a TripleDES-only implementation.

what does the phrase "the preference" refer to?  does it mean if an
implementation doesn't implement a system of preferences?

section 12.7 says:

   We have reserver three algorithm IDs for the US NIST's Advanced

i presume that should be:

   We have reserved three algorithm IDs for the US NIST's Advanced

From: [email-masked]
To: [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Date: Mon, 22 May 2000 19:07:47 +0900
Lines: 19
Sender: [email-masked]

From: [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Date: Thu, 18 May 2000 21:48:17 -0700
Message-ID: <[email-masked]>

> >  so "normally" the contents of the "hashed subpackets" field and the 
> >  "unhashed subpackets" field should be identical, correct?
> 
> No.  Some subpackets are hashed, while other ones are unhashed.  The
> latter are not protected by the signature and would be considered
> "advisory", like hints about where to find the signing key.  Currently
> we consider signing key id to be in that category.

ok.  

so is the signing key id the only subpacket that is allowed to go in
the unhashed area?  also, for a given subpacket type, can instances of
that subpacket appear in either the hashed subpacket field or the
unhashed subpacket field, or is it a mutually exclusive situation?

Date: Thu, 18 May 2000 22:53:29 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Sender: [email-masked]

On Fri, 19 May 2000 [email-masked] wrote:

> section 5.2.3.2 uses the definite article (as in "the default user id"):
> 
>   If the key is located by key id, then [the] algorithm of the default user 
>   id of the key provides the default symmetric algorithm.
> 
> i presume there is only one "default user id" -- that is, given a
> correct openpgp implementation, for any key (not packet, but entire
> key), the implementation should have some algorithm to decide what
> counts as the default user id.
>
> section 5.2.3.19 states that more than one user id in a key can be
> marked as primary and that the implementation may resolve the
> ambiguity in any way it sees fit.  i presume this means that the
> implementation must choose a default user id, but it has the freedom
> to decide how this choosing is done.  is that correct?

Right. There is only one primary user id (or default user id) per
key. More than one user id can have a self-sig with the primary user id
bit set, but the implementation must in some way determine which is the
"real" primary user id. I believe that checking the signature date, and
picking the most recent, makes a lot of sense... but as the RFC says, it
is up to the implementation.

- --Len.

__

L. Sassaman

System Administrator                |  "Everything must end; 
Technology Consultant               |   meanwhile we must 
icq.. 10735603                      |   amuse ourselves." 
pgp.. finger://ns.quickie.net/rabbi |             --Voltaire

From: [email-masked]
To: [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Date: Fri, 19 May 2000 13:59:36 +0900
Lines: 37
Sender: [email-masked]

From: "L. Sassaman" <[email-masked]>
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Date: Thu, 18 May 2000 20:58:58 -0700 (PDT)
Message-ID: <[email-masked]>

> I believe that "default user id" is synonymous with "primary user id".
> 
> - From the current draft:
> 
> 5.2.3.19. Primary user id
> 
>    (1 octet, boolean)
> 
>    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.

hmm...i don't get the impression that they are quite synonymous.

section 5.2.3.2 uses the definite article (as in "the default user id"):

  If the key is located by key id, then [the] algorithm of the default user 
  id of the key provides the default symmetric algorithm.

i presume there is only one "default user id" -- that is, given a
correct openpgp implementation, for any key (not packet, but entire
key), the implementation should have some algorithm to decide what
counts as the default user id.

section 5.2.3.19 states that more than one user id in a key can be
marked as primary and that the implementation may resolve the
ambiguity in any way it sees fit.  i presume this means that the
implementation must choose a default user id, but it has the freedom
to decide how this choosing is done.  is that correct?

From: [email-masked]
Date: Thu, 18 May 2000 21:48:17 -0700
To: [email-masked], [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Sender: [email-masked]

> here are some more clarification questions...
>
> -section 4.3 is titled "Packet Tags", and the term "packet tag" is used
>  throughout, but strictly speaking, shouldn't that be "content tag" as
>  per section 4.2?

I'll let someone else worry about that...

> -section 5.2.3 describes the version 4 signature packet format.  one of the
>  fields is described as:
>
>    Hashed subpacket data. (zero or more subpackets)
>
>  what is meant by "hashed" here?  are the contents of this field actual
>  subpackets or hash(subpackets)?  i presume it is the former and that 
>  "hashed" refers to the fact that the "hashed subpackets" field is included
>  among the material that is hashed when a signature is computed.  

Yes.

>  so "normally" the contents of the "hashed subpackets" field and the 
>  "unhashed subpackets" field should be identical, correct?

No.  Some subpackets are hashed, while other ones are unhashed.  The
latter are not protected by the signature and would be considered
"advisory", like hints about where to find the signing key.  Currently
we consider signing key id to be in that category.

> -section 5.2.3.1 describes the signature subpacket specification.  in
>  the description of the subpacket header there is the following:
>
>    - the subpacket type (1 octet)
>
>  then, shortly after:
>
>    The value of the subpacket type octet may be:
>
>        2 = signature creation time
>        ...
>        100 to 110 = internal or user-defined
>
>  however:
>
>    Bit 7 of the subpacket type is the "critical" bit.  If set, it
>    denotes that the subpacket is one that is critical for the evaluator
>    of the signature to recognize.  If a subpacket is encountered that
>    is marked critical but is unknown to the evaluating software, the
>    evaluator SHOULD consider the signature to be in error.
>
>  i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed
>  for the subpacket type octet actually refer to bits 6 through 0 of the
>  octet, and not that there haven't been any "critical subpacket types" defined
>  yet.  is this correct?  if so, i think alternate wording would be less
>  ambiguous.

Yes, your interpretation is correct.

> -section 5.2.3.3 has some notes on self-signatures.  the following text
>  appears therein:
>
>    If the key is located by key id, then algorithm of the default user id 
>    of the key provides the default symmetric algorithm.
>
>  the term "default user id" is used -- i failed to locate a definition for
>  this term.  could someone point out the definition in the specification 
>  or give one?

The default user id is better known as the primary user id - the user id
with a self-signature on it that includes the primary user id subpacket.

Hal

Date: Thu, 18 May 2000 20:58:58 -0700 (PDT)
From: "L. Sassaman" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Sender: [email-masked]

On Fri, 19 May 2000 [email-masked] wrote:

> -section 5.2.3.3 has some notes on self-signatures.  the following text
>  appears therein:
> 
>    If the key is located by key id, then algorithm of the default user id 
>    of the key provides the default symmetric algorithm.
> 
>  the term "default user id" is used -- i failed to locate a definition for
>  this term.  could someone point out the definition in the specification 
>  or give one?

I believe that "default user id" is synonymous with "primary user id".

- From the current draft:

5.2.3.19. Primary user id

   (1 octet, boolean)

   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.

- --Len.

__

L. Sassaman

System Administrator                |  "Everything must end; 
Technology Consultant               |   meanwhile we must 
icq.. 10735603                      |   amuse ourselves." 
pgp.. finger://ns.quickie.net/rabbi |             --Voltaire

From: [email-masked]
To: [email-masked]
Subject: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Date: Fri, 19 May 2000 12:04:06 +0900
Lines: 66
Sender: [email-masked]

here are some more clarification questions...

-section 4.3 is titled "Packet Tags", and the term "packet tag" is used
 throughout, but strictly speaking, shouldn't that be "content tag" as
 per section 4.2?

-section 5.2.3 describes the version 4 signature packet format.  one of the
 fields is described as:

   Hashed subpacket data. (zero or more subpackets)

 what is meant by "hashed" here?  are the contents of this field actual
 subpackets or hash(subpackets)?  i presume it is the former and that 
 "hashed" refers to the fact that the "hashed subpackets" field is included
 among the material that is hashed when a signature is computed.  

 so "normally" the contents of the "hashed subpackets" field and the 
 "unhashed subpackets" field should be identical, correct?

 if this is correct, i think it would be helpful to explicitly state that
 the contents of the "hashed supackets" field and the "unhashed subpackets"
 field are usually (should be?) the same.  alternatively, perhaps the
 fields could be given different names?  (actually, i think all fields 
 should be named "bruce" to avoid confusion ;-P )

 out of curiosity, why are the field contents repeated?
 
-section 5.2.3.1 describes the signature subpacket specification.  in
 the description of the subpacket header there is the following:

   - the subpacket type (1 octet)

 then, shortly after:

   The value of the subpacket type octet may be:

       2 = signature creation time
       ...
       100 to 110 = internal or user-defined

 however:

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that
   is marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

 i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed
 for the subpacket type octet actually refer to bits 6 through 0 of the
 octet, and not that there haven't been any "critical subpacket types" defined
 yet.  is this correct?  if so, i think alternate wording would be less
 ambiguous.

-section 5.2.3.3 has some notes on self-signatures.  the following text
 appears therein:

   If the key is located by key id, then algorithm of the default user id 
   of the key provides the default symmetric algorithm.

 the term "default user id" is used -- i failed to locate a definition for
 this term.  could someone point out the definition in the specification 
 or give one?

thanks.

From: [email-masked]
To: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?)
Date: Thu, 18 May 2000 10:06:13 +0900
Lines: 38
Sender: [email-masked]

From: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?)
Date: Wed, 17 May 2000 08:39:08 -0700
Message-ID: <[email-masked]>

> > so the last octet before message digest padding would not be the last
> > octet of the passphrase, as section 3.6.1.3 says:
> >
> >    Then the salt, followed by the passphrase data is repeatedly hashed
> >    until the number of octets specified by the octet count has been
> >    hashed.  The one exception is that if the octet count is less than
> >    the size of the salt plus passphrase, the full salt plus passphrase
> >    will be hashed even though that is greater than the octet count.
> >
> > is this correct?
> 
> Yes, but I don't believe 3.6.1.3 says that the last octet before message
> digest padding would be the last octet of the passphrase.

you are absolutely correct -- i agree that the section doesn't say
that.

the reason i asked this question was that since in the case where the
computed octet count is less than the length of the salt + passphrase,
the full salt + passphrase is hashed, one possible generalization for
the cases where the computed octet count is greater than the length of
the salt + passphrase would be to hash on salt + passphrase
boundaries.

what i found slightly ambiguous was the phrase:

   "until the number of ... has been hashed."

i would probably not have been confused if the phrasing had been:

  "until exactly the number of ... has been hashed."

thanks for the clarification.

From: [email-masked]
Date: Wed, 17 May 2000 08:39:08 -0700
To: [email-masked], [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?)
Sender: [email-masked]

> what happens in the case where the computed octet count is:
>
>   -not an integer multiple of the length of salt + passphrase and
>   -greater than the length of salt + passphrase
>
> ?
>
> i presume that exactly "computed octet count" octets are handed to the
> message digest algorithm (+ message digest padding), and not an
> integer multiple number of instances of salt + passphrase.

Yes.

> so the last octet before message digest padding would not be the last
> octet of the passphrase, as section 3.6.1.3 says:
>
>    Then the salt, followed by the passphrase data is repeatedly hashed
>    until the number of octets specified by the octet count has been
>    hashed.  The one exception is that if the octet count is less than
>    the size of the salt plus passphrase, the full salt plus passphrase
>    will be hashed even though that is greater than the octet count.
>
> is this correct?

Yes, but I don't believe 3.6.1.3 says that the last octet before message
digest padding would be the last octet of the passphrase.

Hal

From: [email-masked]
To: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?)
Date: Wed, 17 May 2000 16:54:54 +0900
Lines: 41
Sender: [email-masked]

yet another clarifying question...

From: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?)
Date: Mon, 15 May 2000 22:51:21 -0400
Message-ID: <[email-masked]>

> Actually what is input is:
> 
>    zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ...
> 
>              <---------------------  COUNT bytes  ------------------------->
> 
> and if COUNT (which is the computed octet count) is less than the length
> of salt + passphrase, we hash enough bytes so that we include the full
> salt + passphrase.

what happens in the case where the computed octet count is:

  -not an integer multiple of the length of salt + passphrase and
  -greater than the length of salt + passphrase

?

i presume that exactly "computed octet count" octets are handed to the
message digest algorithm (+ message digest padding), and not an
integer multiple number of instances of salt + passphrase.

so the last octet before message digest padding would not be the last
octet of the passphrase, as section 3.6.1.3 says:

   Then the salt, followed by the passphrase data is repeatedly hashed
   until the number of octets specified by the octet count has been
   hashed.  The one exception is that if the octet count is less than
   the size of the salt plus passphrase, the full salt plus passphrase
   will be hashed even though that is greater than the octet count.

is this correct?

thanks again.

From: [email-masked]
To: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Tue, 16 May 2000 15:38:07 +0900
Lines: 27
Sender: [email-masked]

From: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Mon, 15 May 2000 22:51:21 -0400
Message-ID: <[email-masked]>

...

> > is this correct?
> 
> No, unfortunately this is not correct, although I can see that the
> "repeatedly hashed" language could be read this way.  

doh!  perhaps another candidate for rewording :-)

> Actually what is input is:
> 
>    zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ...
> 
>              <---------------------  COUNT bytes  ------------------------->
> 
> and if COUNT (which is the computed octet count) is less than the length
> of salt + passphrase, we hash enough bytes so that we include the full
> salt + passphrase.

now i see the light!

thanks again.

From: [email-masked]
Date: Mon, 15 May 2000 22:51:21 -0400
To: [email-masked], [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Sender: [email-masked]

> ok, i think i've got it -- below is an outline of my current understanding.
>
> for each hash context instance, the initial input is:
>
>   zero(s) + salt + passphrase
>
> output from the hash, o1, is a fixed number of bytes, h.
>
> if the length of salt + passphrase in bytes is less than the
> calculated octet count, then o1 is given as input to the hash
> function which produces o2 (also length h).
>
> if the length of salt + passphrase + o1 is less than the calculated
> octet count, then o2 is given as input to the hash function and the
> process continues until the length of:
>
>   salt + passphrase + o1 + ... + on
>
> is greater than or equal to the calculated octet count.
>
> also, none of o1, ..., on have octets of zeros prepended.
>
> is this correct?

No, unfortunately this is not correct, although I can see that the
"repeatedly hashed" language could be read this way.  Actually what is
input is:

   zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ...

             <---------------------  COUNT bytes  ------------------------->

and if COUNT (which is the computed octet count) is less than the length
of salt + passphrase, we hash enough bytes so that we include the full
salt + passphrase.

Hal

From: [email-masked]
To: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Tue, 16 May 2000 13:44:45 +0900
Lines: 44
Sender: [email-masked]

From: [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Mon, 15 May 2000 20:41:58 -0400
Message-ID: <[email-masked]>

...

> > 2) for iterated and salted s2k, is the calculated octet count value
> >    taken over all hash context instances or just the first instance?
> 
> The count is per-instance.  

i think i understand now.

> Each instance is given a number of bytes of salt and passphrase,
> equal to the calculated octet count.  The pre-loaded zeros are not
> included in this count.

ok, i think i've got it -- below is an outline of my current understanding.

for each hash context instance, the initial input is:

  zero(s) + salt + passphrase

output from the hash, o1, is a fixed number of bytes, h.

if the length of salt + passphrase in bytes is less than the
calculated octet count, then o1 is given as input to the hash
function which produces o2 (also length h).

if the length of salt + passphrase + o1 is less than the calculated
octet count, then o2 is given as input to the hash function and the
process continues until the length of:

  salt + passphrase + o1 + ... + on

is greater than or equal to the calculated octet count.

also, none of o1, ..., on have octets of zeros prepended.

is this correct?

thanks again for the clarifications.

From: [email-masked]
Date: Mon, 15 May 2000 20:41:58 -0400
To: [email-masked], [email-masked]
Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Sender: [email-masked]

> i have some additional questions about the two subsequent sections.  section
> 3.6.1.2 says:
>
>    Salted S2K is exactly like Simple S2K, except that the input to the
>    hash function(s) consists of the 8 octets of salt from the S2K
>    specifier, followed by the passphrase.
>
> i presume this means that if the hash size is less than the key size,
> the method of utilizing multiple hash contexts and prepending octets
> of zeros described in 3.6.1.1 is employed.

Yes.

> i assume that this also applies to iterated and salted s2k (section 3.6.1.3).

Yes.

> if that is the case, suppose that the hash size is less than the key size:
>
> 1) for the second and subsequent hash context instances, do the octets
>    of zeros get prepended to the salt:
>
>      zero(s) + salt + passphrase
>
>   or are the zeros prepended to the passphrase:
>
>      salt + zero(s) + passphrase
>
>   ?  i presume it is the former, is that correct?

Yes.

> 2) for iterated and salted s2k, is the calculated octet count value
>    taken over all hash context instances or just the first instance?

The count is per-instance.  Each instance is given a number of bytes of
salt and passphrase, equal to the calculated octet count.  The pre-loaded
zeros are not included in this count.

Hal

From: [email-masked]
To: [email-masked]
Subject: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading  work?)
Date: Tue, 16 May 2000 11:40:38 +0900
Lines: 39
Sender: [email-masked]

From: Jon Callas <[email-masked]>
Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work?
Date: Mon, 15 May 2000 13:53:36 -0700
Message-ID: <p04310100b5461443b203@[63.73.97.188]>

> I'll look at clarifying the text.

thanks very much.

i have some additional questions about the two subsequent sections.  section
3.6.1.2 says:

   Salted S2K is exactly like Simple S2K, except that the input to the
   hash function(s) consists of the 8 octets of salt from the S2K
   specifier, followed by the passphrase.

i presume this means that if the hash size is less than the key size,
the method of utilizing multiple hash contexts and prepending octets
of zeros described in 3.6.1.1 is employed.

i assume that this also applies to iterated and salted s2k (section 3.6.1.3).

if that is the case, suppose that the hash size is less than the key size:

1) for the second and subsequent hash context instances, do the octets
   of zeros get prepended to the salt:

     zero(s) + salt + passphrase

  or are the zeros prepended to the passphrase:

     salt + zero(s) + passphrase

  ?  i presume it is the former, is that correct?

2) for iterated and salted s2k, is the calculated octet count value
   taken over all hash context instances or just the first instance?

thanks.

Date: Mon, 15 May 2000 13:53:36 -0700
To: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading  work?
Sender: [email-masked]

I'll look at clarifying the text.

	Jon

From: [email-masked]
To: [email-masked]
Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work?
Date: Sun, 14 May 2000 12:26:41 +0900
Lines: 40
Sender: [email-masked]

From: [email-masked]
Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work?
Date: Fri, 12 May 2000 08:15:42 -0400
Message-ID: <[email-masked]>

> The "preloading" means to hash the preloaded data.  In other words,
> the preloaded data is a prefix to the rest of the data to be hashed.
> It is not inserted directly into the state variables.
> 
> Without preloading, you would do hash(data).  Preloading one byte of
> zero you would do hash(0,data).  Preloading two bytes of data you would
> do hash(0,0,data), and so on, where the commas represent concatenation.

thank you very much for the clarification, i think i understand now.

initially, i had thought that that might have been what was meant, but
since elsewhere in the rfc the term "append" is used (5.1 and 5.5.3)
to describe a similar type of concatenation, i thought that the term
"prepend" might have been used if that was what was meant :-)

also, the phrasing involving "perloading hash contexts" was confusing
to me -- my image of a hash context comes from the source code of rfc
1321:

MD5_CTX *context;                                        /* context */
{
  context->count[0] = context->count[1] = 0;
  /* Load magic initialization constants.
*/
  context->state[0] = 0x67452301;
  context->state[1] = 0xefcdab89;
  context->state[2] = 0x98badcfe;
  context->state[3] = 0x10325476;
}

this particular "context" doesn't appear to contain any octets from
the message data to be hashed.

is there a generally accepted definition for what constitutes a hash
context?

From: Paul Koning <[email-masked]>
Date: Fri, 12 May 2000 11:41:52 -0400 (EDT)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work?
Sender: [email-masked]

>>>>> "hal" == hal  <[email-masked]> writes:

 hal> The "preloading" means to hash the preloaded data.  In other
 hal> words, the preloaded data is a prefix to the rest of the data to
 hal> be hashed.  It is not inserted directly into the state
 hal> variables.

 hal> Without preloading, you would do hash(data).  Preloading one
 hal> byte of zero you would do hash(0,data).  Preloading two bytes of
 hal> data you would do hash(0,0,data), and so on, where the commas
 hal> represent concatenation.

The use of terms like "preloading" and "multiple instances of the hash
context" makes it sound like a description of an implementation, which
of course isn't what you want in a protocol spec.  I wonder if it
would help to phrase it in the other way you just used: hash (data)
concatenated with hash (0 data) concatenated with ...

The key extension description in the IKE spec is done in this way, if
memory serves.

       paul

Date: Fri, 12 May 2000 16:33:16 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: PGP/MIME: Time for last call?
Sender: [email-masked]

On Fri, 12 May 2000, Florian Weimer <[email-masked]
Stuttgart.DE> wrote:
>Ian Bell <[email-masked]> writes:
>
>[micalg parameter doesn't contain all information to precompute the hash]
>
>> I feel that 3) is the most satisfactory fix to the problem, but that at
>> least 1) is incorporated into the draft before it is sent to last call.
>
>Or 4): Drop the micalg parameter.  This will make one-pass processing
>impossible, but I doubt that it's worth the trouble (unless the
>theoretical possibility of one-pass processing is required by some
>MIME standard). 

The micalg parameter is a required parameter of RFC1847.
One-pass processing seems to have been a design-goal of RFC1847.

I think there are benefits deriving from the fact that openPGP/MIME is
based on RFC1847 which mean that the micalg parameter should not be
dropped.

(not least of which is that the multipart/mixed signature draft is
written in terms of multiple RFC1847 signatures, not multiple
openPGP/MIME signatures.)

-- 
Ian Bell                                           T U R N P I K E  Ltd

Date: Fri, 12 May 2000 17:07:10 +0200
From: Thomas Roessler <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: Ian Bell <[email-masked]>, [email-masked]
Subject: Re: PGP/MIME: Time for last call?
Mail-Followup-To: Florian Weimer <[email-masked]>, Ian Bell <[email-masked]>, [email-masked]
Sender: [email-masked]

On 2000-05-12 16:46:10 +0200, Florian Weimer wrote:

> Synchronizing OpenPGP-MIME with these developments is
> not very complicated, but I think the benifit of having
> a micalg parameter is even too small for that.

Please note that the draft text already solves this:

| The "micalg" parameter for the "application/pgp-signature"
| protocol MUST contain exactly one hash-symbol of the
| format "pgp-<hash- symbol>", where <hash-symbol>
| identifies the Message Integrity Check (MIC) algorithm
| used to generate the signature. Hash-symbols are
| constructed from the text names registered in [1] or
| according to the mechanism defined in that document by
| converting the text name to lower case and prefixing it
| with the four characters "pgp-".

Ian: I'll come back to the issue you raised later.  I'll
have to check some things in 1847 for this.

-- 
http://www.guug.de/~roessler/

From: [email-masked]
Date: Fri, 12 May 2000 08:15:42 -0400
To: [email-masked], [email-masked]
Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work?
Sender: [email-masked]

The "preloading" means to hash the preloaded data.  In other words,
the preloaded data is a prefix to the rest of the data to be hashed.
It is not inserted directly into the state variables.

Without preloading, you would do hash(data).  Preloading one byte of
zero you would do hash(0,data).  Preloading two bytes of data you would
do hash(0,0,data), and so on, where the commas represent concatenation.

Hal

To: Ian Bell <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP/MIME: Time for last call?
From: Florian Weimer <[email-masked]>
Date: 12 May 2000 16:46:10 +0200
Lines: 22
Sender: [email-masked]

Ian Bell <[email-masked]> writes:

[micalg parameter doesn't contain all information to precompute the hash]

> I feel that 3) is the most satisfactory fix to the problem, but that at
> least 1) is incorporated into the draft before it is sent to last call.

Or 4): Drop the micalg parameter.  This will make one-pass processing
impossible, but I doubt that it's worth the trouble (unless the
theoretical possibility of one-pass processing is required by some
MIME standard).  Future revisions of the OpenPGP message standard
might specify additional hash algorithms (which might even require
some parameters); OpenPGP implementators might want to use proprietary
algorithms, and so on.  Synchronizing OpenPGP-MIME with these
developments is not very complicated, but I think the benifit of
having a micalg parameter is even too small for that.

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5

From: [email-masked]
To: [email-masked]
Subject: question about section 3.6.1.1 simple s2k: how does preloading work?
Date: Fri, 12 May 2000 17:59:54 +0900
Lines: 40
Sender: [email-masked]

i have a question about the "preloading" of hash contexts w/ zeros
that is described in section 3.6.1.1.

section 3.6.1.1 says:

   If the hash size is less than the key size, multiple instances of
   the hash context are created -- enough to produce the required key
   data. These instances are preloaded with 0, 1, 2, ... octets of
   zeros (that is to say, the first instance has no preloading, the
   second gets preloaded with 1 octet of zero, the third is preloaded
   with two octets of zeros, and so forth).

i am trying to understand how this "preloading" works.  using md5 as
an example, would the values of the context state variables be:

  0x00452301
  0xefcdab89
  0x98badcfe
  0x10325476

for the second instance, and

  0x00002301
  0xefcdab89
  0x98badcfe
  0x10325476

for the third instance?

that is, does the preloading occur after initializing the context
state w/ A, B, C, D, (as in rfc 1321) and starting w/ the most
significant byte?

it is not clear to me from the text of the rfc (and the bis draft)
that one can tell how the details of the preloading should work --
that is, it appears ambiguous to me.  perhaps there is some general
knowledge that i am ignorant of :-)  

is this type of preloading operation for hash contexts described in
detail somewhere?  any pointers would be appreciated.

Date: Thu, 11 May 2000 09:44:28 +0100
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: PGP/MIME: Time for last call?
Sender: [email-masked]

On Wed, 10 May 2000, Thomas Roessler <[email-masked]> wrote:
>Does anyone see a reason why we should not start getting
>the OpenPGP/MIME and multipart/mixed signature drafts into
>the RFC process?

Should the issue of binary versus text-mode signatures be addressed?

RFC1847 had the design objective of aiding single-pass signature
verification. To that end, it defined the micalg paramater so that the
client could pre-calculate the hash over the MIME data.

RFC2015 and RFC2015bis clients know what hash is required for the
signature, but they don't know what data has actually been hashed. The
line endings will always be CRLF because of the MIME canonicalization,
but trailing spaces may or may not be included in the hash depending on
the signature mode.

Possible improvements to openPGP/MIME could therefore be:

1) Simply state the problem, and indicate that for one-pass processing,
   two hashes will have to be prepared - one for binary-mode signatures
   and one for text-mode signatures.

2) Mandate which form of signature must be used. Trailing spaces are
   often significant in email/news (sig-seps, RFC2646), so a binary-mode
   signature might seem preferable. However, existing PGP/MIME clients
   may be using either.

3) Define a "pgp-mode" parameter, pgp-mode=binary or pgp-mode=text and
   ensure that new clients add the parameter to the multipart/signed
   header. If the parameter is missing (RFC2015 messages), then one-pass
   clients will have to prepare two hashes.

I feel that 3) is the most satisfactory fix to the problem, but that at
least 1) is incorporated into the draft before it is sent to last call.

-- 
Ian Bell                                           T U R N P I K E  Ltd

From: [email-masked]
To: [email-masked]
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Thu, 11 May 2000 00:22:19 +0900
Lines: 29
Sender: [email-masked]

From: Werner Koch <[email-masked]>
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Wed, 10 May 2000 16:28:47 +0200
Message-ID: <[email-masked]>

> On Wed, 10 May 2000, [email-masked] wrote:
> 
> > i presume you are referring to an mta on the sending client machine.
> > that is correct, right?
> 
> Sure.  The local /usr/lib/sendmail should do it.

this sounds like you are assuming a unix system w/ sendmail.

what i'm a bit more concerned about is all of the windows and mac
clients that i have to look after for my users.  each of those clients
connects to an external smtp server to send mail (i think that is a
pretty typical setup, don't you?).  i'm not very happy about the idea
of messages being accidentally transmitted in the clear between the
client and the smtp server [*].  it seems like for those cases the
mail client should (perhaps also) be doing the checking.

as a side note, in fact the mail client which i am using already
supports a bit of "policy" w.r.t. replying to messages that were
encrypted -- sadly it isn't a mail client that my windows and mac users
will use :-(

[*] good reason to use ssh port-forwarding of the relevant smtp connection
i guess, but not everyone will be so lucky...

Date: Wed, 10 May 2000 16:28:47 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 10 May 2000, [email-masked] wrote:

> i presume you are referring to an mta on the sending client machine.
> that is correct, right?

Sure.  The local /usr/lib/sendmail should do it.

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

Date: Wed, 10 May 2000 12:32:54 +0200
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Cc: John W Noerenberg II <[email-masked]>, Raph Levien <[email-masked]>, Michael Elkins <[email-masked]>, Dave Del Torto <[email-masked]>
Subject: PGP/MIME: Time for last call?
Mail-Followup-To: [email-masked], John W Noerenberg II <[email-masked]>, Raph Levien <[email-masked]>, Michael Elkins <[email-masked]>, Dave Del Torto <[email-masked]>
Sender: [email-masked]

Does anyone see a reason why we should not start getting
the OpenPGP/MIME and multipart/mixed signature drafts into
the RFC process?

-- 
http://www.guug.de/~roessler/

From: [email-masked]
To: [email-masked]
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Wed, 10 May 2000 19:05:20 +0900
Lines: 28
Sender: [email-masked]

From: Werner Koch <[email-masked]>
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Wed, 10 May 2000 11:10:14 +0200
Message-ID: <[email-masked]>

> On Wed, 10 May 2000, [email-masked] wrote:
> 
> > i would guess there have been cases of people who thought they had
> > encrypted or signed a message before sending it, but it turned out
> > they hadn't.  i have a vague recollection of this being mentioned in a
> > recent pgp usability study (perhaps someone can confirm).
> 
> IMHO, an MTA which rejects unencrypted mails would be a better
> alternative to protect against such kinds of failures.  It may look 
> at some headers to detect ML replies and use a table of
> addresses which are allowed to receive unencrypted mail.  Or reject
> everything unless a special formed address is used (which the MTA
> substitutes for the real address).

that is indeed another (not necessarily mutually exclusive) option.

i presume you are referring to an mta on the sending client machine.
that is correct, right?

i think i would like a client that does both :-)

in any case, i think it would make sense to point out somewhere these
kinds of concerns -- hints for implementors.

Date: Wed, 10 May 2000 11:10:14 +0200
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, 10 May 2000, [email-masked] wrote:

> i would guess there have been cases of people who thought they had
> encrypted or signed a message before sending it, but it turned out
> they hadn't.  i have a vague recollection of this being mentioned in a
> recent pgp usability study (perhaps someone can confirm).

IMHO, an MTA which rejects unencrypted mails would be a better
alternative to protect against such kinds of failures.  It may look 
at some headers to detect ML replies and use a table of
addresses which are allowed to receive unencrypted mail.  Or reject
everything unless a special formed address is used (which the MTA
substitutes for the real address).

  Werner

-- 
Werner Koch				OpenPGP key 621CC013
OpenIT GmbH                             tel +49 211 239577-0
Birkenstr. 12                           email   [email-masked]
D-40233 Duesseldorf                     http://www.OpenIT.de

From: [email-masked]
To: [email-masked]
Subject: suggesting displaying processed message before sending + confirmation (cf. rfc 2368)
Date: Wed, 10 May 2000 13:59:14 +0900
Lines: 32
Sender: [email-masked]

for reference, the following text is from the security considerations
section of rfc 2368:

   A mailto URL gives a template for a message that can be sent by mail
   client software. The contents of that template may be opaque or
   difficult to read by the user at the time of specifying the URL.
   Thus, a mail client should never send a message based on a mailto URL
   without first showing the user the full message that will be sent
   (including all headers that were specified by the mailto URL), fully
   decoded, and asking the user for approval to send the message as
   electronic mail. The mail client should also make it clear that the
   user is about to send an electronic mail message, since the user may
   not be aware that this is the result of a mailto URL.

   A mail client should never send anything without complete disclosure
   to the user of what is will be sent; it should disclose not only the
   message destination, but also any headers. Unrecognized headers, or
   headers with values inconsistent with those the mail client would
   normally send should be especially suspect. MIME headers (MIME-
   Version, Content-*) are most likely inappropriate, as are those
   relating to routing (From, Bcc, Apparently-To, etc.)

in a similar vein, would it not make sense to recommend that mail
clients display the encrypted or signed form of messages and ask for
confirmation before actually sending the message?  or at least
recommend providing the capability to do so.

i would guess there have been cases of people who thought they had
encrypted or signed a message before sending it, but it turned out
they hadn't.  i have a vague recollection of this being mentioned in a
recent pgp usability study (perhaps someone can confirm).

From: "Charlie Fletcher - www.ukdata.com" <[email-masked]>
To: "Finance Director" <[email-masked]>
Subject: Instant On-Line Credit Reports
Date: Tue, 9 May 2000 16:34:00 +0100
Sender: [email-masked]

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies

Date: Tue, 9 May 2000 09:07:54 -0400 (EDT)
From: "David M. Balenson" <[email-masked]>
To: [email-masked]
Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01)
Sender: [email-masked]

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

                          The Internet Society
         2001 Network and Distributed System Security Symposium
                               (NDSS'01)

                           February 7-9, 2001

                Catamaran Resort, San Diego, California

                            IMPORTANT DATES
          Paper Submission due:           August 2, 2000
          Author Notification:            September 27, 2000
          Camera-ready final papers due:  October 31, 2000

GOAL: 
  This symposium will foster information exchange among researchers 
  and practioners of network and distributed system security 
  services.  The intended audience includes those who are interested 
  in the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable 
  the Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium 
  will be published by the Internet Society.

Submissions are solicited for, but are not limited to, the following
topics:
 * Secure Electronic Commerce: e.g., payment, barter, EDI,
   notarization/timestamping, endorsement and licensing.
 * Intellectual Property Protection: protocols, schemas,
   implementations, metering, watermarking, other forms of rights
   management.
 * Implementation, deployment and management of network security
   policies.
 * Integrating Security in Internet protocols: routing, naming,
   TCP/IP, multicast, network management, and the Web.
 * Attack-resistant protocols and services.
 * Special problems and case studies: e.g., interplay and tradeoffs
   between security and efficiency, usability, reliability and cost.
 * Security for collaborative applications and services: tele- and
   video-conferencing, groupwork, etc.
 * Fundamental services: authentication, data integrity,
   confidentiality, authorization, non-repudiation, and availability.
 * Supporting mechanisms and APIs: key management and certification,
   revocation, audit trails and accountability.
 * Public Key Infrastructure.
 * Integrating security services with system and application security
   facilities and protocols: e.g., message handling, file
   transport/access, directories, time synchronization, database
   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.
 * Intrusion Avoidance, Detection, and Response: systems, experiences
   and architectures.
 * Network Perimeter Controls: firewalls, packet filters, application
   gateways.
 * Virtual Private Networks.

BEST PAPER AWARD:
  There will be a best paper award again this year. The award will
  be presented at the symposium to the authors of the best overall
  paper as selected by the Program Committee.

SUBMISSIONS:
  The Program Committee invites both technical papers and panel
  proposals. Technical papers should be at most 20 pages long. Panel
  proposals should be at most two pages and should describe the
  topic, identify the panel chair, explain the format of the panel,
  and list three to four potential panelists. Technical papers will
  appear in the proceedings. 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.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify the
  contact author in case of multi-author submissions. The names of
  authors, affiliations, and other identifying information should
  appear only on the separate title page. Submissions must be
  received by August 2, 2000, and must be made via electronically
  in either PostScript or ASCII format. If the Committee is unable
  to print a PostScript submission, a hardcopy will be requested.
  Therefore, PostScript submissions must arrive well before the
  deadline.

  Submission information can be found at
  http://www.isoc.org/ndss01/cfp. Dates, final call for papers,
  advance program, and registration information will be available
  soon at http://www.isoc.org/ndss01.

  Each submission will be acknowledged by e-mail. If acknowledgment
  is not received within seven days, please contact the program
  Co-chairs as indicated below. Authors and panelists will be
  notified of acceptance by September 27, 2000. Instructions for
  preparing camera-ready copy for the proceedings will be sent at
  that time. The camera-ready copy must be received by October 31,
  2000.

GENERAL CHAIR: 
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Avi Rubin, AT&T Labs - Research
  Paul Van Oorschot, Entrust Technologies

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:
  Carla Rosenfeld, Internet Society

PROGRAM COMMITTEE:
  Bennet Yee, University of California San Diego
  Bill Cheswick, Bell Labs
  Dave Kormann, AT&T Labs - Research
  David Aucksmith, Intel Corportation
  David P. Maher, Intertrust
  David Wagner, UC Berkeley
  Edward W. Felten, Princeton University
  Fabian Monrose, Bell Labs
  Gary McGraw, Reliable Software Technologies
  James Ellis, Sun Microsystems
  Kevin McCurley, IBM Almaden Research Center
  Matt Bishop, UC Davis
  Mudge, L0pht Heavy Industries, Inc.
  Peter Gutmann, University of Auckland, New Zealand
  Radia Perlman, Sun Microsystems
  Sandra Murphy, Network Associates
  Tom Berson, Anagram Laboratories
  Virgil D. Gligor, University of Maryland