Compare commits

...

5 commits

Author SHA1 Message Date
heiko
82b3df12aa Merge pull request 'minor edits, mostly to update links' (#287) from minor-edits into main
Reviewed-on: https://codeberg.org/openpgp/notes/pulls/287
2025-10-01 17:39:00 +02:00
Heiko Schaefer
9c81b2d48c
Update links to RFC 9580 implementations 2025-10-01 15:39:18 +02:00
Heiko Schaefer
3ec4661835
Update CI config (fixes secrets handling)
This fixes new constraints that codeberg's woodpecker CI enforces
2025-10-01 15:39:17 +02:00
Heiko Schaefer
74cb033e91
Update RFC link in README 2025-10-01 15:39:17 +02:00
Heiko Schaefer
a6f3c283d8
Minor fixes: footnote, codespell, broken link 2025-10-01 15:39:17 +02:00
6 changed files with 24 additions and 17 deletions

View file

@ -3,7 +3,7 @@
steps: steps:
pages: pages:
image: woodpeckerci/plugin-docker-buildx image: woodpeckerci/plugin-docker-buildx:6.0.2
settings: settings:
output: type=local,dest=public output: type=local,dest=public
# do not push, push cannot be used with output simultaneously anyway # do not push, push cannot be used with output simultaneously anyway
@ -11,10 +11,14 @@ steps:
# do not refresh image # do not refresh image
pull_image: false pull_image: false
purge: false purge: false
when:
event: push
pages-pr-preview: pages-pr-preview:
image: bitnami/git image: bitnami/git
secrets: [ codeberg_token ] environment:
CODEBERG_TOKEN:
from_secret: codeberg_token
commands: commands:
- git config --global user.email heiko.schaefer+boiler@posteo.de - git config --global user.email heiko.schaefer+boiler@posteo.de
- git config --global user.name "Page Renderer" - git config --global user.name "Page Renderer"
@ -35,7 +39,9 @@ steps:
pages-publish: pages-publish:
image: bitnami/git image: bitnami/git
secrets: [ codeberg_token ] environment:
CODEBERG_TOKEN:
from_secret: codeberg_token
commands: commands:
- git config --global user.email heiko.schaefer+boiler@posteo.de - git config --global user.email heiko.schaefer+boiler@posteo.de
- git config --global user.name "Page Renderer" - git config --global user.name "Page Renderer"

View file

@ -11,7 +11,7 @@ The "Notes on OpenPGP" project aims to produce accessible documentation for the
A book for application developers who want to integrate OpenPGP functionality into their software. A book for application developers who want to integrate OpenPGP functionality into their software.
This book serves as a standalone introduction to the concepts of OpenPGP. It also introduces readers to the [OpenPGP RFC](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/). This book serves as a standalone introduction to the concepts of OpenPGP. It also introduces readers to the [OpenPGP RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html).
## Rendered versions of this text ## Rendered versions of this text

View file

@ -52,4 +52,4 @@ That is:
Note that some historical version 3 signature packets may still be relevant for applications that handle old OpenPGP data[^sig-v3]. These version 3 signature packets will have been generated by version 4 keys. Note that some historical version 3 signature packets may still be relevant for applications that handle old OpenPGP data[^sig-v3]. These version 3 signature packets will have been generated by version 4 keys.
[sig-v3]Version 4 signature packets were introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-5.2) in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2). [^sig-v3]: Version 4 signature packets were introduced in [RFC 2440](https://datatracker.ietf.org/doc/html/rfc2440#section-5.2) in 1998, which specifies that applications SHOULD generate v4 signature, however generation of v3 signature packets has remained allowed through [RFC 4880](https://www.rfc-editor.org/rfc/rfc4880.html#section-5.2).

View file

@ -35,7 +35,7 @@ Above, "plaintext" means one of:
- *signed message*. - *signed message*.
A *signed message*, in turn, is a packet sequence that either A *signed message*, in turn, is a packet sequence that either
- resembles an *inline-signed message* (a *Literal Data* packet sandwhiched between one or more *One-Pass-Signature* and their respective *Signature* packets), or a - resembles an *inline-signed message* (a *Literal Data* packet sandwiched between one or more *One-Pass-Signature* and their respective *Signature* packets), or a
- *prefixed-signed* message (one or more *Signature* packets followed by a single *Literal Data* packet). - *prefixed-signed* message (one or more *Signature* packets followed by a single *Literal Data* packet).
``` ```

View file

@ -110,5 +110,5 @@ In conclusion, converting v4 key material to v6 to verify old signatures is not
Being able to read old messages using a converted key is also not really viable, since it is equally simple to just re-create the PKESK headers for a fresh v6 key. Being able to read old messages using a converted key is also not really viable, since it is equally simple to just re-create the PKESK headers for a fresh v6 key.
```{note} ```{note}
Also see <https://wiki.gnupg.org/OpenPGPEmailSummit202305Notes> Also see <https://www.openpgp.org/community/email-summit/2023/minutes/#Historical_email_archive>
``` ```

View file

@ -84,20 +84,21 @@ Software and protocol development sometimes skips version numbers due to reasons
### OpenPGP version 6 ### OpenPGP version 6
As of this writing (in 2023), [version 6 of OpenPGP](https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/) is approaching publication as an RFC. [RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html) has been published in July 2024, it specifies new OpenPGP version 6 formats.
The [IETF OpenPGP working group](https://datatracker.ietf.org/wg/openpgp/about/#autoid-1) is focused on updating the cryptographic mechanisms, adding new algorithms, and the deprecation of obsolete algorithms. For this revision of the standard, the [IETF OpenPGP working group](https://datatracker.ietf.org/wg/openpgp/about/#autoid-1) has focused on updating the cryptographic mechanisms, adding new algorithms, and the deprecation of obsolete algorithms.
This document describes OpenPGP version 6, while pointing out differences to previous versions that are relevant to application developers. This document describes OpenPGP version 6, while pointing out differences to previous versions that are relevant to application developers.
Significant support for OpenPGP version 6 has already been achieved for multiple implementations, including: At this point, support for RFC 9580 and OpenPGP version 6 is available in many implementations, including:
- [Bouncy Castle Java](https://github.com/bcgit/bc-java/issues/1421), - [Bouncy Castle Java](https://github.com/bcgit/bc-java/) (since version 1.82),
- [GopenPGP](https://github.com/ProtonMail/gopenpgp/tree/v3), - [GopenPGP](https://github.com/ProtonMail/gopenpgp/) (since version 3.0.0),
- [OpenPGP.js](https://github.com/openpgpjs/openpgpjs/releases/tag/v6.0.0-alpha.0), - [OpenPGP.js](https://github.com/openpgpjs/openpgpjs/) (since version 6.0.0),
- [PGPy](https://github.com/dkg/PGPy/tree/dkg/crypto-refresh), - [PGPainless](https://github.com/pgpainless/pgpainless/) (since version 2.0.0),
- [Sequoia PGP](https://gitlab.com/sequoia-pgp/sequoia/-/tree/crypto-refresh). - [PGPy](https://github.com/dkg/PGPy/tree/dkg/crypto-refresh) (in a fork of the project),
- [RNP](https://github.com/rnpgp/rnp/) (since version 0.18),
Initial efforts to incorporate support for OpenPGP version 6 have been undertaken in the PGPainless and RNP implementations. - [rPGP](https://github.com/rpgp/rpgp/) (since version 0.14.0),
- [Sequoia PGP](https://gitlab.com/sequoia-pgp/sequoia/) (since version 2.0.0).
### Post-quantum cryptography in OpenPGP ### Post-quantum cryptography in OpenPGP