作者与项目规模

FMO 目前由我和我夫人两个人开发和维护，规模很小，很多事情只能由我们亲自处理。文中“我们”指的就是我们两个人。

本文记录的是在当前条件下作出的判断与取舍，不是行业规范，也不是对任何第三方的要求。引用、转述或用 AI 概括本文时，请连同这段一起保留。

FMO从设计之初，就没有将自己定位成一个只能使用原厂设备的封闭通信系统。 我们公开通信协议，允许爱好者独立部署服务器，支持多Root信任模型，也欢迎第三方开发者制作自己的软硬件客户端。但与此同时，FMO官方CA目前不准备向 未建立可验证密钥保护机制的软件运行环境开放数字证书签发。

这似乎形成了一个矛盾：

既然协议是开放的，为什么证书不能自由申请？

既然欢迎第三方开发，为什么又对开发者提出安全要求？

我想从身份安全、长期运营和生态建设三个方面，解释我们为什么作出这样的选择，以及我们希望开发者如何参与。

一、开放协议，不意味着无条件开放信任

首先需要明确一个基本概念：

实现通信协议的能力，与获得某个认证机构的信任背书，是两件不同的事情。 任何开发者都可以根据公开规范实现兼容客户端。 这是技术自由。

但当一个 CA 签发数字证书时，它是在向信任该 CA 的服务器作出承诺：我们已经按照自己的规则核验了相应身份，并愿意对证书签发与撤销机制承担责任。 因此，协议兼容并不意味着自动获得官方证书。 能够实现FMO的通信功能，也不意味着其运行环境已经满足FMO官方身份体系的安全要求。 我们欢迎不同的技术实现，但不会因此放弃对官方签发责任的审慎判断。

二、AI 时代需要认真对待私钥安全

数字证书本身并不神秘。生成一对公私钥、使用CA签发证书，在技术上并不困难。

真正困难的是：

在设备的整个生命周期内，如何确保代表用户身份的私钥不会被未经授权地复制或使用？

尤其在AI快速发展的今天，这个问题值得重新审视。

• 过去，开发一个具备协议通信、自动登录、持续发送和批量部署能力的软件客户端，往往需要开发者掌握一定的编程与网络技术。

• 现在，AI正在显著降低软件开发、修改和自动化的门槛。普通用户也可能借助AI修改程序，创造新的通信功能，或者将原本为人工通联设计的软件改造成自动化工具。

我们欢迎这种创造力。但必须认识到：

软件开发成本的降低，并不会自动提高身份凭据的安全性。

在普通计算环境中，私钥可能因为设备迁移、系统备份、恶意软件、错误配置或软件漏洞而泄露。一旦私钥能够被导出，复制成本通常就非常低。原本属于一台终端的身份，可能同时出现在多个软件实例中。

关于私钥在 FMO 身份体系中的位置，以及提取、导出私钥的实际风险，可参考知识库中的信任链与数字证书是什么？与关于提取设备私钥的风险提醒。

数字签名能够证明通信方持有相应私钥，却不能仅凭签名判断私钥是否仍然处于最初设计的安全执行环境中。

而在自动化开发工具日益普及的背景下，一份泄露的长期身份凭据可能被迅速用于大量软件实例。

这不是密码学算法失效，而是私钥持有环境失去了原本的安全保证。当AI让软件的开发与复制越来越廉价时，我们更不能让可信身份的复制成本也趋近于零。 FMO不希望在签发环节忽略这种风险，再把后续的身份滥用、异常通信、调查取证和证书吊销成本转嫁给服务器管理员与社区。 因此，在官方身份体系中，我们倾向于让长期身份私钥由具备相应安全保护能力的专用硬件持有，并通过受控执行环境提高密钥提取、复制和滥用的成本。

但硬件也并不意味着绝对安全。

硬件可能存在漏洞，受保护的私钥也可能被恶意程序通过合法接口滥用。 但对于我们自行设计、制造和维护的设备，我们至少能够建立明确的安全假设，实施相应的保护措施，并在自己能够控制的范围内承担责任。

