Ascii armor allows PGP binary data to be held or transmitted in
any environment that may not be safe to raw binary data.
Can you give us an example of this apart from mail? Web-based keyservers
only use armour because they are based on mail servers. HTTP allows
binary data to be transferred directly.
From RFC 2068 (HTTP 1.1)
Transfer codings are analogous to the Content-Transfer-Encoding
values of MIME , which were designed to enable safe transport of
binary data over a 7-bit transport service. However, safe transport
has a different focus for an 8bit-clean transfer protocol. In HTTP,
the only unsafe characteristic of message-bodies is the difficulty in
determining the exact body length (section 7.2.2), or the desire to
encrypt data over a shared transport.
I can see very little reason why people would want to store PGP data
armoured in a system that supports 8-bit data.
There are other applications that use PGP technology
for authentication, enveloping, etc. and use armor.
Is this because they transfer data by mail?
I am presently working with
someone who is using the new extension mechanism to build an SPKI-like
authorization system for a network server. They want to use armored
blocks.
Unless they want to transmit data by mail, there is no need for them to.
They can send it as 8-bit data. If they do need to, they can use MIME as
they don't need backwards compatibility.
Lastly, there are systems that use (or would like to use) PGP over systems
that are not the internet. I have given the example of pager systems
before. There are other systems that use telephones, private networks, or
other non-Internet means of data transfer.
I would have thought the vast majority of non-Internet means of data
transfer allow 8-bit data to be transmitted over them.
Armor has little to do with message
transmission, and everything to do with *OBJECT* (keys, authorizations,
etc.) transmission.
PGP objects are made up of binary packet(s). They have very little to do
with armour. The labelling is in most cases a convenience feature. For
example:
-----BEGIN PGP SIGNATURE-----
jhglhgd876876jhJkjgJGKJlkjljkgjhg...
-----END PGP SIGNATURE-----
contains a binary encoded Signature packet. It is the format of the
underlying binary data which defines the object, not the armour.
To forbid armor is to say that there is no conceivable use for it.
No-one has suggested this.
Armor itself is
still a preferred way of transmitting OP objects that are not messages.
Could you give us a case where it is vital to the understanding of an
object that it is armoured - i.e. just interpreting the underlying
binary packet(s) will not give you the full meaning of the object.
(1) I'm going to remove anything in OP-FORMAT that requires the use of
ascii armor. Following my touchstone that any feature needed for backwards
compatibility is a SHOULD, it'll be a SHOULD.
(2) A description of OP-MIME will be in Michael Elkin's RFC 2015.
In this case, RFC2015 need updating as it currently *requires* the use
of Armour.
We'll leave it to implementors which they prefer to implement and
encourage the use of MIME for messages.
Perfect!
Ian :D