[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openpgp] details of 4880bis work



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/openpgp