Subject: Back-signatures proposal

From: David Shaw <[email-masked]>
Date: Tue, 28 Oct 2003 11:35:28 -0500

We had a fairly extensive discussion of back-signatures a few months
back on this list.  It seemed (at least to me) that we more or less
came to an understanding as to a way to address the problem.  I'm
planning on writing up the solution more formally, but before I do so,
I'd like a sanity check whether the problem and solution as I
understand it agrees with the problem and solution as everyone else
understands it.

The problem: it is possible for an attacker to take a signing subkey
from a victim's key and attach this signing subkey to the attacker's
own key.  The attacker does this by issuing a new binding signature on
the subkey from his own primary key.  The end result is that a
signature issued by this signing subkey may be claimed to be from
either the attacker or the victim.

Proposed solution: have the signing subkey issue a signature on the
primary key.  This prevents the attacker stealing the victim's subkey
since the attacker could not issue this signature.  Any signing subkey
without such a "back-signature" should be assumed to be suspect.

The details:

1) Define a new type of signature subpacket that consists of a
   regular signature contained in a subpacket.

2) Define a new signature class (Hal suggested 0x19), that is defined
   as a subkey signature on a primary key.  The hashing rules here are
   the same as a 0x1F signature - we hash the primary key, and issue a
   signature from the subkey over this hash.

3) At (sub)key generation time (or later, for existing keys) create
   this 0x19 signature and store it as a subpacket on the subkey
   binding signature.  It does not matter whether it is a hashed
   subpacket or not.

Some advantages:

1) Old signatures issued before this back-signature protection became
   available are automatically protected once the back-signature is
   added to a given key.

2) Storing the back-signature on the subkey binding signatures
   simplifies key maintenance.  If a subkey is deleted, the
   back-signature does with it automatically, and the implementation
   doesn't have to search for and delete back-signatures elsewhere on
   the key.

3) Existing signing subkeys can easily have a back-signature added.
   It is not necessary to create new subkeys.

4) By storing the data as a signature subpacket (which are generally
   ignored if not recognized), we minimize the chance of compatibility
   problems with older implementations.

Comments?

David

---

From: Michael Young <[email-masked]>
Date: Tue, 28 Oct 2003 16:56:18 -0500

I like the general proposal, for all of the reasons that David
listed.

My only question is about the encoding of the cross-signature
subpacket contents.  It could be anything from:
     a full Signature packet (including packet header); to,
     just the Signature packet contents; to,
     a leaner form with just the required fields (hash algorithm
      and signature MPIs), with the rest being assumed for the
      hash computation in order to reuse that.

I could live with any of these, but I lean toward the middle one.
We may uncover a need for subpackets in the cross-signature itself,
but it's hard to imagine wanting to use a different packet type
(as opposed to signature *version*), and the length is absolutely
redundant.  [Note that the signature computation hashes a canonical
header, not the actual one.]

If we do use a regular Signature packet (with or without header),
then
I'd like to see a recommendation on what subpackets it should
contain.
The usual rules don't apply: for example, the issuer is known.  I
don't see a *need* for any subpackets, even creation time (but I'm
open to arguments).

---

From: David Shaw <[email-masked]>
Date: Tue, 28 Oct 2003 17:29:54 -0500

> I could live with any of these, but I lean toward the middle one.

As do I, for reasons given below, as well as for reasons of
simplicity.

> then I'd like to see a recommendation on what subpackets it should
> contain.  The usual rules don't apply: for example, the issuer is
> known.  I don't see a *need* for any subpackets, even creation time
> (but I'm open to arguments).

I think it really depends on what the signature-in-a-subpacket is
being used for.  For the back-signature, it probably doesn't need any
subpackets.  At the same time, it doesn't hurt to include them.  Does
it matter very much?

I'd like to see the signature-in-a-subpacket used for other things
like notary signatures.  For that usage, the issuer and timestamp is
relevant.

David

---

From: Michael Young <[email-masked]>
Date: Tue, 28 Oct 2003 22:47:55 -0500

> being used for.  For the back-signature, it probably doesn't need
 > any subpackets.  At the same time, it doesn't hurt to include them.
 >  Does it matter very much?

Yes, I was referring specifically to subkey cross-signatures.
Including subpackets, particularly issuerId, is just wasteful
in this situation.  (They're pretty wasteful on binding signatures,
too; one might argue that they could help correct a shuffled
packet sequence, but that's a stretch.)  I'd like to see
recommendations for each flavor of signature that reflect
real needs.

---

From: David Shaw <[email-masked]>
Date: Tue, 28 Oct 2003 23:47:04 -0500

> recommendations for each flavor of signature that reflect

I think that is straying into overkill.  If there is no security or
protocol correctness issue at hand, just say nothing.

Let's credit implementors with some ability to know which subpackets
are useful for a given purpose.  We don't need an RFC, written with no
knowledge of the internal code of a given implementation, to proclaim
that an issuer ID might not be necessary - especially since the
presence of that same issuer ID harms nobody.

Also, an issuer ID - at worst - is 14 bytes long.  If you really want
to save some space on keys, we should issue guidelines on how large a
photo ID should be ;)

David

---

From: Michael Young <[email-masked]>
Date: Wed, 29 Oct 2003 16:19:07 -0500

David Shaw wrote:
 >>I'd like to see

I apologize.  Earlier drafts specified that creation time and
issuer were mandatory subpackets.  The current draft no longer
carries that language (and is better for it).

---

From: Carl Ellison <[email-masked]>
Date: Fri, 31 Oct 2003 08:44:39 -0800

This concern applies, IMHO, when the keyholder derives power from the thing that is signed, as opposed to the normal course of business in which the thing signed derives power from the key.

In the normal case, the key itself gets power because someone certifies it. If it's a subkey and the world knows a keyholder by primary key, then you need a signature from the primary key to the subkey.

In this other case, if the source of the power (the thing signed) is capable of signing things, then it needs to sign the subkey, to transmit its power to that key.

If the source of the power is not capable of signing things, then there's no way to construct a cryptographic proof.

For example, the thing granting power might be a patent application.  How would this grant power to a key?

If someone wants to sign the patent app while transmitting it to the USPTO, that's fine, but that signature doesn't mean anything.  The power comes from having the patent app be signed and time-stamped by the USPTO.  If that app includes the hash of the user's signing key, then there is a chain of empowerment established with all the arrow heads pointing in the same direction - and that's the minimum requirement for whatever we're talking about to be meaningful.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]      http://theworld.com/~cme |
|    PGP: 75C5 1814 C3E3 AAA7 3F31  47B9 73F1 7E3C 96E7 2B71       |
+---Officer, arrest that man. He's whistling a copyrighted song.---+

---

From: David Shaw <[email-masked]>
Date: Fri, 31 Oct 2003 14:30:34 -0500

On Fri, Oct 31, 2003 at 08:44:39AM -0800, Carl Ellison wrote:
> 
> This concern applies, IMHO, when the keyholder derives power from
> the thing that is signed, as opposed to the normal course of
> business in which the thing signed derives power from the key.

I see the stolen signatures problem as something that naturally
follows from your second example.  As you say, when I issue a
signature on something, I give that something power.  At the same time
though, I certainly don't want someone else claiming that *they* gave
it that power.

As the protocol stands now, it is easy for multiple people to claim
ownership of a given signature, and produce a valid key to back up
that claim.  To be sure, there are other (more difficult) ways for an
attacker to do the same thing, but either of the proposed fixes raises
the bar sufficiently to stop casual exploitation.

David

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 31 Oct 2003 12:13:55 -0800

At 08:44 AM 10/31/2003 -0800, Carl Ellison wrote:

[...]
>would this grant power to a key?

Suppose I download the patent application from USPTO's site, over a secure 
link.

I notice the patent has a signature on it, and I know the USPTO is in the 
habit of signing pending applications with its own key.

I go to a PGP key server and find a key claiming to belong to USPTO.  I use 
it to verify the application.  Since it verifies, I jump to the conclusion 
that the key belongs to the USPTO.

This conclusion is unwarranted and dangerous, as things stand - just cause 
a key verifies a signature, doesn't mean the key made the signature.

However, if the signed application contained the key or its hash anywhere, 
then I *could* use the application to "authenticate" the key.

The odd thing is the key or its hash doesn't need to be inside the 
signature, just attached to the document somewhere, since the only 
meaningful attack here is one performed by an attacker who can't modify the 
document - such an active attacker could just re-sign the document himself.

Or is that true?  I'm not sure.  Is it possible that an attacker would be 
able to fiddle the key hash but not actually re-sign the document?  Perhaps 
not, but it seems safest to put the key-hash inside the signature, just in 
case.

Anyways, if this was done, then users who make the naive assumption that if 
a key verifies a signature, it must have made the signature, would be safe.

--- (stray thought, not related to PGP) ---

There's another use for including extra "context" in a signature.  I think 
this use is more important in general, but less important in the particular 
case of PGP subkeys.  But I summarize it here cause it's theoretically 
interesting.

This use is to include extra context in a signature so as to differentiate 
between multiple instances of the same key.

For example, I believe an SPKI signature covers the subject certificate 
only, not the issuer's certificate.  Thus if an issuer has multiple 
certificates containing the same key, a subject can "re-root" itself under 
whichever of the issuer's certificates is most to its (the subject's) liking.

For example: suppose an issuer certificate is revoked, and the issuer 
receives a new certificate for the same key.  You might assume all 
certificates issued under the revoked certificate are also revoked, but 
you'd be wrong: the holders of these certificates could re-root themselves 
under the issuer's new certificate.

Similar things are possible in X.509, which is why a recent book on PKI [1] 
recommends against re-using keys:

"There is a more compelling reason not to put a single public key in 
multiple certificates, however: It is too easy to "slip up" and not hold 
all other important aspects of these multiple certificates 
constant.[...]  Such situations may allow an attacker (or even an 
underhanded certificate subject) to substitute one certificate for another 
so that what was once merely a signed piece of data now takes on an 
entirely new meaning.  Mandating that different certificates always contain 
different public keys is a simple way to entirely preclude the risk of such 
substitution attacks."

I dislike that mandate, since there are good reasons for re-using keys 
(limited key storage, the expense of key generation, etc..).  Instead, I 
think it would be preferable if every signature covers all relevant context 
needed to differentiate the signing key from the same key used in a 
different certificate.

Granted, in PGP subkeys this may not be worth doing.   But at the "theory" 
level, this seems a good principle for certificate formats.

I'm curious if you agree with that (I suspect you don't, or SPKI would be 
different :-).  This is wandering off-topic, though, I know..

Trevor

[1] Understanding PKI, 2nd Ed., Carlisle Adams and Steve Lloyd 

Date: Fri, 31 Oct 2003 12:13:55 -0800
To: Carl Ellison <[email-masked]>
From: Trevor Perrin <[email-masked]>
Subject: Re: theory (was Re: Back-signatures proposal)
Cc: [email-masked]
Sender: [email-masked]

At 08:44 AM 10/31/2003 -0800, Carl Ellison wrote:

[...]
>would this grant power to a key?

Suppose I download the patent application from USPTO's site, over a secure 
link.

I notice the patent has a signature on it, and I know the USPTO is in the 
habit of signing pending applications with its own key.

I go to a PGP key server and find a key claiming to belong to USPTO.  I use 
it to verify the application.  Since it verifies, I jump to the conclusion 
that the key belongs to the USPTO.

This conclusion is unwarranted and dangerous, as things stand - just cause 
a key verifies a signature, doesn't mean the key made the signature.

However, if the signed application contained the key or its hash anywhere, 
then I *could* use the application to "authenticate" the key.

The odd thing is the key or its hash doesn't need to be inside the 
signature, just attached to the document somewhere, since the only 
meaningful attack here is one performed by an attacker who can't modify the 
document - such an active attacker could just re-sign the document himself.

Or is that true?  I'm not sure.  Is it possible that an attacker would be 
able to fiddle the key hash but not actually re-sign the document?  Perhaps 
not, but it seems safest to put the key-hash inside the signature, just in 
case.

Anyways, if this was done, then users who make the naive assumption that if 
a key verifies a signature, it must have made the signature, would be safe.

--- (stray thought, not related to PGP) ---

There's another use for including extra "context" in a signature.  I think 
this use is more important in general, but less important in the particular 
case of PGP subkeys.  But I summarize it here cause it's theoretically 
interesting.

This use is to include extra context in a signature so as to differentiate 
between multiple instances of the same key.

For example, I believe an SPKI signature covers the subject certificate 
only, not the issuer's certificate.  Thus if an issuer has multiple 
certificates containing the same key, a subject can "re-root" itself under 
whichever of the issuer's certificates is most to its (the subject's) liking.

For example: suppose an issuer certificate is revoked, and the issuer 
receives a new certificate for the same key.  You might assume all 
certificates issued under the revoked certificate are also revoked, but 
you'd be wrong: the holders of these certificates could re-root themselves 
under the issuer's new certificate.

Similar things are possible in X.509, which is why a recent book on PKI [1] 
recommends against re-using keys:

"There is a more compelling reason not to put a single public key in 
multiple certificates, however: It is too easy to "slip up" and not hold 
all other important aspects of these multiple certificates 
constant.[...]  Such situations may allow an attacker (or even an 
underhanded certificate subject) to substitute one certificate for another 
so that what was once merely a signed piece of data now takes on an 
entirely new meaning.  Mandating that different certificates always contain 
different public keys is a simple way to entirely preclude the risk of such 
substitution attacks."

I dislike that mandate, since there are good reasons for re-using keys 
(limited key storage, the expense of key generation, etc..).  Instead, I 
think it would be preferable if every signature covers all relevant context 
needed to differentiate the signing key from the same key used in a 
different certificate.

Granted, in PGP subkeys this may not be worth doing.   But at the "theory" 
level, this seems a good principle for certificate formats.

I'm curious if you agree with that (I suspect you don't, or SPKI would be 
different :-).  This is wandering off-topic, though, I know..

Trevor

[1] Understanding PKI, 2nd Ed., Carlisle Adams and Steve Lloyd 

Date: Fri, 31 Oct 2003 14:30:34 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: Carl Ellison <[email-masked]>
Subject: Re: theory (was Re: Back-signatures proposal)
Mail-Followup-To: [email-masked], Carl Ellison <[email-masked]>
Sender: [email-masked]

David

Date: Fri, 31 Oct 2003 09:50:27 -0800
To: Michael Young <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 11:12 AM 10/31/2003 -0500, Michael Young wrote:
>Content-Transfer-Encoding: 7bit
>
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote:
> >In my scenario, a bunch of different primary key holders trust a
> >single subkey holder to perform signatures on their behalf.  The
> >subkey holder wants to make sure that each signature is attributed
> >to the proper primary key.
>
>I'd love to have a better framework for publicly expressing trust
>relationships, but I really don't think this was one of the intended
>uses of subkeys.  [Given where the RFC stands, I think that trust
>expresion would best be addressed by a new, adjunct RFC.]

Sure, no problem - I was just thinking we could slay these things with the 
same stone, but in retrospect it seems like it only confuses an issue that 
David had done a good job clarifying..

Trevor 

Date: Fri, 31 Oct 2003 08:44:39 -0800
To: David Shaw <[email-masked]>
From: Carl Ellison <[email-masked]>
Subject: theory (was Re: Back-signatures proposal)
Cc: [email-masked]
Sender: [email-masked]

 - Carl

Date: Fri, 31 Oct 2003 11:12:39 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures, part II
Sender: [email-masked]

On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote:
 >In my scenario, a bunch of different primary key holders trust a
 >single subkey holder to perform signatures on their behalf.  The
 >subkey holder wants to make sure that each signature is attributed
 >to the proper primary key.

I'd love to have a better framework for publicly expressing trust
relationships, but I really don't think this was one of the intended
uses of subkeys.  [Given where the RFC stands, I think that trust
expresion would best be addressed by a new, adjunct RFC.]

Date: Thu, 30 Oct 2003 14:03:43 -0800
To: David Shaw <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 03:20 PM 10/30/2003 -0500, David Shaw wrote:

>On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote:
>
> > In my scenario, a bunch of different primary key holders trust a
> > single subkey holder to perform signatures on their behalf.  The
> > subkey holder wants to make sure that each signature is attributed
> > to the proper primary key.
>
>I'm having trouble seeing the lack of this ability as a problem, much
>less a problem that needs a fix.
>
>It's always possible to come up with a (perhaps convoluted) situation
>where any feature would be useful, and with all due respect, I think
>this scenario crosses the convolution line.

Fair enough.  The more useful scenario I was thinking of is where a single 
primary key is held by a server, which issues short-lived subkeys to 
different users, so they don't have to bother keeping a primary key secure.

But in that case, I think the "Signer's User ID" subpacket is sufficient to 
differentiate things.

Trevor 

Date: Thu, 30 Oct 2003 15:20:16 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures, part II
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote:

> In my scenario, a bunch of different primary key holders trust a
> single subkey holder to perform signatures on their behalf.  The
> subkey holder wants to make sure that each signature is attributed
> to the proper primary key.

I'm having trouble seeing the lack of this ability as a problem, much
less a problem that needs a fix.

It's always possible to come up with a (perhaps convoluted) situation
where any feature would be useful, and with all due respect, I think
this scenario crosses the convolution line.

Sharing signature keys is generally not a good idea.  Note in the
example that if the trusted subkey holder stops being trusted, he can
issue signatures in the name of any of the users.  Plus if any of the
keyholders has a key compromise, all keyholders must re-key.

If and when such a situation develops, I'd support a supplemental RFC
to specify the necessary signature subpacket.  Until the proposed
scenario becomes more concrete, anything we can do about it in 2440bis
is apt to be incorrect in some detail.  In the meantime, I'm content
to say if a user really wants to share keys, he can use a signature
notation to include whatever additional information he lines.  I don't
think this needs to be in 2440bis.

David

Date: Thu, 30 Oct 2003 10:37:18 -0800
To: Adrian von Bidder <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 09:25 AM 10/30/2003 +0100, Adrian von Bidder wrote:
 >
 >On Thursday 30 October 2003 00:17, Trevor Perrin wrote:
 >
 >[subkey signatures - embedding the primary to avoid misattribution]
 >
 >> The case I was thinking of, where key re-use might occur, is in something
 >> like a smartcard, or a delegated signing server.  This might have limited
 >> key storage, or it might not be able to generate new keys (not enough
 >> power, or not enough randomness).  If different users share the device,
 >> they each might want to certify the device's subkey as belonging under
 >> their own primary key.
 >>
 >> The device would want to make sure each of it's signatures are
 >>attributable to the right primary key.  If every signature is a
 >>back-signature, this is accomplished.
 >
 >The hash of the primary would be over the public key? So the holder of
 >the secret subkey can make his subkey signature appear to come from
 >whatever primary he wants, he doesn't need the secret (primary) key.

He can make his subkey signature appear to come under any of the primary 
keys that have trusted him (i.e. any of the primary keys that have issued 
him a subkey binding signature).

 >
 >So, in your scenario, sharing the secret subkey will effectively mean
 >that each can make signatures that will verify with the other's primary.

In my scenario, a bunch of different primary key holders trust a single 
subkey holder to perform signatures on their behalf.  The subkey holder 
wants to make sure that each signature is attributed to the proper primary key.

Maybe this is a use case that subkeys aren't intended to support.  But if 
every signature covered the primary key and subkey it was produced under, 
this would work.

Trevor

Date: Thu, 30 Oct 2003 10:41:30 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Let's finish up 0x50 "notary" signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Oct 30, 2003 at 06:07:32AM +0000, [email-masked] wrote:

> Removing the canonical header replacement for external signing of
> signatures would make it easier to work with many notarized
> signatures. This probably steps on toes, though.

I wouldn't remove the canonical header for hashing the original
signature.  It would be inconsistent with all of the other hashing
rules in the draft.  The only thing that is necessary here is to
specify that the unhashed data in the original signature is not
included in the notary signature.

Specifically, section 5.2.4 currently says:

  When a signature is made over a signature, the hash data starts with
  the octet 0x88, followed by the four-octet length of the signature,
  and then the body of the signature packet.  (Note that this is an
  old-style packet header for a signature packet with the
  length-of-length set to zero).

I would add a sentence between those two that reads something like:

   The unhashed subpacket data of the signature packet being hashed is
   not included in the hash, and the unhashed subpacket data length
   value is set to zero.

The idea here is that the canonical form of a signature to be hashed
has no unhashed subpacket data.

This addresses your first comment as well.  We don't need to specify
what gets hashed into the notary signature, since it is clear that the
entire target signature, minus its unhashed data, is hashed for the
notary signature.

David

From: Adrian von Bidder <[email-masked]>
Organization: Onaras AG
To: [email-masked]
Subject: Re: Back-signatures, part II
Date: Thu, 30 Oct 2003 09:25:52 +0100
Sender: [email-masked]

--Boundary-02=_QsMo/zMRVZGt0Q5
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

[no cc:s please]
On Thursday 30 October 2003 00:17, Trevor Perrin wrote:

[subkey signatures - embedding the primary to avoid misattribution]

> The case I was thinking of, where key re-use might occur, is in something
> like a smartcard, or a delegated signing server.  This might have limited
> key storage, or it might not be able to generate new keys (not enough
> power, or not enough randomness).  If different users share the device,
> they each might want to certify the device's subkey as belonging under
> their own primary key.
>
> The device would want to make sure each of it's signatures are attributab=
le
> to the right primary key.  If every signature is a back-signature, this is
> accomplished.

The hash of the primary would be over the public key? So the holder of the=
=20
secret subkey can make his subkey signature appear to come from whatever=20
primary he wants, he doesn't need the secret (primary) key.

So, in your scenario, sharing the secret subkey will effectively mean that=
=20
each can make signatures that will verify with the other's primary.

Or do I misunderstand someting here?

cheers
=2D- vbi

=2D-=20
featured product: vim - http://vim.org

--Boundary-02=_QsMo/zMRVZGt0Q5
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_QsMo/zMRVZGt0Q5--

Subject: Re: Let's finish up 0x50 "notary" signatures
Date: Thu, 30 Oct 2003 06:07:32 +0000
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Sender: [email-masked]

Casting a vote from the cheap seats, I think signatures-in-subpackets
are an elegant option for 3rd-party signatures on single signatures.
I suggest inserting the following (or something similar) to 5.2.4:

> When a signature over a V4 signature is issued as a subpacket, the
> body of hash data consists of the same data that the (parent) V4
> signature used to build its own hash, that is, the parent's version,
> type, public key algorithm, hash algorithm, and hashed subpacket
> material (length header and subpackets).

and changing the beginning of the existing signature-on-a-signature
paragraph in the same section to make it clear that different rules
apply to "sub-signatures":

< When a signature is made over a signature, the hash data.. 
---
> When a signature is issued over a signature packet, the hash data..

Rounding out thoughts on 0x50,

Removing the canonical header replacement for external signing of
signatures would make it easier to work with many notarized
signatures. This probably steps on toes, though.

The ability to construct nice (10.2) messages using multiple/nested
0x50 signatures on fixed signature data (I suggest adding
functionality to the one-pass packet 'nest') would allow complete
expression of 0x50 signatures per 5.2.1 (as opposed to keeping them
detached or on a per-signature basis in subpackets). Additionally, I
think the "signed and notarized document" deserves the same degree of
clout (that only a bona fide message has) as a normal "signed
document."

Happy days, 
poiboy

Date: Wed, 29 Oct 2003 19:37:20 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Let's finish up 0x50 "notary" signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Oct 29, 2003 at 03:52:38PM -0800, [email-masked] wrote:

> On Wed, 29 Oct 2003 14:25:17 -0800 David Shaw <[email-masked]>
> wrote:
> 
> >A notary can issue a notary signature on any signature, which includes
> >key certifications.  Placing the notary signature in a
> >signature-in-a-subpacket on the unhashed area of the original
> >signature would be an effective way of transporting the notary sig
> >around with the key.
> 
> could this be done in a way that existing implementations can just
> 'ignore' (i.e., not 'choke' on) the notary signature if it can't
> 'recognize' what it is, when importing a key with a notary signature
> on the self- signed sig of the key?

Yes, existing implementations should ignore and certainly not choke on
any unrecognized signature subpacket.  If the signer chooses to, they
can set the "critical" flag, which requests that an implementation
fail the signature verification for unrecognized signature
subpackets, but at the same time, they don't have to.  It's up to the
signer what they want to happen.

(It is a different issue altogether whether a critical bit on an
*unhashed* subpacket should cause this to happen, though!)

David

Date: Wed, 29 Oct 2003 15:52:38 -0800
To: [email-masked]
Cc: 
Subject: Re: Let's finish up 0x50 "notary" signatures
From: <[email-masked]>
Sender: [email-masked]

On Wed, 29 Oct 2003 14:25:17 -0800 David Shaw <[email-masked]>
wrote:

>A notary can issue a notary signature on any signature, which includes
>key certifications.  Placing the notary signature in a
>signature-in-a-subpacket on the unhashed area of the original
>signature would be an effective way of transporting the notary sig
>around with the key.

could this be done in a way that existing implementations can just
'ignore' (i.e., not 'choke' on) the notary signature if it can't 'recognize'
what it is,  when importing a key with a notary signature on the self-
signed sig of the key?

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Wed, 29 Oct 2003 15:44:46 -0800
To: Michael Young <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 05:08 PM 10/29/2003 -0500, Michael Young wrote:

>Trevor Perrin wrote (in another message):
> > I don't want to re-confuse an issue you've just clarified, but
> > here's a  generalization of the second proposal that might be worth
> > considering:
> >
> > You could include in *every* signature a subpacket that contains a
> > hash  of *all* enclosing context.  By "enclosing context" I mean
> > the key  packet for the primary key, along with its
> > self-signatures, and the key  packet for the subkey as well (if the
> > signing key is a subkey) along  with the subkey binding signature.
>
>This would add yet another impediment to rewriting self-signatures
>(or binding signatures).  To permit rewriting, you'd have to keep
>all past versions (and try each one at verification time) or copy
>that material into the signature.

Good point - you'd only want to include context that won't get invalidated 
by re-issued signatures.  So I guess we could change the proposal to only 
cover key packets, not signature packets, without losing too much:

Proposal:  Include in every signature a hashed subpacket that contains a 
hash of the relevant key packets.  The relevant key packets are the primary 
key packet if the signing key is a primary key, or the primary key *and* 
subkey packets if the signing key is a subkey.

This stops these 3 manipulations:
  - issuing a subkey signature to someone else's key, and claiming their 
signatures
  - changing the primary key that a signature performed by a re-used subkey 
belongs under
  - an attacker generating a new key that verifies someone else's signature

Trevor

Date: Wed, 29 Oct 2003 15:17:33 -0800
To: David Shaw <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 05:04 PM 10/29/2003 -0500, David Shaw wrote:

>On Wed, Oct 29, 2003 at 01:33:23PM -0800, Trevor Perrin wrote:
>
> > >> The problem arises when the user signs a document with the subkey, and
> > >> wants this signature to be under one of his particular 
> primaries.  Say he
> > >> has Work and Personal primary keys.  He signs something and wants to
> > >> indicate that it's under his Work primary key.
> > >
> > >A user can "legally" use the same subkey under two different
> > >primaries.
> >
> > yeah, but if he does this, a verifier might assume that the signature was
> > intended under one primary key, when it was really intended under another.
> >
> > >  I think this is more of a feature request than an attack.
> >
> > It's only an attack if a bad guy can choose which primary key the 
> signature
> > appears to be under, in a way that tricks the verifier into treating the
> > signature incorrectly.
>
>The user intentionally chose to use the same subkey in two places.
>The user intentionally issued the signature.  The user shouldn't be
>surprised that either copy of the same key can verify that signature.
>If a user wants to be unambiguous as to which hat he was wearing when
>he issued the signature, he shouldn't use the same key everywhere.

Yeah, this is easily avoided if you just don't re-use keys.

It would also be avoided if the signature is calculated over the hat the 
user was wearing, when he issued the signature.  Then you can re-use keys 
without fear that a verifying party will be confused or tricked about which 
copy of the key you signed with.

>This is somewhat similar to a situation where a user has two user IDs
>on his key: "user at evilcompany.com" and "user at
>anonymouswhistleblowers.com".  If the user sends out whistleblower
>information and signs it with that key, he shouldn't be surprised when
>he is fired...

Anonymity throws a different spin on things.

The case I was thinking of, where key re-use might occur, is in something 
like a smartcard, or a delegated signing server.  This might have limited 
key storage, or it might not be able to generate new keys (not enough 
power, or not enough randomness).  If different users share the device, 
they each might want to certify the device's subkey as belonging under 
their own primary key.

The device would want to make sure each of it's signatures are attributable 
to the right primary key.  If every signature is a back-signature, this is 
accomplished.

Trevor 

Date: Wed, 29 Oct 2003 17:25:17 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Let's finish up 0x50 "notary" signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Oct 29, 2003 at 01:58:14PM -0800, [email-masked] wrote:

> can this be extended to be used as notary signature directly on someone's
> public key?

A notary can issue a notary signature on any signature, which includes
key certifications.  Placing the notary signature in a
signature-in-a-subpacket on the unhashed area of the original
signature would be an effective way of transporting the notary sig
around with the key.

David

Date: Wed, 29 Oct 2003 17:08:51 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures, part II
Sender: [email-masked]

Trevor Perrin wrote:
 > At 10:34 PM 10/28/2003 -0500, Michael Young wrote:
 >> Also, note that the specification already provides a "signer
 >> userId" subpacket that could be used to nearly the same effect as
 >> a "signer primary fingerprint" subpacket.
 >
 > I think that would prevent the version of this where the attacker
 > tries  to convince the verifier that the signed message came from
 > his *name*.

In practice, I think it's far more interesting to claim that a
particular real-world identity signed a document than a particular
primary key.  But I understand the difference -- that's why I said
"nearly".

Trevor Perrin wrote (in another message):
 > I don't want to re-confuse an issue you've just clarified, but
 > here's a  generalization of the second proposal that might be worth
 > considering:
 >
 > You could include in *every* signature a subpacket that contains a
 > hash  of *all* enclosing context.  By "enclosing context" I mean
 > the key  packet for the primary key, along with its
 > self-signatures, and the key  packet for the subkey as well (if the
 > signing key is a subkey) along  with the subkey binding signature.

This would add yet another impediment to rewriting self-signatures
(or binding signatures).  To permit rewriting, you'd have to keep
all past versions (and try each one at verification time) or copy
that material into the signature.

Very little of this "context" is relevant for most uses.  For special
needs, we have notation packets to carry arbitrary additional
context.

Date: Wed, 29 Oct 2003 17:04:15 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures, part II
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Wed, Oct 29, 2003 at 01:33:23PM -0800, Trevor Perrin wrote:

> >> The problem arises when the user signs a document with the subkey, and
> >> wants this signature to be under one of his particular primaries.  Say he
> >> has Work and Personal primary keys.  He signs something and wants to
> >> indicate that it's under his Work primary key.
> >
> >A user can "legally" use the same subkey under two different
> >primaries.
> 
> yeah, but if he does this, a verifier might assume that the signature was 
> intended under one primary key, when it was really intended under another.
> 
> >  I think this is more of a feature request than an attack.
> 
> It's only an attack if a bad guy can choose which primary key the signature 
> appears to be under, in a way that tricks the verifier into treating the 
> signature incorrectly.

The user intentionally chose to use the same subkey in two places.
The user intentionally issued the signature.  The user shouldn't be
surprised that either copy of the same key can verify that signature.
If a user wants to be unambiguous as to which hat he was wearing when
he issued the signature, he shouldn't use the same key everywhere.

This is somewhat similar to a situation where a user has two user IDs
on his key: "user at evilcompany.com" and "user at
anonymouswhistleblowers.com".  If the user sends out whistleblower
information and signs it with that key, he shouldn't be surprised when
he is fired...

David

Date: Wed, 29 Oct 2003 13:58:14 -0800
To: [email-masked]
Cc: 
Subject: Re: Let's finish up 0x50 "notary" signatures
From: <[email-masked]>
Sender: [email-masked]

On Wed, 29 Oct 2003 12:59:59 -0800 David Shaw <[email-masked]>
wrote:
>
>The current state of the 0x50 or notary signature is nearly, but
>not
>quite, completed.  The main thing missing is a machine-readable
>transport of a signature and it's notarization.
>
>The current language in the draft is:
>
>   0x50: Third-Party Confirmation signature.
>
>      This signature is a signature over some other OpenPGP signature
>      packet(s). It is a notary seal on the signed data. A third-
>party
>      signature SHOULD include Signature Target subpacket(s) to
>give
>      easy identification. 

can this be extended to be used as notary signature directly on someone's
public key?

(it would not provide an independent timestamp to the actual signature
of the key-holder, but might be able to eventually improve the web-of-
trust)

with Respect,

vedaal

Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

Date: Wed, 29 Oct 2003 13:33:23 -0800
To: David Shaw <[email-masked]>
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Cc: [email-masked]
Sender: [email-masked]

At 03:13 PM 10/29/2003 -0500, David Shaw wrote:

>On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote:
>
> > >>  - A naive user re-uses the same subkey under 2 different primary
> > >> keys.  Signatures performed by the subkey can't be confined to
> > >> being under one or the other primary key.  This problem can be
> > >> easily avoided: just don't re-use keys, but that caveat would be
> > >> unnecessary if signatures committed to their enclosing context.
> > >
> > >I don't see this as a problem, actually.  So what if a user uses the
> > >same subkey under two different primaries?  The user controls the
> > >subkey, and so can issue valid back-signatures (or fingerprint
> > >subpackets).  The owner of a subkey can do what they like with it.
> >
> > The problem arises when the user signs a document with the subkey, and
> > wants this signature to be under one of his particular primaries.  Say he
> > has Work and Personal primary keys.  He signs something and wants to
> > indicate that it's under his Work primary key.
>
>A user can "legally" use the same subkey under two different
>primaries.

yeah, but if he does this, a verifier might assume that the signature was 
intended under one primary key, when it was really intended under another.

>   I think this is more of a feature request than an attack.

It's only an attack if a bad guy can choose which primary key the signature 
appears to be under, in a way that tricks the verifier into treating the 
signature incorrectly.

I believe signing subkeys are rare, re-use of signing subkeys is rarer, and 
re-using them in such a way that an attacker
can do this trick, and accomplish something, is pretty unlikely.

I'm just trying to point out ways in which signatures can be placed in 
different contexts than what the signer intended.  I view that as the 
commonality that links these things together - if every signature had a 
subpacket that contained a hash of:
  - the key used to perform the signature
  - the primary key (if the signing key is a subkey)
  - any self-signatures on the primary key, and the binding signature on 
the subkey,

then I'd feel re-assured that every signature was bound to all relevant 
context, and no manipulations such as
  - splicing someone else's key under your primary key, to claim their 
signatures
  - fiddling with which primary key a signature appears to be under
  - presenting a different key that happens to verify a signature
would be possible.

The one manipulation that *would* still be possible is presenting someone 
else's key under your primary key, when there's no signature by the 
victimized key present to give the lie to this.  For that, some sort of 
additional back-signature is unavoidable.

But these approaches could be combined - if the back-signature contains the 
sort of subpacket I'm talking about, that's enough to make it a back-signature.

So I guess I'm saying *every* signature should be a back-signature, in that 
it covers the relevant primary key and sub-keys.  But you could also add an 
extra back-signature just when sub-keys are present.

>The include-the-primary-fingerprint fix for the original attack has a
>side effect that gives the information you want here, but I still
>don't think this is an attack on the system.
>
> > I.e.: a user who receives a signed message through some secure channel 
> (say
> > someone hands them a message on a floppy disk), might then retrieve a key
> > through an *un*secure channel, and attempt to validate the key by 
> verifying
> > the message with it.
> >
> > You can say: the user screwed up, we can't help him.  But if the signature
> > covered the public key that produced it, then the user's naive assumption
> > would be correct, and his behavior would be safe.
> >
> > The issuer key ID subpacket makes an attack hard, though, because the
> > attacker would have to try ~ 2^64 trial keys that verify the signature,
> > before discovering one that *also* has the right issuer key ID.  But if 
> the
> > signature covered the public key with a full hash, an attack would be even
> > harder.
>
>Note that most implementations do not store the issuer key ID in the
>hashed portion of the signature.  The issuer ID is thus not part of
>the signature.

In the odd case I'm considering, the verifier gets the signed message 
through some secure channel - someone hands him a signed message on a 
floppy disk, for example.  So even though the issuer key ID isn't part of 
the signature, an attacker who's trying to make a fake key that verifies 
the message, still has to match the issuer key ID.

So that provides some measure of protection, but if the signing key was 
hashed as an input to the signature, that would provide even more.

Trevor

Date: Wed, 29 Oct 2003 16:19:07 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures proposal
Sender: [email-masked]

Date: Wed, 29 Oct 2003 15:59:59 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Let's finish up 0x50 "notary" signatures
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The current state of the 0x50 or notary signature is nearly, but not
quite, completed.  The main thing missing is a machine-readable
transport of a signature and it's notarization.

The current language in the draft is:

   0x50: Third-Party Confirmation signature.

      This signature is a signature over some other OpenPGP signature
      packet(s). It is a notary seal on the signed data. A third-party
      signature SHOULD include Signature Target subpacket(s) to give
      easy identification. Note that we really do mean SHOULD. There
      are plausible uses for this (such a a blind party that only sees
      the signature, not the key nor source document) that cannot
      include a target subpacket.

Two suggestions:

1) Do not include the unhashed data of the target signature when
   generating the notary signature.  The unhashed data is not part of
   the original signature.

2) Define a signature-in-a-subpacket where notary signatures can be
   placed.  This allows the notary signature to be attached (as an
   unhashed subpacket) to the signature that it notarizes, giving a
   simple and clean transport method.  Any number of notary signatures
   can be attached to the original signature this way (up to the limit
   on the unhashed data section), and notary signatures may be easily
   nested (notarizing a notary signature) by placing a notary
   signature in the unhashed data section of another notary signature.

   A signature-in-a-subpacket is simply a signature subpacket that
   contains another signature.  The packet headers are not included,
   but the signature is otherwise complete.

Note that one of the possible solutions to the stolen subkey problem
also involves signature-in-a-subpacket.  This is a different use of
the technique, and its use here is not relevant to the stolen subkey
problem.

David

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Meeting in Minneapolis?
Date: 29 Oct 2003 15:19:59 -0500
Lines: 34
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> On Wednesday, October 29, 2003, at 09:03  AM, Derek Atkins wrote:
> 
> > Well, I missed the deadline to request a timeslot, too..  So we wont be
> > meeting in MSP.  HOWEVER I think we've been making a lot of progress
> > on the doc here on the list so let's continue along the existing path.
> 
> I think we can do that.

I have no objection..  We SHOULD have meetings periodically, if
for no other reason that to get more people involved or at least
knowledgable about what we're doing.

> Ideally, IETF working groups operate *completely* on the mailing
> lists. Alas, we do not live in an ideal world, and face-to-face
> meetings are desirable or necessary.

True.

> However, this working group has been making progress for years without
> a meeting, and that, in my opinion, is not a bug, it's a feature.

Well, it's been making progress but still hasn't completed 2440bis.
We should make that a top priority.

> 	Jon

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Wed, 29 Oct 2003 15:13:06 -0500
From: David Shaw <[email-masked]>
To: Trevor Perrin <[email-masked]>
Cc: [email-masked]
Subject: Re: Back-signatures, part II
Mail-Followup-To: Trevor Perrin <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote:

> >>  - A naive user re-uses the same subkey under 2 different primary
> >> keys.  Signatures performed by the subkey can't be confined to
> >> being under one or the other primary key.  This problem can be
> >> easily avoided: just don't re-use keys, but that caveat would be
> >> unnecessary if signatures committed to their enclosing context.
> >
> >I don't see this as a problem, actually.  So what if a user uses the
> >same subkey under two different primaries?  The user controls the
> >subkey, and so can issue valid back-signatures (or fingerprint
> >subpackets).  The owner of a subkey can do what they like with it.
> 
> The problem arises when the user signs a document with the subkey, and 
> wants this signature to be under one of his particular primaries.  Say he 
> has Work and Personal primary keys.  He signs something and wants to 
> indicate that it's under his Work primary key.

A user can "legally" use the same subkey under two different
primaries.  I think this is more of a feature request than an attack.

The include-the-primary-fingerprint fix for the original attack has a
side effect that gives the information you want here, but I still
don't think this is an attack on the system.

> I.e.: a user who receives a signed message through some secure channel (say 
> someone hands them a message on a floppy disk), might then retrieve a key 
> through an *un*secure channel, and attempt to validate the key by verifying 
> the message with it.
> 
> You can say: the user screwed up, we can't help him.  But if the signature 
> covered the public key that produced it, then the user's naive assumption 
> would be correct, and his behavior would be safe.
> 
> The issuer key ID subpacket makes an attack hard, though, because the 
> attacker would have to try ~ 2^64 trial keys that verify the signature, 
> before discovering one that *also* has the right issuer key ID.  But if the 
> signature covered the public key with a full hash, an attack would be even 
> harder.

Note that most implementations do not store the issuer key ID in the
hashed portion of the signature.  The issuer ID is thus not part of
the signature.

David

Date: Wed, 29 Oct 2003 12:00:08 -0800
Subject: Re: Meeting in Minneapolis?
Cc: OpenPGP <[email-masked]>
To: Derek Atkins <[email-masked]>
From: Jon Callas <[email-masked]>
Sender: [email-masked]

On Wednesday, October 29, 2003, at 09:03  AM, Derek Atkins wrote:

> Well, I missed the deadline to request a timeslot, too..  So we wont be
> meeting in MSP.  HOWEVER I think we've been making a lot of progress
> on the doc here on the list so let's continue along the existing path.
>

I think we can do that.

Ideally, IETF working groups operate *completely* on the mailing lists. 
Alas, we do not live in an ideal world, and face-to-face meetings are 
desirable or necessary.

However, this working group has been making progress for years without 
a meeting, and that, in my opinion, is not a bug, it's a feature.

	Jon

To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Meeting in Minneapolis?
Date: 29 Oct 2003 12:03:32 -0500
Lines: 16
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> I won't be in Minneapolis.
> 
> I stupidly thought the deadline for getting an I-D in was close of
> business Monday, and not 9am Monday, so I blew it. Sorry.

Well, I missed the deadline to request a timeslot, too..  So we wont be
meeting in MSP.  HOWEVER I think we've been making a lot of progress
on the doc here on the list so let's continue along the existing path.

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Tue, 28 Oct 2003 22:59:31 -0800
To: David Shaw <[email-masked]>
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Cc: [email-masked]
Sender: [email-masked]

At 12:58 AM 10/29/2003 -0500, David Shaw wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote:
> >
> > At 05:23 PM 10/28/2003 -0500, David Shaw wrote:
> >
> > >I just checked over my notes about back-signatures, and there was a
> > >second proposal to solve the same problem.  For completeness, here is
> > >the other proposal.
> > >
> > >To repeat the problem: it is possible for an attacker to take a
> > >signing subkey from a victim's key and attach this signing subkey to
> > >the attacker's own key.  The attacker does this by issuing a new
> > >binding signature on the subkey from his own primary key.  The end
> > >result is that a signature issued by this signing subkey may be
> > >claimed to be from either the attacker or the victim.
> >
> > Does this attack also work if the attacker issues a subkey binding
> > signature on the victim's *primary* key, so as to claim signatures issued
> > by this primary key?
>
>You mean take the victim's primary signing key, transform it into a
>signing subkey and bind it to the attacker's primary key?  Yes, the
>attack would still work, but either of the proposed fixes still
>prevents it.
[...]

I think you're right.

> > I don't want to re-confuse an issue you've just clarified, but here's a
> > generalization of the second proposal that might be worth considering:
> >
> > You could include in *every* signature a subpacket that contains a hash of
> > *all* enclosing context.  By "enclosing context" I mean the key packet for
> > the primary key, along with its self-signatures, and the key packet for 
> the
> > subkey as well (if the signing key is a subkey) along with the subkey
> > binding signature.
> >
> > This would protect against the above attack, and some other manipulations,
> > such as:
> >
> >  - A naive user re-uses the same subkey under 2 different primary
> > keys.  Signatures performed by the subkey can't be confined to being under
> > one or the other primary key.  This problem can be easily avoided: just
> > don't re-use keys, but that caveat would be unnecessary if signatures
> > committed to their enclosing context.
>
>I don't see this as a problem, actually.  So what if a user uses the
>same subkey under two different primaries?  The user controls the
>subkey, and so can issue valid back-signatures (or fingerprint
>subpackets).  The owner of a subkey can do what they like with it.

The problem arises when the user signs a document with the subkey, and 
wants this signature to be under one of his particular primaries.  Say he 
has Work and Personal primary keys.  He signs something and wants to 
indicate that it's under his Work primary key.

He could include the Signer's User ID in the signature, but what if both 
primaries have the same User ID?

If every signature committed to all previous context, then the verifier 
could always recognize that this signature was performed under a particular 
primary key, so there wouldn't be ambiguous cases like this.

> >  - Attacker generates a key that verifies a signature issued by someone
> > else [1], then puts this key on a key server where a victim finds it, and
> > assumes that since it verifies the signature correctly, it must belong to
> > the originator of the message.  There's caveats that make this attack 
> hard,
> > and not very useful [1].  Still, it could be avoided entirely if the key
> > used to create a signature was hashed as input to the signature.
>
>Hmm.  I think I see where you are going with this, but isn't this sort
>of the same problem as the "stolen primary that is kept as a primary"
>above?  I can steal a primary key and add a user ID and bribe someone
>to sign it (since I can't sign it myself of course).  Just because
>I've constructed a key that can verify a signature doesn't mean that I
>issued that signature.

You're right, and as long as users keep that in mind, they're safe.

But there's the rub.  It's unintuitive that you can generate a key that 
verifies someone else's signature.  And when things are unintuitive, 
there's room for users to screw up.

I.e.: a user who receives a signed message through some secure channel (say 
someone hands them a message on a floppy disk), might then retrieve a key 
through an *un*secure channel, and attempt to validate the key by verifying 
the message with it.

You can say: the user screwed up, we can't help him.  But if the signature 
covered the public key that produced it, then the user's naive assumption 
would be correct, and his behavior would be safe.

The issuer key ID subpacket makes an attack hard, though, because the 
attacker would have to try ~ 2^64 trial keys that verify the signature, 
before discovering one that *also* has the right issuer key ID.  But if the 
signature covered the public key with a full hash, an attack would be even 
harder.

>   Or forget computer trickery at all: I can just
>get myself a fake ID that says I am "Trevor Perrin" ;)

The trickery I'm envisioning is where a naive verifier tries to validate a 
key by using it to verify a message that was received over some secure channel.

> >  - Attacker fiddles the timestamp in someone's primary-key packet, so that
> > the key still verifies the signature correctly, but the sender appears to
> > have a different fingerprint than he really does.
>
>This would break all signatures on the key, including the
>self-signatures.  I think that would give the attack away.

That's true.  As long as primary keys have self-signatures, and verifiers 
are required to check them before doing anything else with the key, that 
stops this.

Basically, I just like the idea of having signatures cover all relevant 
context.  So I was trying to find some trickery that would justify doing 
this.  The trickery isn't very good, but there's trickier people than me 
out there..

So I dunno, I'm not sure how to balance the costs and benefits here, I just 
wanted to toss this out.

Trevor 

Date: Wed, 29 Oct 2003 00:58:33 -0500
From: David Shaw <[email-masked]>
To: Trevor Perrin <[email-masked]>
Cc: [email-masked]
Subject: Re: Back-signatures, part II
Mail-Followup-To: Trevor Perrin <[email-masked]>, [email-masked]
Sender: [email-masked]

On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote:
> 
> At 05:23 PM 10/28/2003 -0500, David Shaw wrote:
> 
> >I just checked over my notes about back-signatures, and there was a
> >second proposal to solve the same problem.  For completeness, here is
> >the other proposal.
> >
> >To repeat the problem: it is possible for an attacker to take a
> >signing subkey from a victim's key and attach this signing subkey to
> >the attacker's own key.  The attacker does this by issuing a new
> >binding signature on the subkey from his own primary key.  The end
> >result is that a signature issued by this signing subkey may be
> >claimed to be from either the attacker or the victim.
> 
> Does this attack also work if the attacker issues a subkey binding 
> signature on the victim's *primary* key, so as to claim signatures issued 
> by this primary key?

You mean take the victim's primary signing key, transform it into a
signing subkey and bind it to the attacker's primary key?  Yes, the
attack would still work, but either of the proposed fixes still
prevents it.

The back-signature fix prevents this flavor of the attack since the
attacker still could not use the stolen key (be it primary or subkey),
to issue the back-signature.

The include-the-fingerprint fix prevents this flavor of the attack as
well.  Since the key is a primary, existing signatures from the key
would not contain the fingerprint subpacket at all, and would
therefore be suspect.

There are four basic permutations of this attack:

1) Attacker steals a subkey and keeps it as a subkey.  Either fix
   works here.

2) Attacker steals a primary and makes it into a subkey.  Either fix
   works here.

3) Attacker steals a subkey and makes it into a primary.  Neither fix
   is relevant here since the attacker would be unable to bind a user
   ID to such a primary key.  Without a bound user ID, it would be
   difficult at best to get such a key trusted.

4) Attacker steals a primary and keeps it as a primary.  Neither fix
   is relevant here either, for the same reason as #3.

> >Second proposed solution: on all signatures issued by a signing
> >subkey, include a copy of the fingerprint of the primary key that
> >"owns" this subkey.  An attacker cannot issue signatures from the
> >stolen subkey at all, so is foiled.
> 
> I don't want to re-confuse an issue you've just clarified, but here's a 
> generalization of the second proposal that might be worth considering:
> 
> You could include in *every* signature a subpacket that contains a hash of 
> *all* enclosing context.  By "enclosing context" I mean the key packet for 
> the primary key, along with its self-signatures, and the key packet for the 
> subkey as well (if the signing key is a subkey) along with the subkey 
> binding signature.
> 
> This would protect against the above attack, and some other manipulations, 
> such as:
> 
>  - A naive user re-uses the same subkey under 2 different primary 
> keys.  Signatures performed by the subkey can't be confined to being under 
> one or the other primary key.  This problem can be easily avoided: just 
> don't re-use keys, but that caveat would be unnecessary if signatures 
> committed to their enclosing context.

I don't see this as a problem, actually.  So what if a user uses the
same subkey under two different primaries?  The user controls the
subkey, and so can issue valid back-signatures (or fingerprint
subpackets).  The owner of a subkey can do what they like with it.

>  - Attacker generates a key that verifies a signature issued by someone 
> else [1], then puts this key on a key server where a victim finds it, and 
> assumes that since it verifies the signature correctly, it must belong to 
> the originator of the message.  There's caveats that make this attack hard, 
> and not very useful [1].  Still, it could be avoided entirely if the key 
> used to create a signature was hashed as input to the signature.

Hmm.  I think I see where you are going with this, but isn't this sort
of the same problem as the "stolen primary that is kept as a primary"
above?  I can steal a primary key and add a user ID and bribe someone
to sign it (since I can't sign it myself of course).  Just because
I've constructed a key that can verify a signature doesn't mean that I
issued that signature.  Or forget computer trickery at all: I can just
get myself a fake ID that says I am "Trevor Perrin" ;)

>  - Attacker fiddles the timestamp in someone's primary-key packet, so that 
> the key still verifies the signature correctly, but the sender appears to 
> have a different fingerprint than he really does.

This would break all signatures on the key, including the
self-signatures.  I think that would give the attack away.

David

Date: Wed, 29 Oct 2003 00:35:45 -0500
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: Marc Mutz <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP and IDNA/IMAA
Sender: [email-masked]

Marc Mutz wrote:
...
> OpenPGP UIDs are essentially free-form,

Yes, this is one of the advantages of OpenPGP
over other PKI contenders.  It says nothing
about how the UserIds are handled.  Which means
we are free to design the contents to suit our
requirements.

It's certainly a key benefit for my company's
use.  You can't pay enough money to get that
sort of design feature!

> but with the
>   Name (Comment) <mail@address>
> convention for interop.
> 
> The whole string is in utf-8. This opens up two possible ways to encode
> a IDN (or an internationalized email address later) in the UID:
> 
> 1. In ACE form (ASCII compatible encoding)
> 2. In UTF-8
...
> In any case, I think that rfc 2440bis as an IETF protocol that uses
> UTF-8 needs to include at least a stringprep profile to use. I'm no
> IETF expert, though, and it may suffice to reuse whatever comes out of
> IMAA, but that's still at least half a year away.
> 
> If nothing is said and it's accepted as such, then the slot is
> automatically an IDNA-unaware one, to be filled with the ACE form.

I think the key word here is _convention_.  If
there was a desire to document that and other
conventions more clearly, than an adjunct
informational track RFC may be a better bet
than putting it into the base RFC.

That way, applications could be aware of the
convention, but can happily know that any other
form is also quite acceptable.

iang

Date: Wed, 29 Oct 2003 00:02:47 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures, part II
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Oct 28, 2003 at 10:34:17PM -0500, Michael Young wrote:
> 
> I don't feel all that strongly about this -- in fact, I don't
> consider the problem all that serious in the first place -- but
> I do find the properties of the cross-signature subpacket
> solution more attractive.

I think I do as well.  I like that it handles old signatures, and I'm
not yet convinced that the include-the-fingerprint covers all of the
attacks that the back-signature does.

> Also, note that the specification already provides a "signer userId"
> subpacket that could be used to nearly the same effect as a "signer
> primary fingerprint" subpacket.  As I recall, the very first proposal
> was to recommend/require the use of the existing "signer userId"
> subpacket.

Nearly the same effect, yes, but ultimately a different problem.

David

Date: Tue, 28 Oct 2003 23:47:04 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures proposal
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Tue, 28 Oct 2003 20:34:55 -0800
To: Michael Young <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 10:34 PM 10/28/2003 -0500, Michael Young wrote:
[...]
>Also, note that the specification already provides a "signer userId"
>subpacket that could be used to nearly the same effect as a "signer
>primary fingerprint" subpacket.

I think that would prevent the version of this where the attacker tries to 
convince the verifier that the signed message came from his *name*.

It wouldn't prevent the version where the attacker tries to convince the 
verifier that the signed message came from his *key*, which is what using a 
key fingerprint adds.

Trevor 

Date: Tue, 28 Oct 2003 20:18:50 -0800
To: David Shaw <[email-masked]>, [email-masked]
From: Trevor Perrin <[email-masked]>
Subject: Re: Back-signatures, part II
Sender: [email-masked]

At 05:23 PM 10/28/2003 -0500, David Shaw wrote:

>I just checked over my notes about back-signatures, and there was a
>second proposal to solve the same problem.  For completeness, here is
>the other proposal.
>
>To repeat the problem: it is possible for an attacker to take a
>signing subkey from a victim's key and attach this signing subkey to
>the attacker's own key.  The attacker does this by issuing a new
>binding signature on the subkey from his own primary key.  The end
>result is that a signature issued by this signing subkey may be
>claimed to be from either the attacker or the victim.

Does this attack also work if the attacker issues a subkey binding 
signature on the victim's *primary* key, so as to claim signatures issued 
by this primary key?

>Second proposed solution: on all signatures issued by a signing
>subkey, include a copy of the fingerprint of the primary key that
>"owns" this subkey.  An attacker cannot issue signatures from the
>stolen subkey at all, so is foiled.

I don't want to re-confuse an issue you've just clarified, but here's a 
generalization of the second proposal that might be worth considering:

You could include in *every* signature a subpacket that contains a hash of 
*all* enclosing context.  By "enclosing context" I mean the key packet for 
the primary key, along with its self-signatures, and the key packet for the 
subkey as well (if the signing key is a subkey) along with the subkey 
binding signature.

This would protect against the above attack, and some other manipulations, 
such as:

  - A naive user re-uses the same subkey under 2 different primary 
keys.  Signatures performed by the subkey can't be confined to being under 
one or the other primary key.  This problem can be easily avoided: just 
don't re-use keys, but that caveat would be unnecessary if signatures 
committed to their enclosing context.

  - Attacker generates a key that verifies a signature issued by someone 
else [1], then puts this key on a key server where a victim finds it, and 
assumes that since it verifies the signature correctly, it must belong to 
the originator of the message.  There's caveats that make this attack hard, 
and not very useful [1].  Still, it could be avoided entirely if the key 
used to create a signature was hashed as input to the signature.

  - Attacker fiddles the timestamp in someone's primary-key packet, so that 
the key still verifies the signature correctly, but the sender appears to 
have a different fingerprint than he really does.

These aren't a big deal, but it just seems a good principle, in general, 
for signatures to cover as much context as is needed to properly interpret 
them.

Trevor

[1] sci.crypt thread: Choosing key to verify someone else's sig?  

Date: Tue, 28 Oct 2003 22:47:55 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures proposal
Sender: [email-masked]

Date: Tue, 28 Oct 2003 22:34:17 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures, part II
Sender: [email-masked]

I don't feel all that strongly about this -- in fact, I don't
consider the problem all that serious in the first place -- but
I do find the properties of the cross-signature subpacket
solution more attractive.

If I did care about someone claiming my signatures as their own, I
think I would care about old signatures as well.  Under the
per-message scheme, if I cared about old signatures, I'd have to find
all of those signatures *and the associated documents* in order to
reissue them, and then I'd have to deal with disseminating them.

User agents that keep a "key ring" will likely verify a
cross-signature only once, at the same time that they verify the
subkey binding signature.  It need not be a per-message cost.  The
same is true for the storage and transmission of the extra material.
Yes, the cost is higher for a one-time verification... I can
live with that.

Also, note that the specification already provides a "signer userId"
subpacket that could be used to nearly the same effect as a "signer
primary fingerprint" subpacket.  As I recall, the very first proposal
was to recommend/require the use of the existing "signer userId"
subpacket.

I would have no objection to defining both mechanisms, to account for
differing user needs.  If I were forced to choose only one, I'd
take cross-signatures, as it adds more value beyond what we have now.

Date: Tue, 28 Oct 2003 18:25:01 -0800
Subject: Re: Meeting in Minneapolis?
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Saturday, October 25, 2003, at 07:54  PM, Derek Atkins wrote:

> I think we have enough topics to discuss to warrant a meeting in
> Minneapolis.  I need to request a lot by noon on Tuesday, so let me
> know if I'm missing anything.  Currently I think we have the following
> open issues from my reading of the mailing list:
>
>         - Should we obsolete 1991?                      #219
>         - 3rd party signatures                          #220
>         - IDEA, v3-v4 algo. conflict                    #221
>         - non-text User IDs                             #222
>         - Need to update the charter (milestones)       #29
>
> Are there other open issues?  Are there other PGP-related topics that
> people want to discuss in Minneapolis?  Let me know ASAP so I can
> request a timeslot, and if you want to lead a discussion on some other
> topic, please let me know (e.g.  pfs, etc.)
>
> I'd really like to get 2440bis completed, so that's my #1 priority.
>

I won't be in Minneapolis.

I stupidly thought the deadline for getting an I-D in was close of 
business Monday, and not 9am Monday, so I blew it. Sorry.

If anyone wants to see the pre-pre-release -- I'll submit this Nov 10 
-- send me email.

	Jon

Date: Tue, 28 Oct 2003 17:44:00 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: 3rd-party Signatures in a One-Pass Signed Message
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On Tue, Oct 28, 2003 at 10:15:48PM +0000, [email-masked] wrote:

> Since a notarization of a [target] signature signs the target's
> packet body (irrespective of hashed or unhashed portions), the
> notarization-in-a-subpacket will (once settled) effectively sign
> everything around itself and must be removed from the packet body
> string before it can be verified (signatures-in-subpackets used for
> subkey bindings don't have this feature because the subpacketed
> signature did not target its own parent).

I had expected that a notarization would not include any of the
unhashed data from the original signature.  After all, that data is
not part of the original signature.  Looking at the problem with this
in mind, the notary signature doesn't have to be removed before
verification since (being located in the unhashed section of the
original signature), it isn't really there in the first place.

> If this is correct and multiple notarizations of a given target body
> do not happen sequentially using the same (evolving) target body
> string, then verification will require figuring out the state of the
> unhashed subpackets at the time the notarization in question was made
> - a trial and error loop over each permutation.

Using the methodology above, multiple notarizations of a given target
body all have the same target body.

David

Date: Tue, 28 Oct 2003 17:29:54 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures proposal
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

Date: Tue, 28 Oct 2003 17:23:56 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Back-signatures, part II
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I just checked over my notes about back-signatures, and there was a
second proposal to solve the same problem.  For completeness, here is
the other proposal.

To repeat the problem: it is possible for an attacker to take a
signing subkey from a victim's key and attach this signing subkey to
the attacker's own key.  The attacker does this by issuing a new
binding signature on the subkey from his own primary key.  The end
result is that a signature issued by this signing subkey may be
claimed to be from either the attacker or the victim.

Second proposed solution: on all signatures issued by a signing
subkey, include a copy of the fingerprint of the primary key that
"owns" this subkey.  An attacker cannot issue signatures from the
stolen subkey at all, so is foiled.

The details:

   fingerprint.

2) Include it on all subkey signatures as a hashed subpacket.  (It
   must be hashed to be effective).

Comments:

1) Unlike the subkey-signs-primary key solution, old signatures issued
   before this back-signature protection became available are NOT
   automatically protected.

2) Like the other solution, this does not require generating a new
   subkey.

3) Like the other solution, this uses a signature subpacket so there
   should be no backward compatibility problems.

4) This is simpler than the other solution in several ways (less code
   to do it, for one, does not require the key to be modified and
   redistributed, for two).

5) This is likely to be faster than the other solution, as it only
   requires two signature verifications (the data in question plus the
   subkey binding signature) rather than three (the data in question,
   the subkey binding signature, and the back-signature).

6) It will no longer be possible to issue a v3 signature from a
   signing subkey.  I don't see this as a major problem since the
   older programs that don't understand v4 signatures don't
   understand signatures from signing subkeys anyway.

Comparing the two proposals seems to be a wash.  Back-signatures are a
bit slower, but protect existing signatures.  Including a fingerprint
is a bit faster, but does not protect existing signatures.

Perhaps speed and simplicity should win out here.  Speaking as someone
who regularly uses a signing subkey, I don't particularly care if my
old signatures are protected or not.  I obviously can't speak for
everyone using a signing subkey though.

Again, comments welcome.

David

Subject: Re: 3rd-party Signatures in a One-Pass Signed Message
Date: Tue, 28 Oct 2003 22:15:48 +0000
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Sender: [email-masked]

>> how about just putting the 0x50 signature as an unhashed
>> subpacket on the signature that that the 0x50 signature covers?

My concern was over the ability to form an "explicitly notarized
message." I'd prefer to distinguish a notarized document (meaning
"that document whose signatures are collectively notarized") as such
rather than determine the degree of notarized-ness using signature
subpackets. But I think it's just a question of focus: When will the
notarization of signatures deserve more attention (or priority in
computation) than the signatures themselves? I'm imagining something
like:

  10,000 people sign a petition and a notary declares that these
  signatures were made prior to some deadline.

- The notarization is (should be) inseperable from the signature list.
- Hierarchical notarizations need target only the last notary packet.

Where this special consideration is not deserved I agree that a more
general mechanism (like signatures-in-subpackets) should be applied.

>> you can trivially generate notary sigs of notary sigs of notary
>> sigs as many levels as you care to, AND it shouldn't affect any
>> currently deployed code.

As I understand the mechanics of the signature-in-a-subpacket:

Since a notarization of a [target] signature signs the target's packet
body (irrespective of hashed or unhashed portions), the
notarization-in-a-subpacket will (once settled) effectively sign
everything around itself and must be removed from the packet body
string before it can be verified (signatures-in-subpackets used for
subkey bindings don't have this feature because the subpacketed
signature did not target its own parent).

If this is correct and multiple notarizations of a given target body
do not happen sequentially using the same (evolving) target body
string, then verification will require figuring out the state of the
unhashed subpackets at the time the notarization in question was made
- a trial and error loop over each permutation.

Just wondering if this was to be taken in stride or if I've made a
mistake.

Mahalo for your suggestion,
tha Poiboy

PS. Off topic, out of scope, and by the way, it'd be nice to use 'v5'
sigs which operate on whole packets no matter what, allowing one-pass
notarizations to sign an unbroken string of target signature packets
and simplifying 5.2.4. And I should add that my suggestion depends
upon the 0x50 definition in 5.2.1 decscribing signatures on "signature
packet(s)." Get rid of the '(s)' and wonders will cease. :)

Date: Tue, 28 Oct 2003 16:56:18 -0500
From: Michael Young <[email-masked]>
To: [email-masked]
Subject: Re: Back-signatures proposal
Sender: [email-masked]

Date: Tue, 28 Oct 2003 11:35:28 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Back-signatures proposal
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The details:

Some advantages:

Comments?

David

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked]
Subject: OpenPGP and IDNA/IMAA
Date: Tue, 28 Oct 2003 17:07:59 +0100
Sender: [email-masked]

--Boundary-02=_5Rpn/gghVJkmQy/
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi!

After getting IDNA (internationalized domain names in applications) out=20
as RFCs, people are now looking at the local-part of email addresses.

How is the relevant to the OpenPGP spec?

OpenPGP UIDs are essentially free-form, but with the
  Name (Comment) <mail@address>
convention for interop.

The whole string is in utf-8. This opens up two possible ways to encode=20
a IDN (or an internationalized email address later) in the UID:

1. In ACE form (ASCII compatible encoding)
2. In UTF-8

The ACE form (obtained from the Unicode form by IDNA's ToAscii=20
transformtion) would look a bit silly given that the slot is=20
Unicode-aware, but it would work out of the box if you enter it in=20
encoded form.

The UTF-8 form might or might not work, depending on whether the=20
software used to create the key would validate the address according to=20
rfc 2822 or 2821 or simply encode the whole thing in UTF-8.

In any case, I think that rfc 2440bis as an IETF protocol that uses=20
UTF-8 needs to include at least a stringprep profile to use. I'm no=20
IETF expert, though, and it may suffice to reuse whatever comes out of=20
IMAA, but that's still at least half a year away.

If nothing is said and it's accepted as such, then the slot is=20
automatically an IDNA-unaware one, to be filled with the ACE form.

Some pointers:
3454 Preparation of Internationalized Strings ("stringprep"). P.
     Hoffman, M. Blanchet. December 2002. (Format: TXT=3D138684 bytes)
     (Status: PROPOSED STANDARD)

3490 Internationalizing Domain Names in Applications (IDNA). P.
     Faltstrom, P. Hoffman, A. Costello. March 2003. (Format: TXT=3D51943
     bytes) (Status: PROPOSED STANDARD)

3491 Nameprep: A Stringprep Profile for Internationalized Domain Names
     (IDN). P. Hoffman, M. Blanchet. March 2003. (Format: TXT=3D10316=20
bytes)
     (Status: PROPOSED STANDARD)

3492 Punycode: A Bootstring encoding of Unicode for Internationalized
     Domain Names in Applications (IDNA). A. Costello. March 2003.
     (Format: TXT=3D67439 bytes) (Status: PROPOSED STANDARD)

And discussions on [email-masked] and [email-masked].

Marc

=2D-=20
It has become fashionable in the post Cold War world to label
opponents as terrorists [...]. By doing so, the authorities instill
within society a culture of fear, leading people to accept that their
rights (and the rights of others) be trampled on for the sake of the
common good. In other words, it justifies the loss of privacy and a
state of surveillance they would otherwise not accept. Both communism
and fascism were examples of this technique used to perfection.
                  -- John Horvath: The Internet: A Terrorist Network?
                     Telepolis 2001/08/22 (#9350)

--Boundary-02=_5Rpn/gghVJkmQy/
Content-Type: application/pgp-signature
Content-Description: signature

--Boundary-02=_5Rpn/gghVJkmQy/--

Date: Mon, 27 Oct 2003 23:29:38 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Meeting in Minneapolis?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Oct 25, 2003 at 10:54:30PM -0400, Derek Atkins wrote:
> 
> Sorry I've been remiss in my duties as Chair recently.
> 
> I think we have enough topics to discuss to warrant a meeting in
> Minneapolis.  I need to request a lot by noon on Tuesday, so let me
> know if I'm missing anything.  Currently I think we have the following
> open issues from my reading of the mailing list:
> 
>         - Should we obsolete 1991?                      #219
>         - 3rd party signatures                          #220
>         - IDEA, v3-v4 algo. conflict                    #221
>         - non-text User IDs                             #222
>         - Need to update the charter (milestones)       #29
> 
> Are there other open issues?

Back-signatures from a signing subkey onto the primary key.

David

Date: Mon, 27 Oct 2003 13:55:05 -0800
Subject: Re: RFC 3156, status of RFC 2015
Cc: "John W. Noerenberg II" <[email-masked]>, Bob Braden <[email-masked]>, OpenPGP mailing list <[email-masked]>
To: Derek Atkins <[email-masked]>
From: Jon Callas <[email-masked]>
Sender: [email-masked]

On Saturday, October 25, 2003, at 07:38  PM, Derek Atkins wrote:

> Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the
> document header on the first page.
>

Done.

	Jon

Date: Mon, 27 Oct 2003 13:55:05 -0800
Subject: Re: RFC 3156, status of RFC 2015
Cc: "John W. Noerenberg II" <[email-masked]>, Bob Braden <[email-masked]>, OpenPGP mailing list <[email-masked]>
To: Derek Atkins <[email-masked]>
From: Jon Callas <[email-masked]>
Sender: [email-masked]

On Saturday, October 25, 2003, at 07:38  PM, Derek Atkins wrote:

> Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the
> document header on the first page.
>

Done.

	Jon

Date: Mon, 27 Oct 2003 13:51:37 -0800
Subject: Re: Non-textual User IDs
Cc: [email-masked]
To: David Shaw <[email-masked]>
From: Jon Callas <[email-masked]>
Sender: [email-masked]

On Tuesday, October 21, 2003, at 01:24  PM, David Shaw wrote:

>    A User ID packet consists of UTF-8 text that is intended to
>    represent the name and email address of the key holder.  By
>    convention, it includes an RFC 822 mail name, but there are no
>    restrictions on its content.  The packet length in the header
>    specifies the length of the user id.
>

In other words, just removing the line about if it is text....

Done.

	Jon

To: [email-masked]
Subject: Meeting in Minneapolis?
From: Derek Atkins <[email-masked]>
Date: 25 Oct 2003 22:54:30 -0400
Lines: 31
Sender: [email-masked]

Sorry I've been remiss in my duties as Chair recently.

I think we have enough topics to discuss to warrant a meeting in
Minneapolis.  I need to request a lot by noon on Tuesday, so let me
know if I'm missing anything.  Currently I think we have the following
open issues from my reading of the mailing list:

        - Should we obsolete 1991?                      #219
        - 3rd party signatures                          #220
        - IDEA, v3-v4 algo. conflict                    #221
        - non-text User IDs                             #222
        - Need to update the charter (milestones)       #29

Are there other open issues?  Are there other PGP-related topics that
people want to discuss in Minneapolis?  Let me know ASAP so I can
request a timeslot, and if you want to lead a discussion on some other
topic, please let me know (e.g.  pfs, etc.)

I'd really like to get 2440bis completed, so that's my #1 priority.

-derek

PS: I've also been asked to start using RT (https://rt.psg.com) to
track open issues.  I'm still learning the system and I don't (yet)
have a process in place to automatically enter new issues.  But we'll
see how it goes.

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

To: "John W. Noerenberg II" <[email-masked]>
Cc: Bob Braden <[email-masked]>, OpenPGP mailing list <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Fwd: RFC 3156, status of RFC 2015
Date: 25 Oct 2003 22:38:19 -0400
Lines: 37
Sender: [email-masked]

"John W. Noerenberg II" <[email-masked]> writes:

> At 9:38 AM -0700 10/24/03, Bob Braden wrote:
> >suppose a specification was
> >developed by an individual or organization outside the IETF process,
> >but published as an Informational RFC.  That often happens, in fact.
> >Suppose that the IETF then takes this specification into the standards
> >track, resulting in publication of a new version of the spec as a
> >Proposed Standard.  The PS will obsolete the Informational RFC.
> 
> You raise a good point I hadn't considered.  However, my original
> question is still unanswered:
> 
> "Can the WG chair request the Editor amend 2440 with the note that it
> Obsoletes 1991?"

It's not worth our time to worry about 2440.  We can add the text to
2440bis and do it then.

Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the
document header on the first page.

> Derek, I apologize for not doing so earlier, but I'll send you the
> note which originated this discussion.  To show how out-of-touch I've
> become I didn't discover until today that you'd agreed to take on the
> job WG Chair after I asked to step down.

No need for you to appologize, John.  The person who should really be
appologizing is Alfred who completely mis-addressed his original
email.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Fri, 24 Oct 2003 15:20:58 -0700
To: Bob Braden <[email-masked]>
From: "John W. Noerenberg II" <[email-masked]>
Subject: Re: Fwd: RFC 3156, status of RFC 2015
Cc: Derek Atkins <[email-masked]>, OpenPGP mailing list <[email-masked]>
Sender: [email-masked]

At 9:38 AM -0700 10/24/03, Bob Braden wrote:
>suppose a specification was
>developed by an individual or organization outside the IETF process,
>but published as an Informational RFC.  That often happens, in fact.
>Suppose that the IETF then takes this specification into the standards
>track, resulting in publication of a new version of the spec as a
>Proposed Standard.  The PS will obsolete the Informational RFC.

You raise a good point I hadn't considered.  However, my original 
question is still unanswered:

"Can the WG chair request the Editor amend 2440 with the note that it 
Obsoletes 1991?"

Derek, I apologize for not doing so earlier, but I'll send you the 
note which originated this discussion.  To show how out-of-touch I've 
become I didn't discover until today that you'd agreed to take on the 
job WG Chair after I asked to step down.
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   A good traveller has no fixed plans and is not intent on arriving.
   -- Lao Tzu (c. 570-490 B.C.)
   ----------------------------------------------------------------------

Date: Fri, 24 Oct 2003 09:48:24 -0700
To: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
From: "John W. Noerenberg II" <[email-masked]>
Subject: Re: RFC 3156, status of RFC 2015
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], OpenPGP mailing list <[email-masked]>
Sender: [email-masked]

