一家公司在一次董事会会议三年后被出售，而那次会议已没有人记得清楚。买方律师要求提供批准某份许可协议的那项决议。翻出来的，是一份由一位早已离职的同事最后保存的 Word 文件，一份会后两个月才打印的 PDF，以及一封董事长要求对措辞做「一点小修改」的邮件。没有人能说清董事会批准的是哪个文本，也说不清是哪一天。大多数关于会议纪要的争议，都是这个样子。
债法典对会议纪要的要求
瑞士债法典 (OR) 在这一点上着墨不多。根据第 713 条第 2 款，董事会可以在有实际会场的会议上、以电子方式、或以纸质或电子形式的书面方式作出决议，除非有成员要求口头讨论。以电子方式作出的决议不需要签名，除非董事会以书面形式另有规定。第 3 款接着规定，董事会的讨论和决议应当作成会议纪要，由董事长和记录人签署。
对于股东大会，第 702 条第 2 款列出了会议纪要必须记载的内容：日期、开始和结束时间、会议形式和地点、出席代表的股份、决议和选举结果、信息查询请求及所作答复、要求记录在案的声明，以及重大技术问题。第 3 款要求记录人和董事长签署。第 4 款赋予任何股东在 30 天内要求查阅会议纪要的权利。
通过视频开会的董事会可以不签名就作出决议，但会议纪要仍由两位具名人员签署。多年之后的问题是：这份文件是不是那份签署过的记录，有没有被改动，以及它是什么时候产生的。
哪种电子签名算数
债法典第 14 条第 2bis 款回答了第一个问题。根据 联邦电子签名法 (ZertES)，合格电子签名与合格时间戳相结合，视同手写签名，但法律或合同另有规定的除外。打字输入的姓名，或粘贴进 PDF 的扫描签名，都不算。董事长和记录人各自需要一张由认可的服务提供者签发的合格证书，并在签名上附加合格时间戳。
封存后的文件带着什么
在 Swiss Trust Layer 上，会议纪要被上传到一个文件夹并封存。系统计算文件的加密指纹，然后把这个指纹（而不是文档本身）发送给合格信任服务提供者 Swisscom Trust Services，由其用一把从不离开其硬件的密钥签名。这个签名本身已经包含符合 RFC 3161 的时间戳，随后被嵌回 PDF。原始文件不会被改动。
正是这个时间戳解决了「何时」的问题。根据 eIDAS 条例第 41 条第 2 款，合格电子时间戳享有推定：它所标示的日期和时间是准确的，与该日期和时间绑定的数据是完整的。验证签名所需的证书和吊销信息也被嵌入 PDF，因此 PDF 阅读器会把该签名显示为 LTV-enabled。
两位签署人，一份文件
门户的多人签署流程正是为「董事长加记录人」这种情形设计的。封存文件夹的所有者（通常就是撰写纪要的人）输入对方的姓名、邮箱和电话号码，将其添加为签署人。PDF 上为两人各放置一个签名栏。所有者先签；随后第二位签署人收到邀请，用自己的合格签名签署。该版本的证明证书在所有者签署后即可获取，上面显示文件夹为谁封存，以及以 UTC 表示的封存日期和时间。
修改成为新版本，而不是覆盖
会议纪要往往先以草稿形式分发，经修改后在下次会议上批准。问题出在同一个文件被原地修改。在门户中，每个文件夹都有版本历史，修改稿或批准稿作为新版本添加，单独封存并出具证书。每个版本都可以附上备注，于是「会后分发的草稿」和「下次会议批准」各自挨着自己的时间戳。已签发版本的指纹永远不会改变。日后查看历史的人看到的是先后顺序，而不是关于顺序的一番说辞。
股东的 30 天，以及多年后的审计师
当股东行使第 702 条第 4 款赋予的权利时，把封存的 PDF 交给他。他无需注册账户，就可以把文件放进 swisstrustlayer.com/validate 的公开验证器。验证器检查签名链、签发证书的机构、证书有效期和时间戳完整性，并显示谁签了名、何时签的、用的哪张证书，以及签名后内容是否被修改。它能识别 eIDAS 和 ZertES 两种体系下的合格签名。验证器只处理签名元数据，不存储文档，这在纪要本身属于机密时尤为重要。多年以后，审计师拿着同一份文件做同样的事。
封存不能证明什么
封存证明的是：这份一字不差的文本在那一刻存在，并且此后没有改变。它不能证明会议召集合法，也不能证明决议在实体上有效。这些问题要靠会议通知和出席名单来回答，它们应与封存的纪要放在一起，而不是被它取代。时间戳也不能往回补。争议发生时才封存的纪要，带的是封存那天的日期，而不是开会那天的。
本周可以做的一件事
拿出你上一次董事会会议的批准版纪要，封存它，并让董事长和记录人通过多人签署流程签名。把封存后的 PDF 及其证书与公司档案一起保存。从下次会议起，在纪要获批的当天就这样做。完整机制见 工作原理。
在 Swiss Trust Layer 上封存你的第一份文件，让下一个问「哪个版本，什么时候」的人，拿到一份自己会作答的文件。