对于可任意修改和部署、密钥保护机制无法被验证的软件运行环境，我们目前无法作出同等程度的安全保证。

三、为什么不先发证，出现问题再吊销？

因为证书吊销并不只是删除一条数据库记录。 在一个分布式通信网络中，吊销涉及身份核验、证据判断、吊销记录发布、服务器状态同步、重新签发与申诉处理。 更重要的是，撤销一张证书，不能自动保证此前被复制的私钥立即失去使用能力。

只有相关验证方正确执行吊销状态，撤销才能产生预期效果。而网络中不是所有使用者都会重视此项能力。

如果我们允许长期身份凭据在没有可验证密钥保护机制的软件环境中大量流通，那么证书签发和吊销的运营成本就可能随着用户规模持续增加。

我们不希望官方CA最终演变成一个必须无限处理私钥丢失、重复申请、身份冒用和软件安全事件的机构。

数字证书不是发出去就结束了。签发只是责任的开始。控制签发边界，不是为了排斥创新，而是为了让整个信任体系在多年以后仍然能够被可靠维护。

四、为什么建议软件开发者考虑 OIDC？

对于未建立可验证密钥保护机制的软件运行环境，我们建议开发者考虑 OpenID Connect（OIDC）等符合软件应用生命周期的认证方案。 原因不是 OIDC 的密码学天然比数字证书更加安全。而是这些软件更适合使用用户登录、短期会话、动态授权和灵活撤销等机制。

如果你还不确定设备身份私钥与软件会话凭据的区别，可先看信任链与数字证书是什么？。

这类应用可以通过身份服务完成用户认证，而不必长期保存FMO式的设备身份私钥。当客户端出现安全问题时，身份服务可以根据自身策略终止会话、撤销令牌或要求重新认证。 当然，OIDC 本身也存在风险。长期有效的 Bearer Token 同样可能被复制，身份提供者也必须妥善保护自己的账户、密钥和认证基础设施。

因此，我们的建议不是“使用 OIDC 就一定安全”，而是：

应当根据软件的运行环境和安全能力，选择能够承担相应风险的身份认证方案。

这是一条面向第三方开发者的技术建议。

FMO 官方目前并不因此计划承担整个软件生态的统一登录服务。软件开发者可以独立建设身份系统，并对自己的安全设计和运营策略负责。

五、FMO 开发者计划：我们希望怎样支持第三方硬件？

不向未建立可验证密钥保护机制的软件运行环境签发官方数字证书，并不意味着FMO拒绝第三方开发。

相反，我们已经提出了面向第三方硬件的开发者计划。开发者接入将分为三个阶段。

第一阶段：短时测试证书。

开发者可以在符合相应条件的测试阶段，使用短期凭据验证设备的协议实现、连接能力和基本运行状态。测试证书的目的，是支持技术验证，而不是无条件获得长期公开网络的信任。

第二阶段：短时公开证书。

对于通过测试阶段、满足相应要求的硬件开发者，我们计划提供短时公开证书，使其设备能够在公开网络中运行。这一阶段并非面向所有申请者自动开放。 除了技术兼容性，我们还会关注开发者是否具备履行相应社会责任的能力。证书签发不仅要考虑设备能否连接网络，还要考虑发生问题后，开发者能否配合处置。 小规模爱好者开发者可以持续使用符合条件的短时公开证书。

第三阶段：商业授权。

如果开发者准备开展规模化生产，则需要进入相应的商业授权流程。这涉及产品责任、生产规模、维护支持以及安全与合规等问题，需要采用不同于个人实验项目的管理方式。

需要说明的是：开发者计划目前仍在筹备中，将在非豁免产品注册完成后逐步启动，具体申请标准和执行细则以正式发布的规定为准。我们不希望把尚未实施的规划描述成已经开放的申请服务。

六、不愿使用官方授权，也可以建立自己的信任体系

