On Fri 2021-02-26 12:53:11 +0100, Neal H. Walfield wrote:
Hi,
- Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves)
# Security Considerations
A compliant application MUST only use iterated and salted S2K to
protect private keys, as defined in {{iterated-and-salted-s2k}},
"Iterated and Salted S2K".
This precludes the use of private S2K algorithms (algos 100 to 110).
https://tools.ietf.org/html/rfc4880#section-3.7
Would a MUST NOT use Simple S2K and MUST NOT use Salted S2K be better?
I'm not sure about this at all. For example, consider a system that
knows that the string is high-entropy ("good key equivalent") -- should
they be prohibited from using Simple or Salted S2K? Is this MUST really
an interoperability concern as §6 of RFC 2119 suggests?
Furthermore, if this guidance is applicable to private key storage and
S2K, shouldn't it show up in those sections as well, not just in the
Security Considerations section?
I've opened a ticket to track this:
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/20
I welcome proposals for how to fix it.
--dkg
signature.asc
Description: PGP signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp