Subject: Revocation key difficulty

From: David Shaw <[email-masked]>
Date: Tue, 26 Feb 2002 15:58:56 -0500

Hi folks,

While implementing revocation key ("designated revoker") support for
GnuPG, I came across what seems to be a problem in the specificaiton
of revocation keys.

The RFC says the key designated as the revocation key can issue
several types of revocations: key revocations (0x20), subkey
revocations (0x28), and certificate revocations (0x30).  The first two
are not a problem since there is no confusion as to what they revoke.

The problem with certificate revocations is that it is not possible in
some cases to know which certificate is being revoked.  For example,
take Alice, Bob, and Charlie.  Bob is Alice's designated revoker.
Alice and Bob have both signed Charlie's key.  Now Alice asks Bob to
revoke her signature on Charlie's key.

Since both Alice and Bob have signed Charlie's key, and the format of
a revocation that is issued by a designated revoker is the same as a
revocation issued by the key owner, the OpenPGP program has no way to
tell which certification is being revoked: is it Bob's or is it
Alice's?

A while back, someone suggested a "revocation target" signature
subpacket for revocation signatures that would contain the hash of the
signature that was being revoked.  That would fix this problem, but
I'm open to any solution - does it even make sense to allow a
revocation key to issue certificate revocations?  I always thought of
the revocation key as the "revoker of last resort" - more for
emergency key revocations in case of compromise or secret key loss
than for fine-grained control of previously issued signatures.

David

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

---

From: Jon Callas <[email-masked]>
Date: Tue, 26 Feb 2002 14:52:33 -0800

>tell which certification is being revoked: is it Bob's or is it

Ummm, that's certificate revocation, not certification revocation. A PGP
certificate (a.k.a. key) contains a collection of certifications. It is
these certifications (colloquially key signatures) that determine a
certificate's validity.

A certificate revocation makes the certificate dead. It cancels the
*entire* certificate, regardless of anything else.

Here's a scenario like yours:

Alice and Bob have both signed Charlie's key. Alice is also a designated
revoker on Charlie's key. When Alice issues a certificate revocation for
Charlie's key (a.k.a. certificate), then Charlie's key is revoked. It is an
ex-certificate and has joined the Choir Eternal. It has ceased to be. It no
longer matters that Bob signed Charlie's key. It no longer matters that
David through Zelda inclusive has signed it. It is no longer valid. This is
just like what would happen if Charlie issued that revocation himself.

Now, then, there are some unresolved issues related to this. Is the
contract that Bob signed two years ago with me now suddenly void? I think
not. There are, however, people I respect who think it is. But that's a
different discussion.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 26 Feb 2002 18:38:43 -0500

> *entire* certificate, regardless of anything else.

Well understood and agreed, but I really did mean what I said.  The
RFC says (section 5.2.1):

   0x30: Certification revocation signature
       This signature revokes an earlier user ID certification
       signature (signature class 0x10 through 0x13). It should be
       issued by the same key that issued the revoked signature or an
       authorized revocation key The signature should have a later
       creation date than the signature it revokes.

Am I somehow misreading this?  To my eye, this says an authorized
revocation key can issue a genuine 0x30 *certification* revocation
signature.

David

---

From: "Michael Young" <[email-masked]>
Date: Wed, 27 Feb 2002 13:44:29 -0500

> signature that was being revoked.  That would fix this problem, but

I was that someone.  I still think it's a good idea.

How can it possibly hurt to identify the exact signature
being revoked?  It can't be the few extra bytes... it would
be a small fraction of the total, and revocations should be
rare, anyway.

Even if the current issue is resolved by removing the language
about designated revokers issuing certification revocations,
there are other ambiguities that this would solve.  I think
it is quite valid for one key to sign something multiple times,
with a different: signature class; expiration time; notation;
preferred algorithm; or, almost any other optional subpacket.
Some have suggested using the timestamp to decide which
signatures a revocation covers, but others have objected.
I see no need to depend on timestamps -- the hash identifies
the signature perfectly.

When it last came up, Jon asked if anyone would implement it,
and Werner said he would not.  Since my implementation is not
yet (and may never be) public, I didn't feel qualified to say "yes".
But I suppose that either David or I could implement it in
GnuPG, if Werner would pick up the change.

I'm not asking for this to be a MUST.  Old revocations (and
even new V3 ones) will not have the subpacket, so no implementation
should depend on it.  I'd suggest making it a SHOULD.

Any other supporters out there?

---

From: "Michael Young" <[email-masked]>
Date: Wed, 27 Feb 2002 14:28:35 -0500

In my previous message, I mentioned the possibility of changing the
designated revoker language to resolve this issue, but I didn't mean
to recommend that.  In fact, I might argue that the ability to revoke
individual certifications is the only meaningful use of a designated
revoker.

If I want to limit my designated revoker to flushing my whole
key, I can do that *much* more easily -- I can generate my
own revocation, and encrypt it to my designated revoker.
(If you're so afraid that your designee will lose the thing,
put it in a notation packet in another signature, and
ship it off to a keyserver for archiving. ;-)  Doing it that
way doesn't depend on everyone having my revoker's key for
verification, or even knowing who the revoker might be.
This seems so vastly superior to me that I can't imagine
using the designated revoker facility for this purpose.
(Am I missing something?)

But if I'm in the habit of making dubious signatures, and
want to let someone cancel specific ones, I would need to
give my designee an encrypted revocation certificate for
each of those as well.  Not impossible, but a little more
tedious.  The designated revoker encoding is more compact.

[You might ask: what kind of moron habitually issues questionable
signatures?  Perhaps an automated corporate ID generator.
Why designate a revoker?  You might want to destroy away the
generator's private key periodically, to prevent additional
certifications, but still want to be able to revoke things.
A pretty weak example, but the best I can offer.  Can anyone
else provide a stronger example?]

---

From: David Shaw <[email-masked]>
Date: Wed, 27 Feb 2002 22:40:25 -0500

> individual certifications is the only meaningful use of a designated

I can see both sides of this issue.  On the one hand, additional
flexibility in OpenPGP to handle more varied uses is probably good.
Having a designated revoker that can revoke key certifications (0x30)
has also been in the standard for a long time, though as far as I
know, nobody has ever implemented it (I assume if someone had, they'd
have had the same problem and raised the same question I did).

On the other hand, I'm concerned that giving the designated revoker
such fine-grained power to influence previous actions of the key owner
could be dangerous.  I rather like the idea that the absolute worst
thing a rogue designated revoker could do is revoke your key.

Even though the standard allows for more, as far as I know, the only
implementation that does designated revokers is PGP, and it does only
full key revocations (0x20).  GnuPG will start doing designated
revokers RSN, and I wrote the code to only do full key revocations as
well, though I'm open to changing that.

> (Am I missing something?)

Think about this from the perspective of a large company, and it makes
more sense.  You'd want a company key to be designated revoker for
everyone, but storing and keeping track of thousands of revocations is
a pain.  Having a revocation key that can be used when needed is far
simpler.  Also, it sounds a bit easier to automate putting the
revocation key on each new company key as it is created than it is to
automate generating a revocation and sending it to the right person
for storage and later use.

David

---

From: "Michael Young" <[email-masked]>
Date: Thu, 28 Feb 2002 15:24:26 -0500

From: "David Shaw" <[email-masked]>
> full key revocations (0x20).  GnuPG will start doing designated

A while back, I tested a third-party scenario: (Alice's designated
revoker) Bob revokes Alice's signature of Charlie's key/name.  Not only
would PGP not let Bob generate a revocation for a certification
(unless Bob had also signed Alice's key himself), but it wouldn't
recognize one that I manually injected.  I don't recall trying
to revoke a self-signature: Bob revokes one of Alice's names (not the key).

Another aspect I didn't test is what PGP does when the designated
revoker's key is not available.  I suppose it could check for
revocations with a matching "issuer" hint.  (Anyone who could tweak
the hint could destroy the revocation just as easily anyway.)
Does it?  If there is a match (but no key), what is the validity decision?

> You'd want a company key to be designated revoker for everyone, but
> storing and keeping track of thousands of revocations is a pain.

Yes, but some pain is required.  Something still has to hold onto the
keys themselves, specifically the designated revoker subpackets.
Otherwise, a user could throw away the designation.  I think I'd have
enhanced the corporate (key) server rather than complicating the
client validity checking.  But the whole V4 upgrade (especially
the "placeholder for backward compatibility" :-) required changes
to client understanding; in for a penny, in for a pound, I suppose.

Anyway, sorry to poke at a dead horse... I'll let it go, now.

---

From: David Shaw <[email-masked]>
Date: Thu, 28 Feb 2002 18:43:34 -0500

> Does it?  If there is a match (but no key), what is the validity decision?

If the designated revoker's key is not present, then a key "revoked"
by the designated revoker key is not treated as revoked.  GnuPG - as
of this morning - does it the same way.

David

Date: Thu, 28 Feb 2002 18:43:34 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Revocation key difficulty
Mail-Followup-To: [email-masked]
Sender: [email-masked]

> Does it?  If there is a match (but no key), what is the validity decision?

If the designated revoker's key is not present, then a key "revoked"
by the designated revoker key is not treated as revoked.  GnuPG - as
of this morning - does it the same way.

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Revocation key difficulty
Date: Thu, 28 Feb 2002 15:24:26 -0500
Sender: [email-masked]

Date: Wed, 27 Feb 2002 22:40:25 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Revocation key difficulty
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Revocation key difficulty
Date: Wed, 27 Feb 2002 14:28:35 -0500
Sender: [email-masked]

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Revocation identification (was Re: Revocation key difficulty )
Date: Wed, 27 Feb 2002 13:44:29 -0500
Sender: [email-masked]

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: Re: Revocation key difficulty
Date: Wed, 27 Feb 2002 11:42:19 -0500
Sender: [email-masked]

----- Original Message -----
From: "David Shaw" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 26, 2002 6:57 PM
Subject: Re: Revocation key difficulty

>
> On Tue, Feb 26, 2002 at 05:22:35PM -0600, [email-masked] wrote:
>
> > Hmm, so how would it be used?  Alice had signed Charlie's key, and now
> > Alice's key is compromised, so Bob decides to remove Alice's signature
from
> > Charlie's key.  Why?
...
> Exactly.  It seems to make more sense to Bob for issue a general key
> revocation (sigclass 0x20) for Alice's key, rather than issue a
> certification revocation (sigclass 0x30) for Alice's signature on
> Charlie's key.
...

A possible reason why it may be beneficial to to have a revoker selectively
revoke only the signature,
may be if one is forced to give up an RSA encryption key.
{Hopefully, this should never have to be, and the session key should be
enough for the authorities,
but if it 'were' to happen ...,}

Then, to avoid anyone else signing with Alice's key  {if it would be
surrendered},
Alice may want two separate RSA keys, her original one for encrypting, and
another one for signing.

Alice then publicly declares that she is no longer signing with her original
RSA key.

Sometime later, someone else's key that Alice once signed, is now
'questionable', and Alice wants her signature removed.
Now her designated revoker can accomplish this.

vedaal

Date: Tue, 26 Feb 2002 18:57:38 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Revocation key difficulty
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Feb 26, 2002 at 05:22:35PM -0600, [email-masked] wrote:

> Hmm, so how would it be used?  Alice had signed Charlie's key, and now
> Alice's key is compromised, so Bob decides to remove Alice's signature from
> Charlie's key.  Why?  Well, perhaps Alice is a manager and Charlie is an
> employee, and Bob is the tech doing all the work.  Bob is cleaning all the
> underling's keys and doesn't want to ask Alice to get involved, or maybe
> she is out of reach.
> 
> So, why is it necessary to remove Alice's signature from Charlie's key?
> Anyone who verifies Charlie's key will see that Alice's has been revoked
> and will know to ignore it.  If you're going to distribute this
> second-party revokation of signatures, why not just send out a generic
> "Alice's key is bad" revokation, and that implies that it ought to be
> removed from certificates too?

Exactly.  It seems to make more sense to Bob for issue a general key
revocation (sigclass 0x20) for Alice's key, rather than issue a
certification revocation (sigclass 0x30) for Alice's signature on
Charlie's key.

The problem I'm having is that the RFC says that Bob can issue a
certification revocation (0x30. NOT 0x20).  I'm not saying this is
smart, a good idea, or best practice, but the RFC explicitly says it
is possible.

If Bob does this, there is no way to differentiate between Bob's
certification revocation (0x30) of Bob's certification (0x10) of
Charlie's key and Bob's certification revocation (0x30) of Alice's
certification (0x10) of Charlie's key.

I'm including sigclasses here to help make what I'm saying clear.  The
words "certificate" and "certification" are just too similar and I
think I swapped them once or twice in my original mail.  Sorry folks.

David

Date: Tue, 26 Feb 2002 18:38:43 -0500
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked]
Subject: Re: Revocation key difficulty
Mail-Followup-To: Jon Callas <[email-masked]>, [email-masked]
Sender: [email-masked]

David

Subject: Re: Revocation key difficulty
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Date: Tue, 26 Feb 2002 17:22:35 -0600
Sender: [email-masked]

From: John Dlugosz

=====
=====

Hmm, so how would it be used?  Alice had signed Charlie's key, and now
Alice's key is compromised, so Bob decides to remove Alice's signature from
Charlie's key.  Why?  Well, perhaps Alice is a manager and Charlie is an
employee, and Bob is the tech doing all the work.  Bob is cleaning all the
underling's keys and doesn't want to ask Alice to get involved, or maybe
she is out of reach.

So, why is it necessary to remove Alice's signature from Charlie's key?
Anyone who verifies Charlie's key will see that Alice's has been revoked
and will know to ignore it.  If you're going to distribute this
second-party revokation of signatures, why not just send out a generic
"Alice's key is bad" revokation, and that implies that it ought to be
removed from certificates too?

Date: Tue, 26 Feb 2002 14:52:33 -0800
To: David Shaw <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Revocation key difficulty
Sender: [email-masked]

	Jon

Date: Tue, 26 Feb 2002 15:58:56 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Revocation key difficulty
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Hi folks,

David

Date: Sun, 24 Feb 2002 12:26:33 +0200
From: [email-masked]
Organization: disastry.NO.SPaM.NET
To: [email-masked]
Subject: Re: Alice, Bob, ... Foo, bar?
Sender: [email-masked]

John Dlugosz wrote:
> I know about Alice and Bob in general.  But does anyone have a pointer to a
> complete list of which names are commonly used, and what Roles those names
> are used for?  E.g. Eve is used for an evesdropper.  Someone else (I forgot
> who) can alter packets, though.
> --John

see:
http://www.cs.man.ac.uk/~chl/scenarios.html

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

To: "Dominikus Scherkl" <[email-masked]>
Cc: <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: OpenPGP vs. X.509/PKCS
Date: 22 Feb 2002 17:42:34 -0500
Lines: 34
Sender: [email-masked]

Give me a patent-free ECC algorithm that has reasonable performance.

Replies to /dev/null, please.

-derek

"Dominikus Scherkl" <[email-masked]> writes:

> > At the time PGP was created, there were a LOT of things that PGP
> > could offer than X.509 could not.  To name a few:
> > 
> >  - PGP certificates are MUCH smaller than X.509 in terms of 
> the number
> >    of bytes required to represent the same semantic content.
> 
> If you see this as an important advantage, I can't understand why
> still nobody is iteressted in integrating elliptic curves into the
> openPGP standard (as I proposed in last august, you may find it at:
> http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt).
> 
> This Draft is now expired, but I still want it to become part 
> of openPGP.
> 
> PS: my mail-account has changed:
> 
> -- 
> Dominikus Scherkl
> Mail: [email-masked]
>  

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

Date: Fri, 22 Feb 2002 15:30:05 -0500
From: Paul Shields <[email-masked]>
To: Joe Tag <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: Alice, Bob, ... Foo, bar?
Sender: [email-masked]

Also:

    Malcolm: the man in the middle, an active attacker who can alter
messages, forge packets, certificates, etc.

Joe Tag wrote:

> Hi,
>
> You can also find the reference in Schneir __Applied_Crytography__ text;
> and in
> Pfleeger's __Security_in_Computing__ .
> Koblitz in his __Number_Theory_and_Crypto__  used names like
> 'Aida' and 'Bernardo'.
>
> I like 'Anna' ( think the old morse code naviation system " . _ " = a ; "_
> ." = n; and
> ''Anna'' is a 'palindrome name' ; You could use also, "Alyssa" (think
> Milano).
> Boris (Russion), Bruce.
> Carol, Carl, Carlos, Charles is the "Certificate Authority"
> 'Evan' could also be an eavesdropper (just think Evil).
> "Trent" is the "Digital 'Trusted' Notary.  Also known as "Ted".
>
> Sincerely yours,
>
>      Joe Tag,Jr.
>
> http://www.kean.edu/~jtag
>
> On Fri, 22 Feb 2002 12:51:55 -0500 (EST) Robert Guerra
> <[email-masked]> writes:
> >
> > The Alice and Bob After Dinner Speech
> > given at the Zurich Seminar, April 1984
> > by John Gordon
> >
> > http://www.conceptlabs.co.uk/alicebob.html
> >
> > On Fri, 22 Feb 2002 [email-masked] wrote:
> > >
> > > From: John Dlugosz
> > >
> > > I know about Alice and Bob in general.  But does anyone have a pointer
> to a
> > > complete list of which names are commonly used, and what Roles  those
> names
> > > are used for?  E.g. Eve is used for an evesdropper.  Someone else
> > > (I forgot who) can alter packets, though.
> > >
> > > --John

To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 22 Feb 2002 14:47:56 -0500
Subject: Re: Alice, Bob, ... Foo, bar?
From: Joe Tag <[email-masked]>
Sender: [email-masked]

Hi, 

You can also find the reference in Schneir __Applied_Crytography__ text;
and in 
Pfleeger's __Security_in_Computing__ . 
Koblitz in his __Number_Theory_and_Crypto__  used names like 
'Aida' and 'Bernardo'. 

I like 'Anna' ( think the old morse code naviation system " . _ " = a ;
"_ ." = n; and
''Anna'' is a 'palindrome name' ; You could use also, "Alyssa" (think
Milano). 
Boris (Russion), Bruce. 

Carol, Carl, Carlos, Charles is the "Certificate Authority" 

'Evan' could also be an eavesdropper (just think Evil).  

"Trent" is the "Digital 'Trusted' Notary.  Also known as "Ted". 

Sincerely yours, 

     Joe Tag,Jr. 

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

On Fri, 22 Feb 2002 12:51:55 -0500 (EST) Robert Guerra
<[email-masked]> writes:
> 
> The Alice and Bob After Dinner Speech
> 
> given at the Zurich Seminar, April 1984
> 
> by John Gordon
> 
> 
> http://www.conceptlabs.co.uk/alicebob.html
> 
> On Fri, 22 Feb 2002 [email-masked] wrote:
> 
> >
> > From: John Dlugosz
> >
> > I know about Alice and Bob in general.  But does anyone have a 
> pointer to a
> > complete list of which names are commonly used, and what Roles 
> those names
> > are used for?  E.g. Eve is used for an evesdropper.  Someone else 
> (I forgot
> > who) can alter packets, though.
> >
> > --John
> >
> >
> 
> -- 
> Robert Guerra <[email-masked]>
> Director, Computer Professionals for Social Responsibility (CPSR)
> <http://www.cpsr.org>
> 
________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
http://dl.www.juno.com/get/web/.

Date: Fri, 22 Feb 2002 12:51:55 -0500 (EST)
From: Robert Guerra <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: Alice, Bob, ... Foo, bar?
Sender: [email-masked]

The Alice and Bob After Dinner Speech

given at the Zurich Seminar, April 1984

by John Gordon

http://www.conceptlabs.co.uk/alicebob.html

On Fri, 22 Feb 2002 [email-masked] wrote:

>
> From: John Dlugosz
>
> I know about Alice and Bob in general.  But does anyone have a pointer to a
> complete list of which names are commonly used, and what Roles those names
> are used for?  E.g. Eve is used for an evesdropper.  Someone else (I forgot
> who) can alter packets, though.
>
> --John
>
>

-- 
Robert Guerra <[email-masked]>
Director, Computer Professionals for Social Responsibility (CPSR)
<http://www.cpsr.org>

Subject: Alice, Bob, ... Foo, bar?
To: [email-masked]
From: [email-masked]
Date: Fri, 22 Feb 2002 11:15:15 -0600
Sender: [email-masked]

From: John Dlugosz

I know about Alice and Bob in general.  But does anyone have a pointer to a
complete list of which names are commonly used, and what Roles those names
are used for?  E.g. Eve is used for an evesdropper.  Someone else (I forgot
who) can alter packets, though.

--John

content-class: urn:content-classes:message
Subject: RE: OpenPGP vs. X.509/PKCS
Date: Fri, 22 Feb 2002 18:09:16 +0100
From: "Dominikus Scherkl" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

> At the time PGP was created, there were a LOT of things that PGP
> could offer than X.509 could not.  To name a few:
> 
>  - PGP certificates are MUCH smaller than X.509 in terms of 
the number
>    of bytes required to represent the same semantic content.

If you see this as an important advantage, I can't understand why
still nobody is iteressted in integrating elliptic curves into the
openPGP standard (as I proposed in last august, you may find it at:
http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt).

This Draft is now expired, but I still want it to become part 
of openPGP.

PS: my mail-account has changed:

-- 
Dominikus Scherkl
Mail: [email-masked]

Date: Fri, 22 Feb 2002 00:02:42 +0100
From: Helmut Springer <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP vs. X.509/PKCS
Mail-Followup-To: [email-masked]
Organization: elite[tm] since running completely computer based FAX
Sender: [email-masked]

On 21 Feb 2002 at 23:17 +0100, Leon Kuunders wrote:
> So the question is: how could we turn OpenPGP into a
> more-money-making infrastructure? And that comes down to: what

        Title           : Extensions to TLS for OpenPGP keys
        Author(s)       : W. Price, M. Elkins
        Filename        : draft-ietf-tls-openpgp-02.txt
        Pages           : 4
        Date            : 19-Feb-02

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

Comes to mind.  Interoperability with SSH would be another step
towards a "complete" PKI solution.  But then you need both a need
for PKIs and widely used software to generate real money...

-- 
MfG/best regards, helmut springer           "Freedom's just another word
                                             for nothing left to lose"

To: "Leon Kuunders" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
From: "Derek Atkins" <[email-masked]>
Subject: Re: OpenPGP vs. X.509/PKCS
Date: 21 Feb 2002 17:46:00 -0500
Lines: 70
Sender: [email-masked]

At the time PGP was created, there were a LOT of things that PGP
could offer than X.509 could not.  To name a few:

 - PGP certificates are MUCH smaller than X.509 in terms of the number
   of bytes required to represent the same semantic content.

 - at the time X.509 certificates could only carry a single signature,
   forcing users into a strict hierarchical model, whereas PGP allows
   the opportunity for a more web-like model that better mirrors
   real-world relationships.

 - PGP certificates are self-generated, and require no interaction
   with anybody in order to start using the system, wheras with X.509
   you need to get your key signed by an authority before you can use
   it at all.

Note that the question you are asking does not necessarily follow from
the question that I answered.  The question was about why PKCS was
created.  PKCS came from RSADSI, which was the company that owned the
RSA patent.  They created the PKCS standards.

As for why X.509 took off?  It took off because there was money to be
made when you force users to use your services (read: you're a CA),
and because you have a business whereas PGP does not.  (Note that all
this happened in the early 90s, well before PGP, Inc. existed).

-derek

"Leon Kuunders" <[email-masked]> writes:

> So the question is: how could we turn OpenPGP into a more-money-making
> infrastructure? And that comes down to: what kind of need would there be for
> OpenPGP? If there is already X509? What can OpenPGP do what the other one
> can't? And what kind of business model would go with that?
> 
> Is it feasible to think that as long as the 'mainstream' is not convinced of
> the fact that OpenPGP can bring them _more_ money than X509 - that this
> battle is moving towards a definite end?
> 
> -Leon.
> 
> > From: Derek Atkins
> >
> > Because "they" weren't making any money off of PGP. :)
> >
> > -derek
> >
> > [email-masked] writes:
> >
> > > From: John Dlugosz
> > >
> > > If PGP was indeed established as the first useful PK system,
> > why did "they"
> > > come up with PKCS standards that are totally different?  Why
> > did PKCS-style
> > > files and formats propigate through Internet standards, when all along
> > > everyone was using PGP, and had access to that code?
> > >
> >
> > --
> >        Derek Atkins
> >        Computer and Internet Security Consultant
> >        [email-masked]             www.ihtfp.com
> >
> 

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

From: "Leon Kuunders" <[email-masked]>
To: "Derek Atkins" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OpenPGP vs. X.509/PKCS
Date: Thu, 21 Feb 2002 23:17:43 +0100
Importance: Normal
Sender: [email-masked]

So the question is: how could we turn OpenPGP into a more-money-making
infrastructure? And that comes down to: what kind of need would there be for
OpenPGP? If there is already X509? What can OpenPGP do what the other one
can't? And what kind of business model would go with that?

Is it feasible to think that as long as the 'mainstream' is not convinced of
the fact that OpenPGP can bring them _more_ money than X509 - that this
battle is moving towards a definite end?

-Leon.

> From: Derek Atkins
>
> Because "they" weren't making any money off of PGP. :)
>
> -derek
>
> [email-masked] writes:
>
> > From: John Dlugosz
> >
> > If PGP was indeed established as the first useful PK system,
> why did "they"
> > come up with PKCS standards that are totally different?  Why
> did PKCS-style
> > files and formats propigate through Internet standards, when all along
> > everyone was using PGP, and had access to that code?
> >
>
> --
>        Derek Atkins
>        Computer and Internet Security Consultant
>        [email-masked]             www.ihtfp.com
>

To: [email-masked]
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: OpenPGP vs. X.509/PKCS
Date: 21 Feb 2002 16:24:33 -0500
Lines: 18
Sender: [email-masked]

Because "they" weren't making any money off of PGP. :)

-derek

[email-masked] writes:

> From: John Dlugosz
> 
> If PGP was indeed established as the first useful PK system, why did "they"
> come up with PKCS standards that are totally different?  Why did PKCS-style
> files and formats propigate through Internet standards, when all along
> everyone was using PGP, and had access to that code?
> 

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

Subject: OpenPGP vs. X.509/PKCS
To: [email-masked]
From: [email-masked]
Date: Thu, 21 Feb 2002 15:11:50 -0600
Sender: [email-masked]

From: John Dlugosz

If PGP was indeed established as the first useful PK system, why did "they"
come up with PKCS standards that are totally different?  Why did PKCS-style
files and formats propigate through Internet standards, when all along
everyone was using PGP, and had access to that code?

From: "vedaal" <[email-masked]>
To: <[email-masked]>
Subject: pgp oddities
Date: Thu, 21 Feb 2002 14:38:14 -0500
Sender: [email-masked]

have compiled a list of pgp oddities,
composed of examples of what can be done to a pgp message and still have it
decrypt / verify

and what minor changes will invalidate it,

and what differences there are between pgp  and gnupg in how these changes
are accepted.

the site is here:
http://www.angelfire.com/pr/pgpf/pgpoddities.html

except for one clearsigned message done using winpt, all the messages were
generated using pgp 6.5.8 ckt  build 6

some of the examples may be helpful in considering any recommendations for
open pgp format of pgp messages

vedaal

Date: Sun, 17 Feb 2002 01:21:14 +0100 (CET)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Sender: [email-masked]

Jon Callas <[email-masked]>:
> At 10:50 AM +0100 2/13/02, Thomas Roessler wrote:

>>> does not work with many mailing lists (that are configured to
>>> remove attachments),

>> Such mailing lists are broken.

> As someone who runs a number of such "broken" mailing lists, I "broke" them
> because I consider the security risk of my list being use to spread the
> latest Outlook thingie to be much higher than the damage caused by breaking
> them.

So it's not about multipart messages, but about dangerous Content-Types?
Dangerous Content-Type values have nothing to do with whether a
message is a multipart message or not.  Any Content-Type can be named
directly in the main message headers, and completely harmless
Content-Types can be named in the individual body parts of a multipart
message.

>       It also prevents the inevitable newbie who sends a picture or movie
> as an attachment, causing a dozen people to go over their mail quotas.

Again, this has nothing to do with multiparts.  If you want to prevent
huge messages, set an appropriate message size limit.

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode
Date: Fri, 15 Feb 2002 11:39:12 -0500
Sender: [email-masked]

>I want to mention that I want to keep a secret key in format OpenPGP not
> > a plain text.

In this context, the "multi-precision integers comprising the secret
key data" are the plaintext.

> 1) What value should I fill in IV?

In the secret key context, the IV should be filled with random bits.
That IV is included in the unencrypted section of the secret key packet.

For message packets, the IV is initially zero, but the first material
to be encrypted is random, which has similar effect.

> 2) Are those BS+2 octets just for plain text or even for secret key
> material?

The "BS+2" scheme is only used in the Symmetrically Encrypted Data
("message") packets.

Secret key material is encrypted in a pure CFB mode; see below.

> >3. FRE is xored with the first BS octets of random data prefixed to
> >the plaintext to produce C[1] through C[BS], the first BS octets
> >of ciphertext.
> 
> 3) Do the C[i] octets represent the final form for OpenPGP format? 

Yes.

> 4) Let's assume that I encrypt the algorithm-specific portion with IDEA.
> What it happens with the last block of data if the length of the
> algorithm-specific portion is not multiple of 8 (64 bit)? (and, of
> course, the last block it will be less than BS - in this case 8 octets)

CFB mode can use any "block size".  The underlying cipher is always
applied to the "feedback register", which is a whole block, even if
the CFB input is smaller.  If the CFB input is N bytes, only the first
N bytes of the encrypted feedback register are used; they are XORed
with the CFB input to form the CFB output.  The CFB output is then
shifted into the feedback register.

The "block size" under CFB can even change from one input to the
next.  To decrypt, you also need to know how the data was blocked.
RFC2440 uses the phrase "resync" to describe where blocks smaller
than the underlying cipher are processed.  For example, at the
front of a message packet, a full block of random material is
processed, following by an 2-byte block of repeated material --
those two bytes are *not* combined with subsequent plaintext to
form a "full block", but are processed by themselves.
Also, version 3 secret keys are processed one MPI at a time
(including only the data, not the length), so the last bytes
of each MPI may be a short block.

Here is some Java-like pseudo-code for CFB that isn't tied to
the OpenPGP behavior.

  Cipher engine;  // underlying cipher, used in "ECB" mode
  byte [] FR;     // feedback register, block-sized; initialized with IV

  void cfb_encrypt(byte [] src, byte [] dest, int length) {
    // assumes length <= ECB block size; if not, reject or break up the input

    // encrypt the FR, and XOR first "length" bytes with src into dest
    byte [] FRE = engine.encrypt(FR);
    for (int i = 0; i < length; i++)
      dest[i] = src[i] ^ FRE[i];

    // shift "length" bytes of result into FR
    int j = 0;
    for (int i = length; i < FR.length; i++) FR[j++] = FR[i];
    for (int i = 0; j < FR.length; i++) FR[j++] = dest[i];
  }

To: "Cornel GLIGAN" <[email-masked]>
Cc: <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode
Date: 15 Feb 2002 09:26:15 -0500
Lines: 80
Sender: [email-masked]

"Cornel GLIGAN" <[email-masked]> writes:

> Hi!
> 
> First fo all, I want to thank you for you answer me.
> 
> Here are my problems:
> 
> >OpenPGP does symmetric encryption using a variant of Cipher Feedback
> >Mode (CFB mode). This section describes the procedure it uses in
> >detail. This mode is what is used for Symmetrically Encrypted Data
> >Packets; the mechanism used for encrypting secret key material is
> >similar, but described in those sections above.
> 
> In the "secret key material" section I found this: 
> >Encryption/decryption of the secret data is done in CFB mode using
> >the key created from the passphrase and the Initial Vector from the
> >packet.
> 
> (and now, back to the CFB mode)
> >OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
> >and prefixes the plaintext with BS+2 octets of random data, such
> >that octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
> >"resync" after encrypting those BS+2 octets.
> 
> I want to mention that I want to keep a secret key in format OpenPGP not
> a plain text.
> 1) What value should I fill in IV?
> 2) Are those BS+2 octets just for plain text or even for secret key
> material?

The OpenPGP CFB module uses an "Encrypted Initialization".  The way this
works is:
        1) start with an IV of all zeros (in the CFB Context)
        2) Create a buffer of "BS+2" bytes
        3) Fill in the first BS bytes with random bytes
        4) copy the last two bytes of BS into the extra two bytes at the end
        5) CFB Encrypt the "BS+2" bytes <-- This is the encrypted IV
        6) Re-Sync the CFB context.
        7) Start ecnrypting your data.

This is done EVERY TIME you initialize a CFB context.  These extra
BS+2 bytes are prefixed before every CFB encryption.

> >3. FRE is xored with the first BS octets of random data prefixed to
> >the plaintext to produce C[1] through C[BS], the first BS octets
> >of ciphertext.
> 
> 3) Do the C[i] octets represent the final form for OpenPGP format? 

Yes.  Although C[0]..C[BS+2] are the encrypted IV bytes, not your data
bytes.

> >12. FRE is xored with the next BS octets of plaintext, to produce
> >the next BS octets of ciphertext.  These are loaded into FR and
> >the process is repeated until the plaintext is used up.
> 
> 4) Let's assume that I encrypt the algorithm-specific portion with IDEA.
> What it happens with the last block of data if the length of the
> algorithm-specific portion is not multiple of 8 (64 bit)? (and, of
> course, the last block it will be less than BS - in this case 8 octets)

You clearly don't understand how CFB mode works.  You don't encrypt
your input in block-sized chunks; you rotate your feedback register in
block-sized chunks.  The ciphertext is just an xor of the feedback
register with the plaintext, and you rotate the feedback register by
encrypting your output.  So if the last block of plaintext is only 1
byte, you only use one byte from the last feedback and toss the rest
of your feedback on the floor.

> Thank you in advance,
> Cornel Gligan-Ignatescu

-derek

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

Subject: RE: Need some explanations about privarte key in OpenPGP format, CFB mode
Date: Fri, 15 Feb 2002 08:47:54 +0200
content-class: urn:content-classes:message
From: "Cornel GLIGAN" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi!

First fo all, I want to thank you for you answer me.

Here are my problems:

>OpenPGP does symmetric encryption using a variant of Cipher Feedback
>Mode (CFB mode). This section describes the procedure it uses in
>detail. This mode is what is used for Symmetrically Encrypted Data
>Packets; the mechanism used for encrypting secret key material is
>similar, but described in those sections above.

In the "secret key material" section I found this: 
>Encryption/decryption of the secret data is done in CFB mode using
>the key created from the passphrase and the Initial Vector from the
>packet.

(and now, back to the CFB mode)
>OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
>and prefixes the plaintext with BS+2 octets of random data, such
>that octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
>"resync" after encrypting those BS+2 octets.

I want to mention that I want to keep a secret key in format OpenPGP not
a plain text.
1) What value should I fill in IV?
2) Are those BS+2 octets just for plain text or even for secret key
material?

>3. FRE is xored with the first BS octets of random data prefixed to
>the plaintext to produce C[1] through C[BS], the first BS octets
>of ciphertext.

3) Do the C[i] octets represent the final form for OpenPGP format? 

>12. FRE is xored with the next BS octets of plaintext, to produce
>the next BS octets of ciphertext.  These are loaded into FR and
>the process is repeated until the plaintext is used up.

4) Let's assume that I encrypt the algorithm-specific portion with IDEA.
What it happens with the last block of data if the length of the
algorithm-specific portion is not multiple of 8 (64 bit)? (and, of
course, the last block it will be less than BS - in this case 8 octets)

Thank you in advance,

Cornel Gligan-Ignatescu

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Kyser Soze <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: rfc2015bis
Date: Thu, 14 Feb 2002 21:34:56 +0100
Sender: [email-masked]

On Thursday 14 February 2002 18:44, Kyser Soze wrote:
> Hi,
>     I searched the net, there are references to rfc2015bis, but I
> can't seem to download it from anywhere. Where can it get it from?
<snip>

It's already an rfc (3152 or 3156 - I always keep forgetting).

Marc

- -- 
Marc Mutz <[email-masked]>

To: OpenPGP <[email-masked]>
CC: Kyser Soze <[email-masked]>
Subject: Re: rfc2015bis
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Thu, 14 Feb 2002 20:17:13 +0100
Lines: 19
Sender: [email-masked]

On Thu, 14 Feb 2002 11:44:03 -0600, Kyser Soze said:

>     I searched the net, there are references to rfc2015bis, but I can't seem
> to download it from anywhere. Where can it get it from?

This has been published ad rfc3156.

BTW, we need to release another draft:

draft-ietf-openpgp-rfc2440bis-03.txt
Expires Feb 2002

  Werner

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

Date: Thu, 14 Feb 2002 11:44:03 -0600
Subject: rfc2015bis
From: Kyser Soze <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

Hi,
    I searched the net, there are references to rfc2015bis, but I can't seem
to download it from anywhere. Where can it get it from?

Thanks
K.

To: "Cornel GLIGAN" <[email-masked]>
Cc: <[email-masked]>
Reply-To: <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode
Date: 14 Feb 2002 10:23:11 -0500
Lines: 95
Sender: [email-masked]

What, in particular, are you confused about?  (comment inline)

"Cornel GLIGAN" <[email-masked]> writes:

> Hi!
> 
> I tried to store a private key in OpenPGP format, using the CFB mode as
> described in http://www.imc.org/draft-ietf-openpgp-rfc2440bis :
> 
> 12.8. OpenPGP CFB mode
> 
>    OpenPGP does symmetric encryption using a variant of Cipher Feedback
>    Mode (CFB mode). This section describes the procedure it uses in
>    detail. This mode is what is used for Symmetrically Encrypted Data
>    Packets; the mechanism used for encrypting secret key material is
>    similar, but described in those sections above.
> 
>    In the description below, the value BS is the block size in octets
>    of the cipher. Most ciphers have a block size of 8 octets. The AES
>    and Twofish have a blocksize of 16 octets. Also note that the
>    description below assumes that the IV and CFB arrays start with an
>    index of 1 (unlike the C language, which assumes arrays start with a
>    zero index).
> 
>    OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
>    and prefixes the plaintext with BS+2 octets of random data, such
>    that octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
>    "resync" after encrypting those BS+2 octets.
> 
>    Thus, for an algorithm that has a block size of 8 octets (64 bits),
>    the IV is 10 octets long and octets 7 and 8 of the IV are the same
>    as octets 9 and 10. For an algorithm with a blocksize of 16 octets
>    (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
>    octets 15 and 16. Those extra two octets are an easy check for a
>    correct key.
> 
>    Step by step, here is the procedure:
> 
>    1.  The feedback register (FR) is set to the IV, which is all zeros.

What this really says is "The CFB feedback register, which acts at
the Initialization Vector as per the CFB FIPS, is initialized to all
zeros.

>    2.  FR is encrypted to produce FRE (FR Encrypted).  This is the
>        encryption of an all-zero value.
> 
>    3.  FRE is xored with the first BS octets of random data prefixed to
>        the plaintext to produce C[1] through C[BS], the first BS octets
>        of ciphertext.
> 
>    4.  FR is loaded with C[1] through C[BS].
> 
>    5.  FR is encrypted to produce FRE, the encryption of the first BS
>        octets of ciphertext.
> 
>    6.  The left two octets of FRE get xored with the next two octets of
>        data that were prefixed to the plaintext.  This produces C[BS+1]
>        and C[BS+2], the next two octets of ciphertext.
> 
>    7.  (The resync step) FR is loaded with C[3] through C[BS+2].
> 
>    8.  FR is encrypted to produce FRE.
> 
>    9.  FRE is xored with the first BS octets of the given plaintext,
>        now that we have finished encrypting the BS+2 octets of prefixed
>        data.  This produces C[BS+3] through C[BS+(BS+2)], the next BS
>        octets of ciphertext.
> 
>   10.  FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
>        for an 8-octet block).
> 
>   11.  FR is encrypted to produce FRE.
> 
>   12.  FRE is xored with the next BS octets of plaintext, to produce
>        the next BS octets of ciphertext.  These are loaded into FR and
>        the process is repeated until the plaintext is used up.
> 
> Is anybody who can explain to me in details how CFB works because I am
> very confused. I didn't understand anything after I read this text?

Well, it's explained pretty thoroughly above.  The step-by-step
instructions pretty much tell you what you need to know.  What exactly
are you confused about?

> Thank you in advance,
> Cornel Gligan-Ignatescu

-derek

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

Subject: Need some explanations about privarte key in OpenPGP format, CFB mode
Date: Thu, 14 Feb 2002 17:03:31 +0200
content-class: urn:content-classes:message
From: "Cornel GLIGAN" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi!

I tried to store a private key in OpenPGP format, using the CFB mode as
described in http://www.imc.org/draft-ietf-openpgp-rfc2440bis :

12.8. OpenPGP CFB mode

   OpenPGP does symmetric encryption using a variant of Cipher Feedback
   Mode (CFB mode). This section describes the procedure it uses in
   detail. This mode is what is used for Symmetrically Encrypted Data
   Packets; the mechanism used for encrypting secret key material is
   similar, but described in those sections above.

   In the description below, the value BS is the block size in octets
   of the cipher. Most ciphers have a block size of 8 octets. The AES
   and Twofish have a blocksize of 16 octets. Also note that the
   description below assumes that the IV and CFB arrays start with an
   index of 1 (unlike the C language, which assumes arrays start with a
   zero index).

   OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
   and prefixes the plaintext with BS+2 octets of random data, such
   that octets BS+1 and BS+2 match octets BS-1 and BS.  It does a CFB
   "resync" after encrypting those BS+2 octets.

   Thus, for an algorithm that has a block size of 8 octets (64 bits),
   the IV is 10 octets long and octets 7 and 8 of the IV are the same
   as octets 9 and 10. For an algorithm with a blocksize of 16 octets
   (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
   octets 15 and 16. Those extra two octets are an easy check for a
   correct key.

   Step by step, here is the procedure:

   1.  The feedback register (FR) is set to the IV, which is all zeros.

   2.  FR is encrypted to produce FRE (FR Encrypted).  This is the
       encryption of an all-zero value.

   3.  FRE is xored with the first BS octets of random data prefixed to
       the plaintext to produce C[1] through C[BS], the first BS octets
       of ciphertext.

   4.  FR is loaded with C[1] through C[BS].

   5.  FR is encrypted to produce FRE, the encryption of the first BS
       octets of ciphertext.

   6.  The left two octets of FRE get xored with the next two octets of
       data that were prefixed to the plaintext.  This produces C[BS+1]
       and C[BS+2], the next two octets of ciphertext.

   7.  (The resync step) FR is loaded with C[3] through C[BS+2].

   8.  FR is encrypted to produce FRE.

   9.  FRE is xored with the first BS octets of the given plaintext,
       now that we have finished encrypting the BS+2 octets of prefixed
       data.  This produces C[BS+3] through C[BS+(BS+2)], the next BS
       octets of ciphertext.

  10.  FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18
       for an 8-octet block).

  11.  FR is encrypted to produce FRE.

  12.  FRE is xored with the next BS octets of plaintext, to produce
       the next BS octets of ciphertext.  These are loaded into FR and
       the process is repeated until the plaintext is used up.

Is anybody who can explain to me in details how CFB works because I am
very confused. I didn't understand anything after I read this text?

Thank you in advance,

Cornel Gligan-Ignatescu

Date: Thu, 14 Feb 2002 09:23:22 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
Sender: [email-masked]

This is a PGP signed message sent according to RFC3156 [PGP/MIME]

--=_Turnpike_KjRzeFB6H4a84L4A=
Content-Type: text/plain;charset=us-ascii;format=flowed
Content-Transfer-Encoding: quoted-printable

On Wed, 13 Feb 2002, Jon Callas <[email-masked]> wrote:
>
>At 10:50 AM +0100 2/13/02, Thomas Roessler wrote:
>
>>>does not work with many mailing lists (that are configured to
>>>remove attachments),
>>
>>Such mailing lists are broken.
[]
>I must respectfully disagree with this assessment. People who maintain
>computer systems used by a number of people have a responsibility to
>protect that shared resource. Stopping attachments on mailing lists is not
>any more "broken" than putting up a firewall is.

Yes, but there is no reason why mailing-list software should regard=20
application/pgp-signature as an "attachment" when protecting=20
mailing-lists against misplaced or dangerous attachments.

(This sent PGP/MIME signed, just to see what happens on this list!)

--=20
Ian Bell                                           T U R N P I K E

--=_Turnpike_KjRzeFB6H4a84L4A=
Content-Type: application/pgp-signature
Content-Disposition: attachment; filename=signature.asc

--=_Turnpike_KjRzeFB6H4a84L4A=--

From: Marc Mutz <[email-masked]>
Organization: KDE
To: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Date: Wed, 13 Feb 2002 23:09:53 +0100
Sender: [email-masked]

On Wednesday 13 February 2002 20:09, Jon Callas wrote:
> At 10:50 AM +0100 2/13/02, Thomas Roessler wrote:
> >>does not work with many mailing lists (that are configured to
> >>remove attachments),
> >
> >Such mailing lists are broken.
<snip>
> I must respectfully disagree with this assessment. People who
> maintain computer systems used by a number of people have a
> responsibility to protect that shared resource. Stopping attachments
> on mailing lists is not any more "broken" than putting up a firewall
> is.
<snip>

A mailing list software isn't broken because it filters out attachments, 
but because it can't distinguish pgp/mime signed plain text messages 
from attachments. Not everything consisting of a mulitpart contains an 
attachment.
In fact, it would be totally legal for me to always send multipart 
messages, where, for instance, the first nested body part contains the 
text of the mail and the secons one my signature.

I can't speak for Thomas, but that's probably what he meant: That 
mailing list software needs to be able to distinguish between 
attachments and signed messages.

(Though I can understand why Thomas could find ml's which filter all 
"attachments" broken: You can't even forward a message to them (needs a 
multipart/mixed with nested message/rfc822 - eek)).

Marc

- -- 
Marc Mutz <[email-masked]>

Date: Wed, 13 Feb 2002 11:09:45 -0800
To: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
Sender: [email-masked]

At 10:50 AM +0100 2/13/02, Thomas Roessler wrote:

>>does not work with many mailing lists (that are configured to
>>remove attachments),
>
>Such mailing lists are broken.

As someone who runs a number of such "broken" mailing lists, I "broke" them
because I consider the security risk of my list being use to spread the
latest Outlook thingie to be much higher than the damage caused by breaking
them. It also prevents the inevitable newbie who sends a picture or movie
as an attachment, causing a dozen people to go over their mail quotas. My
message to my users is that if it's important, put it somewhere and provide
a URL. If it's important, I'll even provide disk space for it.

I must respectfully disagree with this assessment. People who maintain
computer systems used by a number of people have a responsibility to
protect that shared resource. Stopping attachments on mailing lists is not
any more "broken" than putting up a firewall is.

	Jon

Date: Wed, 13 Feb 2002 11:35:54 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
Sender: [email-masked]

On Wed, 13 Feb 2002, [email-masked] wrote:

>PGP/MIME is evil.

It is the only sensible way to properly secure an entire MIME message
with PGP.

In the case of signed messages, it allows the recipient to be sure that
the sender signed _all_ of the message, including attachments: it allows
arbitrarily complex messages to be signed successfully: in principle it
allows the sender to send a signed message to a group of people, some of
whom are not interested in PGP at all since the act of signing does not
pollute the actual message in any way.

Of course the last point depends on basic MIME compliance of users'
MUAs, and there are some common clients that treat multipart/unknown
differently to multipart/mixed :-((

In the case of encrypted messages, it allows the sender to be sure that
no-one intercepting the message can know if any attachments are present
and what types of attachments there are. It allows encryption of
arbitrarily complex messages.

>can not save message to disk and decrypt

the decryption is easy; but you will be left with a MIME message which
will need to be interpreted (by munpack etc) which is a barrier. Best
thing is to encourage PGP/MIME support in MUAs.

>and/or verify later outside MUA,

verify is easy if the message source is available.

>some virus checking software removes attachments,

some virus checking software removes/quarantines _all_ PGP encrypted
material.

>does not work with many mailing lists (that are configured to remove
>attachments),

Best thing is to encourage PGP/MIME support in mailing-lists.

[[ Actually, best thing is to encourage MIME support in mailing lists
(some lists append text material to the end of messages - which in the
case of multipart/* messages gets hidden by MIME MUAs!) ]]

>does not work with newsgroups.

have a look at alt.security.pgp and see how much PGP clear-signed
material is quoted/requoted etc Many messages consist mainly of
redundant fragments of quoted ascii-armor. This seems to me to be a
serious barrier to the routine use of PGP in newsgroups/mailing-lists.

How about the opposite contention:

"Clear-signed messages are evil"

    The ascii-armor is intrusive, so that the use of PGP is restricted
    to arenas where people will put up with such material "in their
    faces".

    The ascii-armor breaks the UseNet signature convention ("-- "
    becomes "- -- "): another barrier to routine use of PGP in UseNet.

    Clear signing is often done "behind the MUAs back" - leading to
    wrapping problems (how many users have to be told how to balance the
    wrapping action of their MUAs against the wrapping action of their
    PGP settings?)

    Clear-signing starts breaking when messages are not simple us-ascii
    and can't be used to properly secure messages with attachments.

    [As an example of the first case, I will clear sign this message via
    the clipboard. The signature will fail. because the '€' character
    will be signed by PGP as a Windows-1252 character (which is what the
    clipboard will contain), but my MUA will send it utf-8.]

In practice, clear-signing can be made to interoperate for simple us-
ascii messages, and PGP/MIME support is indeed patchy, but I hope
PGP/MIME support does grow because of its inherent advantages.

And if it doesn't, the "world's most popular clients" can still sign and
encrypt arbitrary MIME messages securely - they include seamless S/MIME
support.

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

To: "Cornel GLIGAN" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Need some explanations about privarte key in OpenPGP format
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 13 Feb 2002 11:01:55 +0100
Lines: 58
Sender: [email-masked]

On Wed, 13 Feb 2002 11:01:43 +0200, Cornel GLIGAN said:

> I have some questions about the last three paragraphs:
>    - Is the Initial Vector encrypted with the algorithm-specific
> portion?

The IV is a parameter to the CFB (Cipher Feed Back) encryption mode.

>    - Let's assume that I encrypt the algorithm-specific portion with
> IDEA. What it happens if the length of the algorithm-specific portion is
> not multiple of 8 (64 bit)? How can I fill the last block of the
> algorithm-specific portion to be an 8 byte (64 bit) block?

Padding is not required with CFB.  Don't hardwire the 64 bits; you
have to use the blocksize of the used cipher (e.g. 128 for AES).

You find more information about encryption modes in the standard
literature:

@Book{Men:96:HAC,
  author =	"Alfred J. Menezes and Paul van Oorschot and
		 Scott Vanstone",
  title =	"Handbook of Applied Cryptography",
  language =	"USenglish",
  publisher =	pub-CRC,
  address =	pub-CRC:adr,
  pages =	"xxvii + 780",
  year =	"1996",
  ISBN =	"0-8493-8523-7",
  keywords =	"cryptograpy",
}

There is an online resource for it, IIRC:
http://cacr.math.uwaterloo.ca/hac/  

or

@Book{Sch:96:AC,
  author =	"Bruce Schneier",
  title =	"Applied Cryptography",
  language =	"USenglish",
  edition =	"second",
  publisher =	pub-WIL,
  address =	pub-WIL:adr,
  pages =	"xxiii + 758",
  year =	"1996",
  ISBN =	"0-471-11709-9",
}

Hth,

  Werner

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

From: Marc Mutz <[email-masked]>
Organization: KDE
To: [email-masked], [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Date: Wed, 13 Feb 2002 10:53:17 +0100
Sender: [email-masked]

On Wednesday 13 February 2002 08:44, [email-masked] wrote:
> PGP/MIME is evil.

I disagree. pgp/miem isn't evil at all. It's the broken mail software 
out there that is the problem. And I restate that deprecating pgp/mime 
(or whatever this should lead to) will take the strain off of those 
"vendors" to fix their "products"...

> can not save message to disk and decrypt and/or verify later outside
> MUA,

For "decrypt", this is usually wrong, since exactly one part contains 
the encrypted data, the other only contains metadata, which is either 
superfluous or could be translated into options for the OpenPGP backend 
when decrypting...

So the real problem is signing:
The MUA could offer to convert the multipart/signed part to a 
file/detached sig pair of files on save.

Remember: You can't also view asian text/plain, wihc is usually encoded 
in base64, without the help of the MUA.

> some virus checking software removes attachments,

which is broken behaviour...

> does not work with many mailing lists (that are configured to remove
> attachments),

those ml's are broken (since multipart/signed is _not_ an attachment).

> does not work with web archives of mailing lists (for
> example http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html),

broken software used there, too.

> does not work with newsgroups.

Care to explain what's the problem there?

So why are all those packages broken? Because pgp/mime is so rare that 
they don't need to fix their stuff.

Marc

- -- 
Marc Mutz <[email-masked]>

Date: Wed, 13 Feb 2002 10:50:05 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

On 2002-02-13 09:44:05 +0200, [email-masked] wrote:

>can not save message to disk and decrypt and/or verify later 
>outside MUA,

Where do you get the expectation from that you can handle e-mail 
messages without software able to parse their format?

(And, BTW, you can certainly do all you desire outside the MUA. You 
just have to do some _very_ basic MIME parsing yourself.

>some virus checking software removes attachments,

Such virus checking software is broken.

>does not work with many mailing lists (that are configured to 
>remove attachments),

Such mailing lists are broken.

>does not work with web archives of mailing lists (for example 
>http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html),

That's not an example for PGP/MIME, but an example for mailing list 
archiving software not being able to cope with RFC announcements as 
sent out by the RFC editor.  This is another instance of broken 
software.  Nice try, though.

>does not work with newsgroups.

Why not?

-- 
Thomas Roessler                        <[email-masked]>

Date: Wed, 13 Feb 2002 10:45:11 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked], Will Price <[email-masked]>
Subject: Re: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh
Mail-Followup-To: [email-masked], Will Price <[email-masked]>
Sender: [email-masked]

On 2002-02-12 21:04:15 -0800, Carl Ellison wrote:

>One would think that a good standard wouldn't allow any such 
>variability.

One would also think that a good implementation won't crash when 
encountering standard compliant messages (it shouldn't even crash 
when receiving junk).

On 2002-02-12 21:24:54 -0800, Will Price wrote:

>In recent versions, we accomodated the Mutt way of encoding 
>PGP/MIME. I don't recall exactly which version that went into. The 
>current Eudora plugin version is 7.1.1 which is of course part of 
>PGP 7.1.1.

May I ask what particular detail of mutt's way of encoding had to be 
specifically accomodated?

I'm asking because _if_ mutt is violating the standard, this would 
be something I'd really like to see fixed.  (Yes, I am aware that 
earlier versions of mutt have possibly generated wrong micalg 
parameters, unless users paid attention.  This particular problem 
has, however, been fixed quite thoroughly.)

Writing with the "current mutt maintainer" hat,
-- 
Thomas Roessler                        <[email-masked]>

Subject: Need some explanations about privarte key in OpenPGP format
Date: Wed, 13 Feb 2002 11:01:43 +0200
content-class: urn:content-classes:message
From: "Cornel GLIGAN" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi!

I read and re-read the rfc 2440 and I am confused about few things.
(from http://www.imc.org/draft-ietf-openpgp-rfc2440bis)

...

5.5.3. Secret Key Packet Formats

   The Secret Key and Secret Subkey packets contain all the data of the
   Public Key and Public Subkey packets, with additional
   algorithm-specific secret key data appended, in encrypted form.

   The packet contains:

     - A Public Key or Public Subkey packet, as described above

     - One octet indicating string-to-key usage conventions.  0 
       indicates that the secret key data is not encrypted.  255
       indicates that a string-to-key specifier is being given.  Any
       other value is a symmetric-key encryption algorithm specifier.

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

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

So far so good.

     - [Optional] If secret data is encrypted, Initial Vector (IV) of
       the same length as the cipher's block size.

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

     - Two-octet checksum of the plaintext of the algorithm-specific
       portion (sum of all octets, mod 65536). This checksum is
       encrypted together with the algorithm- specific fields.

I have some questions about the last three paragraphs:
   - Is the Initial Vector encrypted with the algorithm-specific
portion?
   - In case that the Initial Vector is encrypted with the
algorithm-specific portion, does the plain text of the the
algorithm-specific portion, on that the checksum is made, include the
Initial vector or not?
   - Let's assume that I encrypt the algorithm-specific portion with
IDEA. What it happens if the length of the algorithm-specific portion is
not multiple of 8 (64 bit)? How can I fill the last block of the
algorithm-specific portion to be an 8 byte (64 bit) block?

Is anybody who can answer to my questions?

Thank you in advance,

Cornel Gligan-Ignatescu

Date: Wed, 13 Feb 2002 09:44:05 +0200
From: [email-masked]
Organization: disastry.NO.SPaM.NET
To: [email-masked]
Subject: Re: OpenPGP vs. OpenPGP/MIME
Sender: [email-masked]

PGP/MIME is evil.

can not save message to disk and decrypt and/or verify later outside MUA,
some virus checking software removes attachments,
does not work with many mailing lists (that are configured to remove attachments),
does not work with web archives of mailing lists (for example http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html),
does not work with newsgroups.

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)

Date: Tue, 12 Feb 2002 21:24:54 -0800
From: Will Price <[email-masked]>
Reply-To: [email-masked]
To: Carl Ellison <[email-masked]>
CC: [email-masked]
Subject: Re: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh
Sender: [email-masked]

Yes, it is because you're using an old version of PGP (6.5.8) which
was released in June of 1999 (in other words, many years ago).

In recent versions, we accomodated the Mutt way of encoding PGP/MIME.
I don't recall exactly which version that went into. The current
Eudora plugin version is 7.1.1 which is of course part of PGP 7.1.1.

Carl Ellison wrote:
> Does anyone know why PGP/MIME messages from Mutt consistently crash
> Eudora while those from Evolution or exmh don�t?
> 
> One would think that a good standard wouldn�t allow any such
> variability.

- -- Will

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

Date: Tue, 12 Feb 2002 21:04:15 -0800
To: Jon Callas <[email-masked]>, [email-masked]
From: Carl Ellison <[email-masked]>
Subject: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh
Sender: [email-masked]

Does anyone know why PGP/MIME messages from Mutt consistently crash
Eudora while those from Evolution or exmh don�t?

One would think that a good standard wouldn�t allow any such
variability.

 - Carl

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     http://world.std.com/~cme |
|    PGP: 08FF BA05 599B 49D2  23C6 6FFD 36BA D342                 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+

Date: Tue, 12 Feb 2002 08:28:59 +0100
From: Marc Mutz <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
To: Jon Callas <[email-masked]>, Thomas Roessler <[email-masked]>, Simon Josefsson <[email-masked]>
Cc: [email-masked]
Organization: KDE
Sender: [email-masked]

On Friday 25 January 2002 01:48, Jon Callas wrote:
> At 11:46 PM +0100 1/24/02, Thomas Roessler wrote:
> >On 2002-01-24 23:38:13 +0100, Simon Josefsson wrote:
> >>I agree with Jon's opinion.  PGP/MIME interoperability is bad.
> >
> >Really?  It certainly won't get worse than MIME interoperability in
> >general.
>
> That is precisely my point. It's not a PGP problem, it's a MIME
> problem. Which means that PGP/MIME is a good thing in theory, but not
> in practice. Once MIME interoperability starts working, more power to
> it.
<snip>

So we should prolong the lifespan of a broken design (just think i18n) 
just because the mime interop of some widely deployed mail software is 
less than optimal?
What about encouraging people to implement PGP/MIME and see its wide 
deployment force others to fix their stuff?

Just the opinion of someone implementing of a MIME parser: Plain pgp is 
ugly as hell, PGP/MIME resp. rfc1847 sucks much less.

Marc

Date: Tue, 12 Feb 2002 08:19:41 +0100
From: Marc Mutz <[email-masked]>
Subject: Re: OpenPGP vs. OpenPGP/MIME
To: [email-masked], [email-masked]
Organization: KDE
Sender: [email-masked]

On Friday 25 January 2002 18:07, [email-masked] wrote:
<snip>
> Re compatibility: I use (don't laugh) Lotus Notes 4.5 at work, and it
> is totally different from normal email.  It has a gateway to
> translate internet mail into its own document format.
> Mime attachments are turned into embedded documents at the end.

I guess labelling this as re: compatibility is stretching the sense at 
best. If Notes doesn't handle MIME, what's the point in arguing that 
PGP/MIME is bad for interop and citing Notes as an example.

> What would it do to PGP/MIME or any other use of MIME that requires
> knowing the =meaning= of the parts?  I doubt it would work.

As long as MIME parsers follow the rule to treat unknown multipart/* as 
multipart/mixed, no problem would arise. It's the broken mail software 
that causes problems here.

> If the main point of PGP/MIME was to get mail readers to
> transparantly handle PGP, it obviously has problems for readers that
> =don't=.  And mail readers could just as easily be built to know
> about the ===BEGIN...=== lines.

- From the point of view of a MIME parser implementor, old-fashioned pgp 
messages are pure horror. While you can trust that with PGP/MIME signed 
and/or encrypted body parts are correctly labelled, for plain PGP 
messages you have to scan all possible body parts (ie. at least those 
labelled text/plain) to check for pgp message blocks. Worse: Your nice 
DOM that you built around the concepts of rfc(2)822, rfc2015, rfc204x 
and friends is totally wrecked when you have to deal with body parts 
embedded in body parts other that multipart/* or message/*. The same 
issue arises with uuencoded messages.

You have to introduce fake body parts when you want to actually keep 
your DOM. Don't start to think about those broken flat message digests 
with multiple pgp message blocks in them :-(

OTOH, letting aside the cryptographic functions, implementing rfc1847 is 
dead easy.

> Just to throw something out, how about ASCII-Armored PGP for the body
> of the message, and MIME attachments for multiple (paralell)
> signatures?  For that matter, they wouldn't need MIME, just another
> ASCII Armor'ed block following the main one.

See above for why this is a bad idea.

Marc