mirror of
https://codeberg.org/openpgp/notes.git
synced 2024-11-25 17:12:06 +01:00
Compare commits
No commits in common. "8901753d1624e08f19a18998941ba3c9f929017d" and "300f98ec3e3fddb5bdc6a348105bd73f2f965e09" have entirely different histories.
8901753d16
...
300f98ec3e
19 changed files with 1094 additions and 1371 deletions
|
|
@ -18,7 +18,7 @@ steps:
|
|||
image: archlinux:latest
|
||||
commands:
|
||||
- pacman -Sy --needed --noconfirm archlinux-keyring
|
||||
- pacman -Syu --needed --noconfirm epubcheck inkscape noto-fonts make patch python-myst-parser python-sphinx python-sphinxext-opengraph python-sphinx-sitemap ttf-montserrat
|
||||
- pacman -Syu --needed --noconfirm epubcheck inkscape noto-fonts make patch python-myst-parser python-sphinx python-sphinxext-opengraph ttf-montserrat
|
||||
# fix sphinx: https://github.com/sphinx-doc/sphinx/issues/11598
|
||||
- patch -Np1 -d /usr/lib/python3.11/site-packages/ -i "$(pwd)/book/patches/sphinx-11766.patch"
|
||||
- make -C book epub-check
|
||||
|
|
|
|||
|
|
@ -19,5 +19,5 @@ steps:
|
|||
image: archlinux:latest
|
||||
commands:
|
||||
- pacman -Sy --needed --noconfirm archlinux-keyring
|
||||
- pacman -Syu --needed --noconfirm inkscape lychee make noto-fonts python-myst-parser python-sphinx python-sphinxext-opengraph python-sphinx-sitemap ttf-montserrat
|
||||
- pacman -Syu --needed --noconfirm inkscape lychee make noto-fonts python-myst-parser python-sphinx python-sphinxext-opengraph ttf-montserrat
|
||||
- make -C book html-linkcheck
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ WORKDIR /book
|
|||
# fix EPUB rendering: https://github.com/sphinx-doc/sphinx/issues/11598
|
||||
RUN \
|
||||
pacman -Sy --needed --noconfirm archlinux-keyring \
|
||||
&& pacman -Syu --needed --noconfirm inkscape make noto-fonts patch python-myst-parser python-sphinx python-sphinxext-opengraph python-sphinx-sitemap ttf-montserrat \
|
||||
&& pacman -Syu --needed --noconfirm inkscape make noto-fonts patch python-myst-parser python-sphinx python-sphinxext-opengraph ttf-montserrat \
|
||||
&& patch -Np1 -d /usr/lib/python3.11/site-packages/ -i /book/patches/sphinx-11766.patch \
|
||||
&& make epub html
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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 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/).
|
||||
|
||||
## Rendered versions of this text
|
||||
|
||||
|
|
|
|||
|
|
@ -1,74 +0,0 @@
|
|||
<mxfile host="app.diagrams.net" modified="2023-12-19T17:47:29.230Z" agent="Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0" etag="CuD1JH9_KP5-_UnQaIqH" version="22.1.11" type="device">
|
||||
<diagram name="Seite-1" id="06IJX984rhBGnz6KE12L">
|
||||
<mxGraphModel dx="2261" dy="708" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-4" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="9NkdM7txntXo-xmCDq8w-1" target="9NkdM7txntXo-xmCDq8w-3" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-12" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="9NkdM7txntXo-xmCDq8w-1" target="9NkdM7txntXo-xmCDq8w-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="480" y="310" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-1" value="<div>One-Pass-Signature</div><div>Hash: SHA512</div><div>Fingerprint: 0xB0B0<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="50" y="160" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-2" value="<div>Literal Data</div><div>"Hello World!"<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="170" y="160" width="250" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-17" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-3" target="9NkdM7txntXo-xmCDq8w-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-3" value="<div>Signature</div><div>Hash: SHA512<br></div><div>Issuer: B0B0<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="420" y="160" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-8" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=0;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;" parent="1" source="9NkdM7txntXo-xmCDq8w-6" target="9NkdM7txntXo-xmCDq8w-7" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<Array as="points">
|
||||
<mxPoint x="-10" y="120" />
|
||||
<mxPoint x="660" y="120" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-13" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0;entryY=0.5;entryDx=0;entryDy=0;" parent="1" source="9NkdM7txntXo-xmCDq8w-6" target="9NkdM7txntXo-xmCDq8w-16" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="640" y="420" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-6" value="<div>One-Pass-Signature</div><div>Hash: SHA384</div><div>Fingerprint: 0xB0B1<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="-70" y="160" width="120" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-18" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;startArrow=classic;startFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-7" target="9NkdM7txntXo-xmCDq8w-16" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-7" value="<div>Signature</div><div>Hash: SHA384<br></div><div>Issuer: B0B1<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="580" y="160" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-19" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.1;exitY=0.5;exitDx=0;exitDy=0;exitPerimeter=0;endArrow=oval;endFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-9" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="310" y="280" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-9" value="" style="shape=curlyBracket;whiteSpace=wrap;html=1;rounded=1;labelPosition=left;verticalLabelPosition=middle;align=right;verticalAlign=middle;rotation=-90;" parent="1" vertex="1">
|
||||
<mxGeometry x="300" y="140" width="20" height="220" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-20" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;endArrow=oval;endFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-10" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="310" y="310" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-10" value=""Hello World!" is hashed" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="237.5" y="220" width="145" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-14" value="SHA512 Hash" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="440" y="260" width="120" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-16" value="SHA384 Hash" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="600" y="290" width="120" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 12 KiB |
|
|
@ -1,63 +0,0 @@
|
|||
<mxfile host="app.diagrams.net" modified="2023-12-19T17:51:29.565Z" agent="Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0" etag="_bWwKk-sC-z0pngoIar_" version="22.1.11" type="device">
|
||||
<diagram name="Seite-1" id="06IJX984rhBGnz6KE12L">
|
||||
<mxGraphModel dx="2261" dy="708" grid="1" gridSize="10" guides="1" tooltips="1" connect="1" arrows="1" fold="1" page="1" pageScale="1" pageWidth="827" pageHeight="1169" math="0" shadow="0">
|
||||
<root>
|
||||
<mxCell id="0" />
|
||||
<mxCell id="1" parent="0" />
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-2" value="<div>Literal Data</div><div>"Hello World!"<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="170" y="160" width="250" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-24" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;entryX=0.5;entryY=0;entryDx=0;entryDy=0;startArrow=classic;startFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-3" target="9NkdM7txntXo-xmCDq8w-16" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-26" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;endArrow=none;endFill=0;" parent="1" source="9NkdM7txntXo-xmCDq8w-3" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="310" y="360" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="-70" y="360" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-3" value="<div>Signature</div><div>Hash: SHA384<br></div><div>Issuer: B0B0<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="-150" y="160" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-21" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;startArrow=none;startFill=0;endArrow=none;endFill=0;" parent="1" source="9NkdM7txntXo-xmCDq8w-7" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="310" y="270" as="targetPoint" />
|
||||
<Array as="points">
|
||||
<mxPoint x="90" y="270" />
|
||||
</Array>
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-22" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.5;exitY=1;exitDx=0;exitDy=0;startArrow=classic;startFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-7" target="9NkdM7txntXo-xmCDq8w-14" edge="1">
|
||||
<mxGeometry relative="1" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-7" value="<div>Signature</div><div>Hash: SHA512<br></div><div>Issuer: B0B1<br></div>" style="rounded=0;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="10" y="160" width="160" height="60" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-19" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.1;exitY=0.5;exitDx=0;exitDy=0;exitPerimeter=0;endArrow=oval;endFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-9" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="310" y="270" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-23" style="edgeStyle=orthogonalEdgeStyle;rounded=0;orthogonalLoop=1;jettySize=auto;html=1;exitX=0.1;exitY=0.5;exitDx=0;exitDy=0;exitPerimeter=0;endArrow=oval;endFill=1;" parent="1" source="9NkdM7txntXo-xmCDq8w-9" edge="1">
|
||||
<mxGeometry relative="1" as="geometry">
|
||||
<mxPoint x="310" y="360" as="targetPoint" />
|
||||
</mxGeometry>
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-9" value="" style="shape=curlyBracket;whiteSpace=wrap;html=1;rounded=1;labelPosition=left;verticalLabelPosition=middle;align=right;verticalAlign=middle;rotation=-90;" parent="1" vertex="1">
|
||||
<mxGeometry x="300" y="140" width="20" height="220" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-10" value=""Hello World!" is hashed" style="text;html=1;strokeColor=none;fillColor=none;align=center;verticalAlign=middle;whiteSpace=wrap;rounded=0;" parent="1" vertex="1">
|
||||
<mxGeometry x="237.5" y="220" width="145" height="30" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-14" value="SHA512 Hash" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="30" y="300" width="120" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
<mxCell id="9NkdM7txntXo-xmCDq8w-16" value="SHA384 Hash" style="rounded=1;whiteSpace=wrap;html=1;" parent="1" vertex="1">
|
||||
<mxGeometry x="-130" y="390" width="120" height="40" as="geometry" />
|
||||
</mxCell>
|
||||
</root>
|
||||
</mxGraphModel>
|
||||
</diagram>
|
||||
</mxfile>
|
||||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 8.4 KiB |
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 147 KiB After Width: | Height: | Size: 147 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 8.4 KiB |
|
|
@ -1,12 +1,12 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
viewBox="72 -5 170 170"
|
||||
viewBox="0 0 289.7142 162.06558"
|
||||
version="1.1"
|
||||
id="svg1"
|
||||
sodipodi:docname="logo.svg"
|
||||
inkscape:version="1.3.2 (091e20ef0f, 2023-11-25)"
|
||||
width="170"
|
||||
height="170"
|
||||
sodipodi:docname="diag_library_draft.svg"
|
||||
inkscape:version="1.3 (0e150ed6c4, 2023-07-21)"
|
||||
width="289.7142"
|
||||
height="162.06558"
|
||||
xml:space="preserve"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
|
|
@ -64,60 +64,57 @@
|
|||
inkscape:pagecheckerboard="0"
|
||||
inkscape:deskcolor="#d1d1d1"
|
||||
inkscape:lockguides="false"
|
||||
inkscape:zoom="1.8101934"
|
||||
inkscape:cx="442.21795"
|
||||
inkscape:cy="-63.805339"
|
||||
inkscape:zoom="2"
|
||||
inkscape:cx="2755.25"
|
||||
inkscape:cy="-1707.25"
|
||||
inkscape:window-width="2560"
|
||||
inkscape:window-height="1415"
|
||||
inkscape:window-height="1371"
|
||||
inkscape:window-x="0"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-y="314"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="layer31"
|
||||
showgrid="false"
|
||||
inkscape:export-bgcolor="#ffffff00"
|
||||
showguides="true"><sodipodi:guide
|
||||
position="1616.9091,-4149.1099"
|
||||
position="1616.9091,-4157.0443"
|
||||
orientation="0,-1"
|
||||
id="guide360"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="1460.6512,-3963.7147"
|
||||
position="1460.6512,-3971.6491"
|
||||
orientation="0,659.35662"
|
||||
id="guide361"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="2281.0798,273.36511"
|
||||
position="2281.0798,265.43069"
|
||||
orientation="943.88005,0"
|
||||
id="guide362"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="2120.0079,-4907.5948"
|
||||
position="2120.0079,-4915.5291"
|
||||
orientation="0,-659.35662"
|
||||
id="guide363"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="1460.6512,-4907.5948"
|
||||
position="1460.6512,-4915.5291"
|
||||
orientation="-943.88005,0"
|
||||
id="guide364"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="1460.6512,-3963.7147"
|
||||
position="1460.6512,-3971.6491"
|
||||
orientation="0,659.35662"
|
||||
id="guide365"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="2120.0079,-4907.5948"
|
||||
position="2120.0079,-4915.5291"
|
||||
orientation="0,-659.35662"
|
||||
id="guide367"
|
||||
inkscape:locked="false" /><sodipodi:guide
|
||||
position="1460.6512,-4907.5948"
|
||||
position="1460.6512,-4915.5291"
|
||||
orientation="-943.88005,0"
|
||||
id="guide368"
|
||||
inkscape:locked="false" /><inkscape:page
|
||||
x="4.1775389"
|
||||
y="35.996181"
|
||||
width="160.08543"
|
||||
height="103.21368"
|
||||
x="6.7782037e-07"
|
||||
y="-1.4691306e-05"
|
||||
width="289.7142"
|
||||
height="162.06558"
|
||||
id="page94"
|
||||
margin="0"
|
||||
bleed="0"
|
||||
inkscape:export-filename="logo.png"
|
||||
inkscape:export-xdpi="102.31203"
|
||||
inkscape:export-ydpi="102.31203" /></sodipodi:namedview><!--! Font Awesome Pro 6.4.2 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license (Commercial License) Copyright 2023 Fonticons, Inc. --><g
|
||||
bleed="0" /></sodipodi:namedview><!--! Font Awesome Pro 6.4.2 by @fontawesome - https://fontawesome.com License - https://fontawesome.com/license (Commercial License) Copyright 2023 Fonticons, Inc. --><g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer18"
|
||||
inkscape:label="Chapter 6"
|
||||
|
|
@ -125,17 +122,16 @@
|
|||
transform="translate(-864.87878,2550.6205)"><g
|
||||
inkscape:groupmode="layer"
|
||||
id="layer31"
|
||||
inkscape:label="OpenPGP signature packet"><g
|
||||
id="g1"><path
|
||||
id="path2-1-4-5-1-7-1"
|
||||
style="display:inline;mix-blend-mode:multiply;fill:url(#pattern180);fill-opacity:1;stroke:none;stroke-width:5.8655;stroke-linecap:round;stroke-dasharray:none;stroke-opacity:1"
|
||||
inkscape:label="Publickey ((Asym))"
|
||||
d="m 1066.5807,-2416.4209 c 18.627,0.4549 34.0958,-14.2763 34.5508,-32.9033 0.4549,-18.627 -14.2763,-34.0964 -32.9033,-34.5513 -13.0896,-0.3198 -24.6829,7.9128 -30.5393,18.6737 l -0.02,0.6846 c -5.8504,-0.083 -12.9906,-0.3268 -19.4381,-0.4843 l -6.5249,4.132 -8.0925,-4.489 -8.29796,3.9224 -6.10817,-0.1492 -6.38326,-4.281 -10.01748,3.8804 -9.07911,-4.3467 -12.70174,13.9931 12.00349,14.5971 73.79643,1.8024 -0.01,0.2382 c 5.2187,11.3157 16.4642,18.9558 29.7626,19.2806 z m 16.2144,-25.7678 a 7.1906559,7.1906559 0 0 1 -7.0131,-7.3643 7.1906559,7.1906559 0 0 1 7.3642,-7.013 7.1906559,7.1906559 0 0 1 7.0131,7.3642 7.1906559,7.1906559 0 0 1 -7.3642,7.0131 z" /><path
|
||||
id="path2-1-4-5-8"
|
||||
style="display:inline;mix-blend-mode:multiply;fill:none;fill-opacity:1;stroke:#006961;stroke-width:10.4431;stroke-linecap:round;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 156.30312,759.25868 c -9.78054,19.91382 -30.12868,33.02384 -53.81237,33.02384 -33.173715,0 -60.066326,-26.89261 -60.066326,-60.06633 0,-33.17372 26.892611,-60.06633 60.066326,-60.06633 23.31181,0 43.58824,15.15712 53.54415,34.5646 m -9.14624,1.20213 h 4.97796 c 10.89491,0.20296 25.86265,0 38.79397,0 l 11.43353,7.63836 14.59897,-7.63836 14.59896,7.3422 h 10.87817 l 11.54761,-7.3422 17.66083,7.3422 16.34856,-7.34219 22,25.45886 -22,25.45887 h -135.8606 -4.97796 M 89.058073,732.21619 c -4e-6,6.98969 -5.666271,12.65596 -12.655965,12.65596 -6.989695,0 -12.655963,-5.66627 -12.655967,-12.65596 -2e-6,-6.9897 5.666268,-12.65597 12.655967,-12.65597 6.989698,0 12.655967,5.66627 12.655965,12.65597 z"
|
||||
inkscape:label="Publickey ((Asym))"
|
||||
sodipodi:nodetypes="cssscccccccccccccccsssss"
|
||||
transform="matrix(0.56166813,0,0,-0.56166813,920.16065,-2071.6917)"
|
||||
inkscape:path-effect="#path-effect32-1-0-4-9"
|
||||
inkscape:original-d="m 156.30312,759.25868 c -9.78054,19.91382 -30.12868,33.02384 -53.81237,33.02384 -33.173715,0 -60.066326,-26.89261 -60.066326,-60.06633 0,-33.17372 26.892611,-60.06633 60.066326,-60.06633 23.31181,0 43.58824,15.15712 53.54415,34.5646 m -9.14624,1.20213 h 4.97796 c 10.89491,0.20296 25.86265,0 38.79397,0 l 11.43353,7.63836 14.59897,-7.63836 14.59896,7.3422 h 10.87817 l 11.54761,-7.3422 17.66083,7.3422 16.34856,-7.34219 22,25.45886 -22,25.45887 h -135.8606 -4.97796 M 89.058073,732.21619 c -4e-6,6.98969 -5.666271,12.65596 -12.655965,12.65596 -6.989695,0 -12.655963,-5.66627 -12.655967,-12.65596 -2e-6,-6.9897 5.666268,-12.65597 12.655967,-12.65597 6.989698,0 12.655967,5.66627 12.655965,12.65597 z" /></g></g></g></svg>
|
||||
inkscape:label="OpenPGP signature packet"><path
|
||||
id="path2-1-4-5-1-7-1"
|
||||
style="display:inline;mix-blend-mode:multiply;fill:url(#pattern180);fill-opacity:1;stroke:none;stroke-width:5.8655;stroke-linecap:round;stroke-dasharray:none;stroke-opacity:1"
|
||||
inkscape:label="Publickey ((Asym))"
|
||||
d="m 1066.5807,-2416.4209 c 18.627,0.4549 34.0958,-14.2763 34.5508,-32.9033 0.4549,-18.627 -14.2763,-34.0964 -32.9033,-34.5513 -13.0896,-0.3198 -24.6829,7.9128 -30.5393,18.6737 l -0.02,0.6846 c -5.8504,-0.083 -12.9906,-0.3268 -19.4381,-0.4843 l -6.5249,4.132 -8.0925,-4.489 -8.29796,3.9224 -6.10817,-0.1492 -6.38326,-4.281 -10.01748,3.8804 -9.07911,-4.3467 -12.70174,13.9931 12.00349,14.5971 73.79643,1.8024 -0.01,0.2382 c 5.2187,11.3157 16.4642,18.9558 29.7626,19.2806 z m 16.2144,-25.7678 a 7.1906559,7.1906559 0 0 1 -7.0131,-7.3643 7.1906559,7.1906559 0 0 1 7.3642,-7.013 7.1906559,7.1906559 0 0 1 7.0131,7.3642 7.1906559,7.1906559 0 0 1 -7.3642,7.0131 z" /><path
|
||||
id="path2-1-4-5-8"
|
||||
style="display:inline;mix-blend-mode:multiply;fill:none;fill-opacity:1;stroke:#006961;stroke-width:10.4431;stroke-linecap:round;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 156.30312,759.25868 c -9.78054,19.91382 -30.12868,33.02384 -53.81237,33.02384 -33.173715,0 -60.066326,-26.89261 -60.066326,-60.06633 0,-33.17372 26.892611,-60.06633 60.066326,-60.06633 23.31181,0 43.58824,15.15712 53.54415,34.5646 m -9.14624,1.20213 h 4.97796 c 10.89491,0.20296 25.86265,0 38.79397,0 l 11.43353,7.63836 14.59897,-7.63836 14.59896,7.3422 h 10.87817 l 11.54761,-7.3422 17.66083,7.3422 16.34856,-7.34219 22,25.45886 -22,25.45887 h -135.8606 -4.97796 M 89.058073,732.21619 c -4e-6,6.98969 -5.666271,12.65596 -12.655965,12.65596 -6.989695,0 -12.655963,-5.66627 -12.655967,-12.65596 -2e-6,-6.9897 5.666268,-12.65597 12.655967,-12.65597 6.989698,0 12.655967,5.66627 12.655965,12.65597 z"
|
||||
inkscape:label="Publickey ((Asym))"
|
||||
sodipodi:nodetypes="cssscccccccccccccccsssss"
|
||||
transform="matrix(0.56166813,0,0,-0.56166813,920.16065,-2071.6917)"
|
||||
inkscape:path-effect="#path-effect32-1-0-4-9"
|
||||
inkscape:original-d="m 156.30312,759.25868 c -9.78054,19.91382 -30.12868,33.02384 -53.81237,33.02384 -33.173715,0 -60.066326,-26.89261 -60.066326,-60.06633 0,-33.17372 26.892611,-60.06633 60.066326,-60.06633 23.31181,0 43.58824,15.15712 53.54415,34.5646 m -9.14624,1.20213 h 4.97796 c 10.89491,0.20296 25.86265,0 38.79397,0 l 11.43353,7.63836 14.59897,-7.63836 14.59896,7.3422 h 10.87817 l 11.54761,-7.3422 17.66083,7.3422 16.34856,-7.34219 22,25.45886 -22,25.45887 h -135.8606 -4.97796 M 89.058073,732.21619 c -4e-6,6.98969 -5.666271,12.65596 -12.655965,12.65596 -6.989695,0 -12.655963,-5.66627 -12.655967,-12.65596 -2e-6,-6.9897 5.666268,-12.65597 12.655967,-12.65597 6.989698,0 12.655967,5.66627 12.655965,12.65597 z" /></g></g></svg>
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 9.6 KiB After Width: | Height: | Size: 9.4 KiB |
|
|
@ -226,7 +226,7 @@ Disadvantages/risks of minimizing certificates:
|
|||
- Refreshing certificates from key servers may inflate the certificate again, since OpenPGP certificates tend to act as [append-only structures](append-only).
|
||||
- Some libraries, such as [anonaddy-sequoia](https://gitlab.com/willbrowning/anonaddy-sequoia/-/blob/master/src/sequoia.rs?ref_type=heads#L125) strip unusable encryption subkeys, but retain at least one subkey, even if all subkeys are expired. Although this may leave only an expired encryption subkey in the certificate, this presents a better UX for the end-user who potentially is still in possession of the private key for decryption.
|
||||
|
||||
### Guidelines
|
||||
## Guidelines
|
||||
|
||||
1. Don't minimize certificates unless you have a good reason to.
|
||||
2. When minimizing a certificate, minimize it in a way that suites your use-case. E.g., when minimizing a certificate for distribution alongside a signed software packet, make sure to include enough historical self-signatures as to not break the verification of the signed packet.
|
||||
|
|
|
|||
|
|
@ -67,17 +67,15 @@ In addition to key management, a keystore often involves various supplementary f
|
|||
|
||||
OpenPGP is subject to specific vulnerabilities known as key overwriting (KO) attacks. These attacks exploit weaknesses in how encrypted private keys or their metadata are handled, potentially leading to the leakage of secret data when the key is used. The core issue lies in OpenPGP's handling of Secret-Key packets, where corruption of the non-encrypted fields can cause the unaltered private key material to be used with altered parameters. This mismatch can result in private key leakage.
|
||||
|
||||
Importantly, KO attacks are particularly relevant in scenarios where an attacker has control over the storage of a user's encrypted private key. By manipulating the algorithm field in the Secret-Key packet, the attacker may lead the user to perform a cryptographic operation with a different algorithm. For example, the user might unknowingly perform a DSA operation with ECC private key material. Although the attacker does not have direct access to the encrypted private key material, the attacker can deduce and recover the user's unencrypted private key material by observing the output of this compromised operation.
|
||||
Importantly, KO attacks are particularly relevant when an attacker is responsible for storing a user's encrypted private key. By altering the algorithm field in the Secret-Key packet, the attacker may cause the user to perform a cryptographic operation with a different algorithm. E.g., performing a DSA operation with ECC private key material. By observing the output of that attacker-corrupted operation, the attacker can recover the user's unencrypted private key material, even though the attacker had no direct access to it.
|
||||
|
||||
### Mitigation
|
||||
|
||||
Understanding KO attacks is crucial due to their potential to compromise the integrity and confidentiality of encrypted communications, and the risk of complete private key material compromise. KO attacks highlight the necessity for robust key validation procedures and the dangers of storing keys in insecure environments. OpenPGP application developers should conduct a risk assessment to determine the relevance of KO attacks to their applications.
|
||||
Understanding KO attacks is crucial due to their potential to compromise the integrity and confidentiality of encrypted communications, and the risk of complete private key material compromise. KO attacks highlight the necessity for robust key validation procedures and the dangers of storing keys in insecure environments. OpenPGP application developers should consider if this attack class is a concern in their applications.
|
||||
|
||||
Private keys secured with [S2K usage mode 253 (AEAD)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-secret-key-encryption) are safeguarded against KO attacks. This mode ensures the integrity of the private key by using its unencrypted fields, including the algorithm field, as the *authentication tag* for integrity verification in the decryption process.
|
||||
Private keys that are protected with [S2K usage mode 253 (AEAD)](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-secret-key-encryption), are not vulnerable to KO attacks. This mode ensures the integrity of the private key by using its unencrypted fields (including the algorithm field) as the *authentication tag* for integrity verification in the decryption process. When an attacker alters the unencrypted part of the packet, then decryption of the private key material will fail, and the user is prevented from e.g. accidentally using the key material with an altered attacker-controlled algorithm.
|
||||
|
||||
When an attacker alters the unencrypted part of the Secret-Key packet, then decryption of the private key material will fail. This effectively prevents the user from unknowingly using the key material with an altered attacker-controlled algorithm.
|
||||
|
||||
Note that while S2K usage mode 253 (AEAD) has been introduced in the OpenPGP version 6 specification, it can also be applied to OpenPGP version 4 key material (see {ref}`migration-s2k`).
|
||||
Note that while S2K usage mode 253 (AEAD) has been introduced in the OpenPGP version 6 specification, it can also be applied to OpenPGP version 4 key material (also see {ref}`migration-s2k`).
|
||||
|
||||
#### Resources
|
||||
|
||||
|
|
|
|||
|
|
@ -16,30 +16,30 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
|
||||
## Choosing the hash algorithm for a signature
|
||||
|
||||
A central element of signature packets is the hash digest of the input data. OpenPGP software typically supports a variety of hash mechanisms. This ability to choose from multiple options is part of what makes OpenPGP flexible in its cryptography, a feature known as *cryptographic agility*. The chosen mechanism is then used to calculate the hash digest.
|
||||
A central element of signature packets is the hash digest of the input data. Most OpenPGP software supports a set of different hash mechanisms, of which one is chosen for each signature packet (this is one aspect of OpenPGP's *cryptographic agility*), and used to calculate the hash digest.
|
||||
|
||||
Different hash mechanisms offer different trade-offs:
|
||||
|
||||
- *Hash digest size*: The size of the hash digest is a crucial consideration. Generally, a larger hash size is more robust against cryptanalysis. Hash digests are relatively small – typically ranging in size from 32 to 64 bytes. However, in some cases - especially where messages are transmitted over bandwidth-limited networks - larger hash sizes may unacceptably increase message size.
|
||||
- *Computational cost*: Different hash algorithms have different computational costs. Where computing environments are constrained, for example, some OpenPGP users may prefer to limit this cost.
|
||||
- *Hash digest size*: Larger hash size tends to correspond with greater strength against cryptanalysis, and hash digests are relatively small: at the time of this writing, typical sizes are 32 to 64 bytes. However, for some use cases - especially where small messages are sent over a bandwidth-limited transport - larger hash sizes may unacceptably increase message size.
|
||||
- *Computational cost*: Different hash algorithms may have different computational costs. Some OpenPGP users may prefer to limit this cost, for example on constrained computing environments.
|
||||
|
||||
Choosing the hash algorithm is not arbitrary but is guided by specific preferences associated with the OpenPGP certificates involved. The following sections discuss how these preferences influence which hash algorithm is chosen.
|
||||
The following sections discuss how the hash algorithm is chosen, based on preferences that are associated with the involved OpenPGP certificates.
|
||||
|
||||
### General signature context, local algorithm choice
|
||||
### Typically: Local determination
|
||||
|
||||
In many instances, the creation of a signature is not intended for a specific individual or entity. Instead, these signatures are designed to be valid for any recipient who might encounter them.
|
||||
Often, signature creation isn't targeted at a specific receiver. Many signatures are issued for an indeterminate set of "anyone who receives the signature."
|
||||
|
||||
Take, for example, the self-signatures that are part of a certificate. These are intended for a wide audience — essentially, anyone who might interact with the certificate. Another example is the data signatures used for software packages. These signatures are not for a single recipient but for any user or system that verifies the signature, potentially spanning years.
|
||||
For example, self-signatures that form a certificate are aimed at everyone who interacts with that certificate. Similarly, when creating a data signature for a software package, this signature is aimed at "anyone who will check the signature," often over a long period of time, easily spanning years.
|
||||
|
||||
In such cases, where there isn't a specific recipient in mind, the issuer of the signature has the freedom to select the hash algorithm. This choice is made based on the issuer's own criteria or requirements, independent of any third party.
|
||||
In such cases, the issuer of that signature chooses the hash algorithm locally, without following preferences of a third party.
|
||||
|
||||
### Specific signature context, recipient-driven choice
|
||||
### With a specific recipient: "Negotiation" based on recipient's preferences
|
||||
|
||||
When a message is being prepared for a particular recipient, the selection of the hash algorithm for the signature packet should be guided by [the recipient's hash algorithm preference](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hash-algorithm-preferences).
|
||||
In contrast, when a message is created for a specific recipient, the sender can - and should - choose the hash algorithm for the signature packet [based on the recipient's hash algorithm preference](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-hash-algorithm-preferences).
|
||||
|
||||
The recipient's hash algorithm preference is defined in the metadata of their OpenPGP certificate. See {ref}`preferences-features` for more details.
|
||||
The recipient's hash algorithm preference is defined in metadata of their certificate, see {ref}`preferences-features` for more details.
|
||||
|
||||
In this workflow, the signed hash digest is created with a hash algorithm representing the intersection of the recipient's preferences and the sender's capabilities and preferences.
|
||||
In this workflow, the signed hash digest is created with a hash algorithm that follows the recipient's preferences, and its intersection with the sender's capabilities and preferences.
|
||||
|
||||
## Signature versions
|
||||
|
||||
|
|
|
|||
|
|
@ -5,189 +5,48 @@ SPDX-License-Identifier: CC-BY-SA-4.0
|
|||
|
||||
# Advanced material: Signatures over data
|
||||
|
||||
(adv-inline-signature)=
|
||||
## Internals of inline signed messages
|
||||
## Nesting of one-pass signatures
|
||||
|
||||
Inline signed messages are one of the forms of [OpenPGP data signatures](forms-of-data-signatures). An {term}`inline signed message <inline signature>` joins the signed data and its corresponding {term}`data signature` into a single {term}`OpenPGP message`.
|
||||
Signing a message using the one-pass mechanism involves prepending a *One-Pass-Signature* (OPS) packet to the message and appending the corresponding signature, sandwiching the signed content.
|
||||
|
||||
OpenPGP defines two variant forms of inline signed messages:
|
||||
|
||||
1. **{term}`One-pass signed messages<One-pass signed Message>`** This is the commonly used format for inline signed messages. A signer can produce and a verifier can verify this format in one pass.
|
||||
2. **{term}`Prefixed signed messages<Prefixed signed Message>`** This format predates[^inline-signature-formats] {term}`one-pass signed messages<One-pass signed Message>` and is conceptually slightly simpler. However, it is now rarely used and can be considered a legacy format.
|
||||
|
||||
[^inline-signature-formats]: One-pass signing was [first specified in RFC 2440](https://www.rfc-editor.org/rfc/rfc2440.html#section-5.4). The format was not supported in PGP 2.6.x. For one discussion of the feature in the lead-up to the standardization of RFC 2440, see [here](https://mailarchive.ietf.org/arch/msg/openpgp/U4Qg3Z9bj-RDgpwW5nmRNetOZKY/).
|
||||
|
||||
(one-pass-signature)=
|
||||
### One-pass signed message
|
||||
|
||||
This is the commonly used format for inline signed messages.
|
||||
|
||||
#### Structure
|
||||
|
||||
A {term}`one-pass signed<One-pass signed Message>` {term}`OpenPGP message` consists of three segments:
|
||||
|
||||
1. **{term}`One-pass signature packets<One-pass signature packet>`**: These one or more {term}`packets<Packet>` precede the signed data and enable {term}`signature<OpenPGP Signature Packet>` computation (both creation and verification) in a single pass.
|
||||
|
||||
2. **{term}`OpenPGP message`**: This contains the original payload data (e.g., the body of a message), which is signed without additional interpretation or conversion. Internally, a signed [message](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-openpgp-messages) consists of one or more OpenPGP packets. This payload is typically stored as either a {term}`Literal Data Packet`, or a {term}`Compressed Data Packet`.
|
||||
|
||||
3. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These contain the {term}`cryptographic signature` corresponding to the signed data.
|
||||
|
||||
```{figure} ../plain_svg/ops-signed-message.svg
|
||||
:name: fig-ops-signed-message
|
||||
:alt: Depicts the structure of a one-pass signed message. Two one-pass signatures lead a literal data packet, followed by two signature packets. Arrows show, how the hash-algorithm field of the one-pass signatures is inspected in order to initiate the hashing procedure.
|
||||
|
||||
The structure of a one-pass signed message.
|
||||
```
|
||||
An OpenPGP message can contain multiple signatures added that way.
|
||||
|
||||
```{note}
|
||||
Despite its name, a {term}`one-pass signature packet` is not a type of {term}`signature packet<OpenPGP Signature Packet>`.
|
||||
One-Pass-Signatures are nested, meaning the outermost One-Pass-Signature packet corresponds to the outermost signature packet.
|
||||
```
|
||||
|
||||
Instead, it's a type of auxiliary packet that can be used in conjunction with {term}`signature packets<OpenPGP Signature Packet>`, to enable efficient generation and checking of inline signed messages.
|
||||
|
||||
The structure of a {term}`one-pass signature packet` closely mirrors an {term}`OpenPGP signature packet`. However, it does not contain a cryptographic signature.
|
||||
When a message is signed, the signature is always calculated over the contents of the literal data packet, not the literal data packet itself.
|
||||
This means, that if a message, which is compressed using a compressed data packet is wrapped using a one-pass-signature, the signature is still being calculated over the plaintext inside the literal data packet.
|
||||
|
||||
There is one exception though.
|
||||
```{note}
|
||||
Of course there is.
|
||||
```
|
||||
|
||||
(one-pass-signature-packet)=
|
||||
#### The function of the one-pass signature packet
|
||||
The OPS packet has a "nested" flag[^nested-flag], which can either be `1` or `0`.
|
||||
If this flag is set to `0`, it indicates that further OPSs will follow this packet, which are calculated over the same plaintext data as this OPS is. A value of `1` indicates, that either no further OPS packets will follow (this OPS is the last), or that this OPS is calculated over the the usual plaintext data, but wrapped inside any OPS+Signature combinations that follow this OPS.
|
||||
|
||||
The purpose of this packet is efficient handling of inline signed messages in *stream processing* mode. This is particularly important when the signed message is large and exceeds available memory in size.
|
||||
[^nested-flag]: See [description of the nested flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.4-3.8.1).
|
||||
|
||||
Without this packet, the position of signature packets within an inline signed OpenPGP message constitutes a trade-off:
|
||||
|
||||
- The producer of a signed OpenPGP message wants to streamline the signature calculation process in such a way that allows to emit a copy of the signed data while calculating the cryptographic signature. On the signer's side, the signature packet is therefore easy to store after the signed data.
|
||||
- The verifier, on the other hand, needs some information from the signature packet to perform the signature verification process. In particular, the verifier needs to know which hash algorithm was used to calculate the signature, to perform the same hashing operation on the message data.
|
||||
|
||||
As a consequence, without a {term}`one-pass signature packet`, either:
|
||||
|
||||
- The producer would need to process the input data twice:
|
||||
- once to calculate the cryptographic signature, and
|
||||
- a second time to emit the signed data (this format result is a [](prefixed-signature)), or
|
||||
- The verifier would need to process the OpenPGP message twice:
|
||||
- once to read the signature packets at the end to determine the hash algorithm, and
|
||||
- a second time to process the body of the message, and calculate the hash verifying the signature.
|
||||
|
||||
The one-pass signature packet solves this issue by allowing both the *creation* and *verification* of a signed message in a single pass. The one-pass signature packet effectively contains an advance copy of the data in the signature packet, but without the cryptographic signature data.
|
||||
|
||||
The signer can easily emit the metadata in the one-pass signature packet before processing the full message. For the verifier, availability of this metadata at the start of the signed message enables processing of the message body.
|
||||
|
||||
Even in stream processing mode, signers can efficiently generate one-pass signed messages, and verifiers can efficiently check them.
|
||||
|
||||
#### Creation
|
||||
|
||||
To produce a {term}`one-pass inline signature<One-pass signed Message>`, the {term}`signer` decides on a hash algorithm and emits a {term}`one-pass signature packet<One-pass Signature Packet>` into the destination {term}`OpenPGP message`. This contains essential information such as the {term}`fingerprint<OpenPGP Fingerprint>` of the {term}`signing key<OpenPGP Component Key>` and the {term}`hash<Hash Digest>` algorithm used for computing the {term}`signature<OpenPGP Signature Packet>`'s {term}`hash digest`. The signer then processes the entirety of the signed message, emitting it as a series of one or more {term}`packets<Packet>` into the message as well. Once the data is processed, the {term}`signer` calculates a {term}`cryptographic signature` using the calculated hash value. Lastly, the result is emitted as a {term}`data signature packet` to the output message, and the whole packet sequence can be efficiently stored or transmitted.
|
||||
|
||||
#### Verification
|
||||
|
||||
For efficient {term}`verification`, an application must understand how to handle the {term}`OpenPGP message` prior to reading from it. This requirement is addressed by the {term}`one-pass signature packets<One-pass Signature Packet>` located at the beginning of {term}`inline signed<Inline Signature>` messages. This setup enables the verifier to process the data correctly and efficiently in a single pass.
|
||||
|
||||
Strictly speaking, knowing just the hash algorithm would be sufficient to begin the verification process. However, having efficient access to the signer's fingerprint or key ID upfront allows OpenPGP software to fetch the signer's certificate(s) before processing the entirety of the - potentially large - signed data. This may involve downloading the certificate from a keyserver. In case fetching the signer's certificate(s) fails, or requires additional input from the user, it is better to signal the user about this before processing the data.
|
||||
|
||||
{term}`one-pass inline signed messages<One-pass signed Message>` enable efficient {term}`verification` in *one pass*, structured as follows:
|
||||
|
||||
1. **Initiation with {term}`one-pass signature packets<One-pass Signature Packet>`**: These {term}`packets<Packet>` begin the {term}`verification` process. They include the {term}`signer`'s {term}`key ID`/{term}`fingerprint<OpenPGP Fingerprint>`, essential for identifying the appropriate {term}`public key<OpenPGP Certificate>` for signature {term}`validation`.
|
||||
|
||||
2. **Processing the {term}`OpenPGP message`**: This step involves {term}`hashing<Hash Digest>` its data, preparing it for {term}`signature<OpenPGP Signature Packet>` {term}`verification`.
|
||||
|
||||
3. **{term}`Verifying<Verification>` {term}`signature packets<OpenPGP Signature Packet>`**: Located at the end of the message, these {term}`packets<Packet>` are checked against the previously calculated {term}`hash digest`.
|
||||
|
||||
Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature<OpenPGP Signature Packet>` successfully.
|
||||
|
||||
#### Nesting of one-pass signatures
|
||||
|
||||
A {term}`one-pass signed message` can actually contain multiple, nested, signatures.
|
||||
|
||||
Formally, this is the case because in the [OpenPGP message grammar](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-openpgp-messages) when an input OpenPGP message is one-pass signed, the resulting sequence of packets is in turn also considered an OpenPGP message.
|
||||
|
||||
Thus, this signed message can be one-pass signed yet again. This construction means that all signature packet pairs bracket the innermost message, and the outermost one-pass signature packet corresponds to the outermost signature packet.
|
||||
|
||||
##### Two semantics of nested signatures
|
||||
|
||||
There are two different use cases and semantics for nested one-pass signatures:
|
||||
|
||||
- Multiple signers issue independent cryptographic signatures that are stored in one shared (and thus space-efficient) inline signed message. In this case, each signer makes a cryptographic statement about just the signed message. The signatures are independent of each other.
|
||||
- Alternatively, a signer can sign not just the input message, but also include previous signatures in their signature. In this case, the signer makes a cryptographic statement about the pre-existing signature(s) combined with the signed message. This means that the new signer attests the previous signature(s)[^but-why].
|
||||
|
||||
[^but-why]: It's unclear to the authors of this text if any real-world use case for signatures that notarize inner signatures exists.
|
||||
|
||||
##### How to pick one
|
||||
|
||||
When nesting one-pass signatures, the default expectation would be that each enclosing signature makes a statement about the complete message it contains, including any one-pass signatures within the inner message.
|
||||
|
||||
Issuers of signatures can choose the semantics of their signature, using the ["nested" flag](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#section-5.4-3.8.1) in the {term}`one-pass signature packet`. The "nested" flag has a value of either `1` or `0`.
|
||||
|
||||
Meaning of the "nested" flag:
|
||||
|
||||
- `0` means that the one-pass signature that this signature encloses is *not* signed/attested. The new signature doesn't make a cryptographic statement about the directly enclosed signature. If the directly enclosed one-pass signature also has its "nested" flag set to `0`, the enclosing signature also doesn't include the subsequent inner signature in its hashing, and so on.
|
||||
- `1` means that this one-pass signature makes a cryptographic statement about the full message that it encloses, including all enclosed signatures, if any.
|
||||
|
||||
A typical pattern of use is to set the "nested" flag to `1` on the innermost signature and to `0` on all enclosing signatures. With this pattern, all signatures are independent of each other. Each signature makes a statement about just the innermost message payload (which is stored in a literal data packet).
|
||||
|
||||
##### Examples
|
||||
This mechanism enables attested signatures, where the signer signs an already one-pass-signed message including the already contained signature.
|
||||
|
||||
As a practical example, consider the following notation:
|
||||
* `LIT("Hello World")` represents a literal data packet with the content `Hello World`.
|
||||
* `COMP(XYZ)` represents a compressed data packet over some other packet `XYZ`.
|
||||
* `OPS₁` represents a one-pass signature packet with the nested flag set to `1`. Analogous, `OPS₀` has the nested flag set to `0`.
|
||||
* `OPS₁` represents a one-pass-signature packet with the nested flag set to `1`. Analogous, `OPS₀` has the nested flag set to `0`.
|
||||
* `SIG` represents a signature packet.
|
||||
|
||||
A normal, one-pass signed message looks like this:
|
||||
A normal, one-pass-signed message looks like this:
|
||||
`OPS₁ LIT("Hello World") SIG`
|
||||
|
||||
Here, the signature is calculated over the payload `Hello World`. The signature doesn't change if the signed message is instead stored as: `OPS₁ COMP(LIT("Hello World")) SIG` (also see [](hashing-inline-data)).
|
||||
Here, the signature is calculated over the plaintext `Hello World`, as is it in a message that has the following form: `OPS₁ COMP(LIT("Hello World")) SIG`.
|
||||
|
||||
A message, where multiple independent one-pass signatures are calculated over the same payload looks the following:
|
||||
`OPS₀ OPS₀ OPS₁ LIT("Hello World") SIG SIG SIG` - all three signatures are calculated over the same payload `Hello World`.
|
||||
A message, where multiple one-pass-signatures are calculated over the same plaintext looks the following:
|
||||
`OPS₀ OPS₀ OPS₁ LIT("Hello World") SIG SIG SIG`
|
||||
|
||||
By contrast, a message, where the signer attests an already signed message has the following format:
|
||||
`OPS₁ OPS₁ LIT("Hello World") SIG SIG`. While the inner signature is calculated over the usual payload `Hello World`, the outer signature is instead calculated over `OPS₁ Hello World SIG`.
|
||||
All three signatures are calculated over the same plaintext `Hello World`.
|
||||
|
||||
(prefixed-signature)=
|
||||
### Prefixed signed message
|
||||
Now, a message, where the signer attests an already signed message has the following format:
|
||||
`OPS₁ OPS₁ LIT("Hello World") SIG SIG`
|
||||
|
||||
A {term}`prefixed signed message` consists of {term}`signature packet(s)<signature packet>` followed by the message. For the verifier, processing one-pass signed and prefixed signed messages are equally convenient. However, on the signer's side, it takes more resources to generate a {term}`prefixed signed message`.
|
||||
|
||||
This is a legacy format. Not all modern implementations support it. However, for example, GnuPG 2.4.x can validate messages with this signature format.
|
||||
|
||||
#### Structure
|
||||
|
||||
In this format, the signature packets are stored ahead of the message itself:
|
||||
|
||||
1. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These one or more packets contain the {term}`cryptographic signature` corresponding to the original data.
|
||||
|
||||
2. **{term}`OpenPGP message`**: This contains the original data (e.g., the body of a message), without additional interpretation or conversion.
|
||||
|
||||
```{figure} ../plain_svg/prefixed-signed-message.svg
|
||||
:name: fig-prefixed-signed-message
|
||||
:alt: Depicts the structure of a prefixed signed message. As an example, two signature packets lead a literal data packet. Arrows show, how the signatures hash algorithm field is inspected to start the hashing procedure.
|
||||
|
||||
Structure of a prefixed signed message.
|
||||
```
|
||||
|
||||
Compared to a {term}`one-pass signed message`, there are no {term}`one-pass signature packets<One-pass Signature Packet>` in this format, and the (otherwise equivalent) {term}`signature packet(s)<signature packet>` are stored ahead of the signed data.
|
||||
|
||||
```{note}
|
||||
Even when a prefixed signed message contains multiple signature packets, each signature packet contains an independent signature of just the message payload. Signatures do not include subsequent signatures in their hashes, every signature is only over the raw payload data of the message.
|
||||
```
|
||||
|
||||
#### Format is inefficient for the signer
|
||||
|
||||
For verification, this format is equally convenient as the one-pass signed message form.
|
||||
|
||||
However, when a signer creates a {term}`prefixed signed message`, the signed data must be processed twice:
|
||||
|
||||
- once reading it to calculate the cryptographic signature, and
|
||||
- once more to store the data in the generated OpenPGP message, after the signature packet(s).
|
||||
|
||||
(hashing-inline-data)=
|
||||
### Hashing the signed payload of an inline signature
|
||||
|
||||
When inline signing a message, the hash for the signed content is calculated over just the raw payload contained in a literal data packet. No metadata of the literal data packet is included in the signed hash. Even if a compressed data packet wraps the literal data packet, the inline signature is still calculated over the uncompressed content of the literal data packet.
|
||||
|
||||
The calculation of inline data signatures is unusual in two regards:
|
||||
|
||||
- Most OpenPGP signature calculations include packet metadata, but for literal data packets, only the payload is hashed.
|
||||
- Packets are usually hashed without transforming the packet content for hashing. Decompressing the content of a compressed data packet for hashing is an exception to this pattern.
|
||||
|
||||
However, this approach means that detached signatures and inline signatures are calculated on exactly the same data.
|
||||
|
||||
One format can be transformed into the other, after the fact, without requiring the private key material of the signer. A compression layer can be inserted or removed without disturbing the validity of an existing signature.
|
||||
While the inner signature is calculated over the usual plaintext `Hello World`, the outer signature is instead calculated over `OPS₁ Hello World SIG`.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,6 @@ description = 'The essential OpenPGP guide for application developers. Learn the
|
|||
extensions = [
|
||||
'myst_parser',
|
||||
'sphinxext.opengraph',
|
||||
'sphinx_sitemap',
|
||||
]
|
||||
source_suffix = ['.md', '.rst']
|
||||
|
||||
|
|
@ -83,7 +82,6 @@ html_css_files = [
|
|||
('html/css/custom.css', {'priority': 1000})
|
||||
]
|
||||
|
||||
html_baseurl = 'https://openpgp.dev/book/'
|
||||
html_favicon = '_static/html/img/favicon.ico'
|
||||
html_logo = '_static/html/img/logo.svg'
|
||||
html_show_sphinx = False
|
||||
|
|
@ -110,5 +108,3 @@ ogp_custom_meta_tags = [
|
|||
f'<meta property="og:description" content="{description}" />',
|
||||
]
|
||||
|
||||
# sphinx sitemap https://sphinx-sitemap.readthedocs.io/en/latest/advanced-configuration.html
|
||||
sitemap_url_scheme = "{link}"
|
||||
|
|
|
|||
|
|
@ -20,10 +20,10 @@ Algorithm Preferences
|
|||
See [](recipe-algorithm-preferences).
|
||||
|
||||
Asymmetric Cryptography
|
||||
Asymmetric cryptography (also known as public-key cryptography) is used in OpenPGP to send messages without using a prior shared secret. For a more detailed discussion see [](public-key-cryptography).
|
||||
Asymmetric cryptography is used in OpenPGP. For a more detailed discussion see [](public-key-cryptography).
|
||||
|
||||
Authenticated Encryption With Associated Data
|
||||
Short AEAD, refers to an encryption scheme that ensures confidentiality of a message. Additionally, additional data, which is not confidential, may be associated with the message, ensuring integrity of both the confidential part of the message, as well as the additional data.
|
||||
Short AEAD, refers to an encryption scheme that ensures confidentiality of a message. Additionally, additional data, which is not confidential, may be associated with the message.
|
||||
|
||||
See Wikipedia on [Authenticated Encryption](https://en.wikipedia.org/wiki/Authenticated_encryption).
|
||||
|
||||
|
|
@ -32,9 +32,7 @@ Authentication
|
|||
The term "authentication" here is semantically different from the one used in {term}`Authentication Key Flag`.
|
||||
|
||||
Authentication Key Flag
|
||||
A {term}`Key Flag` which indicates that a {term}`Component Key` can be used to prove control over {term}`private key material` with a challenge-response mechanism. This is typically done to log into a remote system, often using the OpenSSH protocol.
|
||||
|
||||
Note that the term "authentication" is used in a different context here than {term}`Authentication` of {term}`identity claims<identity claim>` that are associated with a {term}`certificate`. See [](key-flags).
|
||||
A {term}`Key Flag`, which indicates that a {term}`Component Key` can be used to confirm control over {term}`private key material` against a remote system. The term "authentication" here is semantically different from {term}`Authentication`. See [](key-flags).
|
||||
|
||||
Authentication Tag
|
||||
See {term}`Message Authentication Code`.
|
||||
|
|
@ -51,12 +49,12 @@ Binary Signature
|
|||
Binding
|
||||
The process of creating a {term}`Binding Signature` for a {term}`Component`, or the resulting {term}`Binding Signature`.
|
||||
|
||||
See [](binding-signatures) for more.
|
||||
See {ref}`binding-signatures` for more.
|
||||
|
||||
Binding Signature
|
||||
A {term}`self-signature` on a {term}`component` which associates that {term}`component` to the issuing {term}`component key` in a {term}`certificate<OpenPGP Certificate>`.
|
||||
|
||||
See [](binding-signatures) for more.
|
||||
See {ref}`binding-signatures` for more.
|
||||
|
||||
CA
|
||||
See {term}`Certification Authority`.
|
||||
|
|
@ -71,7 +69,7 @@ Certificate Authority
|
|||
See {term}`Certification Authority`
|
||||
|
||||
Certificate Holder
|
||||
A person or other entity, that holds an {term}`Transferable Secret Key` and thus is able to modify the accompanying {term}`OpenPGP Certificate`. Typically this is the owner of {term}`OpenPGP key`.
|
||||
A person or other entity, that holds an {term}`Transferable Secret Key` and thus is able to modify the accompanying {term}`OpenPGP Certificate`.
|
||||
|
||||
Certification
|
||||
A certification, in OpenPGP, is a signature that makes a statement about an {term}`identity` in a {term}`certificate<OpenPGP Certificate>`, or an entire {term}`certificate<OpenPGP Certificate>`.
|
||||
|
|
@ -92,7 +90,7 @@ Certification Revocation Signature Packet
|
|||
Certification Signature
|
||||
See {term}`Certification`.
|
||||
|
||||
Certifying Self-Signature
|
||||
Certifying Self-signature
|
||||
An {term}`OpenPGP Signature Packet` by the {term}`Certificate Holder` on an {term}`Identity Component` of their own {term}`Certificate`.
|
||||
|
||||
Certifying Signature
|
||||
|
|
@ -114,26 +112,23 @@ Component
|
|||
Component Key
|
||||
See {term}`OpenPGP Component Key`.
|
||||
|
||||
Compressed Data Packet
|
||||
A {term}`packet` that contains a compressed {term}`OpenPGP Message` (typically a {term}`Literal Data Packet`). A Compressed Data Packet represents a "compressed message".
|
||||
|
||||
Compression
|
||||
See {term}`Data Compression`.
|
||||
|
||||
Creation Time
|
||||
The point in time at which e.g. an {term}`OpenPGP Signature`, an {term}`OpenPGP Certificate`, or one of its {term}`component<Component>` is created.
|
||||
The point in time at which e.g. an {term}`OpenPGP Certificate`, or one of its {term}`component<Component>` is created.
|
||||
|
||||
Creator
|
||||
See {term}`Issuer`.
|
||||
|
||||
Criticality Flag
|
||||
A flag on {term}`Subpacket`s, that can mark them as critical or non-critical, which is has an influence on signature validation. See [](criticality-of-subpackets).
|
||||
A flag on {term}`Subpacket`s, that defines their criticality, which is used for validation. See [](criticality-of-subpackets).
|
||||
|
||||
Cryptographic Key
|
||||
A {term}`symmetric<Symmetric Cryptography>` or {term}`asymmetric<Asymmetric Cryptography>` cryptographic key. See [](cryptography).
|
||||
A {term}`symmetric<Symmetric Cryptography>` or {term}`asymmetric<Asymmetric Cryptography>` cryptographic key is used for signing and encryption operations. See [](cryptography).
|
||||
|
||||
Cryptographic Signature
|
||||
A raw cryptographic signature is an algorithm-specific sequence of bytes created by a {term}`Cryptographic Key`.
|
||||
A raw cryptographic signature is a sequence of bytes created by a {term}`Cryptographic Key`.
|
||||
|
||||
CTB
|
||||
See {term}`Cipher Type Byte`.
|
||||
|
|
@ -156,28 +151,19 @@ Delegation
|
|||
This kind of delegation involves {term}`certifications<Certification>` that include the {term}`trust signature` subpacket.
|
||||
|
||||
Detached Signature
|
||||
A {term}`Data Signature` which exists separately to the data it was created for. See [](forms-of-data-signatures).
|
||||
A {term}`Data Signature` which exists as a separate file to the file it was created for. See [](forms-of-data-signatures).
|
||||
|
||||
Direct Key Signature
|
||||
Describes both a {term}`Signature Type ID`, as well as an according {term}`OpenPGP Signature` over a {term}`Primary Key`.
|
||||
|
||||
Issued as a {term}`Self-Signature` it sets preferences and advertises {term}`features<Features Subpacket>` applicable to an entire {term}`Certificate`. See [](direct-key-signature).
|
||||
A {term}`Signature` that sets preferences and advertises {term}`features<Features Subpacket>` applicable to an entire {term}`Certificate`. See [](direct-key-signature).
|
||||
|
||||
Embedded Signature Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket` which contains a complete {term}`OpenPGP Signature Packet`.
|
||||
|
||||
See [RFC 5.2.3.34](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-embedded-signature)
|
||||
|
||||
Encrypted Data
|
||||
Data that is encrypted.
|
||||
|
||||
See [](/encryption).
|
||||
|
||||
Encryption Key Flag
|
||||
A {term}`Key Flag`, indicating that a {term}`Component Key` can be used for encrypting data. See [](key-flags).
|
||||
|
||||
There are two distinct encryption key flags, indicating that the key can encrypt communications, or data in long-term storage respectively.
|
||||
|
||||
Expiration
|
||||
A mechanism by which a {term}`Component` is invalidated due to the {term}`Expiration Time` of its {term}`binding signature` being older than the {term}`Reference Time` by which it is validated.
|
||||
|
||||
|
|
@ -185,7 +171,7 @@ Expiration Time
|
|||
The time of expiry of an {term}`OpenPGP Signature Packet`.
|
||||
|
||||
Features Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket`, which denotes advanced OpenPGP features an {term}`implementation<OpenPGP Implementation>` supports.
|
||||
A {term}`OpenPGP Signature Subpacket`, which denotes advanced OpenPGP features an {term}`implementation<OpenPGP Implementation>` supports.
|
||||
|
||||
For an in-depth view on these {term}`subpackets<OpenPGP Signature Subpacket>` see [](zoom-dks).
|
||||
|
||||
|
|
@ -210,9 +196,6 @@ Hash Digest
|
|||
Hash Function
|
||||
A function used to map data of arbitrary size to fixed-size values (see {term}`Hash Digest`).
|
||||
|
||||
Hash Value
|
||||
See {term}`Hash Digest`.
|
||||
|
||||
Hashed Area
|
||||
An area in an {term}`OpenPGP Signature Packet` containing {term}`OpenPGP Signature Subpacket`s, that is covered by the {term}`Hash Digest` a {term}`Cryptographic Signature` is created for. See [](subpacket-areas).
|
||||
|
||||
|
|
@ -223,14 +206,10 @@ Hybrid Cryptosystem
|
|||
A cryptographic system that employs both {term}`Asymmetric Cryptography` and {term}`Symmetric Cryptography`. See [](hybrid-cryptosystems).
|
||||
|
||||
Identity
|
||||
An identity of a {term}`Certificate Holder`. It is represented by an {term}`Identity Component`, which may be certified using {term}`identity certifications<Identity Certification>`, or by a {term}`Notation`.
|
||||
An identity of a {term}`Certificate Holder`. It is represented by an {term}`Identity Component`, which may be certified using {term}`third-party identity certifications<Third-party Identity Certification>`, or by a {term}`Notation`.
|
||||
|
||||
Identity Certification
|
||||
An {term}`OpenPGP Signature Packet` on an {term}`Identity Component` which {term}`certifies<Certification>` its {term}`authenticity<Authentication>`.
|
||||
|
||||
Identity certifications can be issued either:
|
||||
- by the certificate holder, as a {term}`self-signature`, or
|
||||
- by a third party, as a {term}`third-party identity certifications<Third-party Identity Certification>`.
|
||||
|
||||
Identity Claim
|
||||
A {term}`Certificate Holder` may use {term}`Identity Components<Identity Component>` or {term}`Notations<Notation>` to state a claim about their {term}`Identity`.
|
||||
|
|
@ -245,17 +224,10 @@ Initial Introducer
|
|||
An {term}`OpenPGP Certificate` explicitly {term}`delegated<Delegation>` to from a {term}`Trust Anchor`.
|
||||
|
||||
Inline Signature
|
||||
An [inline signature](inline-signature) is a type of {term}`OpenPGP message` which stores a {term}`Data Signature` alongside the message it signs. Both the message and the signature are stored in a shared OpenPGP container.
|
||||
|
||||
The standard defines two variant formats for inline signatures:
|
||||
|
||||
- {term}`One-pass signed Message`: This format is now commonly used.
|
||||
- {term}`Prefixed signed Message`: This is a historical format. It is still supported, but rarely used.
|
||||
|
||||
For more context, see [](forms-of-data-signatures).
|
||||
A {term}`Data Signature` which exists encapsulated alongside the data it was created for in an OpenPGP container. See [](forms-of-data-signatures).
|
||||
|
||||
Issuer
|
||||
An entity, that created an {term}`OpenPGP Signature Packet` using a {term}`Transferable Secret Key`.
|
||||
An entity, that created an {term}`OpenPGP Signature Packet` using an {term}`Transferable Secret Key`.
|
||||
|
||||
Issuer Fingerprint Subpacket
|
||||
A {term}`Subpacket` specifying the {term}`Fingerprint` of an {term}`Issuer Key`.
|
||||
|
|
@ -281,7 +253,7 @@ Key
|
|||
- {term}`OpenPGP key` (which in turn refers to either an {term}`OpenPGP Certificate` or a {term}`Transferable Secret Key`
|
||||
|
||||
Key Expiration Time Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the {term}`Expiration Time` for a {term}`key<Component Key>`.
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the {term}`Expiration Time` for an {term}`OpenPGP Signature Packet` on a {term}`key<Component Key>`.
|
||||
|
||||
See [RFC 5.2.3.13](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-key-expiration-time)
|
||||
|
||||
|
|
@ -292,12 +264,8 @@ Key Holder
|
|||
See {term}`Certificate Holder`.
|
||||
|
||||
Key ID
|
||||
A Key ID is a shorthand identifier for OpenPGP certificates (or for individual subkeys). A Key ID is a shortened versions of a {term}`fingerprint<OpenPGP Fingerprint>`:
|
||||
|
||||
- For OpenPGP v6 keys, the Key ID consists of the high-order (leftmost) 64 bits of their {term}`OpenPGP Fingerprint`.
|
||||
- For OpenPGP v4 keys, the Key ID consists of the low-order (rightmost) 64 bits of their {term}`OpenPGP Fingerprint`.
|
||||
|
||||
Note that since Key IDs are relatively short, they don't meaningfully guard against collisions. Applications must not assume that Key IDs are unique.
|
||||
The high-order (leftmost) 64 bits of an {term}`OpenPGP Fingerprint`.
|
||||
Historically, this term refers to the low-order (rightmost) 64 bits of an {term}`OpenPGP Fingerprint`.
|
||||
|
||||
Key Material
|
||||
May refer to {term}`Public Key Material` or {term}`Private Key Material`.
|
||||
|
|
@ -309,7 +277,7 @@ Key Revocation Signature Packet
|
|||
A {term}`Revocation Self-signature` for an entire {term}`OpenPGP Certificate`.
|
||||
|
||||
Key Server
|
||||
A service available over the network, which provides access to {term}`OpenPGP Certificates<OpenPGP Certificate>` e.g., by searching for an {term}`OpenPGP Fingerprint` or {term}`User ID`, via the `HKP` and/ or `HKPS` protocols.
|
||||
A piece of software available over the network, which provides access to {term}`OpenPGP Certificates<OpenPGP Certificate>` e.g., by searching for an {term}`OpenPGP Fingerprint` or {term}`User ID`, via the `HKP` and/ or `HKPS` protocols.
|
||||
Several implementations such as [hagrid](https://gitlab.com/keys.openpgp.org/hagrid/), or [hockeypuck](https://github.com/hockeypuck/hockeypuck) exist.
|
||||
|
||||
Life-cycle Management
|
||||
|
|
@ -318,11 +286,7 @@ Life-cycle Management
|
|||
See [](self-signatures).
|
||||
|
||||
Literal Data Packet
|
||||
A {term}`packet` that contains a payload of data. It represents a "literal message".
|
||||
|
||||
A literal data packet typically stores the paintext data of an encrypted message, and/or the data of an inline signed message.
|
||||
|
||||
See [RFC 5.9](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit).
|
||||
A {term}`packet<OpenPGP Signature Packet>` in a {term}`Data Signature` which contains data, that has been signed using a {term}`cryptographic signature`. See [RFC 5.9](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit) for more details.
|
||||
|
||||
MAC
|
||||
See {term}`Message Authentication Code`.
|
||||
|
|
@ -333,10 +297,8 @@ Master Key
|
|||
Message Authentication Code
|
||||
A piece of information used for integrity and {term}`authenticity<Authentication>` verification of a message. See [](message-authentication-code).
|
||||
|
||||
Meta Introducer
|
||||
An {term}`OpenPGP Certificate` that acts as a {term}`Trusted introducer` and has a {term}`Trust Depth` greater than one.
|
||||
|
||||
A meta introducer can introduce other (meta-) {term}`introducers<Trusted introducer>`.
|
||||
Meta-Introducer
|
||||
An {term}`OpenPGP Certificate` with a {term}`Trust Depth` greater than one.
|
||||
|
||||
Metadata
|
||||
Data related to preferences of an {term}`OpenPGP Certificate` or its {term}`Certificate Holder`, that can be found in {term}`signature` {term}`packets<Packet>`. See [](metadata-in-certificates).
|
||||
|
|
@ -351,15 +313,7 @@ Notation Tag
|
|||
Part of a {term}`Notation` name.
|
||||
|
||||
One-pass Signature Packet
|
||||
One or more {term}`packets<Packet>` before the actual data in a {term}`Data Signature` which contain information to allow a receiving {term}`implementation<OpenPGP Implementation>` to create {term}`hashes<Hash Digest>` required for signature verification.
|
||||
|
||||
See [](one-pass-signature-packet).
|
||||
Also see [RFC 5.4](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig).
|
||||
|
||||
One-pass signed Message
|
||||
The commonly used form of an OpenPGP {term}`Inline Signature`. It combines an {term}`OpenPGP Message` with {term}`signature packets<OpenPGP Signature Packet>` and accompanying auxiliary {term}`One-pass signatures<One-pass Signature Packet>`.
|
||||
|
||||
For details see [](one-pass-signature).
|
||||
One or more {term}`packets<OpenPGP Signature Packet>` before the actual data in a {term}`Data Signature` which contain information to allow a receiving {term}`implementation<OpenPGP Implementation>` to create {term}`hashes<Hash Digest>` required for signature verification. See [RFC 5.4](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig) for more details.
|
||||
|
||||
OpenPGP Certificate
|
||||
An OpenPGP certificate contains public key material, identity claims and third party certifications (but no private key material)
|
||||
|
|
@ -367,9 +321,6 @@ OpenPGP Certificate
|
|||
OpenPGP Component Key
|
||||
An {term}`OpenPGP Primary Key` or {term}`OpenPGP Subkey`. For an in-depth discussion see [](component-keys).
|
||||
|
||||
OpenPGP data
|
||||
Any data in OpenPGP format, represented as a series of OpenPGP packets. The data could for example represent an {term}`OpenPGP Certificate`, or an {term}`OpenPGP Signature Packet` combined with plaintext or encrypted data.
|
||||
|
||||
OpenPGP Fingerprint
|
||||
An OpenPGP Fingerprint is a shorthand representation of an {term}`OpenPGP Component Key`. Fingerprints effectively act as unique identifiers. See [](fingerprint).
|
||||
|
||||
|
|
@ -382,14 +333,7 @@ OpenPGP Key
|
|||
Used either for an {term}`OpenPGP Certificate` (containing public key material and metadata), or for an {term}`OpenPGP Private Key`. See [](/certificates) for an in-depth discussion.
|
||||
|
||||
OpenPGP Message
|
||||
A series of OpenPGP packets that represents one of the following formats:
|
||||
|
||||
- an encrypted message
|
||||
- a signed message
|
||||
- a {term}`compressed message<compressed data packet>`
|
||||
- a {term}`literal message<literal data packet>`
|
||||
|
||||
Also see [RFC 10.3](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-openpgp-messages).
|
||||
A data structure, which contains OpenPGP components such as {term}`OpenPGP Certificate` or {term}`OpenPGP Signature Packet` and plaintext or encrypted data.
|
||||
|
||||
OpenPGP Public Key
|
||||
See {term}`OpenPGP Certificate`.
|
||||
|
|
@ -425,7 +369,7 @@ Owner
|
|||
See {term}`Certificate Holder`.
|
||||
|
||||
Packet
|
||||
An element in an {term}`OpenPGP Certificate` or {term}`OpenPGP Message`.
|
||||
An element in an {term}`OpenPGP Certificate`, which represents {term}`components<Component>` or {term}`signatures<OpenPGP Signature Packet>`.
|
||||
|
||||
Packet Header
|
||||
A section of variable length at the beginning of a {term}`Packet`, which encodes for example the {term}`Packet Type ID`. See the relevant [section in the RFC](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-packet-headers), which explains this section in more detail.
|
||||
|
|
@ -442,29 +386,25 @@ Positive Certification
|
|||
See [](bind-identity).
|
||||
|
||||
Preferred Compression Algorithms Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred {term}`compression algorithms<Data Compression>` for an {term}`OpenPGP Certificate` or {term}`Component Key`. This defines which {term}`algorithms<Data Compression>` the {term}`key holder<Certificate Holder>` prefers to receive.
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred {term}`compression algorithms<Data Compression>` for an {term}`OpenPGP Signature Packet`. This defines which {term}`algorithms<Data Compression>` the {term}`key holder<Certificate Holder>` prefers to use.
|
||||
|
||||
See [RFC 5.2.3.17](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-preferred-compression-algor).
|
||||
|
||||
Preferred Hash Algorithms Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred {term}`hash algorithm<Hash Function>` for an {term}`OpenPGP Certificate` or {term}`Component Key`. This defines which algorithms the {term}`key holder<Certificate Holder>` prefers to receive.
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred {term}`hash algorithm<Hash Function>` for an {term}`OpenPGP Signature Packet`. This defines which algorithms the {term}`key holder<Certificate Holder>` prefers to receive.
|
||||
|
||||
See [RFC 5.2.3.16](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-preferred-hash-algorithms).
|
||||
|
||||
Preferred Symmetric Ciphers for v1 SEIPD Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred version 1 {term}`SEIPD<Symmetrically Encrypted Integrity Protected Data>` algorithms for an {term}`OpenPGP Certificate` or {term}`Component Key`. This defines which algorithms the {term}`key holder<Certificate Holder>` prefers to receive and implicitly signifies the supported algorithms of the {term}`key holder<Certificate Holder>`'s {term}`implementation<OpenPGP Implementation>`.
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred version 1 {term}`SEIPD<Symmetrically Encrypted Integrity Protected Data>` algorithms for an {term}`OpenPGP Signature Packet`. This defines which algorithms the {term}`key holder<Certificate Holder>` prefers to receive and implicitly signifies the supported algorithms of the {term}`key holder<Certificate Holder>`'s {term}`implementation<OpenPGP Implementation>`.
|
||||
|
||||
See [RFC 5.2.3.14](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-preferred-symmetric-ciphers).
|
||||
|
||||
Preferred AEAD Ciphersuites Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred version 2 {term}`SEIPD<Symmetrically Encrypted Integrity Protected Data>` algorithms for an {term}`OpenPGP Certificate` or {term}`Component Key`. This defines which algorithms the {term}`key holder<Certificate Holder>` prefers to receive and implicitly signifies the supported algorithms of the {term}`key holder<Certificate Holder>`'s {term}`implementation<OpenPGP Implementation>`.
|
||||
An {term}`OpenPGP Signature Subpacket Type` which defines the preferred version 2 {term}`SEIPD<Symmetrically Encrypted Integrity Protected Data>` algorithms for an {term}`OpenPGP Signature Packet`. This defines which algorithms the {term}`key holder<Certificate Holder>` prefers to receive and implicitly signifies the supported algorithms of the {term}`key holder<Certificate Holder>`'s {term}`implementation<OpenPGP Implementation>`.
|
||||
|
||||
See [RFC 5.2.3.15](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-preferred-aead-ciphersuites)
|
||||
|
||||
Prefixed signed Message
|
||||
A type of {term}`Inline Signature`. This form of {term}`Inline Signature` is historical and now rarely used. Superseded by {term}`One-pass signed Message`.
|
||||
|
||||
For details see [](prefixed-signature).
|
||||
|
||||
Primary Component Key
|
||||
See {term}`OpenPGP Primary Key`.
|
||||
|
|
@ -521,7 +461,7 @@ Reason For Revocation Subpacket
|
|||
See [RFC 5.2.3.31](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-reason-for-revocation)
|
||||
|
||||
Reference Time
|
||||
A point in time at which an {term}`OpenPGP Certificate` or {term}`OpenPGP Signature` is evaluated.
|
||||
A point in time at which an {term}`OpenPGP Certificate` is evaluated.
|
||||
|
||||
Regular Expression Subpacket
|
||||
An {term}`OpenPGP Signature Subpacket` which allows for limiting {term}`delegations<Delegation>` to {term}`identities<Identity>` matching a regular expression.
|
||||
|
|
@ -611,7 +551,7 @@ Signature Type
|
|||
See {term}`OpenPGP Signature Type`.
|
||||
|
||||
Signature Type ID
|
||||
A numerical identifier for a {term}`Signature Type<OpenPGP Signature Type>`.
|
||||
A numerical identifier for a {term}`Signature Type`.
|
||||
|
||||
Signature Verification
|
||||
In cryptography the mechanism of verification relates to a process in which a claim (i.e., a {term}`signature`) is tested (i.e., using the relevant {term}`components<Component>` of a {term}`certificate`).
|
||||
|
|
@ -669,7 +609,7 @@ Text Signature
|
|||
A {term}`signature packet<OpenPGP signature packet>` with the {term}`Signature Type ID` `0x01`, which is used for textual data.
|
||||
|
||||
Third-party Identity Certification
|
||||
{term}`Certification` by third-parties to confirm ownership of an {term}`OpenPGP Certificate` ({term}`Identity Claim`) by a {term}`Certificate Holder`. See [](third-party-identity-certifications).
|
||||
{term}`Certification` by third-parties to confirm ownership of an {term}`OpenPGP Certificate` by a {term}`Certificate Holder`. See [](third-party-identity-certifications).
|
||||
|
||||
Third-party Signature
|
||||
A {term}`Signature` by a third-party on a {term}`Component` of a {term}`Certificate`.
|
||||
|
|
@ -709,7 +649,7 @@ Trust Signature
|
|||
Trusted introducer
|
||||
OpenPGP users can choose to rely on {term}`certifications<Certification>` issued by a third party. The remote party of such a {term}`delegation` is called a "trusted introducer".
|
||||
|
||||
See [](delegation) for more details.
|
||||
See {ref}`delegation` for more details.
|
||||
|
||||
TSK
|
||||
See {term}`Transferable Secret Key`.
|
||||
|
|
@ -727,7 +667,7 @@ Unhashed Subpacket
|
|||
A {term}`Signature Subpacket` residing in the {term}`Unhashed Area` of a {term}`Signature Packet`.
|
||||
|
||||
User Attribute
|
||||
An {term}`Identity Component`, which may hold complex attribute data, e.g. a single JPEG image. See [](user-attributes).
|
||||
An {term}`Identity Component`, which may hold a single JPEG image. See [](user-attributes).
|
||||
|
||||
User ID
|
||||
An {term}`Identity Component`, which describes an {term}`Identity` of a {term}`Certificate Holder`. See [](user-ids).
|
||||
|
|
|
|||
|
|
@ -241,7 +241,7 @@ OpenPGP uses [*trust signature*](https://www.ietf.org/archive/id/draft-ietf-open
|
|||
(trust-level)=
|
||||
#### Trust depth/level
|
||||
|
||||
The "{term}`trust depth`" (or {term}`level<Trust Depth>`) in OpenPGP signifies the extent of transitive {term}`delegation` within the {term}`authentication` process. It determines how far a {term}`delegation` can be extended from the original {term}`trusted introducer` to subsequent intermediaries. Essentially, a {term}`certificate<OpenPGP Certificate>` with a {term}`trust depth` of more than one acts as a "{term}`meta introducer`," facilitating {term}`authentication` decisions across multiple levels in the network.
|
||||
The "{term}`trust depth`" (or {term}`level<Trust Depth>`) in OpenPGP signifies the extent of transitive {term}`delegation` within the {term}`authentication` process. It determines how far a {term}`delegation` can be extended from the original {term}`trusted introducer` to subsequent intermediaries. Essentially, a {term}`certificate<OpenPGP Certificate>` with a {term}`trust depth` of more than one acts as a "{term}`meta-introducer`," facilitating {term}`authentication` decisions across multiple levels in the network.
|
||||
|
||||
A {term}`trust depth` of 1 means relying on {term}`certifications<Certification>` made directly by the {term}`trusted introducer`. The user's OpenPGP software will accept {term}`certifications<Certification>` made directly by the {term}`introducer<Trusted Introducer>` for {term}`authenticating<Authentication>` identities.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Note that {term}`data signatures<Data Signature>` are distinct from [](/signing_
|
|||
|
||||
{term}`Data signatures<Data Signature>` are generated by {term}`hashing<Hash Digest>` the message content along with the {term}`metadata` in the {term}`OpenPGP signature packet`, and calculating a {term}`cryptographic signature` over that {term}`hash<Hash Digest>`. The resulting {term}`cryptographic signature` is stored in the {term}`signature packet<OpenPGP Signature Packet>`.
|
||||
|
||||
{term}`Data signatures<Data Signature>` manifest in three distinct forms, which will be detailed in the subsequent section.
|
||||
{term}`Data signature packets<Data Signature Packet>` manifest in three distinct forms, which will be detailed in the subsequent section.
|
||||
|
||||
(forms-of-data-signatures)=
|
||||
## Forms of OpenPGP data signatures
|
||||
|
|
@ -35,34 +35,62 @@ Note that {term}`data signatures<Data Signature>` are distinct from [](/signing_
|
|||
|
||||
- **{term}`Detached<Detached Signature>`**: The OpenPGP signature exists as a separate entity, independent of the signed data.
|
||||
- **{term}`Inline<Inline Signature>`**: Both the original data and its corresponding {term}`OpenPGP signature<OpenPGP Signature Packet>` are encapsulated within an {term}`OpenPGP message`.
|
||||
- **{term}`Cleartext signature`**: A plain text message and its {term}`OpenPGP signature<OpenPGP Signature Packet>` coexist in a combined text format, preserving the readability of the original message.
|
||||
- **{term}`Cleartext signature`**: A plaintext message and its {term}`OpenPGP signature<OpenPGP Signature Packet>` coexist in a combined text format, preserving the readability of the original message.
|
||||
|
||||
[^sign-modes-gpg]: These three forms of {term}`signature<OpenPGP Signature Packet>` application align with GnuPG's `--detach-sign`, `--sign`, and `--clearsign` command options.
|
||||
|
||||
## Detached signatures
|
||||
### Detached signatures
|
||||
|
||||
A {term}`detached signature` is produced by calculating an {term}`OpenPGP signature<OpenPGP Signature Packet>` over the data intended for signing. The original data remains unchanged, and the {term}`OpenPGP signature<OpenPGP Signature Packet>` is stored separately, e.g. as a standalone file. A {term}`detached signature` file can be distributed alongside or independent of the original data. The {term}`authenticity<Authentication>` and integrity of the original data file can be {term}`verified<Verification>` by using the {term}`detached signature` file.
|
||||
A {term}`detached signature` is produced by calculating an {term}`OpenPGP signature<OpenPGP Signature Packet>` over the data intended for signing. The original data remains unchanged, and the {term}`OpenPGP signature<OpenPGP Signature Packet>` is stored as a standalone file. A {term}`detached signature` file can be distributed alongside or independent of the original data. The {term}`authenticity<Authentication>` and integrity of the original data file can be {term}`verified<Verification>` by using the {term}`detached signature` file.
|
||||
|
||||
This {term}`signature<OpenPGP Signature Packet>` format is especially useful for signing software releases and other files where it is imperative that the content remains unaltered during the signing process.
|
||||
|
||||
(inline-signature)=
|
||||
## Inline signatures
|
||||
### Inline signatures
|
||||
|
||||
An {term}`inline signature` joins the signed data and its corresponding {term}`data signature` into a single {term}`OpenPGP message`.
|
||||
|
||||
This method is commonly used for signing or encrypting emails. Most email software capable of handling OpenPGP communications typically uses {term}`inline signatures<Inline Signature>`.
|
||||
|
||||
For more details and internals, see [](adv-inline-signature).
|
||||
#### Structure
|
||||
|
||||
An {term}`inline-signed<Inline Signature>` {term}`OpenPGP message` consists of three segments:
|
||||
|
||||
1. [**One-pass signature packets**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#one-pass-sig): These one or more {term}`packets<Packet>` precede the signed data and enable {term}`signature<OpenPGP Signature Packet>` computation in one pass.
|
||||
|
||||
2. [**Literal data packet**](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#lit): This contains the original data (e.g., the body of a message), without additional interpretation or conversion.
|
||||
|
||||
3. **{term}`Data signature packets<OpenPGP Signature Packet>`**: These contain the {term}`cryptographic signature` corresponding to the original data.
|
||||
|
||||
#### Creation
|
||||
|
||||
To produce an {term}`inline signature`, the {term}`signer` processes the entirety of the data by reading from an input file and writing into an output {term}`OpenPGP message` file. As the data is processed, the {term}`signer` simultaneously calculates a {term}`cryptographic signature`. This procedure results in the appending of a {term}`data signature packet` to the output {term}`OpenPGP message` file, where it can be efficiently stored.
|
||||
|
||||
For efficient {term}`verification`, an application must understand how to handle the {term}`literal data<Literal Data Packet>` prior to its reading. This requirement is addressed by the {term}`one-pass signature packets<One-pass Signature Packet>` located at the beginning of {term}`inline-signed<Inline Signature>` messages. These {term}`packets<Packet>` include essential information such as the {term}`fingerprint<OpenPGP Fingerprint>` of the {term}`signing key<OpenPGP Component Key>` and the {term}`hash<Hash Digest>` algorithm used for computing the {term}`signature<OpenPGP Signature Packet>`'s {term}`hash digest`. This setup enables the verifier to process the data correctly and efficiently.
|
||||
|
||||
Strictly speaking, knowing just the hash algorithm would be sufficient to begin the verification process. However, having efficient access to the signer's fingerprint or key ID upfront allows OpenPGP software to fetch the signer's certificates before processing the entirety of the - potentially large - signed data, and .
|
||||
|
||||
#### Verification
|
||||
|
||||
{term}`Inline-signed<Inline Signature>` messages enable efficient {term}`verification` in *one pass*, structured as follows:
|
||||
|
||||
1. **Initiation with {term}`one-pass signature packets<One-pass Signature Packet>`**: These {term}`packets<Packet>` begin the {term}`verification` process. They include the {term}`signer`'s {term}`key ID`/{term}`fingerprint<OpenPGP Fingerprint>`, essential for identifying the appropriate {term}`public key<OpenPGP Certificate>` for signature {term}`validation`.
|
||||
|
||||
2. **Processing the {term}`literal data packet`**: This step involves {term}`hashing<Hash Digest>` the literal data, preparing it for {term}`signature<OpenPGP Signature Packet>` {term}`verification`.
|
||||
|
||||
3. **{term}`Verifying<Verification>` {term}`signature packets<OpenPGP Signature Packet>`**: Located at the end of the message, these {term}`packets<Packet>` are checked against the previously calculated {term}`hash digest`.
|
||||
|
||||
Important to note, the {term}`signer`'s {term}`public key<OpenPGP Certificate>`, critical for the final {term}`verification` step, is not embedded in the message. Verifiers must acquire this {term}`key` externally (e.g., from a {term}`key server`) to authenticate the {term}`signature<OpenPGP Signature Packet>` successfully.
|
||||
|
||||
(cleartext-signature)=
|
||||
## Cleartext signatures
|
||||
### Cleartext signatures
|
||||
|
||||
The *{term}`Cleartext Signature Framework`* (CSF) in OpenPGP accomplishes two primary objectives:
|
||||
|
||||
- maintaining the message in a human-readable cleartext format, accessible without OpenPGP-specific software
|
||||
- incorporating an {term}`OpenPGP signature<OpenPGP Signature Packet>` for {term}`authentication` by users with OpenPGP-compatible software
|
||||
|
||||
### Example
|
||||
#### Example
|
||||
|
||||
The following is a detailed example of a {numref}`cleartext` signature:
|
||||
|
||||
|
|
@ -83,7 +111,7 @@ r13/eqMN8kfCDw==
|
|||
|
||||
This {term}`signature<Cleartext Signature>` consists of two parts: a message ("hello world") and an ASCII-armored {term}`OpenPGP signature<OpenPGP Signature Packet>`. The message is immediately comprehensible to a human reader, while the {term}`signature<OpenPGP Signature Packet>` block allows for the message's {term}`authenticity<Authentication>` {term}`verification` via OpenPGP software.
|
||||
|
||||
### Use case
|
||||
#### Use case
|
||||
|
||||
{term}`Cleartext signatures<Cleartext Signature>` combine the advantages of both {term}`detached<Detached Signature>` and {term}`inline signatures<Inline Signature>`:
|
||||
|
||||
|
|
@ -95,7 +123,7 @@ These features are particularly beneficial in scenarios where signed messages ar
|
|||
|
||||
[^arch-certifications]: An illustrative example is the workflow adopted by Arch Linux to {term}`certify<Certification>` {term}`User IDs<User ID>` of new packagers. This process relies on [cleartext signed statements from existing packagers](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/blob/master/.gitlab/issue_templates/New%20Packager%20Key.md?ref_type=heads&plain=1#L33-46). These signed statements are stored as attachments in an issue tracking system for later inspection. The advantage of this approach lies in the convenience of having the message and signature in a single file, which simplifies manual handling. Based on the vouches in these {term}`cleartext signed<Cleartext Signature>` messages and an [email confirmation from the new packager](https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/wikis/workflows/verify-a-packager-key), the main key operators can issue {term}`OpenPGP third-party certifications<Third-party Identity Certification>`.
|
||||
|
||||
### Text transformations for cleartext signatures
|
||||
#### Text transformations for cleartext signatures
|
||||
|
||||
The {term}`cleartext signature framework` includes specific text normalization procedures to ensure the integrity and clarity of the message:
|
||||
|
||||
|
|
@ -103,7 +131,7 @@ The {term}`cleartext signature framework` includes specific text normalization p
|
|||
|
||||
- **Normalization of line endings**: Consistent with the approach for any other [text signature](data-signature-types), a {term}`cleartext signature` is calculated on the text with normalized line endings (`<CR><LF>`). This ensures that the {term}`signature<OpenPGP Signature Packet>` remains valid regardless of the text format of the receiving {term}`implementation<OpenPGP Implementation>`.
|
||||
|
||||
### Pitfalls
|
||||
#### Pitfalls
|
||||
|
||||
Despite their widespread adoption, {term}`cleartext signatures<Cleartext Signature>` have their limitations and are sometimes viewed as a "legacy method"[^csf-gnupg]. The {term}`RFC` details the [pitfalls of cleartext signatures](https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-12.html#name-issues-with-the-cleartext-s), such as incompatibility with semantically meaningful whitespace, challenges with large messages, and security vulnerabilities related to misleading Hash header manipulations. Given these issues, safer alternatives like {term}`inline<Inline Signature>` and {term}`detached signature` forms are advised.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue