On Apr 7, 2016, at 3:39 AM, Werner Koch <wk(_at_)gnupg(_dot_)org> wrote:
On Wed, 6 Apr 2016 20:15, brynosaurus(_at_)gmail(_dot_)com said:
1. What fingerprint scheme(s) should OpenPGP move to going forward?
A SHA-256 hash of the artificial OpenPGP key packet as we use it right
now. The open question is whether to
- include a creation timestamp,
- a timestamp but fixed to 0 (as Google End-to-End does),
- some other static info data to surely separate that fingerprint from
other protocols fingerprint using the same key (i.e. token based)
- no creation timestamp
The rationale for SHA-256 is that this is the only fast algorithm on all
platforms.
What about Blake2? If OpenPGP will be using Argon2 for password hashing, then
all implementations will need to have a Blake2 implementation anyway because
Argon2 builds on Blake2.
A related question is how to identify the new fingerprint scheme in
OpenPGP objects which store a fingerprint:
- Implicit by the length of the fingerprint,
- or by a prefix byte with the hash algorithm,
- or by a prefix byte with the key version number,
- or by a prefix byte with the length of the fingerprint.
This is tricky: a further related question is how OpenPGP implementations
decide what “kind” of fingerprint to produce, or present to the user, or expect
to get, when doing something with a particular public key. As many people have
pointed out, it will be terrible for user experience if users have to start
juggling “new-style” and “old-style” fingerprints for the same public key:
e.g., you sent me your pub key and I want to verify it but your OpenPGP
implementation defaulted to the new fingerprint but mine is giving me an
old-style fingerprint to compare against.
A couple possible solutions occur:
- Define each pub key scheme as having one and only one corresponding
fingerprint scheme. i.e., all existing/legacy pub key schemes remain stuck
with old SHA1 fingerprints and only new pubkeys generated under a new pub key
scheme will get new-style fingerprints. This would have the desirable property
of ensuring that users never confusingly see two different legitimate
fingerprints for the same public key - but it might mean that we never get to
use new fingerprints with RSA/DSA key pairs etc, which may be a non-starter.
- Add a “preferred fingerprint scheme” field of some kind to the self-signed
cert that public keys are created with, so it becomes a property like E-mail
address etc. Benefit: users still only ever see one fingerprint for a given
public key, SHA1 for old public keys or SHA256 (or whatever) for newly-created
public keys, even if the new public key uses an “old” pub key scheme like
RSA/DSA. Drawbacks: implementation complexity; users need to regenerate (or at
least re-self-sign) their keys if they want to get a new-style fingerprint for
their pre-existing public keys.
2. What exactly should the OpenPGP “application” fingerprint with that
scheme?
To clarify, I propose to define a “fingerprint scheme” as an algorithm
that takes a raw octet string and produces an ASCII string of some
You describe how a fingerprint is presented to the user. This has been
out of scope for OpenPGP. Implementations have settled for a de-facto
standard outside of the protocol. I think we should keep it this way
and at best give only a suggestion for a human readable format.
Humans are bad at comparing fingerprints; this should in general be left
to the software and additional protocols to establish a connection
between an identity and a key/fingerprint.
Although it might be good enough to rely in practice on “de facto” standards
for fingerprint presentation, it would suck if two users with different OpenPGP
implementations had no way at all of comparing/verifying fingerprints because
one uses presentation X and the other uses presentation Y and there’s no common
ground. Wouldn’t it at least be worth recommending at least one “common”
fingerprint presentation format be supported for cross-implementation
verifiability, even if individual implementations might have their own
“preferred” presentation/verification mechanism for when both users are using
the same implementation?
B
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp