Jon Callas <jon(_at_)callas(_dot_)org> writes:
I'm starting the task of updating 2440. I need to find an uninterrupted day
or two to do it properly. However, the main thing the working group really
That is good news. Hope you will find the time.
me that is loathe to rush on with mods to 2440 presently. I'd rather see
2440 become a standard than slow the whole process down by adding features,
So do I.
A summary of the problem is that that 2440 does not cover the case where a
clear-signed message does not end with a CRLF or is of length zero.
My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
just declare that that's bad? If a clear-signed message isn't
This is okay for me. If it is in the standard I have an easy answer
to those bug reports. A clear signed message is not intended to be
in the first place machine readable but for humans and they don´t care
about an appended blank line.
hinge on the definition of "canonical text-mode" text, and I always thought
that canonical text-mode text always ended with a line end. Am I wrong on
this?
No.
* One hash algorithm or many? My opinion is one, and that should be SHA-1.
We don't need the full capability of the hash algorithm the way signatures
Go ahead and specify SHA-1 as the only one hash algorithm to be used.
I even give up on my request to add a version number to the new
packet. The only thing I'd really like is to have the hash prefixed
with some bytes which can be interpreted as a packet (new type or
a signature packet of version 0) and the length of the encrypted
packet given without this hash. This way an implementor can choose
between:
a) assume this is one packet (simply adding the fixed size of
the hash packet to the length given in the header or reading
these additional bytes in case of a partial length header).
b) handle them as 2 packets with no need to defer the hashing of
the encrypted packet by the length of the hash.
Consequently, in spite of the fact that I have no particular love for
PGP-CFB mode, I say we just run with it, in the interests of simplicity and
speed.
I agree.
The best thing to do would be for someone to write a PGP-CFB mode wrapper
that could be applied to a number of ciphers. Ideally, this would be
I am not sure whether I understand this correct: Do you mean a thing
to decrypt PGP-CFB and encrypt it using standard CFB?
* We have to design an Optional Features Subpacket. This is a subpacket
that goes in a self-signature that states that the certholder would
understand an MDC message should one be sent to them. It's not really that
Should it go as a hashed subpacket? This would put a burden on the user to
update his self-signature - no big issue but it can't be automatized
by a new version of an implementation. So in addition to this feature
subpacket (which is a good idea), what about a requirement (we already
discussed this) that for cipher algorithms with a blocksize other than
64 bit the use of the new MDC packet is a SHOULD (or MUST). This will
be a good thing for the AES algorithm and Twofish. It won't do any
harm.
To show that I'm an equal-opportunity ox-gorer in the name of simplicity,
do we need the large signature packet? Do we need it now? My opinion is
No we don't need them. I still don't thing that huge signatures are a
good thing - it makes a lot of trouble to handle them the same way as
usual signatures; the signed stuff should better go into a literal
data packet. And yes, I know that there is the PGP ticket project but
we shouldn't discuss this now.
that we need it, but not now. It's far more important that we get
implementations to support 2440 than anything else. I'm willing to put it
Another thing for the optional feature packet ;-)
close. Tom Zerucha's reference implementation, and GnuPG. The main thing I
can think of for us to do is to show that they implement 2440, and
interoperate.
How can we do this? Do we need to meet physically and if, does it need to
happen in the U.S. (due to export control rules)? Is someone still
working on a check list?
- Do we have a way to specify private extensions for the S2K
(I am thinking about hardware tokens).
No, we do not. Do we need them? Do you want to suggest an architecture?
Should I issue a plea for simplicity?
I think it is a good idea to reserve some IDs for experiments, as we
did for ciphers etc. - In case such experimental packets have leaked
out and later revisions of the standard use the same IDs for another
purpose a user has not a good chance to identify this problem.
So I'd suggest to add just this:
3.6.1.4. Reserved S2K Identifiers
Identifiers with a first octet in the range [0x64, 0x64] are
reserved for private/experimental S2K algorithms.
Werner
--
Werner Koch at guug.de www.gnupg.org keyid 621CC013