I'm currently working my way through the draft. Yesterday
night's results follow:
BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the
armor is split amongst Y parts, and this is the Xth part out of Y.
BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is
the Xth part of an unspecified number of parts. Requires the MESSAGE-ID
Armor Header to be used.
I don't see any need for this in the specification: In
virtually all situations I can imagine there are more
appropriate ways to accomplish the same result:
· If OP is used for local data storage, splitting stored
data will be handled by the traditional methods
(split(1) ;-) which will work for encrypted data the
same way they are working for unencrypted data.
· When using OP for data transmission, this will almost
always be in some kind of PGP/MIME context, thus MIME's
partial message methods can be used. No need to
reinvent the wheel.
The Armor Headers are pairs of strings that can give the user or the
receiving OP message block some information about how to decode or use
the message. The Armor Headers are a part of the armor, not a part of
the message, and hence are not protected by any signatures applied to
the message.
The format of an Armor Header is that of a key-value pair. A colon
(':' 0x38) and a single space (0x20) separate the key and value. OP
should consider improperly formatted Armor Headers to be corruption of
the ASCII Armor. Unknown keys should be reported to the user, but OP
should continue to process the message. Currently defined Armor Header
Keys include "Version" and "Comment", which define the OP Version used
to encode the message and a user-defined comment.
One could refer to the e-mail standards' definition of
headers for this part. It's describing almost the same
format, and it's widely used.
The MessageID should not appear unless it is in a
multi-part message. If it appears at all, it should be
computed from the message in a deterministic fashion,
rather than contain a purely random value. This is to
allow anyone to determine that the MessageID cannot serve
as a covert means of leaking cryptographic key
information.
Phrase this as follows: "The MessageID header should not
appear except in multi-part messages. It MUST be computed
as a deterministic function of the armored message data.
Implementors SHOULD use an SHA1 value of the armored
message data concatenated with a string indicating the
time of the message generation."
Rationale: We should prescribe a method to get things
clear; SHA1(armor + time) gives us the necessary amount of
"randomness".
Anyway, the MessageID header is actually not needed.
For extensibility, we should permit X-something armor
headers which MAY be used by specific implementations for
their own purposes.
The precise specification of the radix64 format is not
needed in the present text - the reader can be referred to
RFC2045.
Sometimes it is necessary to sign a textual octet stream without ASCII
armoring the stream itself, so the signed text is still readable
without special software. In order to bind a signature to such a
cleartext, this framework is used. (Note that RFC 2015 defines another
way to clear sign messages for environments that support MIME.)
"Whenever possible and applicable, RFC 2015's method
should be preferred over clear signing material."
If the "Hash" armor header is given, the specified message digest
algorithm is used for the signature. If this header is missing, SHA-1
is assumed. If more than one message digest is used in the signature,
You mean MD5 here, as that's used in PGP 2 which doesn't
add the Hash header.
Dash escaped cleartext is the ordinary cleartext where every line
starting with a dash '-' (0x2D) is prepended by the sequence dash '-'
(0x2D) and space ' ' (0x20). This prevents the parser from recognizing
armor headers of the cleartext itself. The message digest is computed
using the cleartext itself, not the dash escaped form.
In 2.6, the same is valid for lines beginning with the
five characters "From ". I think we should stick with
this convention since clear signing messages will mostly
be used in legacy environments which don't support MIME
(and will mangle From_ lines).
{{Editor's note: This is very complex, with bizarre things
like an 8-bit floating point format. Should we just drop
it? --jdcc}}
Nope, it may be of some use at some point in the future.
See also /etc/shadow. ;)
tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
1280/593238E1 · AE 24 38 88 1B 45 E4 C6 03 F5 15 6E 9C CA FD DB