1. 22 Aug, 2022 1 commit
  2. 19 Jul, 2022 1 commit
  3. 09 Jun, 2022 1 commit
  4. 07 Jun, 2022 2 commits
  5. 06 Jun, 2022 3 commits
  6. 03 Jun, 2022 3 commits
  7. 01 Jun, 2022 5 commits
  8. 30 May, 2022 2 commits
  9. 25 May, 2022 4 commits
    • Justus Winter's avatar
      Add note that it is okay to knowingly ignore packets. · e8b7c521
      Justus Winter authored
      This is borrowed from the signature subpacket framework.
    • Justus Winter's avatar
    • Justus Winter's avatar
      Partition the Packet Tag space into critical and non-critical. · 513ef08a
      Justus Winter authored
      This introduces the concept of Packet Criticality.  If an unknown
      critical packet is encountered in a Packet Sequence, the whole
      sequence MUST be rejected.  On the other hand, unknown non-critical
      packets MUST be ignored.  This provides a way to extend the protocol
      in a forward-compatible way.
      The idea of Packet Criticality is borrowed from the Signature
      Subpacket Framework, where it can be toggled independently from the
      Subpacket Tag.  This is possible because the critical flag is
      protected by the signature.
      On the other hand, the integrity of Packet Framing is not (usually)
      protected, hence may be altered by an attacker.  Therefore, we bind
      Packet Criticality to the Packet Type: now altering the criticality
      alters the type, changing its semantic at the same time.
      We also tighten the rules with regards to unexpected packets in Packet
      Sequences: known, non-critical, yet unexpected packets are not
      allowed.  Picture that we introduce a non-critical packet in the
      future that only makes sense in an OpenPGP Message sequence.
      Implementations that don't yet know this packet will consider it
      unknown, and hence will unfortunately accept it in a TPK.  But
      implementations that do know this packet should reject it in a TPK,
      because it is now known but unexpected.
    • Daniel Kahn Gillmor's avatar
      Document "strict" packet type grammars · b0bdd426
      Daniel Kahn Gillmor authored and Justus Winter's avatar Justus Winter committed
      A strict grammar has the benefit that it is harder to craft a packet
      sequence that might (for example) decrypt to one cleartext in one
      implementation, and a different cleartext in a different
      Encouraging implementations to be strict in their grammars should
      avoid this kind of interoperability failure.
      In the next step, we will partition the unallocated packet space into
      critical and non-critical packets.  This way, making the grammar
      strict doesn't lose any potential future flexibility.
      Closes: #121
  10. 24 May, 2022 12 commits
  11. 20 May, 2022 6 commits