jas at extundo.com
Tue Aug 10 17:28:54 CEST 2004
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.
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
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.
> 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.
> 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.
> 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.
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.
More information about the Gnupg-devel