Jon Callas writes:
At 11:04 AM 11/19/97 +0000, Ian Brown wrote:
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.
There is a new mechanism here. It used to be that you had to say
PART X/Y, like PART 3/10. This meant that you had to know how many parts
there would be, total.
One of the design goals of several of the new changes (new format message
length headers, one-pass signature packets) is to allow processing data
where you don't know how big it is ahead of time. Old PGP had to use
a lot of temp files because it kept having to complete one phase of
the processing before it could begin the next one. Any time you use a
temp file, this could potentially leave incriminating data on the disk
(even a secure wipe is not guaranteed to work). Eliminating temp files
reduces this risk.
The new PART X combined with the MessageID armor header is designed to
allow one-pass processing without knowing how many parts there will be
in advance. The MessageID also allows different messages to be
decoded even when they are interspersed.
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.
This is just meant as a shorthand, moving the hash line up to the end
of the armor header line. A similar change allows the CRC hash to be
at the end of the last signature line instead of on a line of it own.
It's really to reduce visual clutter. PGP cleartext signatures are so
clean and nice, especially compared with the S/MIME alternative, that
there has been a desire expressed to keep them as clean as possible.
5.2.2.2
> {{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.
Actually, key-revocation signatures are directly on keys, and subkey
signatures are directly on subkeys. No userids are involved in either of
these kinds of signatures. I agree with Jon that there could be other
kinds of signatures which would be most logical to apply directly to a
key or subkey.
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.
It's actually an issue more for signature creation than verification.
The signature packet has to go at the front of the message. But you don't
have the hash until you've gotten to the end of the message. Now you have
to go back and stick the signature at the front. This requires a lot of
buffering, temp files, and such. With the one-pass packet you put the
signature at the end. No more temp files, one less security risk.
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.
A related issue is transferrable key structure. A BNF would seem
appropriate in that case.
Hal Finney