Subject: Diffs for next draft

From: Jon Callas <[email-masked]>
Date: Wed, 22 Aug 2001 15:52:12 -0700

Here's everything I have. If there's something you want me to do and I've
been obtuse, let me know again, and it'll get in. I'm planning on
submitting the draft in about 24 hours. I can always do another one when
something's omitted, so don't panic.

	Jon

3,6c3,6
< Category: INTERNET-DRAFT                  Counterpane Internet Security
< draft-ietf-openpgp-rfc2440bis-02.txt
< Expires Apr 2001                                       Lutz Donnerhacke
< October 2000                         IN-Root-CA Individual Network e.V.
---
> Category: INTERNET-DRAFT                       Wave Systems Corporation
> draft-ietf-openpgp-rfc2440bis-03.txt
> Expires Feb 2002                                       Lutz Donnerhacke
> August 2001                          IN-Root-CA Individual Network e.V.
15c15
<                  draft-ietf-openpgp-rfc2440bis-02.txt
---
>                  draft-ietf-openpgp-rfc2440bis-03.txt
18c18
< Copyright 2000 by The Internet Society. All Rights Reserved.
---
> Copyright 2001 by The Internet Society. All Rights Reserved.
400,401c400,401
< 15       -- Symmetrically Encrypted and Integrity Protected Data Packet
< 16       -- Modification Detection Code Packet
---
> 18       -- Symmetrically Encrypted and Integrity Protected Data Packet
> 19       -- Modification Detection Code Packet
530a531,540
> Algorithm Specific Fields for ElGamal signatures:
> .block on -
> MPI of ElGamal value a = g**k mod p.
> MPI of ElGamal value b = (h-a*x)/k mod p-1.
> .block off
>
> The hash h is PKCS-1 padded exactly the same way as for the above
> described RSA signatures.
>
>
537a548,550
> SHA256:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
> SHA384:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
> SHA512:     0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
545a559,561
> SHA256:     2.16.840.1.101.3.4.2.1
> SHA384:     2.16.840.1.101.3.4.2.2
> SHA512:     2.16.840.1.101.3.4.2.3
567a584,598
> .block blank
> SHA256:     0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05,
>             0x00, 0x04, 0x20
>
> .block blank
> SHA384:     0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05,
>             0x00, 0x04, 0x30
>
> .block blank
> SHA512:     0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86,
>             0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05,
>             0x00, 0x04, 0x40
>
765a797,799
> Since the user name space is in the form of an email address,
>implementors MAY wish to arrange for that address to reach a person who
>can be consulted about the use of the named tag.  Note that due to UTF-8
>encoding, not all valid user space name tags are valid email addresses.
>
>
852c886
< 1 - Modification Detection (packets 15 and 16)
---
> 1 - Modification Detection (packets 18 and 19)
863c897
< When a signature is made over a key, the hash data starts with the octet
0x99, followed by a two-octet length of the key, and then body of the key
packet. (Note that this is an old-style packet header for a key packet with
two-octet length.) A subkey signature (type 0x18) then hashes the subkey,
using the same format as the main key. Key revocation signatures (types
0x20 and 0x28) hash only the key being revoked.
---
> When a signature is made over a key, the hash data starts with the octet
>0x99, followed by a two-octet length of the key, and then body of the key
>packet. (Note that this is an old-style packet header for a key packet
>with two-octet length.) A subkey signature (type 0x18) then hashes the
>subkey, using the same format as the main key (also using 0x99 as the
>first octet). Key revocation signatures (types 0x20 and 0x28) hash only
>the key being revoked.
1071c1105,1106
< Two-octet checksum of the plaintext of the algorithm-specific portion
(sum of all octets, mod 65536).
---
> Two-octet checksum of the plaintext of the algorithm-specific portion
>(sum of all octets, mod 65536). This checksum is encrypted together with
>the algorithm- specific fields.
>
1172c1207
< .head 2 Sym. Encrypted Integrity Protected Data Packet (Tag 15)
---
> .head 2 Sym. Encrypted Integrity Protected Data Packet (Tag 18)
1204c1239
< .head 2 Modification Detection Code Packet (Tag 16)
---
> .head 2 Modification Detection Code Packet (Tag 19)
1523c1558
< Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other algorithm.
---
> Implementations MUST implement Triple-DES. Implementations SHOULD
>implement AES-128 and CAST5. Implementations that interoperate with PGP
>2.6 or earlier need to support IDEA, as that is the only symmetric cipher
>those versions use. Implementations MAY implement any other algorithm.
1545c1580
< 4          - Reserved for double-width SHA (experimental)
---
> 4          - Reserved for double-width SHA (experimental, obviated)
1548a1584,1586
> 8          - SHA256                                "SHA256"
> 9          - SHA384                                "SHA384"
> 10         - SHA512                                "SHA512"
1754c1792
< If an Elgamal key is to be used for both signing and encryption, extra
care must be taken in creating the key.
---
> If an Elgamal key [ELGAMAL] is to be used for both signing and
>encryption, extra care must be taken in creating the key.
1756c1794
< An ElGamal key consists of a generator g, a prime modulus p, a secret
exponent x, and a public value y = g^x mod p.
---
> An Elgamal key consists of a generator g, a prime modulus p, a secret
>exponent x, and a public value y = g^x mod p.
1764c1802
< Details on safe use of Elgamal signatures may be found in [MENEZES],
which discusses all the weaknesses described above.
---
> Details on safe use of Elgamal signatures may be found in [MENEZES],
>which discusses all the weaknesses described above. Please note that
>Elgamal signatures are controversial; because of the care that must be
>taken with Elgamal keys, many implementations forego them.
1915,1917c1953,1955
< Counterpane Internet Security, Inc.
< 3031 Tisch Way, suite 100 East Plaza
< San Jose, CA 95128, USA
---
> Wave Systems Corp.
> 1601 S. DeAnza Blvd, Suite 200
> Cupertino, CA 95014, USA
1920,1921c1958,1959
< Email: [email-masked], [email-masked]
< Tel: +1 (408) 556-2445
---
> Email: [email-masked], [email-masked]
> Tel: +1 (408) 448-6801
2059c2097
< Copyright 2000 by The Internet Society. All Rights Reserved.
---
> Copyright 2001 by The Internet Society. All Rights Reserved.

---

From: Werner Koch <[email-masked]>
Date: 23 Aug 2001 09:16:10 +0200

> been obtuse, let me know again, and it'll get in. I'm planning on

Did someone else also checked that the OIDs for SHA-xxx are correct?

I am a little bit curious, can you give a rational why the feature
flags are not bit encoded? 

What about the Klima/Rosa attack?  If this draft is going to be the
next RFC we should do something about it.  IIRC, we had not much
discussion about it. The obvious fix would be use a hash instead of
the simple checksum.  The problem is how to indicate the use of this
new format.

The correct solution would be to introduce a version 5 of the secret
key packet - this is a major change as we may also want to also
introduce a v5 public key packet for symmetry reasons.  I guess this
will break a lot of code.

The hackish solution is to define a new S2K type identical to type 3
(iterated and salted) which would then trigger the use of the new
SHA-1 checksum.  It should be made clear that this S2K type is only to
be used for the protection of the secret key and not for conventional
encryption.

I don't like any of these solutions but the latter one is easier to
implement. Any other ideas?

  Werner

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