At 11:40 AM +0200 10/23/03, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
>studying the [Open]PGP RFCs, I found a distracting situation
>concerning the status of these RFCs:

Regarding 3156 and 2015, marking 2015 as Historic and obsoleted by 
3156, and similarly, marking 3156 as obsoleting 2015 is a reasonable 
action.  To be honest, I don't know if the IESG is required to 
recommend this action or if the RFC Editor can make this change at 
the WG's request (which I've made on behalf of the WG).

In the past, Proposed RFCs that have been superceded by later RFCs 
linger as Proposed indefinitely instead of becoming Historic.  For 
the sake of clarity your suggestion of marking 2015 as Historic is a 
good one, which is why I've requested the change.  However, the 
common culture in the IETF is that a Proposed RFC which is obsolete 
is no longer relevant, so it's status on standards track is 
relatively harmless.

2440 does pay homage to 1991 in its text, but because 1991 is an 
Informational RFC and was never standards track, there's nothing for 
2440 to obsolete.

-- 

john noerenberg
   ----------------------------------------------------------------------
   A good traveller has no fixed plans and is not intent on arriving.
   -- Lao Tzu (c. 570-490 B.C.)
   ----------------------------------------------------------------------

Date: Fri, 24 Oct 2003 09:46:15 -0700
To: OpenPGP mailing list <[email-masked]>
From: "John W. Noerenberg II" <[email-masked]>
Subject: Fwd: RFC 3156, status of RFC 2015
Sender: [email-masked]

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
>Subject: RFC 3156, status of RFC 2015
>To: [email-masked], [email-masked]
>Date: Thu, 23 Oct 2003 11:40:03 +0200 (MESZ)
>Cc: [email-masked], [email-masked], [email-masked],
>         [email-masked]
>X-Mailer: ELM [$Revision: 1.17.214.3 $]
>Mime-Version: 1.0
>
>studying the [Open]PGP RFCs, I found a distracting situation
>concerning the status of these RFCs:
>
>RFC 3156 is a complete re-write and update of RFC 2015, hence it
>effectively "obsoletes" RFC 2015.  But, unfortunately, the header
>of RFC 2015 states: "Updates: 2015", and not: "Obsoletes: 2015".
>Consequentially, the RFC index, "rfc-index.txt", currently contains
>the tags
>   (UPDATED BY 3156)    for RFC 2015, and
>   (UPDATES 2015)       for RFC 3156,
>which effectively should be
>   (OBSOLETED BY 3156)  for RFC 2015, and
>   (OBSOLETES 2015)     for RFC 3156 .
>
>Moreover, RFC 2015 effectively makes *normative* reference to
>RFC 1991, an INFORMATIONAL RFC. Therefore it should never have
>been placed onto the RFC Standards Track and classified as a
>PROPOSED STANDARD.
>
>RFC 1991 in turn actually has been obsoleted by RFC 2440 - another
>fact which (unfortunately) was not stated in the header of RFC 2440.
>
>Obviously, the current proposed OpenPGP standard is specified
>in RFC 2440 (Message formats) and RFC 3156 (application of MIME),
>which both are PROPOSED STANDARDs.
>
>Therefore, RFC 2015 should now be removed from the standards
>track and the PROPOSED STANDARDS section of "rfcxx00.txt" .
>
>
>Please perform the necessary actions to resolve this situation.
>
>Best regards,
>   Alfred H‘nes.
>
>--
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
>| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
>| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
>+------------------------+--------------------------------------------+

-- 
john noerenberg
   ----------------------------------------------------------------------
   A good traveller has no fixed plans and is not intent on arriving.
   -- Lao Tzu (c. 570-490 B.C.)
   ----------------------------------------------------------------------

Date: Tue, 21 Oct 2003 16:24:27 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Non-textual User IDs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

2440 defines a User ID (section 5.11) as:

   A User ID packet consists of data that is intended to represent the
   name and email address of the key holder.  By convention, it
   includes an RFC 822 mail name, but there are no restrictions on its
   content.  The packet length in the header specifies the length of
   the user id.  If it is text, it is encoded in UTF-8.

The various 2440bis drafts keep this same text.

Suggestion: change the current specification of contents (which is
mostly unspecified) to UTF8 text only.

Rationale: The current language was written before the OpenPGP
standard got attribute IDs.  Attribute IDs are a significantly better
way to incorporate arbitrary binary blobs into user IDs.

A simple way to look at this is to note that any user ID that isn't
UTF8 text is going to be implementation-dependent.  Since it is
implementation dependent anyway, implementors may as well use
attribute packets which won't gum up the programs (all OpenPGP
programs I've seen) that more or less do expect user IDs to be text.

Suggested language:
   A User ID packet consists of UTF-8 text that is intended to
   represent the name and email address of the key holder.  By
   convention, it includes an RFC 822 mail name, but there are no
   restrictions on its content.  The packet length in the header
   specifies the length of the user id.

David

Date: Tue, 21 Oct 2003 13:49:31 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: 3rd-party Signatures in a One-Pass Signed Message
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Fri, Oct 03, 2003 at 06:41:29PM +0000, [email-masked] wrote:
> 
> Hello all,
> 
> My assumption: A 3rd-party signature (0x50) is/must be detached and
> its handling is implementation-specific.

It is true there is currently no language in the draft specifying how
a 0x50 3rd-party or notary signature is handled, but I worry about the
complexity of the proposed solution (extending the onepass
functionality).

When I suggested using a signature-in-a-subpacket to handle the need
for a back-signature from a signing subkey to a main key, I mentioned
that this basic idea could be useful in other places.  0x50 signatures
seem to be a good place to use it: rather than extending onepass or
parsing literal packets (which violate the idea of a *literal*
packet), how about just putting the 0x50 signature as an unhashed
subpacket on the signature that that the 0x50 signature covers?

This gives a good bit of flexibility - it's clear which signature is
being "notarized", and you can trivially generate notary sigs of
notary sigs of notary sigs as many levels as you care to, AND it
shouldn't affect any currently deployed code.

David

Subject: 3rd-party Signatures in a One-Pass Signed Message
Date: Fri, 3 Oct 2003 18:41:29 +0000
From: [email-masked]
To: [email-masked]
Sender: [email-masked]

Hello all,

My assumption: A 3rd-party signature (0x50) is/must be detached and
its handling is implementation-specific.

* 10.2 does not recognize a sequence of signature packets as a valid
  message, and 5.2.1 states that the 3rd-party signature is made over
  such a sequence.
* See Mr. Shaw's previous posts (including example sigs, below).

I'd like to work with 3rd-party signatures in a bona-fide (standard,
accepted) message context. This is handled in one case..

 Put the signed key sequence in a literal data packet. This buys
 message-parsing convenience at the expense of requiring a literal
 parser to sneak a peek at the "data that is not to be further
 interpreted." (5.9)

..and could be handled in at least a couple other ways:

 Accept single (standalone/detached) signature packets as a third type
 of Signed Message :- Signature Packet | Signature Packet, OpenPGP
 Message | One-Pass Signed Message. I don't like this because there
 are a number of signatures (0x10-13, 0x18, ..) which really don't
 make sense on their own and I don't think that message definitions
 should start digging into packet body attributes (in this case, the
 signature type).

 -or-

 Add an option to the One-Pass "nested" flag which means "this
 signature is applied to the signatures on the same level
 as the next."
 
The nested flag ('n') is only defined for n=0, leaving other n values
up to the imagination. In practice, the signature directly bordering
the signed message is given n=1 ..effectively stating "this next thing
is in my signed nest." I'd like to use an n=2 (n=x, whatever) option
declaring "this next thing is in my signed /signature/ nest" - a
statement which remains true for all one-pass signatures up to (and
including) the one-pass packet with n=1:

 1PASS_N(n=2), 1PASS_A(n=0), 1PASS_B(n=1), MSG, SIG_B, SIG_A, SIG_N

A and B have independently signed MSG, and N signs the combination
SIG_B + SIG_A. The 3rd-party signature needs only the signature
sequence (SIG_B, SIG_A) at creation time *but can later be
represented* in what amounts to a complete message "history."

This method has an "explicit advantage" over hiding signature
sequences in literal packets.

Thoughts? Kudos? Tomatoes?

Aloha,
poiboy at safe-mail.net

ref: http://www.imc.org/ietf-openpgp/mail-archive/msg04135.html
     http://www.imc.org/ietf-openpgp/mail-archive/msg04385.html