Hello,
I entered this list just recently, sorry about that.
I am wading through the spec bit by bit, hoping to add improvements.
After reading sections 1 and 2 I have seen a lot of confusing names,
often covering the same thing and sometimes used with different meaning.
This does not appeal to me as good specification habits I fear.
Message, data file, object, session
These terms are used in a rotary scheme, but the reader must assume they
mean the same thing, and not something slightly different. The original
thought of OpenPGP seems to have been message formats as sent by email,
but then PGP disk encryption came and the terms had to be altered.
Can be agree on one term for "the stuff that is PGP-ified" perhaps?
I think "OpenPGP data" will be fine, in contrast to "readable data".
OpenPGP: spec or implementation?
Section 1.1 teaches us that "OpenPGP" is the name of a definition
(or specification?) but the list items in section 2.1 use it to indicate
a program. I propose to change "OpenPGP" to "OpenPGP implemetation"
in these list items.
Section 2.0 introduces a self-contradicting loop, by stating that OpenPGP
(the document) does a few things that are beyond the scope of this
document.
A finer note on 1.1 -> I don't think definitions are formalized, instead I
think specifications are described or formulated. Am I going too far?
The subset from 2.5 is sufficiently clear -- but it would not harm to give
it an explicit name, such as "non-encrypting OpenPGP". That would help
clarify references to this document.
The goal, course and fine
The start of section 2 mentions a list of four bullets, specifying a few
techniques used. I am not seeing CR-LF standardisation, but I do see
radix-64 which seems to be of similar weight. Both are not nearly as
important as the first three points. I would leave it to these three
bullets and not get down to the level of representation here.
To be frank, I don't see the point of section 2.4; it seems too early.
I may be off here. Either way, isn't it true that implementations SHOULD
only *accept* radix-64 representations of OpenPGP data?
Somewhat funny: confidentiality is not mentioned here at all!
Procedures, data
Section 2.1 describes the same procedure twice. Once in the
introductionary paragraph, once in the list. What I would have expected
from the plaintext (not the list) in both 2.1 and 2.2 is a description of
the data structure -- that would remove procedurally irrelevant details
from the procedures.
Point 4 of 2.2, "attached" means "appended", so at the end, right?
Point 5 of 2.2, "keeps" means? Should it be "receives"?
Compression
Section 2.3 stresses that compression SHOULD be done, but it is not
mentioned in the procedure under 2.1.
The second paragraph contradicts itself, doesn't it? It speaks of
implementations that do not implement compression and says that they should
at least decompress. This should be said about implementations that do not
compress outgoing messages prior to their encryption.
As for the "added side-effect" (which states the same thing doubly twice) I
see a cryptographic advantage in compression that should go here :- by
compressing a message, the entropy of the data that is encrypted is made
as high as possible.
Let me know if you want me to write actual text. I'm not sure how this
process works -- but I'll be open to suggestions.
Cheers,
Rick van Rein,
OpenFortress.