OpenPGP headers

Tue Aug 10 20:52:40 CEST 2004

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Tue, 10 Aug 2004, Simon Josefsson wrote:
> Atom 'Smasher' <atom at suspicious.org> writes:
>
>> the id (or fingerprint) is just as important in determining the correct
>> key as the size and algo. although it's difficult to do now, there's a
>> trick with v3 keys where it's not difficult to generate a key having a
>> predetermined id (the deadbeef attack). this is made easy when the key
>> size is not confirmed.
>
> Thanks.  If you know the algorithm and key size, is the attack much
> harder, or just slightly harder?  If it is much harder, I think that
> warrant discussion in the draft, and a requirement that clients should
> compare the key size and algorithm (as well as key id, of course)
> after retrieving the key.  If the attack is only slightly harder, the
> added work isn't justified IMHO.
======================

when signing (or otherwise verifying) a key, it's recommended to confirm 
the fingerprint, size, and type of the key (and UID, of course). if all of 
these checks are done (and keys are reasonably large), then it's 
infeasible to substitute a "trojan" key.

> Oh, the draft probably should say that client should compare the key
> id with the key they retrieve, if the key is used to send the person
> encrypted e-mail directly, to at least prevent the most simple
> man-in-the-middle attacks.
=========================

i really don't want to specify what a client should or shouldn't do with 
the information... as long as it isn't altered or removed.

the behavior you describe will also depend highly on someone's personal 
preferences and level of paranoia.

there may be a lot of uses (and abuses) for this information that i can't 
predict, but i will leave that to the application developers.

> The security consideration might _suggest_ use of HTTPS to further
> protect the transfer of keys.  And DNSSEC to protect the lookup of the
> name in the URL.
========================

at some point it all comes down to the web of trust, and personally 
verifying keys. beyond that, i don't believe that technology can save us 
(if you don't believe me, just ask alice and bob... those two are always 
having their messages attacked). before this point becomes an ideological 
discussion, the point you raise here is debatable, but better addressed 
under the topic of policy or best practices. it's beyond the scope of the 
standard that i'm attempting to establish.

>> the way to make it more user friendly while still being machine readable,
>> i think, is to add a "name" column to RFC2440:9.1 (DSA, RSA, ELG, etc) so
>> that algorithms actually do have a standard way of being communicated...
>> is public key algo 21 "DH"? "X942"? "X9.42"? as of now, "21" is the only
>> way to consistently identify it... sure, RSA and DSA are self explanatory,
>> but the naming convention doesn't scale well.
>
> IMHO, the proper thing is to say that implementations MUST understand
> all mnemonics used in RFC 2440, and SHOULD use integer values for any
> algorithm not mentioned by RFC 2440.
====================

i don't want to impose that burden on any application... and who's to say 
that someday there won't be a "X94.2" spec? or DSA-2? the only way to 
ensure long term compatibility is to reduce things to the lowest common 
denominator... for now, that means id numbers.

>> the header name is now "OpenPGP-Key", which i think accurately describes
>> it's contents: information necessary [but not securely!] to confirm that
>> the correct key is used.
>
> You forgot to update the example in section 2.3.
================

??? there are three different headers defined:
 	OpenPGP-Key
 	OpenPGP-Fingerprint
 	OpenPGP-URL

that should be made more clear in a table of contents.

>> draft 0.1 <http://atom.smasher.org/pgp-headers/pgp-headers01.txt> allows a
>> full fingerprint to be used as a key id. it also specifies that a key id
>> SHOULD be prefixed with "0x"... the prefix aids in avoiding ambiguity.
>
> What ambiguity?  I'm not sure I see it.
===================

the 0x is a convention used to denote that a hexadecimal value follows. in 
the event that 160 bit hashes become too small for security, it's not 
ridiculous that some other (more compact) way of presenting a fingerprint 
might evolve... maybe base 64, instead of base 16. who knows. in any 
event, it's always a good practice to precede a key id (or any hexadecimal 
value) with 0x.

> When you convert your draft into IETF format, I would recommend using
> xml2rfc, see <http://xml.resource.org/>.  It takes care of adding most
> of the required headers.
======================

thanks! i'll check that out...

also, if anyone has any experience writing these types of documents, 
please let me know if you want to help in any way. this is certainly not a 
full-scale rfc, but i've never written this type of thing before.

  	...atom

  _________________________________________
  PGP key - http://atom.smasher.org/pgp.txt
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	A student asked his old Sufi Master if he should tie up
 	his camel for the night, so that it wouldn't wander
 	away while they were sleeping or if doing so was an
 	insult to God. Should he leave the camel untied to
 	show his trust in God that the camel wouldn't run away?
 	The Master replied "Trust God AND tie up your camel."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.6 (FreeBSD)
Comment: What is this gibberish?
Comment: http://atom.smasher.org/links/#digital_signatures

iQEcBAEBCAAGBQJBGRl9AAoJEAx/d+cTpVciHAUH/jteUhOy8ZB3PZxx5HSW6Nzt
UtR6cerjctXSU9XGm4+b/tuSTjcLWbzD3GFJIPIN1VYCdCj2VAco/O6bWTI1CStQ
g91x1SEVFYgHIaIVTtenXVg10djk4UlVxzVXDOpwZ2URF62zZv8a6CoBtIGXTf/7
oDZiFrr0FwNWRIG4B62KhW6+jDWDS0VVHb8G7oVxJtUqlTKsaSB6wf7a/VKNcJ0O
qOs5/YC6dfHFrRqOHkyg7gIbWvrroqchuM+yOtSgI+r+u0woneq4Y8yHpBi8/MyZ
E/jT0WZ7Iytw5nYz33qGg8gDuOTwWY2tLBBMMFIHDUiH1flX3H8xi98LZYA/08c=
=7LJi
-----END PGP SIGNATURE-----