Subject: RFC 4880 on OpenPGP Message Format

From: [email-masked]
Date: Fri, 2 Nov 2007 18:29:56 -0700 (PDT)

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

        RFC 4880

        Title:      OpenPGP Message Format 
        Author:     J. Callas, L. Donnerhacke,
                    H. Finney, D. Shaw,
                    R. Thayer
        Status:     Standards Track
        Date:       November 2007
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],  [email-masked], 
                    [email-masked]
        Pages:      90
        Characters: 203706
        Obsoletes:  RFC1991, RFC2440
        See-Also:   

        I-D Tag:    draft-ietf-openpgp-rfc2440bis-22.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4880.txt

This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format.  It is not a step-by-step cookbook for writing an
application.  It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network.  It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.

OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures.  This document specifies the message formats used in
OpenPGP.  [STANDARDS TRACK]

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

This is now a Proposed Standard Protocol.

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

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

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

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

---

From: Ian G <[email-masked]>
Date: Sat, 03 Nov 2007 14:40:13 +0100

>         URL:        http://www.rfc-editor.org/rfc/rfc4880.txt

YeeHaa!  Congratulations, Jon and the team!

iang

---

From: "Vlad \"SATtva\" Miller" <[email-masked]>
Date: Sat, 03 Nov 2007 21:18:36 +0600

Ian G wrote on 03.11.2007 19:40:
>>         Title:      OpenPGP Message Format         Author:     J.
>> Callas, L. Donnerhacke,
>>                     H. Finney, D. Shaw,
>>                     R. Thayer
>>         Status:     Standards Track
>>         Date:       November 2007
>>         Mailbox:    [email-masked],                    
>> [email-masked],                     [email-masked], 
>> [email-masked],                     [email-masked]
> 

Subscribing to Ian's congratulations. That was indeed a great job!

-- 
SATtva | security consulting
www.vladmiller.info | www.pgpru.com

---

From: Stephan Beyer <[email-masked]>
Date: Sat, 3 Nov 2007 16:37:52 +0100

> >>                 RFC 4880

Is it an accident that the RFC number is 4880 = 2440*2? ;-)

Congratulations. ;-)

-- 
Stephan Beyer <[email-masked]>, PGP 0x6EDDD207FCC5040F

---

From: David Shaw <[email-masked]>
Date: Sat, 3 Nov 2007 11:41:41 -0400

>         Author:     J. Callas, L. Donnerhacke,

Thank you, everyone.  It's taken a while, but I think we have a great
new RFC here.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Sat, 3 Nov 2007 16:56:38 +0100

>         Author:     J. Callas, L. Donnerhacke,

Congratulations!

What is the next step for OpenPGP? V5 key format? Stream ciphers?

-- 
Daniel

---

From: Jon Callas <[email-masked]>
Date: Sun, 4 Nov 2007 18:23:06 -0800

On Nov 3, 2007, at 8:56 AM, Daniel A. Nagy wrote:

> * PGP Signed by an unknown key
>
> * Unknown Key
> * 0x5016720C

---

From: Jon Callas <[email-masked]>
Date: Sun, 4 Nov 2007 18:23:46 -0800

Congratulations to everyone!

	Jon

---

From: Werner Koch <[email-masked]>
Date: Mon, 05 Nov 2007 10:08:21 +0100

> Congratulations to everyone!

You did a very good job as editor and contributor over the last 10
years.  Congratulations to veryone.

So now that we have 4880 out, is it now again the time to think about
interop tests and draft status?

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 05 Nov 2007 09:19:55 -0500

> Is it an accident that the RFC number is 4880 = 2440*2? ;-)

<monotone-voice>
The RFC Editor does not reserve RFC numbers.
</monotone-voice>

> Congratulations. ;-)

Indeed.  Good work to everyone involved.  I'd like to thank each
and every one of you for making RFC4880 such a great achievement.

> Stephan Beyer <[email-masked]>, PGP 0x6EDDD207FCC5040F

-derek

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

---

From: Derek Atkins <[email-masked]>
Date: Mon, 05 Nov 2007 09:33:12 -0500

> interop tests and draft status?

Very good questions.  We have a number of items that have come up
before and been tabled.  This work includes (but is not limited to):

  * PFS
  * V5 keys
  * Plausible Deniability
  * Additional Ciphers
  * Updates to PGP/MIME

But before we decide to take on more work, there are a number of
questions we have to ask ourselves.  The first question is: what's in
our charter and would we need to be rechartered to take on this
additional work?  The second question is: are there enough people
interested in doing the work (editors, reviewers, implementors) to
warrant remaining open?  Third: Can we get AD approval to continue?

By my reading of the charter, all these work items could be in scope
if there's enough interest in it.  So I don't think we need to
recharter (yet we DO need to submit new milestones based on whatever
work we attempt to take on).  However questions 2 and 3 still remain.
So now is the time to speak up and submit your drafts so we can show
the AD that there's enough interest to continue working, and that we
have a plan.

As for interop and draft status....  I think if someone wants to host
an OpenPGP implementor get-together that would be just fine.  To make
it an official "interoperability" event we'd need some sort of test
plan, and someone to write up all the results from all the tests.
Taking 2440 to DRAFT would require at last 6 months, plus this test
plan that shows valid interop testing on every feature in 4880.  Any
volunteers?

-derek, your humble wg-chair.

---

From: Werner Koch <[email-masked]>
Date: Mon, 05 Nov 2007 16:09:00 +0100

> the AD that there's enough interest to continue working, and that we

I am pretty sure that Ben Laurie will submit a new PFS draft and I would
be happy to implement it in GnuPG.  David Shaw has a draft for a
Camellia.

With the recent NIST announcements I consider work on ECDSA important
and a task the WG should take up now.

> plan that shows valid interop testing on every feature in 4880.  Any

You mean taking 4880 to DRAFT?

Shalom-Salam,

   Werner

---

From: Ben Laurie <[email-masked]>
Date: Mon, 05 Nov 2007 17:21:40 +0000

Werner Koch wrote:
> be happy to implement it in GnuPG.

I would be up for that, indeed.

> David Shaw has a draft for a
> Camellia.
> 

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

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: David Shaw <[email-masked]>
Date: Mon, 5 Nov 2007 13:17:16 -0500

> be happy to implement it in GnuPG.  David Shaw has a draft for a

I just now sent the Camellia draft in to the IETF.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Mon, 5 Nov 2007 21:35:00 +0100

On Mon, Nov 05, 2007 at 09:33:12AM -0500, Derek Atkins wrote:
> The second question is: are there enough people
> warrant remaining open?

Currently, my team is working on implementing a system that aims at some
level of OpenPGP interoperability. Because of platform limitations, full
interoperability with RFC4880 is not practical. In particular, we are
implementing a symmetrically encrypted data packet format where encryption
is done using a stream cipher (namely: ArcFour), yet following the standard
as closely as possible. The reason is that the target platform (low-end mobile
phones) may perform really poorly using a block cipher.

However, it would be nice if the next version of OpenPGP would be
interoperable with our system even on the encryption level. I shall send the
specifications to this list as soon as they are properly written up.

Regards,

-- 
Daniel

---

From: Derek Atkins <[email-masked]>
Date: Tue, 06 Nov 2007 08:27:12 -0500

> and a task the WG should take up now.

Yes, ECDSA would be yet another cipher draft.  If the WG wants to
standardize on that I think it falls under our charter.

> You mean taking 4880 to DRAFT?

Umm.. yea.  *looks sheepish*.  I guess I've been writing "2440" for
so long that it's going to take time to get used to saying 4880.  :-D

-derek

---

From: Derek Atkins <[email-masked]>
Date: Tue, 06 Nov 2007 08:36:23 -0500

> phones) may perform really poorly using a block cipher.

Have you actually tried using a block cipher like AES, or are you
basing this "may perform really poorly" only on guesswork?
Seriously...  AES was specifically designed to work well in small
systems like cell phones, have you actually tried it?

I'd also suspect that any Public Key operations would take much more
time, although it sounds like you aren't using that part of the spec
at all.

> specifications to this list as soon as they are properly written up.

Go ahead, but we've discussed ArcFour previously and decided it was
too dangerous and didn't fit into the CFB cipher context modes.  But
please send in your specs so we can see them and others on the list
can give their opinion.

-derek

---

From: Werner Koch <[email-masked]>
Date: Tue, 06 Nov 2007 15:23:29 +0100

> so long that it's going to take time to get used to saying 4880.  :-D

I was asking myself whether there are new IETF procedures to get
something into draft status ;-).

Shalom-Salam,

   Werner

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 6 Nov 2007 15:28:59 +0100

Hello

> systems like cell phones, have you actually tried it?

Yes, I have tried AES. It is still almost an order of magnitude slower than
RC4.
 
> time, although it sounds like you aren't using that part of the spec

Exactly.

> too dangerous and didn't fit into the CFB cipher context modes. 

I don't think it is dangerous if done properly, but it definitely does not
fit into CFB cipher condext mode (which, by the way, is another thing that
is worth considering for retirement).

Actually, I am leaning toward introducing a general stream cipher mode of
which block ciphers operated in CTR mode are a special case. CTR has much
nicer theoretical properties than CFB in the sense that security assumptions
for block ciphers imply certain security properties for the stream cipher.

> But

Sure.

Cheers,

-- 
Daniel

---

From: Derek Atkins <[email-masked]>
Date: Tue, 06 Nov 2007 09:47:56 -0500

> Yes, I have tried AES. It is still almost an order of magnitude slower than

That's an unfair comparrison.  AES is going to be slower than RC4 on
all hardware.  That's not the question you need to be asking.  The
question is whether AES is "fast enough" for your application on your
hardware.  I.e., can AES give you enough throughput on your hardware
to get your data?

> is worth considering for retirement).

The problem is that the vast majority of developers don't know how to
use it properly, and it's VERY easy to get wrong.  There's just too
many ways to shoot yourself in the foot, such as reusing keystream,
or not thowing away the beginning of the keystream.

I'd leave it up to the WG about whether we want to retire CFB mode,
I don't have a feel for any consensus on that.

-derek

---

From: [email-masked] (Daniel A. Nagy)
Date: Tue, 6 Nov 2007 16:16:02 +0100

> hardware.  I.e., can AES give you enough throughput on your hardware

No, it is not. A single block operation takes almost half a second on
NOKIA 3410, which means that encrypting a simple text message takes seconds,
which is not nice from a user experience PoV.
 
> or not thowing away the beginning of the keystream.

It should be well defined in the spec and it will be.

> I don't have a feel for any consensus on that.

I think that at least it would be nice to have an alternative.

-- 
Daniel

---

From: Ian G <[email-masked]>
Date: Tue, 06 Nov 2007 16:18:34 +0100

> is worth considering for retirement).

<broken record>

Yes please!

</scratch-kadunk-scratch-kadunk>

> for block ciphers imply certain security properties for the stream cipher.

OpenPGP has these built in application notions that inform 
it on what is "in" and what is "out" ... which are basically 
historical and probably due to be updated.  E.g., ascii 
armouring is "in" and s/mime is "out".

For all those (historical) reasons it probably makes sense 
to sit down around a round table and craft a future 
architecture of what is "base" and what is "extension".  I'd 
see stream modes as being "extensions".

(leaving the question of whether the base includes even a 
block cipher mode to the round table ;)

So I suppose I'm heading over to one of these "big questions":

supposing that we do proceed to do a next generation, are we 
planning on a "big" change over a 10 year cycle, or are we 
planning on a "small" change with only modest fix-ups?

(I'm hoping here that we don't up with a "small" change 
taking 10 years .....)

iang

---

From: David Shaw <[email-masked]>
Date: Tue, 6 Nov 2007 11:13:00 -0500

> I don't have a feel for any consensus on that.

I don't have particularly strong feelings about CFB mode itself, but I
do think it would be nice to move to a more standard mode, rather than
our own OpenPGP CFB mode.

It's not a big deal, and I don't see any particular need to change it
quickly as I don't think OpenPGP CFB is insecure or somehow bad.  The
issue is more that OpenPGP CFB needs to be repeatedly explained ("Hey,
why does this thing use its own cipher mode?  Can you prove it is
secure?")

If we do head down that road, I'd suggest doing it as part of
something else, like V5 keys.  It's not really important enough to
justify doing by itself, and doing it as part of V5 helps prevent
compatibility problems, as there would be no mixture of
implementations some with regular CFB and some with OpenPGP CFB: a V5
key would mean regular CFB from the start.

(Substitute your favorite (but standard) mode for "regular CFB" in the
above if you like.)

David

---

From: Jon Callas <[email-masked]>
Date: Tue, 6 Nov 2007 10:46:49 -0800

When we started the working group, there were many things that I  
thought would be great to "fix." That included OpenPGP CFB. These  
days, I care a lot less.

The reason is that while the OpenPGP CFB is eccentric, it's not  
wrong. CFB itself has a parallelism with CBC. Just about every thing  
you can say about CFB has a parallel thing you can say about CBC. If  
you want real change, you'd want to do something else, which has a  
different set of issues.

If we put in some new mode, the implementations will have to support  
them both for years. If a major or quasi-major implementation balks,  
then that time increases. That increases code size and complexity,  
and that decreases security.

Unless a mode change is folded in with a compelling other reason, I  
don't see it's worth the bother. Every system has warts. This is not  
a large one.

	Jon

---

From: David Shaw <[email-masked]>
Date: Tue, 6 Nov 2007 14:12:00 -0500

> don't see it's worth the bother. Every system has warts. This is not  

Exactly.  That's why I say that *if* we do this, we should do it as
part of V5 keys.  It's not important enough to do on its own.

I should add that I'm not exactly eager to go down the V5 keys path
without a good reason either.  It would be nice to tweak some V4
details (fingerprints being SHA-1), but I don't think those details
are compelling enough to justify a V5 by themselves.

David

---

From: Jon Callas <[email-masked]>
Date: Tue, 6 Nov 2007 15:05:38 -0800

> are compelling enough to justify a V5 by themselves.

We also had a proposal at one time for a fingerprint that would be of  
the form:

<alg>:<hash>

So all existing fingerprints would be 2:<hash>, and a SHA-256 version  
of same would be 8:<hash>.

I love this idea. The best thing about it is that it would not need  
to change, even after AHS. I think someone ought to write up an ID  
for Algorithm-Agile OpenPGP Key Fingerprints or some other  
appropriate name.

	Jon

---

From: "Marko Kreen" <[email-masked]>
Date: Wed, 7 Nov 2007 10:22:03 +0200

> are compelling enough to justify a V5 by themselves.

Agreed.  But instead of V5 keys maybe this should be tied to
stream ciphers?  So instead of _just_ a new mode for block
ciphers, there should be spec for stream ciphers and there could
be block ciphers in counter mode added.

So now the question becomes - are stream ciphers worth it?

-- 
marko

---

From: Werner Koch <[email-masked]>
Date: Wed, 07 Nov 2007 10:18:56 +0100

On Tue,  6 Nov 2007 16:18, [email-masked] said:

> supposing that we do proceed to do a next generation, are we planning
> on a "big" change over a 10 year cycle, or are we planning on a
> "small" change with only modest fix-ups?

We should sync us with the NIST hash competition so that a new version
would be due not before 4 years from now.

Although SHA-3 will be a drop-in replacement for SHA-2, my understanding
is that there will be suggestions on new usage modes like randomization
of hashing.  That requires substantial changes to OpenPGP.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Wed, 07 Nov 2007 10:11:43 +0100

> them both for years. If a major or quasi-major implementation balks,  

We are often specifying things in the context that some messages must be
kept confidential for decades.  Thus an implementation needs to support
if for ore than just a few years.  Even after 20 years people might want
to look at archived emails.  Agreed, the public key might not be anymore
safe at that time but I doubt that anyone will go for cracking a key
just for reading some old mails.

Tying a new cipher mode to the key version (v5) is not a good idea
because OpenPGP is also used for symmetric only encryption.  Thus if we
want to move to a new (not patent encumbered) mode it should be done
when defining a new MDC format.

Shalom-Salam,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Wed, 07 Nov 2007 08:22:56 -0500

> which is not nice from a user experience PoV.

Huh!  Are you sure you're using an AES implementation that's optimized
for your platform?  You can get an order-of-magnitude improvement by
optimizing the code (or running an assembler version).  Obviously there
are time/space tradeoffs to be made as well, but I find it hard to
believe that it takes 500ms for a single block operation even in an
optimized implementation.

-derek

---

From: Ian G <[email-masked]>
Date: Wed, 07 Nov 2007 15:39:05 +0100

> optimized implementation.

Dani probably knows what he is doing.  The mobile phone is a 
particularly difficult device, and unlike ordinary PC 
platforms, performance is a very big issue.

Also, the security model is somewhat different to the normal 
OpenPGP world.  Dani's security model is more about 
transactional security and less about being able to crack 
the encryption.  OpenPGP's security model derives from the 
80s and early 90s when every radical in the world was 
fighting governments with acres of cryptocrunching big iron. 
  Quite different worlds and quite different viewpoints.

(OK, I might know a little more than said here because I've 
talked to Dani at times about it, and there are lots of 
"gotchas".  From my understanding of payment systems and the 
like, he doesn't need to guarantee 100% that the message is 
unreadable, because there are too many other end-node 
threats for that to be valuable.)

That said, it is a good question for the OpenPGP community: 
  do we accept a weaker algorithm for edge cases?  The 
answer is historically, "maybe," IMHO.  We, as a community, 
have not moved aggressively in the past to repair every 
weakness, which indicates that our world of users is 
dominated by "good enough" not "perfect".

Long discussion....

iang

---

From: Ian G <[email-masked]>
Date: Wed, 07 Nov 2007 15:47:10 +0100

> of hashing.  That requires substantial changes to OpenPGP.

Yes, this is where I was heading with my question on big 
cycle versus small.  When OpenPGP started as a working 
group, we knew X as a community about crypto.  That X was 
some large delta away from what PRZ and his large team of 
helpers know 5-10 years earlier.  Call their knowledge V.

Now, 10 years later again, we know X plus another big delta, 
call it Y.  The whole issue of HMACs is post-OpenPGP's 
inception, and block encryption algorithm design process has 
been radicalised by the AES competition.  Fixing the message 
digest "weakness" actually has more ramifications than just 
changing the current one.  Threat models and security models 
are now informed by actual heavy experience.

Etc etc.  I wonder if the answer is that we should bite the 
bullet and say:  let's plan on another 10 year cycle.  That 
is, let's spend an entire year just discussing what the next 
generation OpenPGP should look like.

Alternatively, we might fall in the trap of trying to 
squeeze too many short term fixes in and still take a decade.

iang

---

From: Jon Callas <[email-masked]>
Date: Wed, 7 Nov 2007 11:14:21 -0800

> of hashing.  That requires substantial changes to OpenPGP.

That is not my understanding.

There are people who want that. But there are people who point out  
that if you require something like salted hashing for a hash  
function, then it loses its most valuable facet -- that it is a hash  
function. The latter group are all of us who have to implement these  
in real world systems.

As I understand the consensus, there is value in having people define  
modes of operation for hash functions like salted hashes, that's  
good. And defining how you'd use a salted hash into a signature might  
be good.

But requiring a mode of operation would be like creating CFB along  
with AES. Modes of operation can be used with *any* underlying function.

We can, and should separate any mode of operation from the other  
discussion. The whole point of salted hashing, for example, is to  
compensate for broken hash functions, and making a hash function that  
works is a better solution.

If 4880 were still open, I'd drop in constants SHA-3 for all four of  
its lengths, and we'd be done, just as we were for AES. Now, that  
would be a short RFC.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Thu, 08 Nov 2007 08:40:56 +0100

> function, then it loses its most valuable facet -- that it is a hash  

My point is that we can't know for sure right now, so better lets wait
some time and evaluate the situation again.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Thu, 8 Nov 2007 00:52:27 -0800

> some time and evaluate the situation again.

Okay, then we're in violent agreement.

	Jon