ietf-openpgp
[Top] [All Lists]

Re: I-D ACTION:draft-ietf-openpgp-formats-02.txt

1998-04-23 10:58:03
On Thu, 23 Apr 1998 Internet-Drafts(_at_)ietf(_dot_)org wrote:

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)       : R. Thayer, J. Callas, L. Donnerhacke, H. Finney
      Filename        : draft-ietf-openpgp-formats-02.txt
      Pages           : 54
      Date            : 22-Apr-98

3.6.2.1, Cipher alg: use Simple S2K

... SHOULD NOT be generated.  The only value for Cipher Alg should be 1 to
(IDEA) to maintain compatability, so why not just say 1 instead of saying
that you can theoretically use 3DES or CAST to do something you shouldn't
be doing?

It says 'the cipher algorithm number with an implicit use of MD5 and IDEA'
but the cipher algorithm number only means IDEA if it has the value of 1,
so if there is a cipher algorithm number, then the cipher is *NOT*
implicit, but specified by the number.

(this also creates problems if you don't allow promoting V3 secret keys to
V4 retaining the key id and other associations since you can't use the new
secret key encryption algorithm). 

4.2.2.3 Five octet lengths

Nowhere does it say this SHOULD NOT be used after partial body lengths. 
So can it occur in place of the One or Two octet lengths?  If the idea was
to mimmic the old style CTB, I would think not. 

5.2.2

The full prefix isn't given, just the OID in ASN1 form.  The fuller
version is sequence(sequence(object,null),octet-stream).

If DSA is used (I know it SHOULD NOT) with a hash with less than 160 bits,
I would suggest the data be padded with zeros on the left, or repeat the
hash result.  What about a hash with >160?  I would suggest the rightmost
(least significant) 160 bits. 

A reason to do this might be to use one hash algorithm for both V3 and V4
signatures, which would mean MD5.

7. Cleartest signature framework

"The ASCII armored signature(s)" - for multiple signatures, is each
signature individually armored, or are the signature packets concatenated
and the whole armored?

"If there are no such [Hash:] headers, SHA-1 is used.  So V3 Clearsigned
messages won't interoperate with V4 implementations?  Or should the
default be MD5? 

12.7

This describes ONLY the cfb reset for the symmetrical packet.  V3 RSA
secret keys also need the cfb reset (between MPIs), and they aren't
usually on a 10 byte boundary.

13

How can a broken hash algorithm leak a DSA secret key? (I would like a
reference noting the above interoperability problems, or would this only
affect a signing service where I could provide known plaintext).

--- reply to tzeruch - at - ceddec - dot - com ---