OpenPGP headers

[Simon Josefsson]

Atom 'Smasher' <atom at suspicious.org> writes:

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

Given Werner's comment, I have my doubts whether this checking is
necessary.  It seems the checks provide marginal improvements, in
which case I believe that any requirement to perform these checks
itself (i.e., the _requirement_ itself, not the checks) is more
harmful than not performing the checks.

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

Recommending some simple common precautions is typically a good idea
for security considerations in IETF documents.

What I'm worried about here is this scenario: a user receive an e-mail
with OpenPGP-URL:, the user clicks on 'Reply securely' (or whatever)
and the client goes and fetch the URL, and then start to edit the
reply e-mail, and then signs it to the key retrieve without verifying
that the key retrieved even match the Key ID/fingerprint from the
message.  This isn't unreasonable client behavior if there is no
guidance, and I'm not sure it is a good idea to permit clients to
behave this way.  More thought on this might help.

Naturally, if there is ONLY a OpenPGP-URL, and no
OpenPGP-Key/Fingerprint, then it is impossible to do any checking, and
in that case I think that's no checking is just fine.  Then standard
web of trust apply.

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

I agree.  It was a suggestion to things to add to the 'security
consideration', and not to the core part of the document, after all.

The security consideration is typically the place where you put things
that you don't really want to care about, but that is prudent to
mention as a possible improvement.  It is a way to acknowledge that
"you could improve things by doing this, but this specification
doesn't bother to do it".

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

Hm.  Lowest common denominator seem to be RFC 2440.  But I realize now
that RFC 2440 does not specify "Text names" for the PK algorithms,
only for the hash algorithms.  That's a shame.  So it seems id numbers
is the way to go here.  I think it might be hinted that RFC 2822
comments may be used to improve human readability:

OpenPGP-Key: id=0x4711; algo=2 (RSA Encrypt only); size=42

or whatever.

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

Sorry, I thought you merged OpenPGP-Key with OpenPGP-Fingerprint.

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

Well, in that case a new specification is needed anyway, to specify
that base64 is used.  To be backwards compatible with your
specification, I can't see how it can use the same OpenPGP-Key header
name.  But this isn't an important aspect.

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

Based on your writeup, polishing up the language and making it into a
proper IETF document using xml2rfc, suitable for RFC publication,
shouldn't be difficult.  I can help with this, if you want to.

Thanks,
Simon