On Mon, 1 Jun 2015 19:40, dkg(_at_)fifthhorseman(_dot_)net said:
I think i'm still not convinced by this -- can you give an example of
what kind of confusion you're hoping to avoid?
Alice reads her 40 hex digit fingerprints on the phone using oldtool;
Bob comapres it using his newtool, which shows a different fingerprint.
Both don't know anything about fingerprint details but have been advised
to compare them character by character. Their conclusion will be that
this is not the right key.
Even though I am not working on a helpdesk I have had phone conversions
to check X.509 fingerprints which ended into me explaining the different
types of fingerprints in use for X.509.
For ECC, being pretty new, we could easily switch to a new format but
what shall we keep on using the old for RSA keys?
Note that I do not insist on binding a new fingerprint format to the
public key format version, it is just something which needs to be
discussed.
Users can infer that keys using new algorithms will implicitly have the
new preferences; But we can also indicate the new preferences explicitly
within the old format.
Which new algorithms? I doubt that we will add a new cipher algorithm
to replace 3DES.
I think the main difference you're offering with a v5 format is the
ability to explicitly disavow the 4880 MTI algorithms. Is that right?
Yes. So that we won't need to support all old algorithms till 2106.
BTW, why do you and some others use the term MTI? That term seems to
mean mandatory-to-implement and comes from Jabber, to me this sounds
very much like MUST (cf. RFC-2119).
Maybe there are other ways that implementations can explicitly disavow
the 4880 MTI algorithms, that can be done without introducing a v5
format? What's the advantage of introducing a mandatory
incompatibility?
Not sure. However, we are right now discussing the charter ;-)
Salam-Shalom,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp