Subject: Camellia for OpenPGP

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 23 Apr 2007 14:42:20 +0900

Hi. I'd like to propose a new id number of symmetric key algorithms
for Camellia that is known as RFC3657.

Camellia source code is available as GPL, BSD Lisence, Mozilla Public
License and OpenSSL License. And it is included in OpenSSL,
ipsec-tool, Linux kernel, Firefox trunk and NSS trunk.  Also, there
are a Camellia patch for GNUPG. Camellia is moving to main stream
cipher of FLOSS community.

Camellia is more popular than any other symmetric key algorithms in
rfc2440bis except AES.

Proposal is as below;

Thanks.

---section 9.2---
9.2. Symmetric Key Algorithms

        ID           Algorithm
        --           ---------
        0          - Plaintext or unencrypted data
        1          - IDEA [IDEA]
        2          - TripleDES (DES-EDE, [SCHNEIER] [HAC] -
                     168 bit key derived from 192)
        3          - CAST5 (128 bit key, as per RFC 2144)
        4          - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
        5          - Reserved
        6          - Reserved
        7          - AES with 128-bit key [AES]
        8          - AES with 192-bit key
        9          - AES with 256-bit key
        10         - Twofish with 256-bit key [TWOFISH]
        11         - Camellia with 256-bit key [RFC3657]
        100 to 110 - Private/Experimental algorithm.

---section 13.9---

13.9. OpenPGP CFB mode

    ...

    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, 
    Twofish and Camellia have a block size 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).

---section 16----

16. References (Normative)
....

    [RFC3657]    S. Moriai and A. Kato, "Use of the Camellia Encryption
                 Algorithm in Cryptographic Message Syntax (CMS)", RFC
                 3657.
----

---
Hironobu SUZUKI <hironobu at h2np dot net><hironobu at fsij dot org>
Hironobu SUZUKI Office, Inc. / FSIJ / WCLSCAN / OpenPKSD
Tokyo, Japan.
http://h2np.net

---

From: [email-masked] (Daniel A. Nagy)
Date: Mon, 23 Apr 2007 10:30:39 +0200

While we are at it, I have an application, where using block ciphers is
prohibitively slow and thus I use ArcFour (RC4) in symmetrically encrypted
data packets in the following way:

The key (either from s2k specifiers or from asymmetrically encrypted
packets) is concatenated with an 8-byte salt at the beginning of the
encrypted packet, the result is hashed using RIPEMD-128 and the resulting
128 bits are used as the ArcFour key encrypting the data. The first 256
bytes are discarded from the key stream. The same format is used in both
MDC-protected data packets and in non-integrity-protected data packets, the
sole difference being the MDC packet at the end of the integrity-protected
kind.

Otherwise, the application is RFC2440-compliant. Right now, I use an
experimental/private number for this symmetric encryption algorithm, but
maybe it would make sense to include it in the standard as something
optional to allow interoperability with other OpenPGP applications.
I also have a patch for GnuPG.

-- 
Daniel

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 23 Apr 2007 18:01:56 +0900

Hi, RC4 is well-known as an insecure cipher algorithm today.  I hope
that you read some papers about RC4 that are linked this web site.

   http://www.wisdom.weizmann.ac.il/~itsik/RC4/rc4.html

Especially, I recommend you read this paper.

  Weaknesses in the Key Scheduling Algorithm of RC4, Fluhrer, Mantin
  and Shamir, SAC 2001

Thanks,

---

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Apr 2007 11:33:00 +0200

> for Camellia that is known as RFC3657.

The WG should be aware that Camellia is patented.  An announcement
related to this exists:

http://www.ntt.co.jp/news/news01e/0104/010417.html

The license (if one can speak of a license at all, the page is not
clear that it is a license agreement) do not appear to be perpetual,
and it seem to restrict implementation to be unmodified Camellia.

The IETF IPR page do not seem to contain anything related to RFC 3657,
RFC 3713, or RFC 4132 which seems to be a mistake.  Unless someone can
tell me more about why this is the case, I'll send a third-party
notification shortly.

/Simon

---

From: [email-masked] (Daniel A. Nagy)
Date: Mon, 23 Apr 2007 11:52:20 +0200

On Mon, Apr 23, 2007 at 06:01:56PM +0900, Hironobu SUZUKI wrote:
> 
> Hi, RC4 is well-known as an insecure cipher algorithm today. 

It has known weaknesses, but I would not call it insecure. It must be used
with care, but it can still be relied upon if attention is paid to details.

> I hope

Yes, of course.

>   Weaknesses in the Key Scheduling Algorithm of RC4, Fluhrer, Mantin

That's right, hence the hashing and discarding the first 256 bytes from the
keystream, as described in my previous post.

Regards,

-- 
Daniel

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 23 Apr 2007 19:51:34 +0900

> and it seem to restrict implementation to be unmodified Camellia.

I guess their intention is to protect their hardware version of
Camellia implementation because they build not only software version
but also hardware version of Camellia.

As far as I know, Japanese version of patent law is very limited on
Software.  It is very different from US patent law situation.  NTT is
a Japanese company and NTT speaks in Japanese context.

We can get GPL, BSD License and others version of Camellia source code
that are provided by NTT that is Camellia's patenter.  This Camellia
code is well tuned up and runs very fast. It is not sort of sample
code.

  http://info.isl.ntt.co.jp/crypt/eng/camellia/source.html

If we can NOT use, copy, modify, and redistribute it, that is a sort
of license violation against GPL by the original licenser.  I believe
NTT knows what GPL is.

Regards,

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 23 Apr 2007 19:59:15 +0900

Hi,

>  That's right, hence the hashing and discarding the first 256 bytes
> from the keystream, as described in my previous post.

I really appreciate if I could read a paper(s) about analysis of this
technique.

Regards,

---

---

From: Ian G <[email-masked]>
Date: Mon, 23 Apr 2007 13:51:22 +0200

> a Japanese company and NTT speaks in Japanese context.

Hmmm...  I think we would need a patent lawyer to opine on
what the ramifications are.  Patent law is full of all sorts
of tricks and turns, it isn't like "ordinary" law where you
can use common sense.

I personally would be skeptical.  Unless there is a clear
and open licence for anyone to use that algorithm, then
saying it is patented is probably the best description.

The problem is that if we start using this algorithm, and it
becomes popular, then NTT can change their minds and start
to go after people.  Unless they have granted a clear
perpetual licence, this is something that is hard to protect
against.  The guys at NTT may be really nice guys, but they
may not be there in 10 years time.

The problems that were had with IDEA seem to point us to
non-patented algorithms, simply because it is more certain.

> of license violation against GPL by the original licenser.  I believe

The licence to the source code is orthogonal to the patent
situation.  The source code is not the invention.

To some extent, they tried to address this issue in GPL v3,
I have no idea how successfully...

iang

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 23 Apr 2007 23:12:01 +0900

> of tricks and turns, it isn't like "ordinary" law where you

Yes, I know it, JPEG, GIF, SCO things ... sigh, that's American way ;-<

> The problem is that if we start using this algorithm, and it becomes
> popular, then NTT can change their minds and start to go after
> people.

NTT don't need to that as well as IBM don't need to that.

NTT is huge telephone company as well as old-"AT&T".  There are only
one NTT's concerning thing that they protect themself.

I think their motivation is "standardization", not for sale patents.

NTT is #1 hardware buyer in Japan. They buy equipments multi-billion
dollars in every year.  Another patenter of Camellia is Mitsubishi
Electric Corporation. Mitsubishi supplies security and military
systems to the goverment of Japan.  Fair "standardization", I mean not
only American way but also more neutral way of standardization, is
required for it.

AES is defined as FIPS (Federal Information blah, blah, blah),
essentially no international standard. There is a some risk when US
start to export restriction.  They need to make risk hedge by their
own way.

They push Camellia to ISO and it become ISO/IEC18033.  They submited
it NESSIE in EU and CRYPTREC in Japan.  RFCs also.  This tactics
inherits from KASUMI by Mitsubshi for 3GPP cipher.

That's my opinion.

So, please let me know what we should get from NTT?

Fair use statement? (Sorry, I don't know what it is ;-)

If you show something that we need to get, I'll try to find it.

> situation.  The source code is not the invention.

That it correct. Potentially, that problem exists not only Camellia
code but also any code that we wrote.

>  To some extent, they tried to address this issue in GPL v3, I have
> no idea how successfully...

I think they are easy to move from GPLv2 to GPLv3 when GPLv3 is
appeared because they have nothing to lose about it.  And it will be
clear what they want to do.

At the last of the 5th International GPLv3 Conference at Tokyo,
Kanda-san who is a project leader of Camellia in NTT spoke about NTT
and Camellia team's contribution/efforts to FLOSS community.

If you want to know about what he talked, I'd like to ask Kanda-san
that he talk it again at rump session of CRYPTO2008.

Regards,

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Mon, 23 Apr 2007 23:21:25 +0900

> and Camellia team's contribution/efforts to FLOSS community.

Oops, sorry. URLs are below;

5th International GPLv3 Conference web site

URL http://gplv3.fsij.org/

Masayuki Kanda's presentation

http://gplv3.fsij.org/trac.cgi/attachment/wiki/Japanese/gpl20061122_v0.pdf?format=raw

---

---

From: Florian Weimer <[email-masked]>
Date: Mon, 23 Apr 2007 17:14:31 +0200

> one NTT's concerning thing that they protect themself.

Nowadays, AT&T patents are used in active, non-defensive litigation.
The problem is that companies change much faster than deployments
these days.

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 24 Apr 2007 00:40:27 +0900

>  Nowadays, AT&T patents are used in active, non-defensive
> litigation.  The problem is that companies change much faster than
> deployments these days.

US's pro-patent policy has been corrupted the world. US companies
descended Japanese companies many times by this policy. Nowaday,
Japanses company behave overreacting protection in patents. That's
true ;-<

I don't understand why so many people ignore GPL/BSD license source
code by patenter of Camellia.  It is same situation of some device
drivers in Linx kernel. What's different?

Regards,

---

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Apr 2007 09:38:15 -0700

Personally, I don't think that Camellia's (or any other symmetric  
cipher's) patent status matters for us. An implementer can safely  
ignore an algorithm with little impact.

	Jon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Apr 2007 19:11:49 +0200

> ignore an algorithm with little impact.

The proposal was to make Camellia a normative reference in the base
OpenPGP document.  I see a problem with that.

Having the reference be informational would be OK, as long as there
are no requirements to implement it.  Only then can implementers that
wish to conform to the base spec safely ignore Camellia.

Given what people have said about NTT's intentions in this area, it
may be worthwhile to pursue and ask them to provide a better patent
license that would guarantee that Camellia can be used freely.  But
that is a separate problem, and not related to OpenPGP.  Until there
is a good license available, I would be against anything more than a
informational reference in the OpenPGP document.

/Simon

---

From: Mike Markowitz <[email-masked]>
Date: Mon, 23 Apr 2007 13:33:00 -0500

>informational reference in the OpenPGP document.

In this regard it might be worth noting this:

http://www.ntt.co.jp/news/news06e/0604/060413a.html

"Hereafter, however, in accordance with an agreement between NTT and 
Mitsubishi,
Camellia essential patents can be used at no charge by any Camellia 
user without
concluding such royalty-free licensing agreement hereafter."

So it appears that you don't need a license, somewhat like the situation
with IBM and DES.

-mjm

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Apr 2007 20:46:19 +0200

> So it appears that you don't need a license, somewhat like the situation

Nice!  Is there a real patent license available, rather than news
items?  I think that before asking a lawyer to evaluate whether the
license is sufficient, I need something that at least looks like a
license instead of a news article.

It seems possible that this concern can be resolved, either by someone
finding an already existing real license from NTT/Mitsubishi, or if
they write a new license text based on the ideas expressed on their
web pages already.  If that happens, I think it would actually be a
good idea for OpenPGP to have a normative reference to Camellia!

/Simon

---

From: Rodney Thayer <[email-masked]>
Date: Mon, 23 Apr 2007 12:38:09 -0700

>> So it appears that you don't need a license, somewhat like the situation

I would think you still need to make sure it's
been properly documented with the IETF that there's a patent.
It sounds like that's not quite been done.  If people want to
push this (as informational...) then it should have it's act together.

There have been "submarine patent" issues in the past, especially
in the crypto area, so some people are sensitive about this.

---

From: Stephan Somogyi <[email-masked]>
Date: Mon, 23 Apr 2007 12:48:12 -0700

>wish to conform to the base spec safely ignore Camellia.

I think there are two separate considerations here, and that you may 
be conflating them.

If I understand it correctly, the original proposal was to define an 
ID number for Camellia. I interpret the intent behind this as wanting 
to ensure that, should multiple implementors choose to implement it, 
they are using the same ID. Similarly, the desire is for no-one else 
to use that same ID for a different cipher.

This to me has nothing at all to do with establishing whether 
Camellia is required in a baseline OpenPGP implementation.

>license that would guarantee that Camellia can be used freely.

But is the ability for a cipher to be used freely a reasonable 
criterion to determine suitability for a slot in the ID list?

It seems to me that commercial OpenPGP developers may well choose to 
implement some algorithms that might not be freely usable, but they 
will nonetheless want to be good standards citizens and be as 
diligent as possible about ensuring that there are neither ID 
collisions and that other implementors use the same ID for the same 
cipher.

>But

Unless I'm mistaken, all that is needed here is an agreed upon ID 
number for the Camellia cipher. Nothing more.

s.

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Apr 2007 13:08:45 -0700

> informational reference in the OpenPGP document.

There are not going to be (substantial) changes to 2440bis. We're far  
too late for that -- and that's a process comment. We're waiting for  
the IESG to decide 2440bis can go out the door. This would be a  
substantial change. The 2440bis train has left the station. I  
genuinely thought that went without saying, and offer that as my  
excuse for not saying it.

However, if someone were to write a document for Camillia in OpenPGP,  
that would be a reasonable thing to do -- *after* 2440bis comes out  
of the pipe. It is in fact the rough consensus of this group that  
that's presently the best way to add algorithms.

"Normative" and "informational" aren't precisely the right terms, but  
I know what you mean. I think you meant to say "mandatory-to- 
implement" (or MUST) versus "optional-to-implement" (or MAY). I agree  
with you completely that making Camillia a MUST would not be good,  
but I didn't read it. Perhaps I just assume that any new algorithm  
would be a MAY. Certainly I interpreted this request this way.

The reason I think that patents aren't an issue is that we have two  
algorithms that were problematically patented, and still have one.  
They are IDEA and RSA. If you remember, there were OpenPGP  
implementations that did not implement RSA until the patent expired,  
and some that were a bit schizo about it. IDEA is still problematic  
from an intellectual property standpoint, but there's an easy way  
around it, which is just don't implement it. Since compatibility with  
PGP 2 is now deprecated, there's no need to implement IDEA, and so  
the patent on it only hurts IDEA.

I think the same is true with Camillia (and SEED, GOST, etc.) --  
whatever the IP status is, it doesn't matter because we don't *need*  
these algorithms. If the IP is so onerous that they aren't  
ubiquitously deployed, that's their problem, not ours. Note that  
assumes they'd be MAYs.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Apr 2007 13:52:14 -0700

I'm replying to this now with my implementer's hat on, rather than  
spec-writer's hat.

I expect that after 2440bis is done, we'll see requests for various  
national ciphers. I'm okay with it. My customers in Japan would like  
to see Camillia used. I'm happy to do that for them, especially if I  
don't have to pay for it. Even if I do have to pay for it, I'm happy  
to do it for them -- I'll just charge them money for it. Ditto for  
SEED, GOST, and any other cipher that is secure.

I see it as a good thing because the people who don't care about them  
don't have to implement or use them, and those who do can do as they  
want. The only potential problem is if you had private keys encrypted  
with one of these ciphers and you imported those keys into an  
implementation that didn't have them.

I see it as a good thing because S/MIME can use them. I don't want to  
be so rigid in what goes into OpenPGP that people who want to use  
OpenPGP but have a desire or need to use one of these other ciphers  
have to use a different protocol.

My products (the PGP family) implement both the OpenPGP and S/MIME  
standards. It would be a real pity if my Japanese product did  
Camillia for S/MIME but not for OpenPGP.

	Jon

---

From: Ian G <[email-masked]>
Date: Mon, 23 Apr 2007 22:55:55 +0200

> excuse for not saying it.

Concur.  Absolute agreement :)

But, wasn't the numbering of algorithms something that was 
taken out of the document on AD request?  I must be confused...

> that's presently the best way to add algorithms.

As we haven't done much to add algorithms, I'd say this is 
fairly open territory.

On the one hand we have plenty of numbers ...

On the other hand, we probably want some minimal proof of 
need.  By way of example only, 2 cooperating implementations 
using an experimental number?

The reason I say that is that we would then have 2 groups 
that would also cooperate to write the specification, rather 
than one group that asserts "it works for me!"

...
> ubiquitously deployed, that's their problem, not ours. Note that  

OK, as long as any algorithms that are patent encumbered are 
MAYs that would cover my concerns.

iang

---

From: David Shaw <[email-masked]>
Date: Mon, 23 Apr 2007 17:37:38 -0400

On Mon, Apr 23, 2007 at 12:48:12PM -0700, Stephan Somogyi wrote:

>  It seems to me that commercial OpenPGP developers may well choose
>  to implement some algorithms that might not be freely usable, but
>  they will nonetheless want to be good standards citizens and be as

Yes.  2440bis specifies a simple way to add new algorithms to OpenPGP.
This is the IETF CONSENSUS method as specified in RFC-2434.  Boiled
down to the bare details, that method is "write it down in an RFC and
get the RFC accepted".  That's really all that needs to happen to add
Camellia or any other cipher, and it's a pretty low bar.

I have no objections to adding Camellia.  My only concerns are that
this is done in a new RFC (2440bis is effectively closed now), and
that the new algorithm is not a MUST (for various reasons).  I don't
see that patent and/or licensing issues (if there are any) really
figure into this.  The end result is that those who want to implement
Camellia will, and those who don't, won't.  We already have a cipher
preference system to ensure that the two sides can interoperate
regardless of the presence or lack of Camellia.

David

---

From: David Shaw <[email-masked]>
Date: Mon, 23 Apr 2007 17:45:21 -0400

> I really appreciate if I could read a paper(s) about analysis of this

http://eprint.iacr.org/2002/067 actually argues for 512 bytes.

David

---

From: Rodney Thayer <[email-masked]>
Date: Mon, 23 Apr 2007 15:06:09 -0700

Ian G wrote:

> As we haven't done much to add algorithms, I'd say this is fairly open
> territory.

...and it's been handled in various ways by various other groups,
sometimes badly...  certainly not consistently.... if an AD chair
wanted to comment on this that'd be nice.  (And, if I'm missing
some process that's already there, my apologies.)

> On the other hand, we probably want some minimal proof of need.  By way
> of example only, 2 cooperating implementations using an experimental
> number?
> 
> The reason I say that is that we would then have 2 groups that would
> also cooperate to write the specification, rather than one group that
> asserts "it works for me!"

I agree that some level of consensus would be a good thing.  I don't
know if there's a current way to formalize this in the IETF.  In the
old days they allegedly required "three genetically separate
implementations".  I see your idea as being along this line.  Some
number of implementations GREATER THAN one.

---

From: Jon Callas <[email-masked]>
Date: Mon, 23 Apr 2007 15:53:42 -0700

> number of implementations GREATER THAN one.

If the working group thinks it is a good thing, very little is  
needed. You need an Internet Draft that says:

	You MAY implement Camillia. [ref]
	Cipher number is 11.

I picked 11 because it's the next number. And then a lot of  
boilerplate, and a little bit of kerfuffle. If the [ref] contains  
test vectors etc., then the kerfuffle is kept to a minimum.

To make that draft into a standards-track finished document, you need  
something like interop proof.

	Jon

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 24 Apr 2007 11:31:22 +0900

> OpenPGP document.  I see a problem with that.

I intended to avoid ID number confliction.

Thank you.

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 24 Apr 2007 11:48:44 +0900

> 	You MAY implement Camillia. [ref]

That's good.

 	You MAY implement Camillia with 256-bit key. [ref]
 	Cipher number is 11.

It would be perfect.

---

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Apr 2007 10:47:19 +0200

Stephan Somogyi <[email-masked]> writes:

> This to me has nothing at all to do with establishing whether Camellia
> is required in a baseline OpenPGP implementation.

Oh, if you interpret the request like that, I have no problem at all.

I believe registering a number for the Camellia algorithm should
happen no matter how many patents there are on it, just to avoid any
risk of number conflicts.

I read the original request differently, because it proposed to add
Camellia as a normative reference.

> criterion to determine suitability for a slot in the ID list?

No.  But I believe only freely usable ciphers, if at all possible,
should be SHOULD or MUST algorithms.

> will nonetheless want to be good standards citizens and be as diligent
> as possible about ensuring that there are neither ID collisions and
> that other implementors use the same ID for the same cipher.

Yes.  Sometimes this is handled through an IANA registry.

> number for the Camellia cipher. Nothing more.

Ok.  I probably misunderstood the initial request.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Apr 2007 11:05:17 +0200

> in the crypto area, so some people are sensitive about this.

I've found some notifications regarding this:

IPSEC:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=771
http://www1.ietf.org/ietf/IPR/mitsubishi-ntt-joint-ipr-disclosure.pdf

S/MIME:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=133
http://www.ietf.org/ietf/IPR/ntt-mitsubishi-ipr-camellia.txt

TLS:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=41
http://www.ietf.org/ietf/IPR/NTT-MITSUBISHI-CAMELLIA

I don't know if there is a bug in the IETF IPR search page or in the
NTT/Mitsubishi's disclosures which cause the above to not be found
when searching for the following RFCs:

jas@mocca:~/rfc$ grep -i camellia rfc-index.txt
3657 Use of the Camellia Encryption Algorithm in Cryptographic Message
3713 A Description of the Camellia Encryption Algorithm. M. Matsui, J.
4132 Addition of Camellia Cipher Suites to Transport Layer Security
4312 The Camellia Cipher Algorithm and Its Use With IPsec. A. Kato, S.
jas@mocca:~/rfc$

The disclosures appear to only give rights for IPSEC, S/MIME and TLS,
respectively.  It seems that another disclosure is required to be able
to use Camellia in OpenPGP.  It may be simpler to grant the right to
use Camellia for any use instead...

/Simon

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 24 Apr 2007 20:29:05 +0900

>  The disclosures appear to only give rights for IPSEC, S/MIME and
> TLS, respectively.  It seems that another disclosure is required to
> be able to use Camellia in OpenPGP.  It may be simpler to grant the
> right to use Camellia for any use instead...

Personally, I don't need anymore such thing because I don't think that
they attack to only OpenPGP. ( How could I say such thing in English,
overkill?)

But, if some disclosure document for OpenPGP is required, I ask it
NTT.  I estimate that it takes 2 or 3 weeks to get it.

I'd like to confirm again. Do we need a disclosure document from
NTT/Mitubishi for Camellia in OpenPGP?

Regards,

---

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 24 Apr 2007 21:08:06 +0900

Rodney, 

> in the crypto area, so some people are sensitive about this.

That's an evil thing.  I'm understanding why some people become
sensitive.

Don't worry, because "submarine patent" is not allowed in Japanese
patent law. Both companies are Japanese company. So, we don't need to
think about such evil thing.

Regards,

---

---

From: Heiko Stamer <[email-masked]>
Date: Wed, 25 Apr 2007 10:26:43 +0200

Hello,

> http://eprint.iacr.org/2002/067 actually argues for 512 bytes.

Please note the following paper [1] by Andreas Klein, which is submitted
to Designs, Codes and Cryptography. AFAIK his attack is possible, even if
the first bytes of the keystream are discarded.

[1] http://cage.ugent.be/~klein/RC4/RC4-en.ps

Best regards,
-- 
Heiko Stamer <[email-masked]>, Fon: +49 561 804-6635

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 25 Apr 2007 11:12:50 +0200

Hi,

> [1] http://cage.ugent.be/~klein/RC4/RC4-en.ps

Thank you for the interesting paper. I was not familiar with this particular
result, though the weakness it exploits is well known. In order to avoid
such problems, I hash the key and the IV. From page 20 of the referenced
paper (last paragraph):

"An other interesting idea is to compute the session key from the main key
and the initialization vector via a hash function [1]. The hashing would
avoid ALL ATTACKS (emphasis mine) similar to the FMS-attack or the attacks
described in this work."

Cheers,

-- 
Daniel

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 25 Apr 2007 11:24:35 +0200

> [1] http://cage.ugent.be/~klein/RC4/RC4-en.ps

The abstract says that the attack works if the initial 256 bytes are
discarded, but the conclusion of the paper says that "If one wants to
use RC4 he should ...discard the output of the first 12 rounds" (i.e.,
12*256 = 3072 bytes).