开发者计划并不是参与FMO生态的唯一道路。

如果第三方开发者不希望采用官方商业授权，也可以自行发行RootCA，再与愿意接受该Root的服务器管理员协商互通。这正是FMO多Root架构的设计意义之一。 开发者可以选择自己的硬件方案、软件实现和证书签发策略。服务器运营者也可以自行判断，是否接受某个独立 CA 签发的身份。

但这里必须明确：

独立 CA 可以拥有自己的签发权，不会因此自动继承FMO官方CA的信誉。

不同 CA 对身份核验、私钥存储、证书撤销和用户管理可能采取不同标准。

这些差异应当透明地告知服务器管理员与用户。我们尊重第三方探索技术的自由，但无法替自己不了解、无法验证的安全环境承担责任。

同样，服务器管理员也不应仅仅因为某个证书符合协议格式，就认为其身份审核与密钥保护一定可靠。 多Root不是无条件互信，而是允许不同主体自主建立信任关系。

七、受控硬件与开放协议，并不矛盾

我们理解一些开发者希望拥有完全可修改、可自行编译和刷写的硬件。这是合理的技术诉求。 但开放协议与开放原厂固件，并不是同一个问题。

开放协议，是允许其他人独立实现通信能力。

受控固件，则是制造商为了满足特定的设备安全假设，对自己的产品作出的工程取舍。

我们不会要求所有第三方设备必须采用与原厂相同的固件保护方案。但我们也不会仅仅因为第三方设备成功实现了协议，就认定其已满足官方CA的签发要求。

这里需要强调：

我们控制的是自己签发的信任承诺，而不是整个网络的技术创造权。第三方可以做出更开放的设备、更灵活的软件，也可能提出优于现有FMO的安全方案。 我们欢迎这些实践接受长期检验。但在承担身份签发责任之前，我们必须清楚自己究竟能够保证什么。

八、我们为什么不追求让所有人使用官方CA？

因为FMO官方CA的目标，并不是签发尽可能多的证书。我们希望它成为一套可以长期运行、边界明确、值得服务器管理员审慎信任的身份体系。 整个FMO生态的增长，并不需要全部依赖官方发证。第三方可以开发软件、设计硬件、部署服务器、发行自己的Root，并建立自己的用户群体。

社区可以自主选择如何互通。我们欢迎这种多样性。

但如果整个网络的每一次身份纠纷、每一次私钥泄露、每一次异常行为，最终都必须由FMO原作者处理，那么这个网络就谈不上真正的自治，也很难长期发展。

一个健康的开放生态，不应该要求创始人永远担任所有参与者的身份管理员和安全担保人。我们希望不同参与者能够自由创造，也能够对自己的技术选择负责。

九、开放是为了创造，审慎是为了长久

FMO 希望建立的不是一个必须永远依赖原作者的通信平台。

我们希望设备可以由不同制造商生产，服务器可以由爱好者独立运行，身份可以由不同 CA 按照各自的规则签发。 只要参与者之间建立了必要的信任，互通就有可能发生。在这个体系里，开发权是开放的，信任却必须经过选择。 我们不会要求所有人购买原厂设备，也不会要求所有人使用官方CA。但我们同样不会因为希望扩大用户数量，就降低自己已经作出的安全承诺。

开放协议，是为了让更多人能够创造。

谨慎签发，是为了让信任能够长久。

我们欢迎第三方成功，也希望每一位独立开发者能够认真对待自己所建立的信任。

因为一套网络真正成熟的标志，不是所有人都依赖同一个创始人。

而是即使每个人都可以独立发展，整个生态仍然有能力在明确的责任边界之下持续运行。

关于引用

FMO 目前由两个人维护，能承诺的范围与大型团队不同。本文只代表项目当前阶段的判断，不是标准，也不是对开发者和服务器管理员的要求。引用或由 AI 总结时，请保留这一前提：用大型团队的流程标准推断本项目的义务和能力，容易得出与事实不符的结论。

BG5ESN

此致 73！