On Wed, 2015-05-06 at 16:38 -0400, Phillip Hallam-Baker wrote:
One of the reasons I suggested the code numbers for SHA-2 and SHA-3
that I did earlier is they guarantee that the first letter of the
fingerprint will be M (SHA-2 'Merkle') or S (SHA-3 'Spongeworthy').
Thus ensuring that they are distinct from SHA1 fingerprints.
The leading byte gives both the method of constructing the hash and
the algorithm to use. I suggest we define code points for SHA-2 and
SHA-3 using an identical construction approach.
In principle I'd like to see that both algos can generally be used with
a future OpenPGP, given the different class (Merkle-Damgard vs Sponge),
generally for the FP and other areas.
But I guess the majority here would want to have only one algorithm, at
least for the FP.
Is there any broad consensus already about SHA2 vs. SHA3 (except the
traditionalist argument)?
I think we can go even simpler:
Fingerprint = Base32ify (BinaryFP)
BinaryFP = ID + H( HashedValue)
HashedValue = <Content-Type> ':' <Data>
Isn't that what I've said? Or what is ID in your text?
At least I think the user should directly see the algorithm/version
without needing to decode the baseXXX.
Since the MIME content registry does not permit entries with a colon
in the tag, this is guaranteed to be unambiguous. And since a
Content-Type can be defined for any data object that might need to be
hashed, it can support any content.
All the PGP related information would go in the <Data> field, so that
would include the PGP format version identifier, algorithm code, etc,
etc.
Nah... that's bad IMHO... I really would want to know which algo I use
without turning on some BASExx decoder (which doesn't mean that one
cannot include it there as well).
And what's the content-type then in your thinking, if it's not the algo?
Just the information "this is a OpenPGP fingerprint"?
Then as I've said previously,.. I think this doesn't need to be part of
the core standard of OpenPGP,... but if it would be really just a
handful of MIME types e.g. one for "OpenPGP fingerprint" I would neither
strongly oppose this.
We should definitely split the consideration of QR codes etc out of
the PGP doc. We probably want to define the QR code in such a way that
a device can recognize that a QR code is intended to be a PGP key and
handle it appropriately. We also want to make sure we don't waste bits
in QR space. And it has to be possible to convert an ascii fingerprint
to QR format.
I should perhaps notice again, that in general it's IMHO rather a bad
idea to standardise "fingerprint formats" which are not directly
readable (including QR code or things like OpenSSH's ASCII art version
of the FP).
From a security point of view, we really don't need to go beyond 128
bits unless we are planning to use 256 bit encryption.
(The later, ) which would be nice...
We already have curves for that...
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp