[Top] [All Lists]

Re: Armour

1997-11-26 19:37:45
Quoting Hal Finney <hal(_at_)rain(_dot_)org> on or about 1997/11/27 05:28 

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 

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" 
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 

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

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

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 

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 


Gavan Schneider           | In a world without fences,
<gavan(_at_)magna(_dot_)com(_dot_)au>      | who needs Gates?

<Prev in Thread] Current Thread [Next in Thread>