Reserving a number for RC4 in OpenPGP might make sense, but then again,
given that it seems unclear how many bytes to discard (which you would
have to specify in order to get interoperability), it might be simpler
to have people using RC4 continue to use the private numbers.

Another idea is to have two OpenPGP number allocation for, say,
"RC4-256" and "RC4-3072" which would cover (for RC4-256) discarding 256
bytes, which is used by at least one implementation, and (for RC4-3072)
discarding 3072, which is the most conservative thought-to-be-secure
mode today.

I'd rather just declare RC4 as broken and move on, though.

/Simon

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 25 Apr 2007 11:48:28 +0200

> I'd rather just declare RC4 as broken and move on, though.

RC4, if used correctly, is not broken. Actually, no known attack exists on
RC4 with the first two(!) bytes discarded, if the session key is a hash
value of the concatenated key and IV. Discarding the first 256 bytes is a
safety-belt measure on my part, guarding against yet undiscovered attacks.

There are many ways to use RC4 just as there are many ways to use block
ciphers. Allowing a stream cipher like RC4 in OpenPGP would be a radical
departure from the current policy, but once we do that, the mode of use
should be specified to the same detail as the CFB mode for stream ciphers.

I have good reasons to believe that my use of RC4 is safe, but then again,
it relies on RIPEMD128 for hashing, which is not required by RFC2440. One
could use (possibly truncated) SHA1, which is a bit slower, but it makes no
real difference. If any other implementor expresses interest in RC4, I am
willing to consider switching from RIPEMD128 to SHA1.

Cheers,

-- 
Daniel

---

From: Werner Koch <[email-masked]>
Date: Wed, 25 Apr 2007 11:54:14 +0200

> given that it seems unclear how many bytes to discard (which you would

... and how to turn it into a block cipher for our required CFB mode.

> I'd rather just declare RC4 as broken and move on, though.

Exactly.

Salam-Shalom,

   Werner

---

From: Ian G <[email-masked]>
Date: Wed, 25 Apr 2007 12:48:06 +0200

> I'd rather just declare RC4 as broken and move on, though.

I'd be much happier there too.  But Dani declared a valid 
use case, and assuming that it "takes off" there is still an 
issue.

Jon's "process email" indicated that if an informational 
style RFC was written, then that is all that is needed, that 
covers all the finickety details that surround the best way 
to use this algorithm.  It becomes a MAY algorithm, and 
everyone is happy.

The numbers issue then appears orthogonal to brokenness.

However, I'm curious whether there is no other fast stream 
algorithm that can compete with RC4?  RC4 is very old, and 
there is a conference (FSE?) devoted to this area, surely 
something has popped out in the last decade or so?

iang

---

From: David Shaw <[email-masked]>
Date: Mon, 30 Apr 2007 20:13:36 -0400

>  	You MAY implement Camillia with 256-bit key. [ref]

If nobody objects, I thought I'd have a crack at putting together a
draft for this.  I've been meaning to learn the xml2rfc stuff anyway.

I notice you're just mentioning Camellia with a 256-bit key, which
leaves out the 128 or 192-bit keys.  I don't disagree, but I'm curious
if that was intentional.

128 is okay, but 192-bit keys in OpenPGP strike me a bit as "neither
here nor there" (I argued to keep AES-192, but that had already been
deployed in the field).

David

---

From: Hironobu SUZUKI <[email-masked]>
Date: Tue, 01 May 2007 12:08:42 +0900

> NTT.  I estimate that it takes 2 or 3 weeks to get it.

I contacted to NTT about issuing IPR for OpenPGP WG as well as IPSEC,
S/MIME, TLS.  They accepted it and IPR for OpenPGP will be issued for
a while.

Regards,

---

From: Hironobu SUZUKI <[email-masked]>
To: Rodney Thayer <[email-masked]>
cc: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 01 May 2007 15:37:36 +0900
Sender: [email-masked]

Rodney, 
 
> AES-256 is listed in a NIST recommendation.  It's not marketing,
> it's following NIST guidance.

I'm taking about TLS/AES-256, not taking about AES-256. In TLS WG,
they tried to adapt only AES-128 and ignored AES-256. First of all,
they said "AES-256 is too much". I pushed AES-256 to TLS because it
was nice for backup cipher for AES-128 and it was only a chance to
adapt 256-bit cipher to TLS.

They didn't select AES-256 as by NIST recommendation. They didn't
select AES-192 also. They selected AES-256 as "backup for 128bit
cipher".

That is ture story.

At that time, I didn't think that many people use AES-256 because
actually, AES-128 was enough.

Today, in fact, many people use AES-256.  I learn that people tend to
use stronger cipher which is prepared for them because they want to
feel safer. That is a sort of psycological attitude, not technical
attitude.

> Not to say that's not debatable but it's not just "marketing" or key
> material size obsession.

I'm sorry that I confused you by my English capability.  

I meant a term "marketing" that I said is as "to know what people want
to get".  I have thought that we should provide a service for people
by what people want to do, not by engineer's ego.  And I have thought
that we should think something practical.  To implement Camellia-256
is practical thing more than to implement a set of Camellia-128/256. A
set of Camellia-128/256 may be acceptable but a few people will use
Camellia-128 because there are other 128-bit ciphers and it's too late
to list it up.  So, I list only Camellia-256 and I think it is OK for
everyone.

Also, only Camellia-256 is nothing special because only TWOFISH-256 is
listed in OpenPGP cipher.

Regards,

---

Date: Mon, 30 Apr 2007 22:27:22 -0700
From: Rodney Thayer <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Sender: [email-masked]

Hironobu SUZUKI wrote:
> David,
>> leaves out the 128 or 192-bit keys.  I don't disagree, but I'm
>> curious if that was intentional.
> 
> Yes, intentional. I chose Camellia-256 by the point of view of
> marketing.
> 
> I found that may people had selected TLS/AES-256 ciphersuite for their
> https when they could use it under their system.

AES-256 is listed in a NIST recommendation.  It's not marketing,
it's following NIST guidance.

Not to say that's not debatable but it's not just "marketing" or
key material size obsession.

From: Hironobu SUZUKI <[email-masked]>
To: David Shaw <[email-masked]>
cc: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 01 May 2007 12:49:43 +0900
Sender: [email-masked]

David,
 
> leaves out the 128 or 192-bit keys.  I don't disagree, but I'm
> curious if that was intentional.

Yes, intentional. I chose Camellia-256 by the point of view of
marketing.

I found that may people had selected TLS/AES-256 ciphersuite for their
https when they could use it under their system. Many people think
"more strong cipher for me".  I know that it is overkill for thier
security.  But most important thing is "to supply what users want to
get".

And there are many 128-bit ciphers which are already used. People will
use a cipher that they used to using.  But in 256-bit ciphers, there
only two ciphers except Camellia and many people aren't familiar with
256-bit cipher yet. In that situation, it will be easy to accept
Camellia-256bit.

Camellia-256 is good for surviving cipher war.

Regards,

---

From: Hironobu SUZUKI <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 01 May 2007 12:08:42 +0900
Sender: [email-masked]

> NTT.  I estimate that it takes 2 or 3 weeks to get it.

I contacted to NTT about issuing IPR for OpenPGP WG as well as IPSEC,
S/MIME, TLS.  They accepted it and IPR for OpenPGP will be issued for
a while.

Regards,

---

Date: Mon, 30 Apr 2007 20:13:36 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: fingerprint hash material in 12.2.
Date: Mon, 30 Apr 2007 13:08:16 -0700
To: Stephan Beyer <[email-masked]>
Sender: [email-masked]

> in section 12.2., the text says, that _the_ two-octet packet length
> comes after the 0x99 octet.
>
> Does that mean, that the public key data may not be larger than 65536
> bytes?
>
> If so: Is that stated anywhere?
> And... is this good? Considering permanently growing key sizes or the
> possible existence of practically useful public key algorithms using
> (for example) a variable number of integers[1].
>

I'm only going to answer parts of your question.

This really isn't an issue. Right now, just about everyone uses only  
4k public keys. 4k bits is 512 bytes. Even if you need several 4k bit  
numbers, there's plenty of room.

The long-term issue we face is crypto-balance with 256-bit symmetric  
algorithms. NIST estimates a 15k-bit key to be balanced with AES-256.  
While plenty of people disagree with that, we all agree that we're  
not going to crypto-balance RSA with AES. It would be annoying and slow.

Long term, we're going to move to elliptic curve, and those keys are  
smaller. Crypto-balance would be at about 512 bits, and thus it fits  
in just fine.

However, let me just assume that next week someone invents Magic  
Dingus Encryption, which has the advantage that it is not only ten  
times faster than ECC, but is proven immune to quantum computers as  
well as mental telepathy. The downside is that the public keys are  
128k bytes in size.

In such a case, when we write the RFC for MDE in OpenPGP, we would  
need to state how you compute the fingerprint of an MDE key in that  
RFC. That's it. (And as a matter of fact, when we do ECC for OpenPGP,  
we'll have to specify the ECC parameters for fingerprints in whatever  
RFC specifies ECC for OpenPGP.)

The reason why it specifies in 12.2 the precise length is that in  
OpenPGP there are often many ways to state a length. Thus, we have to  
state precisely how to compute the fingerprint, because don't want to  
end up with a to-may-to/to-mah-to issue in computing fingerprints.  
That's it.

	Jon

Date: Mon, 30 Apr 2007 17:52:24 +0200
From: Stephan Beyer <[email-masked]>
To: [email-masked]
Subject: fingerprint hash material in 12.2.
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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

Hi,

in section 12.2., the text says, that _the_ two-octet packet length
comes after the 0x99 octet.

Does that mean, that the public key data may not be larger than 65536
bytes?

If so: Is that stated anywhere?
And... is this good? Considering permanently growing key sizes or the
possible existence of practically useful public key algorithms using
(for example) a variable number of integers[1].

So, if there is no 64k limit on public key data, a further question
occurs:
Is the "two-octet packet length" the packet length modulo 65536?[2]
But then, isn't the
	a.2) high order length octet of (b)-(f) (1 octet)	[3]
some kind of "second low order length octet"? ;-)

Or is (a.2) the "most significant octet of the length" while (a.3) is=20
the "least significant octet"? ;-)

I looked what GnuPG does, and - note the first comment - ...
 -- snip g10/keyid.c --
  /* What does it mean if n is greater than than 0xFFFF ? */
  md_putc( md, n >> 8 );   /* 2 byte length header */
  md_putc( md, n );
 -- snap --
=2E..they use the "modulo 65536" variant. ;-)

Kind Regards,
Stephan Beyer

Footnotes:
 1. Although it is not considered secure, think of a knapsack-based
    methods with n integers.
 2. By the way, is it correct to say "packet length" when you don't
    actually mean the length of the packet, but the length of
    (b)-(e) in the example? ;-)
 3. Note, that there is a further mistake: (f) doesn't even exist.
    The list ends with (e).

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

--ew6BAiZeqk4r7MaW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--ew6BAiZeqk4r7MaW--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-22.txt 
Date: Wed, 25 Apr 2007 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-22.txt
	Pages		: 85
	Date		: 2007-4-25
	
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.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Referencs for rfc2440bis
Date: Wed, 25 Apr 2007 09:23:02 -0700
To: Sam Hartman <[email-masked]>
Sender: [email-masked]

Sam, I sent in bis-22. It has your changes and the other IESG changes  
(change "preferred" to "RECOMMENDED" in section on new/old header  
types, and formatting error on header of Security Considerations.)

	Thank you for all your work,
	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Referencs for rfc2440bis
Date: Wed, 25 Apr 2007 08:30:35 -0700
To: Sam Hartman <[email-masked]>
Sender: [email-masked]

On Apr 24, 2007, at 4:54 PM, Sam Hartman wrote:

>
>
>
> Hi folks.
>
> I've reviewed the normative and informative references for rfc2440bis
> and have a few concerns.  Some of these were introduced in response to
> last call comments, but I think the fix may be wrong.
>
> First, may I suggest we replace the aes reference with:
>
>
>    [AES]	 NIST, FIPS PUB 197, "Advanced Encryption Standard
>    		 (AES)," November 2001.
>    		 http://csrc.nist.gov/publications/fips/fips197/
>    		 fips-197.{ps,pdf}
>
>
>
> RFC 1951 is listed as an informative refernec.  However as best I can
> tell RFC 1951 is normative and needs to be moved to the normative
> references section.
>
>
> I believe that RFC 2119 and 2434 need to be moved to the normative
> references section.  No I don't know why; it's always done that way.
>
> I realize that RFC 1951 is an informational RFC.  I'll deal with that.
>
> If the authors could make these changes I can bring this to the IESG.
> I'm sorry for the delay I've introduced.
>
>

I can handle that. Please realize that 1991 and 2434 were moved to  
informative from normative because the GEN-ART review insisted on it.  
I'm happy to move them back. It would, however, be nice to -- well,  
you know.

I will submit another draft.

	Jon

Date: Wed, 25 Apr 2007 12:48:06 +0200
From: Ian G <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
Sender: [email-masked]

iang

From: Werner Koch <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Heiko Stamer <[email-masked]>, [email-masked]
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 25 Apr 2007 11:54:14 +0200
Sender: [email-masked]

Exactly.

Salam-Shalom,

   Werner

Date: Wed, 25 Apr 2007 11:48:28 +0200
To: Simon Josefsson <[email-masked]>
Cc: Heiko Stamer <[email-masked]>, [email-masked]
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

Cheers,

-- 
Daniel

From: Simon Josefsson <[email-masked]>
To: Heiko Stamer <[email-masked]>
Cc: [email-masked]
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 25 Apr 2007 11:24:35 +0200
Sender: [email-masked]

/Simon

Date: Wed, 25 Apr 2007 11:12:50 +0200
To: Heiko Stamer <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

Hi,

Cheers,

-- 
Daniel

Date: Wed, 25 Apr 2007 10:26:43 +0200
From: Heiko Stamer <[email-masked]>
To: [email-masked]
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
Sender: [email-masked]

Hello,

Best regards,

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Referencs for rfc2440bis
Date: Tue, 24 Apr 2007 19:54:14 -0400
Sender: [email-masked]

Hi folks.

I've reviewed the normative and informative references for rfc2440bis
and have a few concerns.  Some of these were introduced in response to
last call comments, but I think the fix may be wrong.

First, may I suggest we replace the aes reference with:

   [AES]	 NIST, FIPS PUB 197, "Advanced Encryption Standard
   		 (AES)," November 2001.
   		 http://csrc.nist.gov/publications/fips/fips197/
   		 fips-197.{ps,pdf}

RFC 1951 is listed as an informative refernec.  However as best I can
tell RFC 1951 is normative and needs to be moved to the normative
references section.

I believe that RFC 2119 and 2434 need to be moved to the normative
references section.  No I don't know why; it's always done that way.

I realize that RFC 1951 is an informational RFC.  I'll deal with that.

If the authors could make these changes I can bring this to the IESG.
I'm sorry for the delay I've introduced.

From: Hironobu SUZUKI <[email-masked]>
To: Rodney Thayer <[email-masked]>
cc: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 24 Apr 2007 21:08:06 +0900
Sender: [email-masked]

Rodney, 

Regards,

---

From: Hironobu SUZUKI <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Rodney Thayer <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 24 Apr 2007 20:29:05 +0900
Sender: [email-masked]

Regards,

---

From: Simon Josefsson <[email-masked]>
To: Rodney Thayer <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 24 Apr 2007 11:05:17 +0200
Sender: [email-masked]

IPSEC:

S/MIME:

TLS:

/Simon

From: Simon Josefsson <[email-masked]>
To: Stephan Somogyi <[email-masked]>
Cc: [email-masked]
Subject: Re: Camellia for OpenPGP
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 24 Apr 2007 10:47:19 +0200
Sender: [email-masked]

/Simon

From: Hironobu SUZUKI <[email-masked]>
To: Hironobu SUZUKI <[email-masked]>
cc: Jon Callas <[email-masked]>, Rodney Thayer <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 24 Apr 2007 11:53:50 +0900
Sender: [email-masked]

> 
>  	You MAY implement Camellia with 256-bit key. [ref]
                          ^^^^^^^^
>  	Cipher number is 11.

Oops sorry my typo.

---

From: Hironobu SUZUKI <[email-masked]>
To: Jon Callas <[email-masked]>
cc: Rodney Thayer <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 24 Apr 2007 11:48:44 +0900
Sender: [email-masked]

That's good.

It would be perfect.

---

From: Hironobu SUZUKI <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 24 Apr 2007 11:31:22 +0900
Sender: [email-masked]

Thank you.

---

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Camellia for OpenPGP
Date: Mon, 23 Apr 2007 15:53:42 -0700
To: Rodney Thayer <[email-masked]>
Sender: [email-masked]

	Jon

Date: Mon, 23 Apr 2007 15:06:09 -0700
From: Rodney Thayer <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Sender: [email-masked]

Date: Mon, 23 Apr 2007 17:45:21 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Mon, 23 Apr 2007 17:37:38 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Camellia for OpenPGP
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Date: Mon, 23 Apr 2007 22:55:55 +0200
From: Ian G <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Sender: [email-masked]

...

iang

From: Jon Callas <[email-masked]>
Subject: Re: Camellia for OpenPGP
Date: Mon, 23 Apr 2007 13:52:14 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Camellia for OpenPGP
Date: Mon, 23 Apr 2007 13:08:45 -0700
To: Simon Josefsson <[email-masked]>
Sender: [email-masked]

	Jon

Date: Mon, 23 Apr 2007 12:48:12 -0700
To: [email-masked]
From: Stephan Somogyi <[email-masked]>
Subject: Re: Camellia for OpenPGP
Sender: [email-masked]

s.

Date: Mon, 23 Apr 2007 12:38:09 -0700
From: Rodney Thayer <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Sender: [email-masked]

From: Simon Josefsson <[email-masked]>
To: Mike Markowitz <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 23 Apr 2007 20:46:19 +0200
Sender: [email-masked]

/Simon

Date: Mon, 23 Apr 2007 13:33:00 -0500
To: Simon Josefsson <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: Re: Camellia for OpenPGP
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

-mjm

From: Simon Josefsson <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 23 Apr 2007 19:11:49 +0200
Sender: [email-masked]

/Simon

From: Jon Callas <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Mon, 23 Apr 2007 09:38:15 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

	Jon

From: Hironobu SUZUKI <[email-masked]>
To: Florian Weimer <[email-masked]>
cc: Hironobu SUZUKI <[email-masked]>, Ian G <[email-masked]>, Simon Josefsson <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Tue, 24 Apr 2007 00:40:27 +0900
Sender: [email-masked]

Regards,

---

From: Florian Weimer <[email-masked]>
To: Hironobu SUZUKI <[email-masked]>
Cc: Ian G <[email-masked]>, Simon Josefsson <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Date: Mon, 23 Apr 2007 17:14:31 +0200
Sender: [email-masked]

From: Hironobu SUZUKI <[email-masked]>
To: Hironobu SUZUKI <[email-masked]>
cc: Ian G <[email-masked]>, Simon Josefsson <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Mon, 23 Apr 2007 23:21:25 +0900
Sender: [email-masked]

---

From: Hironobu SUZUKI <[email-masked]>
To: Ian G <[email-masked]>
cc: Hironobu SUZUKI <[email-masked]>, Simon Josefsson <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Mon, 23 Apr 2007 23:12:01 +0900
Sender: [email-masked]

That's my opinion.

Regards,

---

Date: Mon, 23 Apr 2007 13:51:22 +0200
From: Ian G <[email-masked]>
To: Hironobu SUZUKI <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
Sender: [email-masked]

iang

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked] (Daniel A. Nagy)
cc: Hironobu SUZUKI <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP] 
Date: Mon, 23 Apr 2007 19:59:15 +0900
Sender: [email-masked]

Hi,

Regards,

---

From: Hironobu SUZUKI <[email-masked]>
To: Simon Josefsson <[email-masked]>
cc: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP 
Date: Mon, 23 Apr 2007 19:51:34 +0900
Sender: [email-masked]

Regards,

---

Date: Mon, 23 Apr 2007 11:52:20 +0200
To: Hironobu SUZUKI <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

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

On Mon, Apr 23, 2007 at 06:01:56PM +0900, Hironobu SUZUKI wrote:
>=20
> Hi, RC4 is well-known as an insecure cipher algorithm today.=20

>=20

Yes, of course.

>=20

Regards,

--=20
Daniel

--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--UlVJffcvxoiEqYs2--

From: Simon Josefsson <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Camellia for OpenPGP
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 23 Apr 2007 11:33:00 +0200
Sender: [email-masked]

/Simon

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked] (Daniel A. Nagy)
cc: OpenPGP <[email-masked]>
Subject: Re: ArcFour for OpenPGP [Re: Camellia for OpenPGP] 
Date: Mon, 23 Apr 2007 18:01:56 +0900
Sender: [email-masked]

Thanks,

---

Date: Mon, 23 Apr 2007 10:30:39 +0200
To: OpenPGP <[email-masked]>
Subject: ArcFour for OpenPGP [Re: Camellia for OpenPGP]
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

--=20
Daniel

--4Ckj6UjgE2iN1+kY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--4Ckj6UjgE2iN1+kY--

From: Hironobu SUZUKI <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Camellia for OpenPGP
Date: Mon, 23 Apr 2007 14:42:20 +0900
Sender: [email-masked]

Proposal is as below;

Thanks.

---section 9.2---

        ID           Algorithm
        --           ---------

---section 13.9---

13.9. OpenPGP CFB mode

    ...

---section 16----

---

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-21.txt 
Date: Tue, 10 Apr 2007 15:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-21.txt
	Pages		: 85
	Date		: 2007-4-10
	
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.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: [email-masked]
To: Derek Atkins <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: New Draft on its way
Date: Tue, 10 Apr 2007 11:01:01 -0400
Sender: [email-masked]

Hi.  Sending the new draft was fine in this instance.  I'm sorry there
are so many picky and confusing rules about when it's OK and when it
is not.  Basically the best way is to coordinate with the AD after
publication request.

I briefly reviewed the diffs in 20 before pulling it from the agenda.
The reason I pulled it is that it looked like references required to
implement the spec were moved from normative to informative
(presumably in response to last call/genart comments).  I suspect that
this was wrong and need to go back and confirm what is going on.  I
don't think I will get to this today; I'm trying for tomorrow.

--Sam

From: Derek Atkins <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>, [email-masked]
Subject: Re: New Draft on its way
Date: Tue, 10 Apr 2007 09:09:25 -0400
Sender: [email-masked]

Jon Callas <[email-masked]> writes:

> On Apr 9, 2007, at 6:20 PM, Derek Atkins wrote:
>
>>
>> Jon,
>>
>> Can you please hold off on submitting the new draft for now?
>> We should be on the next IESG telechat with -20, and I wouldn't
>> want to derail it.  Now, if Sam says it's okay to submit -21
>> then let's go ahead, but otherwise we should just hold onto it
>> and then we can feed the IESG comments into a new draft and either
>> send the diffs or a new document as necessary.
>>
>
> Sorry, too late. I can ask the ID desk to hold it, but it's in.

Well, we'll see what Sam has to say.  PGP isn't on the agenda
for the 4/19 meeting, yet, so reviewing -21 might be okay.  But
it's up to Sam.

Sam?

> 	Jon

-derek

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

Cc: OpenPGP <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: New Draft on its way
Date: Mon, 9 Apr 2007 23:38:33 -0700
To: Derek Atkins <[email-masked]>
Sender: [email-masked]

On Apr 9, 2007, at 6:20 PM, Derek Atkins wrote:

>
> Jon,
>
> Can you please hold off on submitting the new draft for now?
> We should be on the next IESG telechat with -20, and I wouldn't
> want to derail it.  Now, if Sam says it's okay to submit -21
> then let's go ahead, but otherwise we should just hold onto it
> and then we can feed the IESG comments into a new draft and either
> send the diffs or a new document as necessary.
>

Sorry, too late. I can ask the ID desk to hold it, but it's in.

	Jon

Date: Mon, 09 Apr 2007 21:20:24 -0400
From: Derek Atkins <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>, [email-masked]
Subject: Re: New Draft on its way
Sender: [email-masked]

Jon,

Can you please hold off on submitting the new draft for now?
We should be on the next IESG telechat with -20, and I wouldn't
want to derail it.  Now, if Sam says it's okay to submit -21
then let's go ahead, but otherwise we should just hold onto it
and then we can feed the IESG comments into a new draft and either
send the diffs or a new document as necessary.

Thanks,

-derek

Quoting Jon Callas <[email-masked]>:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm going to be submitting bis21 shortly. This has the following
> changes in it:
>
> * Working author email address for Rodney Thayer.
>
> * Additional notes from IANA comments, as well as some reworking.
> Reserved signature subpacket types are explicitly marked reserved,
> there are notes in section 9 that make things more clear, and
> sections 10.4 through 10.6 have been moved to the end of section 13
> because they are not IANA considerations per se, but considerations
> that future work should pay attention to. I also changed "upwards-
> compatible" to "backwards-compatible" in the meta-considerations
> section, because that seems better to me.
>
> I apologize about confusion about the last couple drafts. I was
> accidentally omitted from the email from IANA. About the time that
> they sent it, I sent out bis20, which had corrections from other IETF
> Last Call comments. The coincidence in timing meant that many people
> thought I was strangely not including IANA comments. I was confused
> about why people were confused. I think we're all no longer confused,
> and I think that this is a wrap. My fingers are crossed.
>
> 	Jon
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP Universal 2.6.0
> Charset: US-ASCII
>
> wj8DBQFGGtT3sTedWZOD3gYRAlZSAKC9sVJnzMGxekIO1+a62z/810fRwQCgsjmf
> vSNpf3d4p4GHbcQ2kPy49j8=
> =1Wz2
> -----END PGP SIGNATURE-----
>
>

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

To: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: New Draft on its way
Date: Mon, 9 Apr 2007 17:06:15 -0700
Sender: [email-masked]

I'm going to be submitting bis21 shortly. This has the following  
changes in it:

* Working author email address for Rodney Thayer.

* Additional notes from IANA comments, as well as some reworking.  
Reserved signature subpacket types are explicitly marked reserved,  
there are notes in section 9 that make things more clear, and  
sections 10.4 through 10.6 have been moved to the end of section 13  
because they are not IANA considerations per se, but considerations  
that future work should pay attention to. I also changed "upwards- 
compatible" to "backwards-compatible" in the meta-considerations  
section, because that seems better to me.

I apologize about confusion about the last couple drafts. I was  
accidentally omitted from the email from IANA. About the time that  
they sent it, I sent out bis20, which had corrections from other IETF  
Last Call comments. The coincidence in timing meant that many people  
thought I was strangely not including IANA comments. I was confused  
about why people were confused. I think we're all no longer confused,  
and I think that this is a wrap. My fingers are crossed.

	Jon

Cc: OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Last Call: draft-ietf-openpgp-rfc2440bis (OpenPGP Message  Format) to Proposed Standard
Date: Tue, 3 Apr 2007 01:05:18 -0700
To: Simon Josefsson <[email-masked]>
Sender: [email-masked]

> There are reference to old documents, including:
>
>   RFC 2279 -> RFC 3629
>   RFC 1750 -> RFC 4086
>

Thanks.

> There are normative reference to non-standards track RFCs, including:
>

>   RFC 1641

I just removed this.

>   RFC 1951

This is the definition of ZIP/DEFLATE. We have to have it. It is also  
the best documentation of ZIP there is. Nonetheless, I moved it to  
Informative despite the fact that it is a normative reference,  
because idnits complained about it, too.

>   RFC 1991 (which documents is intended to obsolete?)

RFC 1991 is the RFC that describes PGP 2.6.x. With 2440bis, we have  
deprecated those mechanisms. Consequently, they are less well-defined  
in 2440bis than they were in 2440. If an implementation wants to be  
compatible with PGP 2.6.x, it is more important that this be  
referenced. I moved it to informative, too, because idnits complained.

>   RFC 2144

This is the description of CAST5. Idnits didn't complain about this  
one, so I left it.

> The following reference are never cited in the text as far as I can
> tell.  Most of them should likely be removed, but citing
> [BLEICHENBACHER] at some appropriate point may be useful.
>
>     [RFC1423]        Balenson, D., "Privacy Enhancement for Internet
>                      Electronic Mail: Part III: Algorithms, Modes, and
>                      Identifiers", RFC 1423, October 1993.

Moved to Informative. It would be a shame not to honor the  
contribution that PEM made to secure email.

>
>     [RFC1641]        Goldsmith, D. and M. Davis, "Using Unicode with
>                      MIME", RFC 1641, July 1994.
>

I just removed it.

>     [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
>                      signatures without knowing the secret key,"
>                      Eurocrypt 96. Note that the version in the
>                      proceedings has an error. A revised version is
>                      available at the time of writing from
>                      <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
>                      /isc/ElGamal.ps>
>

I added a reference in the discussion of Elgamal signatures.

>     [DONNERHACKE]    Donnerhacke, L., et. al, "PGP263in - an improved
>                      international version of PGP", ftp://ftp.iks-
>                      jena.de/mitarb/lutz/crypt/software/pgp/
>

Removed, since we're deprecating 2.6.x.

>     [MAURER]         Ueli Maurer, "Modelling a Public-Key
>                      Infrastructure", Proc. 1996 European Symposium on
>                      Research in Computer Security (ESORICS' 96),
>                      Lecture Notes in Computer Science, Springer- 
> Verlag,
>                      vol. 1146, pp. 325-350, Sep 1996.
>

I'm leaving this in, because it's a good informative reference  
despite there being no specific place for it.

>     [RFC1983]        Malkin, G., "Internet Users' Glossary", FYI  
> 18, RFC
>                      1983, August 1996.
>

Removed.

Thanks for the comments.

	Jon

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-20.txt 
Date: Mon, 02 Apr 2007 18:50:02 -0400
Sender: [email-masked]

--NextPart

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

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-20.txt
	Pages		: 84
	Date		: 2007-4-2
	
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.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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

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

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

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--