Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
  • Sign in / Register
  • R rfc4880bis
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 40
    • Issues 40
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 18
    • Merge requests 18
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

GitLab 15.0 is launching on May 22! This version brings many exciting improvements, but also removes deprecated features and introduces breaking changes that may impact your workflow. To see what is being deprecated and removed, please visit Breaking changes in 15.0 and Deprecations.

  • openpgp-wg
  • rfc4880bis
  • Merge requests
  • !77
Closed
Created Oct 13, 2021 by Justus Winter@teythoonMaintainer
  • Review changes

  • Download
  • Email patches
  • Plain diff

Add a timestamp to secret key packets.

  • Overview 5
  • Commits 2
  • Changes 1

This timestamp denotes the time at which the secret key material was encrypted or decrypted. This allows implementations to decide which secret key material to keep when merging transferable secret keys.

Consider using a TSK on two devices. At some point, you decide to change the key's password on one device. Now, if for some reason you need to merge the TSKs again, which have diverged at least in the secret key encryption password, implementations previously had no way of telling which secret key packet to keep and which one to drop.

This timestamp allows implementations to make a decision that is at best consistent with user expectations, at worst deterministic.

Previously, this field was an octet count of the secret key material. Re-purposing this field as timestamp preserves compatibility with keys (and, to some extent, with code) created prior to the re-purposing:

  • The largest specified secret key format is RSA with four MPIs. A MPI can store 2**16 octets, resulting in 2**16 + 2 octets. Therefore, the secret key parameters can take up to 32776 octets. This corresponds to "Thu 01 Jan 1970 10:06:16 AM CET", so every timestamp will be newer than that.

  • Conversely, every current timestamp will be larger than 1634123369 or so, considerably larger than the packet's remaining extent. Code that pedantically checks whether the octet count equals the packet's extent will not accept keys with a timestamp. But, code that ignores this count (which was redundant to start with) and use the packet's extent will continue to work.

Edited Oct 13, 2021 by Justus Winter
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: justus/secret-key-timestamp