rpm 4.19.1.1 The RPM Package Manager

Loading...
Searching...
No Matches
Data Fields
pgpPktKeyV3_s Struct Reference
OpenPGP API.

`#include <rpmpgp.h>`

## Data Fields
uint8_t | version
pgpTime_t | time
uint8_t | valid [2]
uint8_t | pubkey_algo

## Detailed Description

5.5.1. Key Packet Variants

5.5.1.1. Public Key Packet (Tag 6)

A Public Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).

5.5.1.2. Public Subkey Packet (Tag 14)

A Public Subkey packet (tag 14) has exactly the same format as a Public Key packet, but denotes a subkey. One or more subkeys may be associated with a top-level key. By convention, the top-level key provides signature services, and the subkeys provide encryption services.

Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. This tag was selected for reuse because no previous version of PGP ever emitted comment packets but they did properly ignore them. Public Subkey packets are ignored by PGP 2.6.x and do not cause it to fail, providing a limited degree of backward compatibility.

5.5.1.3. Secret Key Packet (Tag 5)

A Secret Key packet contains all the information that is found in a Public Key packet, including the public key material, but also includes the secret key material after all the public key fields.

5.5.1.4. Secret Subkey Packet (Tag 7)

A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key packet, and has exactly the same format.

5.5.2. Public Key Packet Formats

There are two versions of key-material packets. Version 3 packets were first generated by PGP 2.6. Version 2 packets are identical in format to Version 3 packets, but are generated by PGP 2.5 or before. V2 packets are deprecated and they MUST NOT be generated. PGP 5.0 introduced version 4 packets, with new fields and semantics. PGP 2.6.x will not accept key-material packets with versions greater than 3.

OpenPGP implementations SHOULD create keys with version 4 format. An implementation MAY generate a V3 key to ensure interoperability with old software; note, however, that V4 keys correct some security deficiencies in V3 keys. These deficiencies are described below. An implementation MUST NOT create a V3 key with a public key algorithm other than RSA.

A version 3 public key or public subkey packet contains:

- A one-octet version number (3).
- A four-octet number denoting the time that the key was created.
- A two-octet number denoting the time in days that this key is valid. If this number is zero, then it does not expire.
- A one-octet number denoting the public key algorithm of this key
- A series of multi-precision integers comprising the key material:
  - a multiprecision integer (MPI) of RSA public modulus n;
  - an MPI of RSA public encryption exponent e.

V3 keys SHOULD only be used for backward compatibility because of three weaknesses in them. First, it is relatively easy to construct a V3 key that has the same key ID as any other key because the key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, which increases the opportunity for fingerprint collisions. Third, there are minor weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of key IDs and fingerprints.

## Field Documentation

## ◆ pubkey_algo

uint8_t pgpPktKeyV3_s::pubkey_algo

public key algorithm.

## ◆ time

pgpTime_t pgpPktKeyV3_s::time

time that the key was created.

## ◆ valid

uint8_t pgpPktKeyV3_s::valid[2]

time in days that this key is valid.

## ◆ version

uint8_t pgpPktKeyV3_s::version

version number (3).

The documentation for this struct was generated from the following file:

- /tmp/rpm-20240229-5467-git1p2/rpm-4.19.1.1/include/rpm/rpmpgp.h