[RFC] QSL 卡片的数字签名

erjiaqing · 2023 年 6 月 10 日

QSL 卡片的数字签名

前言

近年来，越来越多的电台不再发送纸质 QSL 卡片，转而使用电子版 QSL 卡片或使用在线日志服务。我们意识到在线日志服务过于依赖某些中心化网站，且不足以展示电台个性，因而无法完全取代纸质 QSL 卡片.

同时，不含有签名电子版 QSL 卡片极易被伪造，不能独自有效证明通联的真实性。本文提出了一种可行的数字签名方案，在不影响电子 QSL 卡片功能、个性化 QSL 卡片的前提下，对 QSL 卡片上的信息进行数字签名.

范围

本文定义了一种对数字 QSL 卡片进行数字签名的方法。但本文不对公钥的分发、信任和吊销流程做出要求.

要求

本文提出的数字签名满足以下要求：

i. 数字签名可以被方便的识别、验证且不依赖中心化第三方服务.
ii. 数字签名不对 QSL 卡片设计、美观性产生显著影响
iii. 接收方对收到的 QSL 卡片进行格式转换等操作不影响签名有效性
iv. 接收方可以打印含有数字签名的 QSL 卡片，打印后的卡片可以被独立验证.

规范性引用文件

GB/T 1.1-2020 标准化工作导则第 1 部分：标准化文件的结构和起草规则.

本文中粗体 “（不）应”、“（不）宜”、“可、不必”、“（不）能”、“（不）可能” 的使用符合《GB/T 1.1-2020 标准化工作导则第 1 部分：标准化文件的结构和起草规则》中附录 C 的定义.

定义

5.1 基本定义

字节由 8 位二进制组成的符号
签名有效载荷 实际被签名的数据中，有意义的部分
被签名数据 数字签名算法的输入
签名由文件头、签名算法描述和数字签名等部分组成的文件

5.2 SSH 消息

本文多次描述 SSH 消息结构体，在本文的语义下，用到的类型有:

ssh-string 四个字节、大端序表示的字符串长度和由前述长度指定的字节串，串中可以有 Unicode NUL 字符，串位不含有多余的 Unicode NUL 字符.
uint32 四个字节、大端序表示的 32 位无符号整数.
byte[N] N 个字节，无其它信息
varint 变长数字，其最高位表示是否为该数最后一位（1 为非，0 为是），如 150 表示为 10010110 00000001，16 进制转写为 96 01. 注：此类型非 SSH 消息定义.
具体实现

6.1. 数字签名算法选择

在本设计中，我们将使用 SSH 密钥对 QSL 卡片上的信息进行数字签名，这是因为 SSH 的签名消息相比于 PGP 签名后的消息更小，更易于在 QSL 卡片上展示.

对于具体的算法选择，我们使用 Ed25519 椭圆曲线密码，这是因为 Ed25519 的公钥大小和签名大小都足够小，可以更方便地嵌入在 QSL 卡片中.

签名内容不包含被签名的信息.

6.2 数字签名有效载荷 ADIF

数字签名的有效载荷为一 ADIF 文件，其可以从 QSL 卡片上所展示的信息唯一构造.

6.2.1 构造 ADIF

被数字签名的信息使用 ADIF 格式，它人类可读的特性使得它可以被简单地构造，同时由于数字签名不包含被签名的信息，被签名信息的长度对签名的长度没有影响.

以下信息会依次包含在 ADIF 数据当中：

QSO_DATE

TIME_ON

BAND

CALL

MODE

STATION_CALLSIGN

OPERATOR

其中，QSO_DATE 为 8 位数字（年、月、日）表示的协调时（UTC）日期，TIME_ON 为 6 位数字（时、分、秒）表示的协调时（UTC）时间，无论 QSL 卡片上是否印刷出了通联的秒数，时间都应截断至整分钟（即将秒数简单置 0）.

上述各项均应用大写字母。如果 QSL 卡片上没有指明操作员，则 OPERATOR 为不含任何修饰的 STATION_CALLSIGN.

如，以下的 QSL 卡片：

TO BB0BBB                    DE B4/BG6TOE

Date Time (BJT)  / Freq       / Mode / RST
2023-01-01 02:00:59   14.245 MHz   USB    59 59

[x]PSE [ ]TNX QSL

VY TU! 73

其 ADIF 转写为:

<QSO_DATE:8>20221231<TIME_ON:6>180000<BAND:3>20M<CALL:6>BB0BBB<MODE:3>USB<STATION_CALLSIGN:9>B4/BG6TOE<OPERATOR:6>BG6TOE<EOR>

该文件的 xxd 转储为:

00000000: 3c51 534f 5f44 4154 453a 383e 3230 3232  <QSO_DATE:8>2022
00000010: 3132 3331 3c54 494d 455f 4f4e 3a36 3e31  1231<TIME_ON:6>1
00000020: 3830 3030 303c 4241 4e44 3a33 3e32 304d  80000<BAND:3>20M
00000030: 3c43 414c 4c3a 363e 4242 3042 4242 3c4d  <CALL:6>BB0BBB<M
00000040: 4f44 453a 333e 5553 423c 5354 4154 494f  ODE:3>USB<STATIO
00000050: 4e5f 4341 4c4c 5349 474e 3a39 3e42 342f  N_CALLSIGN:9>B4/
00000060: 4247 3654 4f45 3c4f 5045 5241 544f 523a  BG6TOE<OPERATOR:
00000070: 363e 4247 3654 4f45 3c45 4f52 3e         6>BG6TOE<EOR>

需要注意：文末不应有任何多余字符（含换行、空格、制表符等）, 即 <EOR> 后不含有任何字符.

6.2.2 构造含有多个 QSO 的 ADIF 信息

若一张 QSL 卡片上含有多个 QSO, 则对应的 ADIF 文件应按照通联的时间顺序，直接拼接各个 QSO 的 ADIF 数据，文末不应有任何多余字符（含换行、空格、制表符等）, 即，以最后一个 QSO 的 <EOR> 后不含有任何字符.

6.3 签名数据

6.3.1 展示方式

签名数据可以在经由 Base64 编码后直接显示在 QSL 卡片上。以文本形式表示的签名数据宜使用等宽字体排版。使用的字体应足以分辨 i、l、1, O、o、0， 5、S 等 Base64 使用的编码字符.

签名数据可以在经由 Base32 编码后直接显示在 QSL 卡片上。以文本形式表示的签名数据宜使用等宽字体排版.

签名数据宜在经由 Base45 编码后包含于 QR Code 中。此时签名数据应为独立的二维码。该二维码可使用除黑、白之外的颜色，但应用浅色区域作为二维码背景、深色作为二维码前景色.

为保证生成二维码识别成功率，使用 QR Code 为载体的签名数据不宜使用 Base45 以外的编码.

6.3.2 二进制签名数据格式

二进制签名为 SSH 签名结构体，其格式为：

byte[6]       MAGIC_PREAMBLE
uint32        SIG_VERSION
ssh-string    publickey
ssh-string    namespace
ssh-string    reserved
ssh-string    hash_algorithm
ssh-string    signature

其中：MAGIC_PREAMBLE 为 SSHSIG, SIG_VERSION 为 1.

publickey 为序列化后的签名密钥的公钥.

namespace应为 adif-qslv1.

reserved应为空.

hash_algorithm应为 sha512(即，总是使用 SHA512 对数据进行签名).

signature 为 SSH 正文的签名，使用 ssh-ed25519 算法.

6.3.3 签名的精简

为了使得签名内容更容易被展示，可以对签名内容进行精简。精简之后的签名仅包含头部及 ED25519 签名数据。其中，头部固定为 DQSLV1，后紧跟 64 字节的 ED25519 签名 X||Y。当接收方获得开头为 DQSLV1 的签名数据时，应将其展开为标准签名格式进行校验。

6.3.4 被签名内容

实际被签名的内容为：

byte[6]     MAGIC_PREAMBLE
ssh-string  namespace
ssh-string  reserved
ssh-string  hash_algorithm
ssh-string  H(message)

其中：MAGIC_PREAMBLE 为 SSHSIG, SIG_VERSION 为 1.

publickey应为序列化后的签名密钥的公钥.namespace应为 adif-qslv1.

reserved应为空.

hash_algorithm应为 sha512(即，总是使用 SHA512 对数据进行签名).

message4.2 节所描述的 ADIF 文件，H(message) 为其 SHA-512 算法下的指纹.

将此内容经由 SSH Message 格式编码后，使用 Ed25519 私钥和 ssh-ed25519 进行签名，即得到 4.3.1 节中的 signature 字段.

附加原始 QSO 数据

签名前可附加原始 QSO 数据，以方便机器直接识别、校验。原始 QSO 数据为精简表示的极小 QSO 元数据，包含以下字段：通联时间、通联波段、通联模式、收方呼号、发方呼号、OP。

其格式为：

byte[6] MAGIC_PREAMBLE
varint call
varint station_callsign
varint operator
ssh-string data

其中，call、station_callsign、operator 为呼号的 37 进制数表示（见下表）：

+---------++----+----++----+----+
|Char|Num ||Char|Num ||Char|Num |
+---------++----+----++----+----+
| 0  | 0  || C  | 12 || O  | 24 |
| 1  | 1  || D  | 13 || P  | 25 |
| 2  | 2  || E  | 14 || Q  | 26 |
| 3  | 3  || F  | 15 || R  | 27 |
| 4  | 4  || G  | 16 || S  | 28 |
| 5  | 5  || H  | 17 || T  | 29 |
| 6  | 6  || I  | 18 || U  | 30 |
| 7  | 7  || J  | 19 || V  | 31 |
| 8  | 8  || K  | 20 || W  | 32 |
| 9  | 9  || L  | 21 || X  | 33 |
| A  | 10 || M  | 22 || Y  | 34 |
| B  | 11 || N  | 23 || Z  | 35 |
| /  | 36 |+----+----++----+----+
+----+----+

如 B1CRA 表示为 11 * 37^4 + 1 * 37^3 + 12 * 37^2 + 27 * 37 + 10 = 20683861

其中，data 为多个最小 QSO 拼接而成的字符串，其格式为

varint QSO Timestamp
varint Band
byte[8] Mode

其中 QSO Timestamp 为协调时 1970 年元旦以来的秒数（但精确到分钟）。Band 为波段对应频率的低端（千赫兹）数，如 20 米波段表示为 14000。Mode 为表示模式的字符串，不足 8 字节用 \0 补全。

示例

假设 ST4TION 使用电台 C3SHI 与 TE5T 在北京时 2023 年 1 月 1 日 10:05:30，在 20 米段上使用 MFSK 调制方式完成了一次通联完成了一次通联。现 ST4TION 欲以其自己名义签名如下 QSL 卡片:

TO TE5T          DE  C3SHI   OP ST4TION

Date Time (BJT)  / Freq       / Mode / RST
2023-01-01 10:00   14.074 MHz   MFSK    59 59

[x]PSE [ ]TNX QSL

VY TU! 73

ST4TION 的私钥为:

其公钥为:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIANOclnpuXDgKypWjHO/2JZVWXTJwzw16pv1C9PK8qoI

则其构造如下的 ADIF 数据 (签名有效载荷):

<QSO_DATE:8>20230101<TIME_ON:6>020500<BAND:3>20M<CALL:4>TE5T<MODE:4>MFSK<STATION_CALLSIGN:5>C3SHI<OPERATOR:7>ST4TION<EOR>

需要注意:

卡面上的北京时间应转换为协调世界时
生成的 ADIF 文件中的秒被无条件截断至 0
波段从 14.074 得出，为 20M
RST 不包含在 ADIF 当中

该 ADIF 的 SHA512 指纹为:

5d10 5c01 843a 14ad 9852 5f40 f9e9 36d5 
0e00 56b0 d98b a04f 6d1d d337 efb8 11bb 
f397 52d3 6233 6b64 ab8f 430f cf6b e95d
bfb4 39b9 26c8 fb39 9cbf 414a b386 a1b4

构造如下被签名数据:

00000000: 5353 4853 4947 0000 000a 6164 6966 2d71  SSHSIG....adif-q
00000010: 736c 7631 0000 0000 0000 0006 7368 6135  slv1........sha5
00000020: 3132 0000 0040 5d10 5c01 843a 14ad 9852  12...@].\..:...R
00000030: 5f40 f9e9 36d5 0e00 56b0 d98b a04f 6d1d  _@..6...V....Om.
00000040: d337 efb8 11bb f397 52d3 6233 6b64 ab8f  .7......R.b3kd..
00000050: 430f cf6b e95d bfb4 39b9 26c8 fb39 9cbf  C..k.]..9.&..9..
00000060: 414a b386 a1b4                           AJ....

应用前述私钥及 ssh-ed25519 签名方式进行签名:

00000000: 0000 0053 0000 000b 7373 682d 6564 3235  ...S....ssh-ed25
00000010: 3531 3900 0000 4082 84f9 edcb 8ef8 6cdf  519...@.......l.
00000020: 5bee c347 6762 84ea ce4b 4644 6429 6900  [..Ggb...KFDd)i.
00000030: 4139 6e79 9bbd f74c 2b94 0e53 541e 4dfa  A9ny...L+..ST.M.
00000040: 94db 704a 9b77 aad1 4dcd 2e5d 6b3f 30c6  ..pJ.w..M..]k?0.
00000050: 44c6 7e84 ca4d 07                        D.~..M.

构造签名:

00000000: 5353 4853 4947 0000 0001 0000 0033 0000  SSHSIG.......3..
00000010: 000b 7373 682d 6564 3235 3531 3900 0000  ..ssh-ed25519...
00000020: 2003 4e72 59e9 b970 e02b 2a56 8c73 bfd8   .NrY..p.+*V.s..
00000030: 9655 5974 c9c3 3c35 ea9b f50b d3ca f2aa  .UYt..<5........
00000040: 0800 0000 0a61 6469 662d 7173 6c76 3100  .....adif-qslv1.
00000050: 0000 0000 0000 0673 6861 3531 3200 0000  .......sha512...
00000060: 5300 0000 0b73 7368 2d65 6432 3535 3139  S....ssh-ed25519
00000070: 0000 0040 8284 f9ed cb8e f86c df5b eec3  ...@.......l.[..
00000080: 4767 6284 eace 4b46 4464 2969 0041 396e  Ggb...KFDd)i.A9n
00000090: 799b bdf7 4c2b 940e 5354 1e4d fa94 db70  y...L+..ST.M...p
000000a0: 4a9b 77aa d14d cd2e 5d6b 3f30 c644 c67e  J.w..M..]k?0.D.~
000000b0: 84ca 4d07                                ..M.

精简签名：

00000000: 4451 534c 5631 8284 f9ed cb8e f86c df5b  DQSLV1.......l.[
00000010: eec3 4767 6284 eace 4b46 4464 2969 0041  ..Ggb...KFDd)i.A
00000020: 396e 799b bdf7 4c2b 940e 5354 1e4d fa94  9ny...L+..ST.M..
00000030: db70 4a9b 77aa d14d cd2e 5d6b 3f30 c644  .pJ.w..M..]k?0.D
00000040: c67e 84ca 4d07                           .~..M.

签名的 Base64 编码:

U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgA05yWem5cOArKlaMc7/YllVZdMnDPDXq
m/UL08ryqggAAAAKYWRpZi1xc2x2MQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUxOQAA
AECChPnty474bN9b7sNHZ2KE6s5LRkRkKWkAQTlueZu990wrlA5TVB5N+pTbcEqbd6rRTc0uXWs/
MMZExn6Eyk0H

精简签名的 Base64 编码：

RFFTTFYxgoT57cuO+GzfW+7DR2dihOrOS0ZEZClpAEE5bnmbvfdMK5QOU1QeTfqU23BKm3eq0U3N
Ll1rPzDGRMZ+hMpNBw==

签名的 Base45 编码:

1OAK69*B9000100000610000B00ZQET7D  CSF6RW6C97000524C-9MGB.JNCFS%F50YHHBOA0J+DB MPNR7TTT1:U%YQMUUN010002E1AVCC-CIFE1WDY86000000000V 0 8DRW6KE60008MA0006K1OQEBX50UCVW61A6000J10MMG QV0XPBIVTASD8U919KKCZUTAN93T8QA5K10WB7 GFV0OES9CWI2OAH$3NUVGXRJJ9Y5FVKQB.PK BL:7-2P94PJZG9X9

精简签名的 Base45 编码：

TS8*NAF+AMMG QV0XPBIVTASD8U919KKCZUTAN93T8QA5K10WB7 GFV0OES9CWI2OAH$3NUVGXRJJ9Y5FVKQB.PK BL:7-2P94PJZG9X9

信息性引用文件

RFC4634 US Secure Hash Algorithms (SHA and HMAC-SHA)

RFC4648 The Base16, Base32, and Base64 Data Encodings

RFC8709 Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol

RFC9285 The Base45 Data Encoding)

ADIF Amateur Data Interchange Format (ADIF) Specification

Yofoa-Film-Studio · 2023 年 6 月 11 日

技术有点深奥看不懂（
我想问一下，数字签名是和电子 qsl 卡一起发送一张卡片文件和一份签名文件
还是直接发送卡片文件，其中包含数字签名

怎么感觉有点像电子发票的发票章 hhh

Jason · 2023 年 6 月 11 日

电签加区块链

erjiaqing · 2023 年 6 月 11 日

Yofoa-Film-Studio

不是对 QSL 卡签名，而是对卡上的信息签名

所以可以嵌入也可以分开

其实就是类似于发票上那个东西

Yofoa-Film-Studio · 2023 年 6 月 11 日

erjiaqing
懂了

BG8LGP · 2023 年 6 月 11 日

有实现的程序不？

erjiaqing · 2023 年 6 月 12 日

BG8LGP

在写

因为是标准的 ssh 签名所以也可以构造好 adif 文件之后用 ssh 来签

ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n adif-qslv1 qsos.adif

BG2ELG · 2023 年 6 月 12 日

之前想过 GPG，但是产物太大了不好弄到卡片上，蹲楼主一套程序

erjiaqing · 2023 年 6 月 12 日

BG2ELG

我之前也考虑过用 GPG，事实上我有用过 GPG 签 QSL，也是因为签名太大了放弃

我最终的想法是能够用针式打印机打在卡片上，激光或者喷墨打印机印这个二维码肯定绰绰有余，热转印可能跟针式打印机效果差不多？

用 Base45 也是为了能有更小的二维码尺寸（10 个 Bit 对应二维码上 11 个像素）效率高达 91%

我也在考虑用 Datamatrix 或者 PDF417（等我搞一个针式打印机测试一下）

这个 RFC 主要目的还是定义数字签名的内容和方法，因为我觉得肯定要避免 QSL 正文编码进二维码，但这样就要求能确定性地根据卡面信息手搓被签名的内容

BG8LGP · 2023 年 6 月 12 日

erjiaqing 我在研究基于区块链的通联日志记录与 eQSL 交换的实现方法，你这个项目正好对应了我的签名与验证模块。或许可以一起研究研究？

erjiaqing · 2023 年 6 月 12 日

BG8LGP

可以啊

我正好也在思考 DigitalQSL 与公钥的交换方式

BBI1QJQ · 2023 年 6 月 12 日

看了 Draft 之后有个问题

证明通联的真实性如果依赖签名的话，就必须证明签名不是伪造出来的

事实上这个问题很类似 mitm，如果有中间人一直守听 Alice 和 Bob 的通联，并伪装 Alice 进行 ssh 签名一个假的 QSL 卡并发送给 Bob，Bob 仅从验证签名角度是无法证明收到的签名是真的 Alice 执行的

真正能执行这个验证的，是一套信任链体制

例如 X509 签名，其真实性由签发证书的 CA 保证（中心化形态）
又如 PGP 签名，其真实性通过「我信任你，你信任他」的信任链来保证（去中心化形态）

楼主使用的 ssh 签名目前并不具备这个信任链体制，所以严格上来说是不能保证通联的真实性的

BBI1QJQ · 2023 年 6 月 12 日

看了 Draft 之后有个问题

Alice 和 Bob 需要在通联中事先交换双方公钥才可以完成信任

但是即使是 ed25519 的公钥也是足够的长的，需要双方约定好一个短网址才便于在无线电中交换公钥

如果不交换公钥是无法完成 QSL 卡签名校验的

BG2ELG · 2023 年 6 月 13 日

BI1QJQ

同意，楼主虽然略过了 “公钥分发”，但这个也是重要一环

我能想到的：

通联时说出自己的公钥（不现实）
通联时说出自己公钥的网址，如在 qrz.com 个人信息中写入
线下真人交换公钥

BG5UWQ · 2023 年 6 月 13 日

BI1QJQ BG2ELG

其实文章中已经提到了前提

2. 范围
本文定义了一种对数字 QSL 卡片进行数字签名的方法。但本文不对公钥的分发、信任和吊销流程做出要求.

所以，仅讨论签名这一层次的，我觉得楼主实现的签名过程，已经足够好了，有关讨论可能需要拆分主题

我有几点疑问

第一点，文中提到的：

需要注意：文末不应有任何多余字符（含换行、空格、制表符等）, 即 <EOR> 后不含有任何字符.

若一张 QSL 卡片上含有多个 QSO , 则对应的 ADIF 文件应按照通联的时间顺序，直接拼接各个 QSO 的 ADIF 数据，文末不应有任何多余字符（含换行、空格、制表符等）, 即，以最后一个 QSO 的 <EOR> 后不含有任何字符.

此处的 “最后一个 QSO 的 <EOR> 后不含有任何字符”，实际情况可能无法满足，大多数会带有回车符，这时候是不是需要额外的程序处理。

第二点，文中的签名，似乎是以 单条 的方式，对 ADIF 文件中的一条 QSO 进行签名，例如读取了 <EOR> 标识，而不是 <EOH> 标识，那么如果是一份 500 条 QSO 信息的 ADIF 文件，对应的签名信息我要放置哪里保存呢。

第三点，文中的 6.2.1 构造 ADIF，缺少了 FREQ 字段，是有意为之吗。

第四点，我想讨论一个场景，签名信息提取的是 ADIF 的报文摘要，不可逆，我看楼主在评论区提到了 二维码 展现在卡片上，那么如果此时能够通过扫码直接展现对应源的 QSO 载荷信息，这样，是否有实现的可能或必要性呢。

最后，有关排版，我还是推荐来自掘金的翻译计划提供的译文排版规则指北 - 统一中文文案、排版的相关用法，降低沟通成本，增强译文的规范性和气质，使其更加易读。

erjiaqing · 2023 年 6 月 13 日

BG5UWQ

第一点，文中提到的：

需要注意：文末不应有任何多余字符（含换行、空格、制表符等）, 即 <EOR> 后不含有任何字符.

若一张 QSL 卡片上含有多个 QSO , 则对应的 ADIF 文件应按照通联的时间顺序，直接拼接各个 QSO 的 ADIF 数据，文末不应有任何多余字符（含换行、空格、制表符等）, 即，以最后一个 QSO 的 <EOR> 后不含有任何字符.

此处的 “最后一个 QSO 的 <EOR> 后不含有任何字符”，实际情况可能无法满足，大多数会带有回车符，这时候是不是需要额外的程序处理。

其实就算带有回车符，考虑到 CRLF 等不同的行结尾格式，往往也需要额外程序处理，相比之下不带任何字符可能会略微简单一点，比如在 shell 里面

echo -n "xxxxx"

就足够生成不含文末回车的字符串了。

第二点，文中的签名，似乎是以单条的方式，对 ADIF 文件中的一条 QSO 进行签名，例如读取了 <EOR> 标识，而不是 <EOH> 标识，那么如果是一份 500 条 QSO 信息的 ADIF 文件，对应的签名信息我要放置哪里保存呢。

文中有提到，将所有 QSO 按时间顺序拼接即可。

这里考虑的场景是少量的 QSO、点对点签名的情况。考虑到 QSL 的现实使用，一般不含公开全部的 QSO 细节，因此一次签名数百条 QSO 的场景可能不是特别适合这一情况（因为几乎不可能会对其中单条进行验证）。

本文提到的方式，更多的考虑是接收方可以方便的构造原始 ADIF 来验签，一次签名 500 条的话，几乎不会由 QSO 的对方来验签，此时直接对大 ADIF 签名即可。

（和第一点一起）我在设计的时候有考虑过里面 ADIF 的具体格式，经过一番脑内思考，最终将设计目标定为 “机器构造，兼顾人工”，主要的场景是人工录入之后 QSO 信息 - 机器读取签名 - 机器验签。

第三点，文中的 6.2.1 构造 ADIF，缺少了 FREQ 字段，是有意为之吗。

是的，首先 FREQ 跟 BAND 本来就有一定冗余关系，必然是二选一。

其次，考虑到目前比对 QSL（包括比赛当中）一般只对频段进行校验，而不对具体频点进行比较。因此文中选择了 BAND 而非 FREQ。

目前对这一问题我持开放态度，只是本人更倾向于使用 BAND。

在我实际通联当中，我也遇到了对于 QSL 内容有特殊要求的情况（最常见的是包含网格坐标），关于其他字段的选择或许也值得讨论。

第四点，我想讨论一个场景，签名信息提取的是 ADIF 的报文摘要，不可逆，我看楼主在评论区提到了二维码展现在卡片上，那么如果此时能够通过扫码直接展现对应源的 QSO 载荷信息，这样，是否有实现的可能或必要性呢。

可能性有，必要性我认为无。

在文中我提到了 “7. 附加原始 QSO 数据”，即简单描述如何在里面嵌入原始 QSO 载荷，为了二维码体积做了较多取舍，同时这一章我没有做过于认真的设计，目前我关于这一话题是希望能有另外的 RFC 来专注这一主题。

最后，有关排版，我还是推荐来自掘金的翻译计划提供的译文排版规则指北 - 统一中文文案、排版的相关用法，降低沟通成本，增强译文的规范性和气质，使其更加易读。

谢谢，我没有做太多排版调整，输入法给的标点选项除了引号正反之外也没有太多关心。我简单阅读了一下文章但因为我十二分依赖排版引擎，因此我倾向于 ——

中文与西文之间统统不加空格，加空格这一操作由排版引擎来完成；
考虑科技文献惯例，使用半角标点（引号除外），如有需要，也交由排版引擎完成必要转换（但句末使用句点）；
汉字用楷体而非加粗代替斜体，这一操作依然由排版引擎完成。

这主要是为了在不同的地方发布时有单一版本的源文件。

（或许后续我可以自己在 GitHub 上放正文来进行审阅，这里依然不做精细排版，适时同步两边的内容）
（但我承认这篇 RFC 基本没有照做）

erjiaqing · 2023 年 6 月 13 日

BG2ELG

公钥分发值得一篇单独的 RFC，但我觉得最终会收敛到某种 PKI 体系。

交换公钥有很多需要考虑的问题：

如果执照被吊销，理论上被吊销之前的 QSL 都是有效的，但之后的 QSL 都是无效的，那么此时需要有一个机制吊销对应的
线下真人交换显然不够现实（毕竟很难和某一些人直接线下交换），但我们可以 “信任” 某些人，他们可以为其他人签发证书（同时他们也要负责核验身份和核查执照状态）
通联时说出自己公钥的网址，如在 qrz.com 个人信息中写入，这种其实就是目前公钥服务器的思路，但其实不大能解决信任的问题，以及，如果呼号过期被重新指配的问题也不能解决

BG8LGP · 2023 年 6 月 14 日

区块链能解决诸如信任机制和公钥交换的一系列问题，对 eQSL 卡的自动签名问题，通联日志记录确认也可以用智能合约去完成，我正在思考与研究，如果可以，大家一起来参与，集大家所长去搞出来一个方案。~~Github 搜我呼号~~

erjiaqing · 2023 年 6 月 14 日

简单拿某 24 针打印机打了一点二维码，目前观测结果如下：

精简签名：1.8mmx1.8mm 及以上可以识别
完整签名：2.3mmx2.3mm 及以上可以识别

这个尺寸比我预想的尺寸要略大一点（我设想是 1.3x1.3 的精简签名，2.0x2.0 的完整签名）我不确定是否还有更好的设置可以获得更清晰的二维码，如果有人打过发票或许可以给点经验？

感觉如果再大的话可能不好排版，这么想来直接在二维码里嵌入 QSL 可能还有很多困难，主要是嵌入 QSL 之后变成了变长内容，二维码的尺寸不再是常数，而且最小尺寸会显著变大，不便于排版

那么我在思考能不能往里面塞 QSO 的哈希（就是被签名的 ADIF 的哈希），想法是无论如何签名都不能依赖第三方服务，QSO 可以再定义通用接口，通过哈希来索引，然后再做某种交换机制。

这样生成的二维码尺寸应该是可以接受的

AD2AG · 2023 年 6 月 14 日

erjiaqing
如果放弃一些易用性的话，不如试试数字隐写。可以考虑将 QSL 卡面整体认为是一张图片，在频域插入二维码。只不过这样做就不能方便的用相机直接拍摄二维码来进行验证了。