As an editorial remark, it would be nice if rfc4880bis were to use
a consistent representation for the secure hash algorithm families.
SHA1 is sometimes written as SHA1 and sometimes written as SHA-1.
I will also note that "SHA224" "SHA256" "SHA384" "SHA512" "SHA-224"
"SHA-256" "SHA-384" and "SHA-512" might want to be more completely
specified as members of the SHA-2 family [FISP180] by using the tag
"SHA2-224" "SHA2-256" "SHA2-384" and "SHA2-512" as the algorithm name in
section 9.5 as compared with members of the SHA-3 [FIPS202] family of
algorithms: SHA3-224, SHA3-256, SHA3-384, SHA3-512 (noting that the
SHA-3 family are NOT YET a part of rfc4880bis).
https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-01
Suggested update to section 9.3:
----------%<----------%<----------%<----------%<----------%<----------
9.3. {9.2} Symmetric-Key Algorithms
+-----------+-----------------------------------------------+
| ID | Algorithm |
+-----------+-----------------------------------------------+
| 0 | Plaintext or unencrypted data |
| 1 | IDEA [IDEA] |
| 2 | TripleDES (DES-EDE, [SCHNEIER] [HAC] |
| | - 168 bit key derived from 192) |
| 3 | CAST5 (128 bit key, as per [RFC2144]) |
| 4 | Blowfish (128 bit key, 16 rounds) [BLOWFISH] |
| 5 | Reserved |
| 6 | Reserved |
| 7 | AES with 128-bit key [AES] |
| 8 | AES with 192-bit key |
| 9 | AES with 256-bit key |
| 10 | Twofish with 256-bit key [TWOFISH] |
| 11 | Camellia with 128-bit key [RFC3713] |
| 12 | Camellia with 192-bit key |
| 13 | Camellia with 256-bit key |
| 100--110 | Private/Experimental algorithm |
+-----------+-----------------------------------------------+
Implementations SHOULD implement TripleDES. Implementations MUST
implement AES-128. Implementations MAY implement CAST5.
Implementations that interoperate with PGP 2.6 or earlier need to
support IDEA, as that is the only symmetric cipher those versions
use. Implementations MAY implement any other algorithm.
----------%<----------%<----------%<----------%<----------%<----------
and suggested update to section 9.5:
----------%<----------%<----------%<----------%<----------%<----------
9.5. {9.4} Hash Algorithms
+-----------+---------------------------------+--------------+
| ID | Algorithm | Text Name |
+-----------+---------------------------------+--------------+
| 1 | MD5 [HAC] | "MD5" |
| 2 | SHA-1 [FIPS180] | "SHA1" |
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" |
| 4 | Reserved | |
| 5 | Reserved | |
| 6 | Reserved | |
| 7 | Reserved | |
| 8 | SHA2-256 [FIPS180] | "SHA256" |
| 9 | SHA2-384 [FIPS180] | "SHA384" |
| 10 | SHA2-512 [FIPS180] | "SHA512" |
| 11 | SHA2-224 [FIPS180] | "SHA224" |
| 100--110 | Private/Experimental algorithm | |
+-----------+---------------------------------+--------------+
Implementations SHOULD implement SHA-1. Implementations MUST
implement SHA256. Implementations MAY implement other algorithms.
MD5 and RIPE-MD/160 are deprecated.
----------%<----------%<----------%<----------%<----------%<----------
Plus changes to 14.3.2:
----------%<----------%<----------%<----------%<----------%<----------
14.3.2. {13.3.2} Hash Algorithm Preferences
Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation.
Thus, if Alice is authenticating herself to Bob with a signature, it
makes sense for her to use a hash algorithm that Bob's software uses.
This preference allows Bob to state in his key which algorithms Alice
may use.
Since SHA256 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly.
----------%<----------%<----------%<----------%<----------%<----------
-- Mark
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp