ietf-openpgp
[Top] [All Lists]

Re: Draft comments

1997-11-21 19:19:24
At 11:04 AM 11/19/97 +0000, Ian Brown wrote:
   Took a while to plough through!
   
   It's a pretty good document overall - please don't take the following
   comments as quibbling in any way, I'm just trying to contribute ;-)

Thanks. Now you see why it took so long to produce. I couldn't have gotten
it out even *this* fast without Hal, Rodney, Lutz, and Paul Hoffman. They
did about 95% of the writing, and I just pulled it together.
   
   Sec  Comments
   
   2.4.1        - Just one quibble. Since Armour is largely for backward
   compatibility with the 4 million users of PGP 2.6, do we *really* need
   to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could
   Message-ID also go? It does say in PGP/MIME that "When the amount of
   data to be transmitted requires that it be sent in many parts, the MIME
   message/partial mechanism should be used rather than the multipart ASCII
   armor PGP format."

I've already said my part on why I think armour is *not* primarily for
backwards compatibility. The PART X headers are not a new header, though.
They are an old header. I don't mind losing them, or deprecating them.
   
   2.6  - I'm not sure what jdcc means by "Should the armor header line stay
   or go... I think anything that reduces parsing complexity is a Good
   Thing." I agree, but by this do you mean it saves implementations
   parsing the algorithm fields in the actual signature itself?

I meant that new combined header that has a begin-message and the hash
announcement. I think that as long as the "Hash:" header line can have
multiple hashes there (or it is legal to have multiple hash headers), then
we don't need this, and it simplifies to just remove it.
   
   3.5  - Are the S2K functions really necessary? Are dictionary attacks on
   passphrases in an (at least) 128-bit keyspace likely to be successful?
   If so, I still agree with jdcc that the Iterated-Salted algorithm should
   be dropped.

Yes, I think dictionary attacks are trivial to do successfully, and salted
hashes are the way to thwart them. 
   
   5.1  - "An implementation should accept, but not generate a version of 2,
   which is equivalent to V3 in all other respects." Is this purely for
   legal (RSAREF) reasons? The international version of PGP 2.6 can
   generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is
   there any *technical* reason why OP implementations should not generate
   version 2 packets?

When PGP 2.6 was created, the version number of the packets was bumped from
2 to 3, but nothing else was changed. It's really only there so you can
tell whether a message was made by 2.5 or 2.6. There is no technical reason
not to generate a V2 packet, but there is no technical reason *to* generate
them, either. RFC 1991 says on the subject: 

"A version number of 2 or 3 is currently allowed for each packet
 format.  New versions will probably be numbered sequentially up from
 3.  For backwards compatibility, implementations will usually be
 expected to support version N of a packet whenever they support
 version N+1.  Version 255 may be used for experimental purposes."

This paragraph is my rationale for preferring V4 to V3, and noting that V2
is identical to V3, but that it must not be generated.
   
   5.2.2.2
   
   "Preferred hash algorithms" - you mention "If this subpacket is not
   included, ZIP is preferred." Would it be useful to put a sentence of
   this type in the preferred symmetric and hash algorithms also? We have
   3DES and SHA-1 as MUSTs, so they could be used...

The reason I put that there is that this preference is different in
semantics from the others. You see, most implementations of PGP compress by
default. The main reason for this packet is so that a key can say, "Hey, if
you send me a compressed message, I can't read it." This is so that a
minimal implementation -- one that does not have compression (remember, the
MUST algorithm for compression is uncompressed) -- can advertise that it
doesn't have compression. 

I put that sentence in there so that all the existing keys in the world
will continue to work the way they always have.
   
   > {{Editor's note:  It would be nice to have a signature that applied to
   > the key alone, rather than a key plus a user name... --jdcc}}
   
   What would it mean to have just key material signed by someone else?

Right now, all the signatures sign the key material and a user name, thus
binding the user name to to the key. All of the subpackets, because they
are on an identity signature, apply only to that one username. I added in
this draft language to make that specific -- see the paragraph on them
being interpreted narrowly. If you wanted, for example, to set a symmetric
algorithm preference for the entire key, or for someone to issue some
statement about the entire key, then there has to be a signature type that
spans the entire key.
   
   > {{Editor's note:  There is presently no way for a key-signer (a.k.a.
   > certifier) to sign a main key along with a subkey.  There are a number
   > of useful situations for a set of keys (main plus subkeys) to all be
   > signed together... --jdcc}}
   
   Could you give a few examples?

A feature of the V4 keys is to have a main key and some number of subkeys.
Certifications (a.k.a. key signatures) are over the main key only. This
means that you can replace your encryption key without losing your
signatures. This is a Good Thing.

However, a number of people, including you and Adam, are proposing that as
an alternative to ARR/CMR/whatever that some form of "key escrow" be used.
Adam and I are starting to work on a paper that compares "shared key" (the
Crypto-Correct term for placing a secret key in a third party's possession)
and "multiple encryption" schemes for providing access to data.

As presently described, the key-replacement mechanisms make it impossible
to implement a shared-key access system. (In the Bad Old Days, I bragged
that PGP 5 was "escrow-resistant" -- but it now seems that what I used to
think of escrow is actually a feature to a lot of people.) So we need to
have a mechanism that lets someone sign not only your top-level key, but
some number of subkeys, too.

I can think of two main ways to do this:

(1) Add a new signature type. This new signature type is like an existing
certification signature, but certifies a list of subkeys, too. We'd have to
devise a syntax for it.

(2) Add a subpacket type. This subpacket would be included in a
certification signature and would state that a subkey (specified by algid
and fingerprint) is to be included in the hash. More than one of these
subpackets means more than one key is part of the certification. 

I think (2) is better -- which you can probably tell because I started to
design the thing. There are other ways to do it, but I think that a
subpacket is preferable, because it piggybacks on the existing
signature-plus-subpacket framework.
   
   5.4  - Is the one-pass signature packet *really* necessary?

It depends on what you mean by really. Without it, you have to verify a
signature with a two-pass scheme (hence the name "one-pass signature") and
this requires storing the whole message during the time that the signature
is being computed. This leads either to a slowdown, or a breakdown of the
whole system (a relay system could not verify a signature on a message
larger than its storage). So no, it's not *really* necessary -- PGP has
survived for years without it. Is it useful? Yes, very.
   
   5.10 - I think you're right about there being so many problems with
   Trust packets, we should forget them. Your idea about them being
   implementation dependent is good, except that different OP
   implementations may want to use the same keyring. For example, I use PGP
   2.6.3i and my mail encrypting program with the same keyring. If they
   implement trust packets differently, it would be very confusing. I think
   we should just specify that they should be ignored.

All PGP implementations have "export" and "import" functions, and don'e
merely pass keyrings around. Passing a keyring *works* but it's not a good
idea, because it leaks all your trust information. If an implementation 
   
   8.1  - Why not use the BNF-like notation from section 7.2 to describe
   keyring structure also?
   
I think the keyring structure is outside the scope of this document. All
the current implementations I know of use a sequential file of keys, but I
think that longterm that is going to be inadequate, and a real database is
required. Beyond that statement, I have to do a lot of handwaving.
Traditionally, IETF documents leave on-disk structure, and things like that
to the implementor. 

        Jon



-----
Jon Callas                                  jon(_at_)pgp(_dot_)com
Chief Scientist                             555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                   Suite 570
(415) 596-1960                              Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)