Hi,
Current text says:
Implementations SHOULD generate V4 signatures. Implementations MUST
NOT create version 3 signatures; they MAY accept version 3
signatures.
There is no MUST create version. Is this intended to change?
Later (5.8):
This packet is obsolete. An implementation MUST NOT create this
packet. An implementation MAY process such a packet but it MUST
return a clear diagnostic that a non-integrity protected packet has
been processed. The implementation SHOULD also return an error in
this case and stop processing.
I'm confused by this text. If an implementation chooses to process this
packet type (e.g. I have 20-year-old PGP-encrypted messages that I'd still
like to be able to read without re-encrypting them), why are you saying
that it should return an error and stop processing? So it MAY process but
SHOULD stop processing? I'm confused.
Those were the only issues I noticed reading through this version.
Thank you for your hard work!
-derek
On Mon, February 22, 2021 9:19 pm, Paul Wouters wrote:
Hi,
I pushed an updated version of the crypto refresh document:
https://www.ietf.org/rfcdiff?url2=draft-ietf-openpgp-crypto-refresh-02
I've also pushed the git changes to
https://gitlab.com/openpgp-wg/rfc4880bis
The commit on white space changes was reverted, as the WG will be
re-opening that discussion later once we have all the consensus
items from the previous 4880bis discussion re-published in this
document.
The following items were merged in:
- Produce 4-level-deep ToC
- Reserve codepoints in the registries
- reorganize signature and asymmetric key value fields
- Re-flow the v3 and v4 signature descriptions
- Incorporated RFC 6637 (ECDSA and ECDH, using NIST curves)
- textual cleanup (no substantive changes)
- Update most registries to be SPECIFICATION REQUIRED
- Deprecate v3 signatures
- Deprecate non-integrity-protected encryption
- Include SHA3
- Incorporate Curve25519 for ECDH
- Add ECC Point compression flag bytes appendix section
- update reference RFC2434 to RFC8126
Please review the changes and let the WG know of any issues you see.
This includes if you think something was merged that did not have WG
consensus.
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
--
Derek Atkins 617-623-3745
derek(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp