Quoting Hal Finney <hal(_at_)rain(_dot_)org> on or about 1997/11/27 05:28
Sydney
time-
Dave Crocker writes:
1. Technical
There is no strong argument that either MIME or Armour are superior at
doing protection against the vagaries of transport.
It is worth noting that Armour combines the control information with
the data, whereas MIME keeps them separate. This facilitates processing by
recipients who either do not have the necessary security software or who
want to defer its use. That is, for authenticated data which is not also
encrypted, the main data can be kept cleartext whereas with Armour it is
not.
I described several technical objections to the use of MIME which no one
has addressed.
Ok ok I might only qualify for the contingency substitute reserve bench
but I will give it a go and see how I go :-) I apologise if I end up
creating too much work for others.
Many of them are related to the MIME convention you describe of separating
control information from data. This works well in an email environment,
where such separation is already in place. We have mail headers and body,
and it is natural to add the MIME control information to the headers,
and to put the MIME body parts into the body. This also works for HTTP
and news, which have a similar header/body distinction.
My earlier comments were designed to be for email only. I admit after
reading the comment by Jon Callas <jon(_at_)pgp(_dot_)com> that my "premise"
stating
this was poorly expressed but that was my intent. I was not trying to
draw a conclusion.
Now I will **try** to cover a broader scope. And I am aware from Dave
Crocker's separate reply that many of these issues are beyond the remit
of the proposed standard. I will try to tie some back to the proposal as
best I can.
But this model breaks down when we are in an environment where such
separation does not exist. I used the example of disk files.
I am sure others will comment on this and set me right as appropriate but
I find it extremely hard to think of any logical construction which could
ever hope to address files in the same breath as email, usenet and web
based cgi transactions.
#pragma personal_opinion_mode true
I will now go right out on a long limb and risk all sorts of fire and
brimstone (and this folks, without a helmet :-) and say:
A wonderful multi purpose application like PGP 2,3,5 does not fit well
into a single standard. (And I expect I am not the first to have thought
that!)
In my mind the original and subsequent PGP applications all addressed
multiple cryptographic needs from a single code base and in doing this
came up with the necessary (non cryptographic) fixes like ascii armour
just to get the thing to work in the real world. As David Sternlight is
so fond of saying Phil Z./PGP Inc. did not invent the cryptographic
"bricks", the algorithms. And I always thought that was a feature not a
problem. One big achievement of Phil Z./PGP Inc. was to built a "house"
with good quality pretested "bricks" and bring it to us at a price we
could afford. And more recently to do some "renovations" because some to
the original "bricks" are not as good as originally thought :-).
I think it would be a nonsense to attempt to codify some version of PGP
as a standard. A standard is not an application programming language.
What we want from the standard is a well defined result. The result we
want is effective cryptography in our existing environments. I do
believe this process of defining a standard is a way of thinking about
all the different services provided by the PGP application and getting
the same benefits in an integrated way along side all the other
"standard" ways to achieve specific results.
I want to emphasise that I am not claiming any of this is true. I just
wanted to say it so you would have a better idea of my mind set and maybe
get a better gauge of what I think is so obvious I might never think to
say it.
Thank you for your forbearance. Please send me my "reeducation camp"
bookings in a plain envelope. I do not want my family to be upset :-)
#pragma personal_opinion_mode 0.5
Now, some
people have said that this should not count, either because people don't
exchange disk files, or they don't need disk files to be ascii armored.
Actually, people do exchange disk files all the time, either as email
attachments, or by FTP, or by sharing them in other ways.
Mostly I use .hqx, .uu, .b64 or whatever binary-to-ascii transmission
format the other person needs. My helper/application list is already
very long just to handle the current lot. Why add another encapsulation
format when these will do the job just fine?
When all is said and done an encrypted file is just another binary file
for transmission purposes. The general internet file transfer
conventions with O/PGP would go something like:
Start with:
mysecret.doc -> mysecret.pgp -> mysecret.uu
send file over internet
mysecret.uu -> mysecret.pgp
apply the correct key and the recipient gets mysecret.doc
And the standard should make this as simple as possible. Ascii armour is
not needed. It would do just fine in place of encoding with
uu/hqx/b64/... but is not needed.
And there
are reasons for ascii armoring files. One good example is a clearsigned
file, where you want to be able to view the contents while maintaining
the signature in the file. There may also be situations where people
find it convenient to be able to view their encrypted files and see BEGIN
PGP MESSAGE, so that they are reminded that they hold encrypted data.
The only way that I can see to support this with PGP/MIME is to make
the file consist of the MIME headers, then a blank line, then the MIME
body parts. In effect we adopt a convention that files do have two parts,
control information and data, and that they are separated by a blank line.
We are forced to do this if the file system does not provide us with
another place to put lengthy control information, as most do not.
AFAIK O/PGP/MIME could only address the manner in which an email message
is constructed. It has nothing to do with the **internal** structure of
an attached file if that file type is not defined to the mime system as
needing translation. If OTOH the O/PGP standard defines a mime
conversion for files with suffix .pgp then the standard also has to be
specific about the internal structure of that file. To me this implies
some sort of delimiter setup and could still be well defined in terms of
mime type encapsulation. After unpacking, the result on the recipient's
system might have any combination of blank lines, resource forks, paired
files with the proper suffix... pick your OS and you get the most natural
solution, and the standard should deliver from one system/format to
another system/format via the mime packing/unpacking. The bits and
pieces (content, signatures, certificates, whatever) are all best
displayed via the application interface or as a result of a unix style
command line. Let the code do the work, use the standard to define the
end results.
I have a dream... (sorry! wrong holiday :-) that O/PGP will not be a
bunch of cluncky headers and strange looking ascii strings. Sure that
sort of stuff will still be around but it should be "under the hood".
Interested types can still look at the raw data, nothing is hidden we
just move to higher level of function.
But since this convention cannot be applied uniformly throughout the file
system, ambiguities arise. There is no way to tell a priori whether a
file is in this new "MIME format" or whether it is an ordinary file.
I described various examples of where these ambiguities could cause
problems.
Agreed. O/PGP cannot define the contents of the file system at large,
but it can define a valid file for its own purposes. Nothing will ever
stop people from sometimes serving the wrong files to an application.
All we can ever do is ensure there is enough redundancy in the system to
allow for robust sanity checking. Ascii-armour is only one way. I would
like to hear an expert talk of the other possibilities. And there is no
specific reason why the current PGP file part delimiters cannot remain in
files stored on the file system. But we still need to repack the file if
we want to transmit it over the internet and mime is the way to go in
that area.
I also pointed out other places where PGP/MIME conventions that would be
logical for email don't make sense in more constrained applications, such
as the convention that data to be signed MUST be converted to 7 bit form
beforehand.
This is an excellent point. Maybe the convention is wrong. Let us not
to hobble this new standard with an outmoded one byte alphabet. If it
has not been suggested already let's get multi byte alphabets built into
the standard from the ground up. No late add-on fixits to cater for the
Chinese, Hindu, Japanese... scripts. These are all huge markets and
getting bigger, and I believe there is already an ISO standard for these
alphabets. We don't have to invent this wheel. Just use it and make
O/PGP savvy with it.
In addition, I mentioned that PGP/MIME does not provide methods to
encapsulate some legal PGP packet structures which were expected not to
be used for email.
Propose the packets for inclusion.
Sorry to be redundant here, but since my first message apparently made
so little impact, perhaps a repetition will help.
No problem for me. Got me off the bench. But there are so many good
players in this game I always think I look stupid :-)
Quoting Adam Back <aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> on or about
1997/11/27 07:51 Sydney
time-
A minimal implementation should be allowed to call itself OpenPGP
compliant without implementing either MIME or armor.
I would worry about a standard which did not define a minimum
functionality so that all implementations could talk to each other. I
think mime should be MUST, this is looking ahead, and means all
conformant implementations can talk to each other via this format. Allow
ascii-armour as a MAY, does the right thing by history and the method is
available between consenting parties.
Enjoy the turkey and holiday folks, it is already Thanksgiving in
Australia
Regards,
Gavan.
Gavan Schneider | In a world without fences,
<gavan(_at_)magna(_dot_)com(_dot_)au> | who needs Gates?