大家好，并提前感谢您的帮助。
我的目标是让两个或更多不同的人逐步处理文件：
第一个将创建xml，只编译文档的一个子部分（根据他的角色），然后只签署他编译的内容。
第二个人将从第一个人那里获取文件并编译他的小节，而不修改第一个人写的任何内容。然后，他将添加他的签名，签署他的子章节和第一个人。
依旧......
我该怎么办？根据标准，XAdES特定的xml元素（例如用于签名的证书的ID）都在<object>元素内（在signed properties子元素中），在我看来，这意味着只有一个人可以一次签署对象（即文档），而不必覆盖签名数据。
我错了吗？如果有一种我没有考虑过的方法，有人可以帮助我吗？
谢谢，
一个。
答案 0 :(得分：1)
我的2美分......
这看起来是使用反签名的情况。
要确保只签署文档的某些部分，您必须使用参考中的xpath变换器。
第二个人将对前一个签名进行反号，并且您可能还需要添加引用（xpath？）他编辑的新部分。
你有一些研究要做......
链接到xades4j的计数器签名示例： https://github.com/luisgoncalves/xades4j/blob/master/src/test/xml/document.signed.bes.cs.xml
编辑：
参见xades规范：ETSI TS 101 903 V1.4.2（2010-12） http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf 见第7.2.4章和附录C.
答案1） 我会说是的，正如规范所说： ＆＃34;应用程序可以添加其他ds：引用ds：SignatureValue元素的引用元素 以前存在的CounterSignature元素。这允许构建任意长的显式链 联署＆＃34;
答案2） 嗯，我想这是你的决定......关于副签名，他们说： ＆＃34;这个定义的唯一目的是作为签名的简单识别，实际上是一个签名。＆＃34; 因此，如果您认为更容易（在这里添加对您有意义的理由......）将其作为签名而非签名，您可以。
答案 1 :(得分：0)
我认为在签名元素中有更多引用是不可能的，因为我的反签名是先前签名的签名，但标准并没有禁止它，也许你是对的。谢谢。
其他考虑，只是为了确保我理解正确 1）随着计数器签名者数量的增长，将需要嵌套的签名元素，这对于ETSI标准是可行的 2）为什么创建了会签元素？是不是可能在同一容器节点内创建更多的签名元素，这些元素通过引用元素引用彼此和感兴趣的文本部分？我正在考虑你发布的例子，其中数据元素是内部附加的，并且只有一个签名：添加更多带有正确引用的签名元素将使我能够获得相同的行为或者存在我没有的限制确定了吗？
谢谢大家的贡献。
编辑：
答案1） 我会说是的，正如规范所说： “应用程序可以添加其他ds：引用ds：SignatureValue元素的引用元素 以前存在的CounterSignature元素。这允许构建任意长的显式链 联署“。
答案2） 嗯，我想这是你的决定......关于副签名，他们说： “这个定义的唯一目的是作为签名的简单识别，实际上是一个签名。” 因此，如果您认为更容易（在这里添加对您有意义的理由......）将其作为签名而非签名，您可以。
参见xades规范：ETSI TS 101 903 V1.4.2（2010-12） http://www.etsi.org/deliver/etsi_ts%5C101900_101999%5C101903%5C01.04.02_60%5Cts_101903v010402p.pdf
见第7.2.4章和附录C.