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
  • !113
Merged
Created Jan 04, 2022 by Andrew Gallagher@andrewgdotcomContributor
  • Review changes

  • Download
  • Email patches
  • Plain diff

Clarify which key creation time is used to calculate the key expiration time

  • Overview 8
  • Commits 2
  • Changes 1

This change is not related to crypto-refresh, but is an important clarification that should be without side-effects, and so IMO should be considered for -bis.

The ambiguity was identified through analysis of the Hockeypuck implementation (see https://github.com/hockeypuck/hockeypuck/issues/140). Key expiration times are stored as the number of seconds since the key creation time, but it is not explicitly stated whether the primary key or subkey creation time should be used as the origin for subkey binding signatures. Hockeypuck always measures expiry relative to the primary key creation time, whereas (most?) other implementations use the subkey creation time in sbinds.

This change explicitly states the common interpretation where subkey expiration times are calculated relative to the subkey's own creation time.

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: relative-expiry