Some thoughts, none really need answering.
On 10/04/2015 12:38 pm, Stephen Farrell wrote:
a) update the fingerprint format (avoid inclusion of creation date, use
stronger digest algorithm; i'm dubious about embedding algorithm
agility in the fingerprint itself, but explicit version info in the
fingerprint might be reasonable so we don't have to keep guessing by
fpr structure for future versions)
In the past, where I've had a very occasional need to indicate
version/alg in fingerprint like material, and full tagging wasn't
justified, I've used the length to do that. E.g., 16 bytes was MD5, 18
was NAH, 20 was SHA1. Clunky, but it served. Just a thought.
d) clarify that cleartext signatures should all use charset/encoding
UTF-8.
Are calculated over cleartext UTF-8 plaintext document as the default? OK.
(Not, the cleartext sigs are now to be delivered in UTF-8, or, the
cleartext sigs will be parsable unchanged and therefore compatible with
both US-ASCII and UTF-8.)
f) standardize the two new curves coming out of the CFRG: 25519 and
curve448 ("goldilocks") for both signatures and encryption (Werner
has already started this process for 25519 signatures)
Why two curves? Is this just the algorithm agility discussion or is
there an actual difference between them? Why not just use the stronger
one and be done with it?
(Not wishing to start the algorithm agility debate, I'm sure everyone's
familiar with the basics there, just wondering if there is any other
motivation.)
h) clean up the language: clearly distinguish between "public key" and
"certificate", and ensure that the use of the terms "trust" and
"validity", if still present, are used unambiguously.
It would be nice if we could eliminate the term "trust" altogether.
Humans trust, software agents cannot. Calling some bit a "trust bit" is
therefore almost guaranteed to become ambiguous, and the resultant
self-deception is one of the root causes of PKI failure in both x.509
and pgp circles.
In "theory" we might be better off replacing it with "policy" which is a
word that clearly indicates there should be some wider document that
describes what the bit is trying to record.
In the alternate, if we don't like the word "policy" perhaps "claim" or
"statement" or even "relationship graph link" or "edge" or...
i) declare a literal data packet type "m" that means "MIME content" so
that we can punt on the rest of the message
structure/format/encoding/type craziness to MIME.
j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can
get away with.
k) provide a modern streamable/chunkable AEAD replacement for
Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets
l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD
mechanism should be the baseline.
No RSA? Is there consensus amongst devs that enough of us aren't going
to implement RSA anyway? We're ready to make a clean break, and
actually mitigate against it?
(I'm happy to join the witch-burning party, but it's had such long legs,
it saw off the DSA challenger even tho many tried to kill it.)
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp